The first thing I wondered when I got my hands on the DE0-Nano was how best to communicate with a design inside the FPGA. Initially, I assumed that with the USB connection onboard there would be some form of UART connected to a few of the FGPA Pins. Unfortunately, this was not the case.

I sent an email to the creators of the DE0-Nano, terasIC asking how best to go about communicating with a design and their application engineer recommended adding a second USB connection with something like the FTDI 232RL USB to UART Bridge.

I was still convinced there had to be a more elegant way. Fortunately, I came across this post on the Altera forums talking about the Virtual JTAG interface. Thanks to those pointers from the ever helpful Dave, the seed was planted for the solution presented below.

Virtual JTAG Example – Blinky Lights

Download the Project Files

Download the project here:

vJTAG_DE0-Nano_Example.zip

Digital Design Files (Quartus Project)

Top Level

Top Level Schematic

vJTAG

vJTAG Block

The Megafunction User Guide has a great description for what this block is all about:

The virtual JTAG megafunction IP gives you direct access to the JTAG control signals routed to the FPGA core logic, which gives you a fine granularity of control over the JTAG resource. This opens up the JTAG resource as a general-purpose serial communication interface. A complete Tcl API is available for sending and receiving transactions into your device during runtime. Because the JTAG pins are readily accessible during runtime, this megafunction can be an easy way to customize a JTAG scan chain internal to the device, which can be used to create debugging applications.

vJTAG_interface

vJTAG_interface

In this case we configured the vJTAG to have a 1 bit wide instruction register (0 = Bypass, 1 = Capture New LED Output Settings).

Here is the verilog code for this block:

module vJTAG_interface (
	input tck, tdi, aclr, ir_in,v_sdr, udr,

	output reg [6:0] LEDs,
	output reg tdo

);

reg DR0_bypass_reg; // Safeguard in case bad IR is sent through JTAG
reg [6:0] DR1; // Date, time and revision DR.  We could make separate Data Registers for each one, but

wire select_DR0 = !ir_in; // Default to 0, which is the bypass register
wire select_DR1 = ir_in; //Data Register 1 will collect the new LED Settings

always @ (posedge tck or posedge aclr)
begin
	if (aclr)
	begin
		DR0_bypass_reg <= 1'b0;
		DR1 <= 7'b000000;
	end
	else
	begin
		DR0_bypass_reg <= tdi; //Update the Bypass Register Just in case the incoming data is not sent to DR1

		if ( v_sdr )  // VJI is in Shift DR state
			if (select_DR1) //ir_in has been set to choose DR1
					DR1 <= {tdi, DR1[6:1]}; // Shifting in (and out) the data

	end
end

//Maintain the TDO Continuity
always @ (*)
begin
	if (select_DR1)
		tdo <= DR1[0];
    else
		tdo <= DR0_bypass_reg;
end		

//The udr signal will assert when the data has been transmitted and it's time to Update the DR
//  so copy it to the Output LED register.
//  Note that connecting the LED's to the DR1 register will cause an unwanted behavior as data is shifted through it
always @(udr)
begin
	LEDs <= DR1;
end

endmodule

This code was developed and derived with the help of some examples from the Altera Wiki

Clock Blinker

clk_blinker

module clk_blinker (
	input clk,
	output blink
);
reg [25:0] count;
always @(posedge clk)
	count <= count + 1'b1;
assign blink = count[25];
endmodule

LED Connector

LED Connector

module LED_Connector(
	input [6:0]LEDs,
	output wire LED_6,
	output wire LED_5,
	output wire LED_4,
	output wire LED_3,
	output wire LED_2,
	output wire LED_1,
	output wire LED_0

);

assign LED_6 = LEDs[6];
assign LED_5 = LEDs[5];
assign LED_4 = LEDs[4];
assign LED_3 = LEDs[3];
assign LED_2 = LEDs[2];
assign LED_1 = LEDs[1];
assign LED_0 = LEDs[0];
endmodule

TCL TCP/IP Server

##############################################################################################
############################# Basic vJTAG Interface ##########################################
##############################################################################################

#This portion of the script is derived from some of the examples from Altera

global usbblaster_name
global test_device
# List all available programming hardwares, and select the USBBlaster.
# (Note: this example assumes only one USBBlaster connected.)
# Programming Hardwares:
foreach hardware_name [get_hardware_names] {
#	puts $hardware_name
	if { [string match "USB-Blaster*" $hardware_name] } {
		set usbblaster_name $hardware_name
	}
}

puts "\nSelect JTAG chain connected to $usbblaster_name.\n";

# List all devices on the chain, and select the first device on the chain.
#Devices on the JTAG chain:

foreach device_name [get_device_names -hardware_name $usbblaster_name] {
#	puts $device_name
	if { [string match "@1*" $device_name] } {
		set test_device $device_name
	}
}
puts "\nSelect device: $test_device.\n";

