XP2 Board: JTAG scan with ispVM

Back in business, and ain’t it grand! So I decided to go with option number two and bring my old PC back to life. I could not stand the though of having to reboot between Mac OS X and Windows.  With the old PC I have not tried to build any designs or run any simulations yet, but the machine should be able to handle it, perhaps quite slowly though.

To continue with my exploration of the XP2 board, I thought it best to make sure that I could see the FPGA in the JTAG programming chain.  JTAG is an simple interface used for testing silicon devices on a circuit board, and it is also a common interface for programming FPGAs during the design and testing phase in the development cycle.  Every FPGA vendor has its own tool for programming devices, and for Lattice FPGAs the tool is ispVM.

Lets get started.  First the XP2 board must be connected to a JTAG programming cable using the J3 connector labeled “JTAG” on the circuit board.  For the parallel port programming cable supplied with the XP2 Brevia Kit, just follow the directions in the QuickStart guide.  For the USB programming cable, note the the names of the different wires, and then use the QuickStart guide to match the wire name to the right pin.

Once the cable is connected correctly, supply power to the XP2 board and launch ispVM.  After it opens, I like to close all of the open windows in the GUI and start fresh, as shown below.

To perform a simple JTAG chain scan, press F2 or select from the menu bar ispTools->Scan Chain.  ispVM reports all of the devices in the JTAG chain connected to connector J1 on the board. For this XP2 Brevia board, the only device is the XP2 FPGA itself.  In more complex designs, it is not uncommon to have several devices in the chain, such as a flash memory for device configuration, FPGAs, CPLDs, and even embedded processors like PowerPC or DSPs.  When the scan is complete, the XP2 FPGA should be visible and the only device:

 

XP2 FPGA found from the JTAG chain scan

As expected, the device is visible and we have also gained some basic familiarity with the ispVM tool.  With both the serial port verified with the demo program and the JTAG scan completed, the basic connections to the outside world are verified.  Before creating a simple design and programming it to the device, there is one more critical step that requires attention: power and clock systems on the circuit board.  And that shall be the topic of the next post!

Regarding my XP2 posts

I have found that I am going to have to pause my series on the XP2 board.  The reason is that I cannot get my USB programmer to be recognized by Lattice’s software via VirtualBox.  I use Mac OS X, and I have Windows XP2 installed in a virtual machine (VirtualBox).  Though Mac OS X recognizes the USB programmer and VirtualBox does as well, Lattice’s software does not recognize the hardware and nor does Windows XP.  I cannot seem to find a way to get it to either, so I’m essentially dead in the water.

At this point I have three options:

  1. Install BootCamp on my Mac so that I can dual boot OS X and Windows XP — I don’t particularly like this because the Windows XP install will eat up quite a bit of my disk space that I would rather use for video editing.  I suppose I could reclaim some of it by deleting my VirtualBox Windows XP install. But I hate the idea of having to reboot to use Windows or Mac OS X, what a pain!  Hopefully a native install of Window with direct access to the USB subsystem on this computer would allow the Lattice USB programmer to function.
  2. I have an old Pentium-III machine with 256 MB of memory and 10 GB of disk space that runs Windows 2000 smoothly.  I do not have a monitor for the machine, however, so I would need to purchase a monitor, then setup the machine again, and hope that the Lattice software won’t overpower this old machine that I purchased in 1999.  This machine has a parallel port on the motherboard, so I could use the parallel port programmer cable that came with the XP2 board.  This parallel port support gives me some hope that Lattice’s design software is no overbearing. After all, new Dell PCs don’t even have parallel ports!
  3. Buy a new PC with Windows 7 – I’d rather not take this route, but for the long-term it may be necessary.  My hobby and passion is electronics, and despite how much I love Mac OS X, I may have to prepare a Windows machine so that I can take advantage of all of the free tools available for Windows in the electronics world.  I could purchase a basic modern PC for less than $400 and I could get a nice monitor for $200, but that is still a lot of money when I am already happy with my Mac.

