Debugging Lattice FPGAs for the Impatient
I'm working with FPGAs and CPLDs a lot lately. Usually, the development tools require vendor-specific programming cables. I don't have the vendor programming cables, but I do have an FTDI [FT2232H][ft223h] integrated onto my board that I can wire to the Lattice XP2 FPGA as a JTAG interface. Combined with urJTAG, I was able to program my board's FPGA. There were several hurdles:
- urJTAG requires a BSDL file for programming. I was able to download a BSDL file for my FPGA from the Lattice Web site.
- urJTAG can only program using SVF files, at the moment. I tried the new STAPL support, but it crashes. It might be something wrong with my build environment.
- Lattice Diamond does not output SVF files. I needed to download the separate ispVM System program.
- ispVM System outputs an SVF file that urJTAG doesn't like. Use the "Rev D" SVF output option.
- SVF programming of the XP2 flash is extremely slow. I'm not sure, but I think the SVF has a delay that accounts for time required to erase the flash. I eventually realized that, for development, I could load a bitstream into the FPGA's SRAM far faster.
Here's what a programming session looks like:
$ jtag
jtag> cable ft2232 vid=0xcafe pid=0xbabe interface=1 driver=ftdi-mpsse
jtag> bsdl path /Users/jboone/src/bsdl
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000001001010011001000001000011 (0x01299043)
Filename: /Users/jboone/src/bsdl/lfxp2_5e_tqfp144.bsd
jtag> svf <filename>.svf progress stop
detail: Parsing 23450/23458 ( 99%)detail:
detail: Scanned device output matched expected TDO values.
jtag>
This technique should work with the Bus Blaster, too, since it's based on the FT2232H.
Comments
Isn't Lattice cable a FT2232 JTAG device as well? At least their eval boards, both CPLD and FPGA have it directly connected to JTAG port (don't remember, but Ithink with FTDI's port B). May be it will just work with Diamond if you connect it? I will check their VID/PID, may be they set them to their own values.
@Victor: Not sure, but I know it's an FTx232 of some sort. I had the same thought, but was too lazy to ascertain the VID/PID and reprogram my FTDI FT2232H to find out… :-) I'll gladly give it a try if you find out the VID/PID.
Somehow I did not get a notification that you answered this comment. Gonna check my dev boards (I have both CPLD and FPGA boards) and write here.
On Lattice Versa it is just default FTDI vid/pid - 0403/6010, same with Lattice MachXO2 Pico board, and Bus Blaster - all of them even mapped to the same COM ports on my Windows machine because they don't have device serial number set and they all use FT2232H. So your board should be recognized natively by Lattice DIamond tools if you use channel B for JTAG.
Try to connect your board, start Diamond Programmer which comes with Lattice Diamond - it's in Lattice Diamond/Accessories (I have 1.3 installed), and instruct it to generate new project from scan. It should find your board.
Unfortunately I don't have a Lattice board with easily accessible JTAG, I would have tried this myself.
@Victor: That's good info. I'll try it soon. I think my first mistake was to rewrite the FT2232H EEPROM with a different VID/PID so my installed FTDI driver wouldn't pick up the device and I could work with it using libftdi instead. I'll either wipe my EEPROM, or rewrite it with the stock VID/PID. Probably the latter, because my recollection is the FT2232H synchronous FIFO is dependent on certain EEPROM settings.
And I told you that it uses channel B for JTAG by mistake - I looked once more at the schematics of Lattice breakout boards and Pico board - they use channel A.
@Victor: Channel A? Crap, I'm sunk then. My current design has the FPGA hard-wired to the FT2232H's channel A, which is the only channel that will do synchronous FIFO. Synchronous FIFO is the only interface mode that will suit my design, and I can't optionally wire channel A to the FPGA's JTAG, too, due to signal integrity/timing concerns.
In any case, the solution I have described in this post works pretty well, especially after I realized I could load the bitstream directly into the FPGA's SRAM cells, instead of programming the flash first. I've gone from a five-minute programming cycle to roughly twenty seconds. And that beats the time taken by the Diamond tools to generate a bitstream – by an order of magnitude or more! Once I have a good design, I can take that five-minute hit to program the flash.
I would try to connect it and detect with Diamond Programmer anyway - you never know how they do the detection. May be they try both channels. I don't have the FTDI/Lattice combo (beyond their native boards) handy, so can't do it myself.
Hehe, I made another interesting experiment - I connected Bus Blaster, which uses JTAG A as the main interface, routing it through Xilinx CPLD and using it as a reconfigurable buffer, and - bingo! - JTAG B to program this CPLD. I ran Diamond Programmer, and after some detection it found this CPLD as an unknown JTAG target with passthrough as only possible operation. But is was found as a valid JTAG target, meaning that it is very possible that it tries to detect on both channels!