FPGALink: Easy USB to FPGA Communication

The xilprg code bundled with NeoPurgo was written by Zoltán Csizmadia; you can find its homepage here. The only changes I made to Zoltán's code were to implement the NeroJTAG back-end and to replace the readline-based command-shell with a command-line interface. I'm not familiar with the .bit file programming algorithms. It might be worth asking Zoltán for some guidance on implementing Spartan-6 support.

Of course, the alternative is to not use xilprg at all, but to use Xilinx impact to generate an XSVF file from your Spartan-6 .bit file, then convert it to a CSVF file with xsvf2csvf, and then use csvfplay to load it into your FPGA. It's a bit more inconvenient, but not much slower than using xilprg.

Hello Ben, glad you like it!

Following feedback I've had from early adopters, I'm repackaging NeoPurgo to include an easy-to-use DLL (.so on Linux) which will make it possible for people to evaluate it without having to install all the tooling necessary to build from source. The library incorporates:

• The pre-built firmware and code to load it into the FX2 chip
• The code to program the FPGA from an XSVF file ("NeroJTAG")
• The code to communicate with the FPGA, once programmed ("CommFPGA")

It would be good if you could try the library and let me know what you think. I'll send you an alpha version.

As far as throttling goes, I've had some success with throttling to a guaranteed-predictable rate by adding wait states into the VHDL as you mention. Unfortunately that approach will not work well for cases where the throttling is to an unpredictable rate (i.e you have no idea when data will be available, or how much). This is because the host code is inherently synchronous: you say "get some data" and it blocks until it has your data or it hits the timeout. But if the host side times out (as it can do if your data flow is unpredictable), it leaves the FX2 and FPGA in a state which I suspect will be difficult to recover from.

The alternatives are:

• Query the FPGA first to see how much data it has available, then request exactly that much data from it.
• Switch the host side to use asynchronous APIs where you get a callback when data is available.

The latter is probably non-trivial because aynchronous USB is handled differently on the Windows and Linux versions of LibUSB.

The last point I wanted to make is about latency. NeoPurgo uses bulk USB endpoints to transfer data to and from the FPGA. Bulk endpoints are reliable in the sense that they will never silently drop or corrupt data, but without latency guarantees. USB audio I/O modules usually use isochronous endpoints, which offer guaranteed latency at the expense of data integrity.

Hello Max.

FPGALink should work fine on the Atlys board since as you mention it uses the same FX2LP microcontroller with the same pin connections. You would naturally have to provide Atlys platform files for the VHDL build. When you get it working feel free to send me patches so I can include your Atlys platform files in the project on GitHub, so others may benefit from your work.

As to your questions about sending files to and from the FPGA, I'm confused. Are you asking about how to do transfers using FPGALink or with Adept? If the former, you just use the flWriteRegister() or flReadRegister() functions (see the API docs); these functions can send and receive single bytes or whole files. If the latter, I don't know; but I'd be interested to hear the ways in which FPGALink does not meet your needs, so I can improve it.

