06-22-2008 03:49 PM
I've been working on several boards configured as described in XAPP424/975, where I have a Virtex 4 and an XCF08P with separate JTAG connectors, and the Virtex 4 can control the XCF08P's JTAG lines via user I/O. These boards will be buried inside a system, but may need occasional firmware upgrades, so I'm trying to find a good solution for programming over a serial link instead of via direct JTAG.
XAPP424 looked good - it takes a lot of extra steps to prepare the files for flashing, but it can be done. The killer was the long preprogrammed delays for erasing etc, instead of polling the device for operation completion. >30 minutes per board is way too much.
XAPP975 looked even better - very few steps to prepare the files needed for upload, and the embedded programmer polls the XCF08 instead of using the long delays, so it's fast. However, it was written for an XCF32P, and is not very well documented. When I tried it with an XCF08P, it did not program correctly. I could try blindly changing the various constants I see in the XAPP975 source VHDL by factors of 4, but I'd prefer to better understand what's going on.
So, I've been writing my own small ISP JTAG code, taking my information from XAPP424, XAPP975, the 1149.1 standard, STAPL files generated from iMPACT, the XCF08P BSDL files, and various other sample source code from the web for Xilinx ISP. Unfortunately, I haven't found quite enough data out there to get it working.
Is there documentation I'm missing, or is the Platform Flash erase/program/verify cycle considered proprietary? Specifically, I'd like to know what data needs to be loaded into the JTAG data register for the various relevant commands (ISC_ENABLE, XSC_UNLOCK, ISC_ERASE, etc), and what to query from the XSC_OP_STATUS command to determine when programming is complete.
Alternatively, could XAPP975 be updated to be little more general than juts programming XCF32Ps?
I realize I could scrap the Virtex 4/ XCF combo altogether and probably come up with a PIC/COTS flash solution, but I'd hate to scrap the investment I have in my existing boards.
Thanks in advance for any guidance.
06-26-2008 02:46 PM
So, I finally have a working solution. I found a lot of the info in the 1532 BSDL files for the XCF08P, since it actually shows flows for erasing, programming, etc. Unfortunately, the steps shown in those files differ from the steps shown from a STAPL output from iMPACT doing the same task, which also differs from what iMPACT actually does over the JTAG interface. It was only after going through a scope capture of iMPACTs true JTAG behavior bit by bit that I got everything to work. In particular, XSC_OP_STATUS alwasy returned 0x72 or 0x76 after starting an ISC_ERASE operation, contrary to what the 1532 BSDL file said should happen, and often went to 0x76 (which seemed to mean "done") before the erase was truly done. I solved this when I observed that iMPACT skips the Run Test/Idle state and goes straight back to Select DR Scan immediately after issuing the ISC_ERASE command. After tweaking my code to do the same, I now get the 0x32/0x36 response codes expected from the BSDL files.
In any case, better/correct documentation of these functions would be extremely helpful in the future. Reverse engineering JTAG communications just to get an efficient erase/program/verify operation going is frustrating!
On a side note, I implemented my serial->JTAG interface with a Picoblaze controller. Picoblaze rocks!
09-09-2011 12:37 PM
I'm implementing the ACE player (after converting to Verilog actually) and I'm a little stuck with simulation. Did you ever simulate your work with the ACE player? If so, how? I can't find a model of the PROM (XCF32P) or any equivalent that I can simulate with...
09-09-2011 01:31 PM
I'm not sure if simulation models of JTAG targets (like the XCF parts) exist. For my JTAG development work I found it easier to just watch the JTAG lines on a scope. I started with the most basic JTAG commands and worked my way up to verify proper operation. Since I originally posted this topic, I've abandoned using the Xilinx platform flash parts and just use commodity flash PROMs, as their interfaces are simpler and well documented.