# Open device
proc openport {} {
	global usbblaster_name
        global test_device
	open_device -hardware_name $usbblaster_name -device_name $test_device
}

# Close device.  Just used if communication error occurs
proc closeport { } {
	catch {device_unlock}
	catch {close_device}
}

proc set_LEDs {send_data} {
	openport
	device_lock -timeout 10000
	# Shift through DR.  Note that -dr_value is unimportant since we're not actually capturing the value inside the part, just seeing what shifts out
	puts "Writing - $send_data"
	device_virtual_ir_shift -instance_index 0 -ir_value 1 -no_captured_ir_value
	#set tdi [device_virtual_dr_shift -dr_value $send_data -instance_index 0  -length 7] #Use this if you want to read back the tdi while you shift in the new value
	device_virtual_dr_shift -dr_value $send_data -instance_index 0  -length 7 -no_captured_dr_value

	# Set IR back to 0, which is bypass mode
	device_virtual_ir_shift -instance_index 0 -ir_value 0 -no_captured_ir_value

	closeport

	#return $tdi
}

##############################################################################################

##############################################################################################
################################# TCP/IP Server ##############################################
##############################################################################################

#Code Dervied from Tcl Developer Exchange - http://www.tcl.tk/about/netserver.html

proc Start_Server {port} {
	set s [socket -server ConnAccept $port]
	puts "Started Socket Server on port - $port"
	vwait forever
}

proc ConnAccept {sock addr port} {
    global conn

    # Record the client's information

    puts "Accept $sock from $addr port $port"
    set conn(addr,$sock) [list $addr $port]

    # Ensure that each "puts" by the server
    # results in a network transmission

    fconfigure $sock -buffering line

    # Set up a callback for when the client sends data

    fileevent $sock readable [list IncomingData $sock]
}

proc IncomingData {sock} {
    global conn

    # Check end of file or abnormal connection drop,
    # then write the data to the vJTAG

    if {[eof $sock] || [catch {gets $sock line}]} {
	close $sock
	puts "Close $conn(addr,$sock)"
	unset conn(addr,$sock)
    } else {
	#Before the connection is closed we get an emtpy data transmission. Let's check for it and trap it
	set data_len [string length $line]
	if {$data_len != "0"} then {
		#Extract the First Bit
		set line [string range $line 0 6]
		#Send the vJTAG Commands to Update the LED
		set_LEDs $line
	}
    }
}

#Start thet Server at Port 2540
Start_Server 2540

##############################################################################################

In order to run this server, I recommend you create a shortcut to the quartus_stp.exe application, then modify the shortcut to execute this script like I’ve shown here:

Shortcut Example to Run Tcl TCP/IP Server

When you run this shortcut the device should be detected automatically, and the server will start and begin listening for connections. It should look like this:

TCL Server

Python LED Counting Script

import socket

host = 'localhost'
port = 2540
size = 1024 

def Open(host, port):
	s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
	s.connect(( host,port))
	return s

def Write_LED(conn,intValue):
    size = 7
    bStr_LEDValue = bin(intValue).split('0b')[1].zfill(size) #Convert from int to binary string
    conn.send(bStr_LEDValue + '\n') #Newline is required to flush the buffer on the Tcl server

conn = Open(host, port)

for val in range(0, 2**7):
    Write_LED(conn, val)

conn.close()

Summary

In the next blog post I’ll show how to simulate this design in ModelSim, I think this is an excellent way to understand how the digital design works.

In addition, just after I finished putting this post together I stumbled across a very rigorous, and more complex example of using this Virtual JTAG, and Tcl Server. In this tutorial the author shows how to connect the Virtual JTAG to an Avalon-MM master, find it here: Using the USB-Blaster as an SOPC/Qsys Avalon-MM master Tutorial.

This tutorial assumes you have some basic experience working with Quartus II. Going through the examples in the DE0-Nano User manual should be sufficient.

For the tutorial, I’m using the following versions of the software:

• Quartus II v. 11.0 Build 208
• ModelSim 10.0C (Quartus 11.1) Starter Edition

You can see the versions of my software aren’t the same, this is probably why I have the EDA tool pathing issue described below. I recommend installing both tools at the same time, from the same release.

Note that you will have to install the ModelSim (Altera Version) software separately from Quartus, Altera’s website makes it seem like they come bundled but this is not the case.

First Step – Create the Design

Start by creating a new project in Quartus II. When using the New Project Wizard, make sure to select the DE0-Nano’s FPGA which is the EP4CE22F17C6. Also, select the ModelSim-Altera as the simulation tool and select the format as Verilog HDL.

Create the Inverter HDL Code

Now create a new Verilog file, which you can save as SimpleInverter.v.

module SimpleInverter(
	input wire a,
	output wire a_bar
	);

	assign a_bar = ~a;

	endmodule

Now you need to set the Inverter as the TopLevel Entity

You’ll need to run the Analysis & Synthesis portion of the compilation process to prepare the files for ModelSim