Great, thanks for the link! Would you like to contribute your platform/atlys/* files?

Hi Dan,

I consider the VHDL reference design to be source code, so it doesn't appear in the binary distribution. On GitHub you can browse the VHDL, or download the entire source tarball. Just unpack it and run "make PLATFORM=nexys2" in the vhdl directory. To build the VHDL you'll need Windows or Linux with a Xilinx WebPACK installation. On Windows you'll also need the 3.5MiB MakeStuff build infrastructure.

If something is unclear or doesn't work for you, please let me know so I can fix it.

Chris

You're very welcome. Please subscribe to the mailing list to ensure you're notified of updates.

I found the file which defines the 4 JTAG pin assignments. Hopefully after re-assigning the pins and recompiling the firmware, it would work with your FPGALink. Fingers crossed.

After a few days of work to make the source compiling on Fedora 86_64, we finally have our target programmed through USB, thanks to your FPGAlink. I will show you the modifications.

Hi Ray,

Really sorry I haven't been replying, I've been away on vacation. I'm really pleased you got it working.

One thing you can do to eliminate the need for recompiling the entire library is to only recompile the firmware with your changes, and then use flLoadCustomFirmware() or flFlashCustomFirmware(), which will load your updated firmware from a file.

I quite like the idea of a way to configure the JTAG port lines from within the library itself though, thus eliminating the need for a custom firmware; I'll try to do it when I have time.

Meanwhile please join the mailing list and let me know if you run into problems; I promise to be more responsive in future!

Chris

Hi Ardon,

I admire your gumption for questioning the operation of my code after reading it but not trying it out. It reminds me of the Donald Knuth quote, "beware of bugs in the above code; I have only proved it correct, not tried it." Too many people assume that just because a bit of code appears to work, it must be correct!

Your interpretation of the TRM is correct. In synchronous mode, SLOE and SLRD must be asserted on the rising edge of IFCLK to advance the read FIFO pointer, and SLWR must be asserted on the rising edge of IFCLK to advance the write FIFO pointer.

In the VHDL reference design I have grouped SLWR, SLRD and SLOE together into one std_logic_vector called fifoOp:

signal fifoOp       : std_logic_vector(2 downto 0);
constant FIFO_READ  : std_logic_vector(2 downto 0) := "100"; -- assert slrd_out & sloe_out
constant FIFO_WRITE : std_logic_vector(2 downto 0) := "011"; -- assert slwr_out
constant FIFO_NOP   : std_logic_vector(2 downto 0) := "111"; -- assert nothing

  :

-- Breakout fifoOp
sloe_out <= fifoOp(0);
slrd_out <= fifoOp(1);
slwr_out <= fifoOp(2);

Refer also to TRM section 9.2.5, where it states, "by default, SLOE and SLRD are active-low; their polarities can be changed via the FIFOPINPOLAR register," and later on, "by default, SLWR is active-low; its polarity can be changed via the FIFOPINPOLAR register". In my firmware I have set FIFOPINPOLAR = 0x00, which according to TRM section 15.5.8 merely chooses the default polarity: active low.

From TopLevel.vhdl and the state chart above, you can see that fifoOp is FIFO_READ on read states, FIFO_WRITE on write states and FIFO_NOP otherwise.

I hope this clarifies things. Meanwhile I can assure you the code does actually work!

Chris

Hi René,

You're very welcome. If you're using FPGALink, please join the mailing list.

The reason ISE generates a different-size .bit file is because the Makefile is configured to generate a compressed .bit file, whereas by default ISE is not.

• You can tell the Makefile build not to generate a compressed .bit file by removing -g Compress from platform.ut.
• You can tell ISE to generate a compressed .bit file by selecting TopLevel.vhdl, then right-clicking "Generate Programming File" and choosing "Process Properties". Check "Enable BitStream Compression".

Enabling or disabling .bit file compression will not affect the functionality or performance of a design, but it will affect the size of the generated .bit file (and the corresponding .xsvf file). Confusingly enough, FPGALink implements its own compression which only comes into play if you use FPGALink standalone mode, in which the the FX2LP microcontroller reads a compressed XSVF stream from its configuration EEPROM and loads it into the FPGA on power-on. Perversely, running FPGALink compression on a Xilinx-compressed .xsvf file generates a bigger file than running FPGALink compression on a non-Xilinx-compressed .xsvf file:

So, in short, if you're using FPGALink standalone mode, it makes sense to disable Xilinx compression, because you end up needing a smaller boot EEPROM, but if you're not using FPGALink standalone mode (i.e there's always a host computer to load the FPGA), it makes sense to enable Xilinx compression. Phew.

With regard to making ISE use FPGALink to program the FPGA as part of the ISE design cycle, I don't see any easy way to do that. I may be wrong, but ISE does not appear to have any hooks to allow you to add a custom build step. You could either run the last two steps (.bit -> .xsvf and .xsvf -> FPGA) from the command-line, or just use ISE as a glorified VHDL editor, and run the entire build process from the command-line.

Chris