We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Newbie genady
Registered: ‎03-23-2011

How to debug the FPGA configuration process



We are working on an application to program Spartan-6 FPGA. We use the slave SelectMAP configuration interface to x16-bit data bus and Non-Continuous data loading of a bitstream(.bit) with swapped bytes.

The way we do the configuration is not exactly as in Xilinx examples (UG380). In the examples the data[15-0] is driven from CPLD, we drive it from the CPU by doing a write Access to the FPGA address space (using CPU CSn1). In the examples the CSn and RDWR signals are driven through CPLD/GPIO and we use the CSn and Write signals of the CPU access during its write access. 


We are configuring the FPGA in a Non-Continuous data loading which is a combination of the both ways of Non-Continuous data loading presented in the UG380. 

The only possible problem that we have ability to detect is the configuration abort which occurs if RDWR signal is rising while CSn is asserted, if abort occurs then the Busy signal is asserted in the middle of an access. We saw that the BUSY signal is rising only after CSn is negated. 

Does that mean that it is OK (not ABORT)?  


We succeeded to move the rise of CCLK into the CPU Write Access (data is latched to the FPGA on rising of CCLK). 

After finishing writing the FPGA data we write additional 100 write accesses with data=0xFFFF in order to enable the assertion of the Done pin but the Done was not asserted. 


Could you please recommend us the way how to debug the configuration process. 




0 Kudos
1 Reply
Xilinx Employee
Xilinx Employee
Registered: ‎07-30-2007

Re: How to debug the FPGA configuration process



This would be a good place to start for deubugging information.


The ABORT will trigger when ever RDWR toggled before CS and at that point the input bus becomes and output and the abort status word is shifted out.  You should be able to see this on a scope. 


You can also run a Verify in iMPACT after programing was attempted.  Then run a Verify on a blank device and compare the number of differences.  If the number of differences is the same the part is still empty.  You can also loook at the Status Register in iMPACT after trying to program the device, there is an AR about what the different bits in the status register mean. Typically GHIGH needs to be 1 to signify that data has been loaded into the device.


S-6 also has an issue where CS can not be deasserted when the sync word is shifted in, so make sure this is not occuring.

0 Kudos