RTL Level Simulation with ModelSim

Now that the HDL has been created we can start ModelSim (from within Quartus) to do the RTL verification and ensure the design works as we expect.

Start ModelSim using the menu: Tools -> Run EDA Simulation Tool -> EDA RTL Simulation

If you get an error message where the path to the ModelSim software is not specified, search your C:\altera folder for the vsim.exe file. Then update the path by using the Tools -> Path menu, next set the path in the EDA Tool Options category

It’s quite confusing the first time you use ModelSim from Quartus because after ModelSim opens it doesn’t give you any tips as to where your Inverter went. By default the Inverter is put into the “work” Library.

Once you find the module, double click it, or right click and start the simulation:

Now you should see something like this:

If you don’t see all these windows you can bring them up from the Windows -> Toolbar menu.

Create a Stimulus

First thing we need to do is to create a stimulus on our input (a), you can right click the a in the Objects window and for this example let’s just make it a clock:

Let’s make it a 20Mhz clock, so a period of 50nS, make sure to keep the lowercase “ns” or ModelSim will complain.

Next, we’ll add the two signals (a and a_bar) to the Wave window, there are a few different ways to do this, but I prefer to just shift-select both a and a_bar and drag-drop it into the Wave window:

Simulate some Time

Now we need to tell ModelSim to start simulating some portion of time, so lets click the Run button after adjusting the RunLength to 200nS:

Now you should see something like the following in the Wave window:

We need to re-zoom the Wave window to better see the simulation:

You can also change the “Radix” so the values will come up as binary and not “St1″ and “St0″, just shift-select both signals, right click and select Radix…

And select “Binary”:

Analyzing the signal

You can zoom in on the signal easily using the CTRL+Mousewheel. Now we can see that our design is working exactly as we expect an ideal inverter to work. There is no propagation delay between a going high and a_bar going low:

Simulating a Real-World Inverter (Gate-Level Simulation)

In order to see what a non-ideal inverter might look like, let’s jump back to Quartus.

Assign pins

Open the pin planner and assign the following pins:

Here is the location of the pins we chose:

Full Compilation

Now kick off a full compilation:

Gate Level Simulation

Now that the full compilation has finished, we can run gate level simulation. This will include some of the real-world delays and give us a better expectation of how the design will really work.

Using the Tools menu, start the gate level simulation:

Next, you’ll be asked which timing model you want to use, let’s just pick the default, “Slow -6 1.2V 85 Model”, this simulates nominal core voltage at 85degC.

If you get a NativeLink error, something like “error deleting "msim_transcript": permission denied.” you’ll need to make sure you close your current ModelSim environment, or at least stop the current simulation.

Kicking off the Gate-Level Simulation

Now comes a little trick to start this simulation. If you try to begin the gate-level simulation like we did with the RTL simulation (double clicking the work/SimpleInverter module), you’ll be given the following error:

# Loading work.SimpleInverter
# ** Error: (vsim-3033) SimpleInverter_6_1200mv_85c_slow.vo(67): Instantiation of 'cycloneive_io_obuf' failed. The design unit was not found.
#         Region: /SimpleInverter
#         Searched libraries:
#             C:\altera\11.0sp1\simulation\modelsim\gate_work
# ** Error: (vsim-3033) SimpleInverter_6_1200mv_85c_slow.vo(77): Instantiation of 'cycloneive_io_ibuf' failed. The design unit was not found.
#         Region: /SimpleInverter
#         Searched libraries:
#             C:\altera\11.0sp1\simulation\modelsim\gate_work
# Error loading design

We need to start the simulation and tell it where to find the Cyclone IVe I/O pin library.

We’ll click the Simulate -> Start Simulation... menu:

In the Design tab, enter the work.SimpleInverter as the Design unit:

Next we click the Library tab, and add the cycloneive_ver (“ver” for the verilog version of the Library). (Make sure you have the “e” after the “iv” otherwise your design will fail.)

After you kick off the simulation you’ll be presented with a similar ModelSim simulation as before, however there are now a few extra signals and design units. You can see the signals we care about, a and a_bar are still present.

Simulate

Let’s add those signals to the Wave window, create an input stimulus on the a signal and start a 200nS simulation like we did in the RTL Simulation above.

Analyzing the Results

Now we see a very different behavior than we saw in the RTL simulation, there is some propagation delay between a going high and a_bar going low.

Measuring Propagation Delay

You can add a second cursor to the wave window by clicking the “Insert Cursor” button:

We can see ModelSim and the Altera models are estimating a 6.7nS delay.

Verifying in Hardware

In order to verify the results given in ModelSim, I downloaded the configuration file to my DE0-Nano. Using a pulse generator and an oscilloscope I was able to collect the following data. (Data was pulled from the scope and regenerated in Python using matplotlib)

Zooming in a little closer, we can measure a propagation delay of about 6.5nS, quite close to the results given in the simulation. (My testing was done at ~30degC not the 85degC)