Decisions, decisions, decisions.  Once I’ve found my solution I will re-start this series about the Lattice XP2 board.  In the mean time, I have learned that despite the growth in Mac computing, Windows still rules the world.  Even though most of the FPGA vendors now support Linux, I would still go the Windows route until the industry is ready to accept Linux alongside Windows.

Software access to XP2 board

Thanksgiving has come and gone and my life is back to the usual schedule.  That means I have time to experiment with my XP2 board!  In my last post I made sure that I could access the XP2 board from a terminal.  I now want to do this in a programmable way with software. Instead of using a standard terminal interface, my long-term plan is to use a binary serial protocol to communicate between my PC software and the FPGA on the XP2 board.

I coded up some simple C language functions that access and perform I/O via the serial port using standard POSIX functions.  It was simple and did not require much effort, and I’m left wondering why if serial ports can be supported for Linux, why other POSIX platforms like Mac OS X have no support.  I suppose the GNAT supporters have their reasons…probably due to business “use cases”.

Nonetheless, using standard POSIX interfaces worked fine on Mac OS X.  For example, the following screen capture shows the result of reading 512 bytes from the serial port after resetting the XP2 board:

The output matches the terminal output I captured last time with the screen program, and my simple C code serves to prove that we are ready on the software side to interact with theXP2 board.  I will not publish the C code just yet–I plan to make it more adaptive and provide an Ada interface as well.  Just using C would be no fun, I’d learn nothing new.  But interfacing C and Ada, especially since GNAT does not provide serial port support for OS X, is  a great opportunity to learn more about Ada.

My USB programmer cable arrived in the mail recently, and now that we have the software interface working as expected, it is time to make sure the JTAG interface on the hardware works as expected.  Once we have the JTAG programmer figured out, we can try to implement some simple logic in the FPGA.

Connecting to the XP2 Brevia Board

Much to my surprise, my Lattice XP2 Brevia board arrived in the post today.  I printed out the User’s Guide with the schematic because I know I’ll be pouring over the schematics during my lunch break at work and when I get home in the evenings.  The kit contains a null-modem (serial port) cable, the 3 inch x 2 inch board, a parallel-port programming cable, and a power adapter with exchange sockets depending on the electrical standard in your region.  This is truly a versatile development kit for experimenting with FPGAs.

Because I don’t have a PC with a built in parallel port, I have to use a USB programmer, and I’m still waiting on my Lattice USB programming cable to arrive in the post.  Note: Lattice says that USB-to-parallel converters will not work with their parallel port programming cable.

It is often helpful to evaluate the status of the board before beginning with prototyping and development.  If I had designed the board myself, I would be checking the voltage levels at critical parts in the circuit and making sure they match they intended levels.  I’d also be checking the power-up sequence and reset circuits to make sure that these basic functions behave as expected.  I trust, however, that Lattice has taken care of this.

My test plan is:

  1. Connect to the board’s serial interface via a terminal and verify that the factory-installed demo application runs as expected
  2. Connect to the board’s serial interface with my own software and make sure I can interact with the factory-installed demo application

Connecting to the board with a terminal

If you have a Microsoft Windows workstation, you can follow the Lattice QuickState guide and use HyperTerminal to connect to the board.  Though I have Windows installed through a Virtual Machine, I only use it for the Lattice FPGA design software and device programmer.  I would like to use my preferred OS, Mac OS X, for interacting with the XP2 board.  While Mac OS X does not have a graphical application like Microsoft’s HyperTerminal pre-installed, we can use a terminal tool called screen.

Screen comes installed on Mac OS X and it is accessible via the terminal (of course).  The Lattice QuickStart guide says that the serial connection parameters are 8 data bits, no parity, 1 stop bit, no flow control and a baud rate (bits per second) or 115,200.  Most of the parameters, except for the baud rate, are rather standard, so I just have to specify the baud rate when I start a new screen session.

screen /dev/tty.usbserial-A600cGQW 115200

