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!

AR# 8181

Virtex Configuration - How do I perform Virtex readback?


General Description:

How is a Virtex readback performed? Are there any special situations to consider?


The Virtex readback flow is discussed in (Xilinx XAPP138): "Virtex Configuration and Readback." There are two types of readback: readback verify and readback capture. The same data and signaling is required for both -- the only difference is the way in which the readback data is interpreted.

In a readback verify, the user wishes to ensure that the bitstream loaded is correct. You would read back the CLB frames only (since the contents of the Block RAMs would likely change during device operation). The data is then masked appropriately by the .msk file produced by BitGen and compared to the .bit file. (This is performed by the Hardware Debugger/JTAG Programmer, using the MultiLINX cable.)

In a readback capture, the internal states of LUTs, flip-flops, and certain IOB signals are extracted from the readback data to check proper design functionality. The .ll file is used to correlate bits in the readback stream to actual logic bits in the device. For readback capture, you must instantiate the CAPTURE block (either CAPTURE_VIRTEX, CAPTURE_VIRTEX2, or CAPTURE_SPARTAN2) and pulse the TRIG signal in order for the capture to occur. Read back the data after the TRIG signal is pulsed.

Note that there is no direct software support for Virtex readback capture; the closest thing that exists is the Hardware Debugger function "Readback to file". This will still require you to parse the output and correlate to the .ll file. ChipScope ILA is probably a better alternative to readback capture.

Regardless of the readback performed, there are two important things to keep in mind when performing a readback:

1. If Distributed RAMs or SRL16s are used in the design, reading back those LUTs could destroy the contents within if the WE is asserted while the readback is being performed on those frames.

2. The configuration logic takes over the address lines to the BRAMs, so those RAMs cannot be accessed or written to while readback of the BRAM frames is in progress.

If the above two conditions are prevented, the design can run continuously during the readback process.

AR# 8181
日期 01/24/2013
状态 Active
Type 综合文章