In this tutorial, we’ve covered the basics of running simulations in ModelSim of designs created in Quartus II. Let me know if this was useful and informative, or if I’ve left anything important out.

Further Reading:
MIT ModelSim Tutorial (Introductory Digital Systems Laboratory)

The DE0-Nano development board from Terasic. This little guy is exactly what I was aiming for with my Saturn Project. Looking at everything they pack in here for $79, I don’t think there was anyway I could have competed. I’m getting the feeling FPGA development in the hobby-space is still pretty limited, especially with the Cyclone II Breakout board being discontinued.

Follow this link to get the full specs on the board, but for a quick summary:

DE0-Nano Development and Education Board

• Cyclone® IV FPGA
• On-board USB-Blaster circuit for programming
• Altera serial configuration device – EPCS16
• Two 40-pin Headers (GPIOs) provides 72 I/O pins
• One 26-pin Header
• 32MB SDRAM
• 2Kb I2C EEPROM
• 8 green LEDs
• 2 debounced push-buttons
• 4 dip switches
• 3-axis accelerometer
• 8-Channel, 12-bit A/D Converter

If you want to pick up one of these for yourself you have a few different options. From what I’ve read on various forums it’s really difficult (and actually more expensive in the end) to order directly from Terasic and ship to the US. Apparently, you have to pay with a money order and the shipping options are pretty limited out of Taiwan.

Another option is to cruise on over to Adafruit, they are selling it for $99. Finally, probably the best option is to pick this up from Digikey for $86.25, you’ll want to compare the shipping options and prices to find what’s best for you.

(If you’re a student you can get the board from Terasic at a significant discount that might make it worth the hassle buying through them.)

Using the board is super easy, in the first hour or two of getting the board I was able to run through both of the tutorials in the manual. The first project is a simple blinking LED project, and the second is dropping in a NIOS II softcore processor using the SOPC Builder tool.

The SOPC Builder tool is actually being replaced by the newer better Qsys tool. I’m going to start playing around with Qsys and see if I can make a comparable tutorial.

This board really is nano, check out this picture I snapped with my phone, using my hand to help put the size into perspective:

Looking forward to playing around with this little toy and blogging my progress.

Did you pick one up? Working on any fun projects with it? Leave a comment and let me know.

(Side note: I learned from watching one of their video’s that the company name Terasic is pronounced like Jurassic, and not like “tear-ASIC”)

Down the road I plan on making my own breakout board, probably with the basic regulators and USB connections to make it run. I would try to keep it cheap and as barebones as possible, and my thought is to build custom “headers” similar to what is done on the Arduino.

Leave a message in the comments if you would be interested in such a product so I can set my motivation appropriately.

To get myself back into the blogging spirit, I decided to put together a series of posts sharing what content I’m absorbing these days. Let’s start off with:

RSS Feeds I’m subscribed to:

EngineerBlogs.org – A great mashup of different types of engineers (Electrical, Mechanical, etc.) all posting on a select topic each week. Not all the posts hit home for me, but most are worth the read.

SparkFun – Always exciting to see the projects they share, and most importantly the Friday “New Product Posts”.

FlyingFlux – A blog of an anonymous Analog Engineer who doesn’t hold back. His blog is no longer updated, as he’s left to spend more time with his family, but there is still a few years worth of posts to go read.

Electronics-Lab.com – The electronic hobbyist news blog. Very active stream of cool hobby projects.

EDN Product fEEd – New products, most aren’t very applicable to my job and/or hobbies, but it’s good to stay on top of new products coming out.

Cosmic Variance – Random samplings from a universe of ideas. Discover Magazine presents a blog from a group of scientists, most of the best posts come from Sean Carroll

XKCD – A webcomic of romance, sarcasm, math, and language. Everyone should be subscribed to this comic without a doubt.

Pharyngula – Blog of biologist PZ Myers, like Dawkins only with an ample dose of hilarity and sarcasm.

Coding Horror – The blog of prominent coding guru Jeff Atwood. He’s doesn’t really blog as much these days as he used to, but still worth staying subscribed.

Julie Harris Photography – An amazing photographer, a good artistic diversion from the day to day nerdom.

Fail Blog – Constant stream of hilarity.

From my understanding Bryan is running Debian on an ARM, and is programming the Cyclone II on his Morph-IC-II development board.

I haven’t had a chance to test the code, but Bryan has shown it to process and send a 50K RBF file in less than 3 seconds. The code demonstrates the usage of many libftdi function calls not mentioned in my last post. Also, Bryan’s code is checking the NCONF_DONE pin of the FPGA to ensure the configuration file has been sent correctly.

Great work Bryan!

The first part in the series describes how to compile and install the hardware drivers in Ubuntu that we need to use to access the FT232RL functions. The second part describes the hardware modifications and connections required to interface the FT232RL to SparkFun’s Cyclone II Breakout board.