Now I just have to press the reset button on the XP2 board:

Voila!  I am now hooked up to the factory-installed demo application.  Next I will use some custom C software and make sure I can interact with the demo application.

NCVerilog Tutorial: Configuration

The first thing to do is setup an environment for compiling and elaborating our designs.  Any serious FPGA design will use libraries from the FPGA manufacturer for managing clock, DSP and memory resources.  My platform is the Xilinx Virtex5 FPGA, but the process explained here can be used for any platform.  Also, please note that I won’t cover how to prepare NCVerilog for use with Xilinx smartmodels used in modeling designs with IP cores.  If you’re trying to simulate FPGA designs with RapidIO, PCIe or CPRI IP cores, it is best to consult the documentation that comes with the IP core or with a vendor field application engineer.

Let us get started now.  From Appendix B of the Xilinx Synthesis and Simulation Design Guide, we have two choices for configuring NCVerilog.  We could instruct NCVerilog to use single-step mode and directly use the VHDL/Verilog source for the library.  But single-step mode combiles both compliation and elaboration, and I prefer to separate the two.  The other option is to use multi-step mode and  pre-compile the libraries ahead of time.  I’m going to go ahead and pre-compile them so I don’t have to constantly specify Xilinx libraries with each new project.

To pre-compile, one first has to run a Xilinx utility called compxlib.  There are several options for controlling the output, but I’m going to keep most of the defaults.  We only really need to specify the simulator, but I’m going to go further and limit my build to verilog libraries and the Virtex5 platform to save time.  On the command line of your workstation, exectue the following command.

compxlib -s ncsim -arch virtex5 -l verilog

If you’re ushing VHDL, replace “verilog” with “vhdl” in the above command.  For more about the options, use the help command provided with the tool or refer to Chapter 27 of Xilinx’s Development System Reference Guide.  The above command outputs to %XILINX%\verilog\ncsim, where %XILINX% is the environment variable for the Xilinx base directory.  %XILINX% would be $XILINX on Linux/UNIX.

One the compilation process ends, the next step is to update your library mapping configuration.  This is very easy to do, luckily.  I created a folder called ncsimcfg, and it is located in C:\work\ncsimcfg.  With your favorite text editor, create a new file in this directory and name it “xilinx_cds.lib”.  You can call it anything you like actually, but I’ll stick with xilinx_ cds.lib as it makes it clear this file is for designs using Xilinx libraries.

Now we have to fill in the library mapping. Let’s include the core libraries from Cadence first.  Add the following line to file:

include $CDS_INST_DIR\tools\inca\files\cds.lib

This includes Cadence’s libraries, such as their IEEE implementation and Cadence-specific primitives.  Next we need to add the Xilinx libraries.  There are the libraries that were created by compxlib in the beginning of this tutorial.

define simprims_ver $XILINX\verilog\ncsim\simprims_ver
define unimacro_ver $XILINX\verilog\ncsim\unimacro_ver
define unisims_ver $XILINX\verilog\ncsim\unisims_ver
define XilinxCoreLib_ver $XILINX\verilog\ncsim\XilinxCoreLib_ver

Please note that if your libraries are stored in a directory that has spaces in the path, you must enclose the path with quotation marks.  Save the cds.lib file because we’re through with it.

Next, create a file named “xilinx.src”, which will be a list of Xilinx verilog source that will need to be compile.  Again, you can name it anything, but I chose this name becaues it makes it clearer that the file relates to source code, and that it is also related to Xilinx.  In this file, for now,  we only have to insert one line:

$XILINX\verilog\src\glbl.v

If we later find that designs need other common files, we can add a new line with the path to the verilog source.  Now have two global files that we can share amongst our designs: a vendor-specific library mapping file and a vendor-specific source list.  If we have to support multiple FPGA vendors, we could create such a file for each vendor, such as “altera_cds.lib” and “altera.src”.

There is one more file that we must create.  It will be used in the elaboration process that I will cover later.  For now, in the same place as xilinx_cds.lib and xilinx.src, create a file named xilinx.elab.  In the file, insert the following line:

glbl:module

This just tells the elaboration process about the Xilinx glbl module. Finally, it is a good idea to run nchelp to enumerate your library mappings and make sure there aren’t any mistakes.

nchelp -cdslib C:\work\ncsimcfg\xilinx_cds.lib

As we can see on screen, the libraries we manually added are enumerated, and we can also see what the Cadence library mapping file including in our mapping file contains:

Defined in ..\Program Files\Cadence Design Systems\IUS\tools\inca\files\cdsvhdl.
lib:
Line #  Filesys            Verilog  VHDL               Path
——  ——-            ——-  —-               —-
1    std                std      STD                ..\Program Files\Cadence
Design Systems\IUS\tools\inca\files\STD
2    synopsys           synopsys  SYNOPSYS           ..\Program Files\Cadence
Design Systems\IUS\tools\inca\files\SYNOPSYS
3    ieee               ieee     IEEE               ..\Program Files\Cadence
Design Systems\IUS\tools\inca\files\IEEE
4    ambit              ambit    AMBIT              ..\Program Files\Cadence
Design Systems\IUS\tools\inca\files\AMBIT
5    vital_memory       vital_memory  VITAL_MEMORY       ..\Program Files\Cad
ence Design Systems\IUS\tools\inca\files\VITAL_MEMORY
6    ncutils            ncutils  NCUTILS            ..\Program Files\Cadence
Design Systems\IUS\tools\inca\files\NCUTILS
7    cds_assertions     cds_assertions  CDS_ASSERTIONS     ..\Program Files\C
adence Design Systems\IUS\tools\inca\files\CDS_ASSERTIONS

Defined in ..\Program Files\Cadence Design Systems\IUS\tools\ict\files\cds_ict.l
ib:
Line #  Filesys            Verilog  VHDL               Path
——  ——-            ——-  —-               —-
1    summit             summit   SUMMIT             ..\Program Files\Cadence
Design Systems\IUS\tools\ict\files\SUMMIT

This concludes the tutorial for now.  To recap everything, we pre-compile Xilinx’s libraries with xcomplib first.  We then create three global configuration files: xilinx.src, xilinx.elab and xilinx_cds.lib.  With these files in place we are ready to begin compiling, the subject of an entry to come.

Joe Armstrong Interviews: Erlang and FPGAs

I’m trying to learn Erlang, so when I found MSDN’s interviews (part I, part II) with Joe Armstrong I could not wait to listen.  Anyone interested in listening to intelligent computer scientists have a casual conversation about functional programming concepts should definitely watch them both.  Listening to Mr. Armstrong talk about the concepts behind Erlang and the type of problems it addresses really helped me to understand some fundamental things about Erlang.  As Erik Meijer mentioned, after initially learning imperative programming styles with assembly language and C, trying to force my mind into the functional programming mode is not easy task. 

However, I was really impressed with Mr. Armstrong’s knowledge of FPGAs and reconfigurable computing.  FPGAs are wonderful tools and it was nice to see a computer scientist interested in the possibilities of FPGAs.  They are still really expensive devices though; in Japan, for small lots, Xilinx sells their Virtex5 FPGA for around US$4000, and Altera sells their Stratix-II FPGA for around US$6000.  As such, FPGAs are usually considered in the realm of hardware design prototyping and communications systems.  I mostly use them to bridging different components together such as DSPs, ADCs, DACs and the PCI bus.  These days you can even program PowerPC or ARM CPU cores into an FPGA, it is really amazing.  One day I hope I’ll get the chance to implement some DSP applications in an FPGA–someday I can escape from being a “bit plumber”!  

So what does this have to do with Erlang?  Programming FPGAs in VHDL or Verilog requires a different style of thinking compared to most modeling.  In fact, hardware modeling resembles Erlang in many respects now that I think of it: processes run in parallel and send data over buses to exchange data.  Check it out yourself if you don’t believe me.