Let me give you a quick high-level overview of what we must do in order to configure the Cyclone II using the FT232RL, after which we will dive head first into all the juicy details.

High Level Steps:

1. Convert the FPGA Config file from SOF to RBF (Raw Binary File) in Quartus.

In Python:

2. Read and process the .rbf configuration file into a serial bit stream. We then need to “weave” in the DCLK transitions to create a parallel byte stream which will be sent to the FT232RL. More on that in a bit.
3. Open a connection to the FT232RL hardware, and configure it for Bit Bang mode operation.
4. Trigger the Cyclone II into configuration mode.
5. Push the bit stream to the FPGA.
6. Close our FT232RL connection.

Generate the RBF File (Quartus II)

Once you “compile” (synthesis) an FPGA design in the Quartus II software, the tool generates a file which contains all the information required to configure your FPGA. However, the default file type is a .SOF which I’m not sure how to manage. However there are other file types available to use for configuration, so much so that Quartus II has a built in tool to convert between formats.

We will be converting the SOF file to an RBF, Raw Binary File which appears to be easier to work with.

The graphic below highlights these steps you will need to take:
(First, open the Convert Programming File tool from the menu.)

1. Select the Programming file type as “Raw Binary File (.rbf)
2. Set the new file’s path and name.
3. Add the source SOF file to be converted. (This file should be in the root directory of your FPGA’s project after you synthesis the design)
4. Click on the Properties button and enable Compression. This reduces the number of bits we need to send. (The CII has an onboard decompression engine)
5. The final step is to click the “Generate” button.

Python Code

First, I just want to throw all the code out there for people who would like to copy & paste it in it’s entirety, next I’ll break it down and explain its components.

'''
Created on Feb 21, 2011

@author: Chris Zeh

'''

from binascii import hexlify
import ftdi

NCONFIG_HIGH = 0x4 #Bitbang Pin #3 (NCONFIG)
DCLK_HIGH = 0x2    #Bitbang Pin #2 (DCLK)

def InitFDTI():
    _ftdic = ftdi.ftdi_context()
    ftdi.ftdi_init(_ftdic)
    ftdi.ftdi_usb_open(_ftdic,0x0403,0x6001) #The last 2 params identify the Vendor_ID and Product_ID programmed into your FT chip. 0x6001 is FT232RL
    #Go here to find the default Product_ID for different parts:
    #www.ftdichip.com/Documents/technicalnotes/tn_100_usb_vid-pid_guidelines.pdf

    ftdi.ftdi_enable_bitbang(_ftdic,0xFF)
    ftdi.ftdi_set_baudrate(_ftdic,9600*16) #Not certain what is the fastest setting possible yet.
    return _ftdic

def StartConfig(ftdic):
    #To start the config process we need to take FPGA's NCONFIG pin LOW then HIGH
    ftdi.ftdi_write_data(ftdic,chr(0),1)
    ftdi.ftdi_write_data(ftdic,chr(NCONFIG_HIGH),1)

def toBINstr(hexstr):
    #Converts a hex string ('\xff' to a binary str 11111111)

    data_byte = eval('0x' + hexlify(hexstr))
    bindata = ''
    for b in range(7,-1,-1):
        bindata+=str(data_byte>>b & 1)

    return bindata

def ReadFile(path):

    f = open(path,'r')
    dat = f.read()
    f.close()
    return dat #Read all of the data into a string

ftdic = InitFDTI()

print 'Device Opened'
StartConfig(ftdic)

data = ReadFile('/home/chris/Projects/Saturn Project/FPGA Code/Hello World/Hello_World_Compressed.rbf')
NewData=''
print 'Preparing the Config Data'

#We set the current state of all 8 Bit-Bang pins of the FT232RL by sending it one byte.
#      each bit in said byte cooresponds to one pin on the FT232RL.

#So we need to convert the bits in the RBF file into bytes to send to the FT232RL, setting the DATA0 pin and then "clocking" it in.

#The following generates the byte stream from the RBF file.
#Basically, every config bit we send to the FPGA needs to be clocked in.
#So take the DCLK low. Set the DATA0 to the value of the bit we want
#to send. Then take the DCLK high. Repeat for all bits in the file.
#You can see we need to send 3 Bytes to the FT232RL in order to send one
#configuration bit.

for byte in range(0,len(data)):
    bits = toBINstr(data[byte])
    for bit in range(-1,-9,-1): #The strange range parameters are to reorder the bits in the RBF correctly for the FPGA
        NewData += chr(int(bits[bit]) | NCONFIG_HIGH) #Set DATA0 to the bit, Set DCLK Low. (Be sure to keep holding up the NCONFIG pin)
        NewData += chr(int(bits[bit]) | NCONFIG_HIGH | DCLK_HIGH) #Clock the data in
        NewData += chr(int(bits[bit]) | NCONFIG_HIGH) #Falling edge of the clock, this can probably be removed but I have to check the timing to be sure (setup/hold times).

print 'Writing to the FPGA'
#The following code is/was needed for version 0.17-1 of the ftdi driver (There is a bug where too large a buffer kicks back a -14 memory error)
#Re = ''
#for x in range(1,24):
    #Re = NewData[(x-1)*2**18:x*2**18]
    #rc = ftdi.ftdi_write_data(ftdic,Re,len(Re))
    #print rc

#Version 0.18 allows for the full buffer to be passed:
rc = ftdi.ftdi_write_data(ftdic,NewData,len(NewData))
print 'Configured!'

ftdi.ftdi_usb_close(ftdic)

Breaking down the code.
Alright, we’ll skip past the declarations for now and start with the code in the order it executes.

First step is to initialize our connection with the ftdi driver and connect to the FT232RL device:

ftdic = InitFDTI()

def InitFDTI():
    _ftdic = ftdi.ftdi_context()
    ftdi.ftdi_init(_ftdic)
    ftdi.ftdi_usb_open(_ftdic,0x0403,0x6001) #The last 2 params identify the Vendor_ID and Product_ID programmed into your FT chip. 0x6001 is FT232RL
    #Go here to find the default Product_ID for different parts:
    #www.ftdichip.com/Documents/technicalnotes/tn_100_usb_vid-pid_guidelines.pdf

    ftdi.ftdi_enable_bitbang(_ftdic,0xFF)
    ftdi.ftdi_set_baudrate(_ftdic,9600*16) #Not certain what is the fastest setting possible yet.
    return _ftdic

If you are using a device other than the FT232RL you might need to modify the Product_ID in the ftdi_usb_open function. See the comments in the code for more details.

The ftdi_enable_bitbang function configures the 8 bit-bang pins to either an Input or an Output. For this example I’m setting all 8 pins to be Outputs, hence the 0xFF. If you wanted all the pins to be Inputs you would send 0x00, and if you wanted half to be input and half output: 0xF0.

According to the documentation this ftdi_enable_bitbang function is depreciated and favors the new function ftdi_set_bitmode. This new function wasn’t working for me, but maybe you’ll have more luck with it than I did.

The next step is to signal to the FPGA that we are going to send it a configuration stream. We need to yank its NCONFIG line low then high:

StartConfig(ftdic)

def StartConfig(ftdic):
    #To start the config process we need to take FPGA's NCONFIG pin LOW then HIGH
    ftdi.ftdi_write_data(ftdic,chr(0),1)
    ftdi.ftdi_write_data(ftdic,chr(NCONFIG_HIGH),1)

We send data to the FT232RL as a Byte of data (ftdi_write_data), with each bit corresponding to the state of each pin. You can see I defined the NCONFIG_HIGH to set the 3rd pin high:

NCONFIG_HIGH = 0x4 #Bitbang Pin #3 (NCONFIG)
DCLK_HIGH = 0x2    #Bitbang Pin #2 (DCLK)$

Next I load the FPGA’s configuration file into memory:

data = ReadFile('/home/chris/Projects/Saturn Project/FPGA Code/Hello World/Hello_World_Compressed.rbf')

Next we need to process the RBF file to get it ready to send to the FT232RL and the Cyclone II:

for byte in range(0,len(data)):
    bits = toBINstr(data[byte])
    for bit in range(-1,-9,-1): #The strange range parameters are to reorder the bits in the RBF correctly for the FPGA
        NewData += chr(int(bits[bit]) | NCONFIG_HIGH) #Set DATA0 to the bit, Set DCLK Low. (Be sure to keep holding up the NCONFIG pin)
        NewData += chr(int(bits[bit]) | NCONFIG_HIGH | DCLK_HIGH) #Clock the data in
        NewData += chr(int(bits[bit]) | NCONFIG_HIGH) #Falling edge of the clock, this can probably be removed but I have to check the timing to be sure (setup/hold times).

Here is the key sentence from the Altera CII documentation explaining how the data needs to be sent to the FPGA:

send the configuration data on the DATA0 pin one bit at a time. If you are using configuration data in RBF, HEX, or TTF format, send the least significant bit (LSB) of each data byte first. For example, if the RBF contains the byte sequence 02 1B EE 01 FA, you should transmit the serial bitstream 0100-0000 1101-1000 0111-0111 1000-00000101-1111 to the device first.

Now, every bit we send on DATA0 needs to be clocked-in, which is why we set the DCLK low, put the data on the DATA0 pin, then take DCLK high. You can see for each configuration bit we want to send to the FPGA, we are sending 3 bytes to the FT232RL.

(If you are trying to use this code on Windows, you might have to adjust the code to avoid Endian problems)

Now that we have the byte stream generated we need to send it to the FT232RL. Fortunately, the ftdi library makes this pretty easy for us:

rc = ftdi.ftdi_write_data(ftdic,NewData,len(NewData))

I had a problem using the older version of the libftdi driver (v0.17-1) where sending the full buffer in one go would kick back a -14 memory error. The following code was a workaround to send the data in smaller bits:

#The following code is/was needed for version 0.17-1 of the ftdi driver (There is a bug where too large a buffer kicks back a -14 memory error)
#Re = ''
#for x in range(1,24):
    #Re = NewData[(x-1)*2**18:x*2**18]
    #rc = ftdi.ftdi_write_data(ftdic,Re,len(Re))
    #print rc

Finally, let’s close our connection with the ftdi device:

ftdi.ftdi_usb_close(ftdic)

And that is all there is to it! After running the code your FPGA should be up and running.

I had a lot of problems initially because of Ubuntu’s security blocking me from accessing the FT232RL, so be sure to read my first post describing how to setup a udev rule to allow non-root access to the device.

I recommend looking at the libftdi documentation as well as the Cyclone II Configuration documentation if you have any problems with the code and/or configuration process.

Best of luck. Please leave a comment and let me know if this code has helped you, or if you have any questions.

I’m going to break this tutorial up into three separate posts. The first has already been uploaded: libFTDI v0.18 with Ubuntu (Lucid Lynx), which describes how to install the proper version of the hardware drivers on Ubuntu. This post, being the second in the series, will cover the hardware modifications required to interface the FT232RL with an FPGA setup. The third post will show the Python code used to push the FPGA configuration file down to the FPGA bit by bit.

The Cyclone II FPGA has a few different methods for configuration as described by the Altera Cyclone II Handbook:

1. Active serial (AS) : Configuration using serial configuration devices (EPCS1, EPCS4, EPCS16 or EPCS64 devices). These can be described as basically non-volatile memory blocks that hold your configuration file. The Cyclone II will actually access this memory to configure itself on power-up.
2. Passive serial (PS) : Configuration using enhanced configuration devices (EPC4, EPC8, and EPC16 devices), EPC2 and EPC1 configuration devices, an intelligent host (microprocessor), or a download cable.
3. JTAG-based configuration : Configuration via JTAG pins using a download cable, an intelligent host (microprocessor), or the JamTM Standard Test and Programming Language (STAPL)

Previously, I had been configuring the Cyclone II on my SparkFun breakout board using the JTAG configuration method. Now I decided I wanted to start using a USB connection instead of the antiquated parallel port required for the Altera JTAG programmer, but to be honest this decision was partially based on the fact that my new computer has no parallel port.

For this USB programming solution, we will be using the Passive Serial (PS) configuration method where our computer will act as the intelligent host.

The following diagram shows how we need to configure the breakoutboard for Passive Serial:

Here is the breakout board schematic showing the modifications we need to make: Removing four solder jumpers, and connecting half of one jumper to the supply voltage (Original Schematic here):

And here is the breakout board layout showing the changes to be made:

Finally, here is a picture of the changes made on my breakout board:

Okay, now we need to connect the FT232RL Breakout-board (BOB) to our Cyclone II BOB. First, let me show you the schematic for the FT232RL Breakout Board:

We are going to be using the FT232RL in bitbang mode. According to Table 2.1 of the FT232R Bit Bang Mode’s application note we have the following pin-outs for bitbang mode:

For convenience, I’ve drawn out where the bitbang pins are on the breakoutboard:

Now, our final step in setting up the hardware is to connect the DATA0, DCLK and NCONFIG pins of the Cyclone II to the FT232RL breakout board:

1. Connect Pin 20 (DATA0) of the Cyclone II BOB to the BitBang Pin 0 of the FT232RL.
2. Connect Pin 21 (DCLK) to BitBang Pin 1.
3. Connect Pin 26 (NCONFIG) to Bitbang Pin 2.

Here is a capture from the Cyclone II BOB Schematic:


Finally, here is a picture of my FT232RL BOB inserted into my protoboard, you can see I ran some wires from the eight BitBang lines to the side of the protoboard for easier access.


That concludes the hardware modifications required for programming the Cyclone II (on a SparkFun BOB) using the FT232RL. Next post I’ll show the software required to process a configuration file and send it to the Cyclone II, bit by bit.

(Teaser: I’m currently working on a MUX system that will allow us to “reconnect” those FT232RL pins to I/O pins of the Cyclone II, instead of always being connected to the FPGA’s config pins. With a little work it should give us the ability to program and communicate with the FPGA for less than $15! )

]]> http://idle-logic.com/2011/02/21/programming-an-altera-cyclone-ii-fpga-with-a-ft232rl-usb-to-uart-bridge/feed/ 13 http://idle-logic.com/2011/02/21/programming-an-altera-cyclone-ii-fpga-with-a-ft232rl-usb-to-uart-bridge/ http://feedproxy.google.com/~r/Idle-logic/~3/AtApVZBmHbA/ http://idle-logic.com/2011/01/18/ieee-paper-published/#comments Wed, 19 Jan 2011 04:00:25 +0000 Chris Zeh http://idle-logic.com/?p=774 I thought I would utilize my blog for a little bit of shameless self promotion…

Several months back I was fortunate enough to join some of my work colleagues in publishing a paper and presenting a poster at the IEEE COMPEL 2010 conference. The title of the paper is “Power Electronics Control to Reduce Hard Disk Drive Acoustics Pure Tones”:

Abstract
Hard Disk Drives are used more and more in environments where the noise level needs to be kept at a very low level. One example is the DVR-application in a bedroom. While the mechanics are important, power electronics control can help to reduce the noise. This paper is presenting two new algorithms that reduce significantly the acoustics pure tones generated by the spindle motor. The first method counters 5/7th harmonics. The second dilutes the pure tones thanks to a spread spectrum approach. Comprehensive theory and measurement data are presented. The electronics driver stays simple and is available into low-cost custom IC.

Most of my work involved preparing the poster presentation along with developing software and giving the live demo. However, I was still able to tack my name onto the paper, and partake in the eternal glory.




My mug made it on the conference website

Finally, after several months of anxious waiting the paper has been published here on the IEEE Xplore. I’m still waiting for the truckloads of cash and notoriety that comes along with having a paper published… but something tells me I’ll be waiting hopelessly.

Maybe my next paper: “Alcohol’s effects on reducing eyeball effective resolution; a technique in pub television cost investment optimization” will have a wider audience

]]> http://idle-logic.com/2011/01/18/ieee-paper-published/feed/ 0 http://idle-logic.com/2011/01/18/ieee-paper-published/ http://feedproxy.google.com/~r/Idle-logic/~3/AKFN6bm8uQw/ http://idle-logic.com/2010/12/13/libftdi-v0-18-with-ubuntu-lucid-lynx/#comments Mon, 13 Dec 2010 19:43:42 +0000 Chris Zeh http://idle-logic.com/?p=798


FT232RL Breakout Board

Now that I’ve upgraded my computer, I no longer have a Parallel port which renders my Altera FPGA Compatible Programmer obsolete. Instead of buying a $300 USB-Blaster from Altera, I’m developing a much cheaper solution…

In my next post I’m going to show a technique I’ve come up with to configure the Cyclone II FPGA using a FT232RL USB to UART Bridge. The breakout board costs $15, while the part itself costs $4 which is a much more agreeable solution for my wallet.

Before I can get into the specifics of the FPGA configuration, I need to show you how to install the proper drivers to play with the FT232RL. Presently FTDI recommends using the libFTDI driver which appears to be maintained by the Intra2Net company. The library is released under the GNU Lesser General Public License so you can use it in free and proprietary programs. Currently only version 0.17-1 of libFTDI is available from the Ubuntu Software center, which has a few too many bugs for my liking. This lead me to another learning experience in my linux adventures: I had to learn how to compile the driver from its source code.

I should mention quickly that I’m going to be writing code using Python. I’m using the eclipse editor with the Pydev IDE.

In order to use the libFTDI driver in Python you will need to run the SWIG tool to generate the ‘glue code’ to call the libFTDI’s C/C++ functions. I’ll cover this aspect of the install in this tutorial as well.

Here are the steps to get going with the latest version of libFTDI:

1. Download the latest tarball from their website: libftdi-0.18.tar.gz
http://www.intra2net.com/en/developer/libftdi/download.php

2. Extract the files into another directory named libftdi.

3. Using Ubuntu Software Center install the following:
SWIG (To generate the Python ‘glue code’)

Python Headers (Dependencies for using SWIG)

libusb-dev (Need these development (header) files to compile the libFTDI drivers)


4. We need to make a minor modification to the source code to allow us to actually read data from the device using Python due to a bug:
In the file: /libftdi/libftdi-0.18/bindings/ftdi.i

We need to insert a single line:
%pointer_functions(unsigned int, uintp);
(Check the screenshot)


5. Now we go through the install process.
In a terminal window, navigate to the folder where you extracted the tarball files:
For me: ~/Downloads/libftdi/libftdi-0.18$ and type the following statement:
./configure --enable-python-binding
(Note that the --enable-python-binding option will automatically tell the installer to run SWIG and generate our python glue-code.)
next type:
make

then:
sudo make install

6. Now, we have one last step in order to make the device available to non-root users. We’ll be adding a rule to the udev:
Create a new file in the /etc/udev/rules.d folder called 60-FTDIRT232R-usb.rules

Enter the following text into the file:
ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", MODE="0666"

(I’m pretty sure you will need root to create this file)



Now you should be good to go. Try running python in interactive mode and type import ftdi to make sure the install and pathing is correct.

In the next post I’ll show you how to actually use this library to do work.

]]> http://idle-logic.com/2010/12/13/libftdi-v0-18-with-ubuntu-lucid-lynx/feed/ 0 http://idle-logic.com/2010/12/13/libftdi-v0-18-with-ubuntu-lucid-lynx/