Virtex® Family FPGAs

[henningsahlbach]

Hi,

I implemented ICAP-based configuration readback using the state machine provided in UG191, page 139 (table 7.2) on a Virtex 5 SX240t. I omitted the state machine's shutdown and startup commands in order to keep the FPGA and my user logic operational.

Currently, I am able to successfully readback the first part of the FPGA configuration into the operating PC via the FPGA's PCI-Express interface. However, after a certain amount of frames (approx. 35000 frames) the PCIe interface stops accepting data, which also stops the readback process. Additionally, the FRAME_ECC_VIRTEX5 primitive indicates errors. I am currently trying to determine the exact position that causes the crashes.

Does the readback sequence somehow influence the correct execution of the FPGA or the PCIe interface? Or do I have to omit certain areas of configuration memory during readback? When I only read the first few frames of the configuration, everything works fine, so the implementation of the state machine seems to be correct.

Kind regards,

Henning

[austin]

h,

Readback of BRAM while the BRAM is operating may corrupt its contents.

The dual port BRAM has two ports, and the readback usurps one of them (steals it) so that any read, or write to the same BRAM, at the same time, may result in a read distrub, or a write of a bad value.

All BRAM must have the clock stopped to them, or their CE disabled, if their contents are to be 100% preserved by a readback.

[henningsahlbach]

Austin, thanks for the quick reply. I am only interested in reading back and verifying the configuration memory content, I do not care about the BRAM content. Stopping all BRAMs would turn the rest of the design more or less unusable as all BRAMs would have to be stopped during the complete readback phase (unless there is a more fine-grain way of stopping them when they are accessed). Is there a way to only read back the configuration memory without touching the BRAMs? Is ICAP able to mask out the BRAMs during readback? Kind regards, Henning

[austin]

h,

If you wish, you can specify the type of frames to read back.

All configuration is of one type, BRAM another, etc.

Look st the SEU Monitor IP core documentation for details on how to do this:

http://www.xilinx.com/products/intellectual-property/SEM.htm

This IP core uses ICAP to ONLY monitor the configruation memory, finding and fixing soft error upsets.

[henningsahlbach]

Austin,

the readback type is already set to configuration frames only as the FAR is set to 0x0.

Is there any difference between the ICAP and the SelectMap interfaces except for the byte-wise bit reordering?

Kind regards,
Henning

[austin]

h,

No.  The ICAP is nothing but a 2:1 mux port, which functions identically to the external configuration pins.  Pins on one port, ICAP on the other.

If you had never read back the BRAM frams, or the other frames, then I am at a loss to explain why the system did anything strange at all.

Perhaps you are also trying to use Chipscope (JTAG)?  There is one, and only one, confiuration engine, and it must be shared between users (ICAP, ChipScope, etc.).  This implies you would have to design the logic to manage the resource, and modify ChipScope (or whatever) to work in that framework.

Another example is trying to do any kind of fall-back configuration (to a back-up design) while also trying to use ICAP:  again, there is only one configuration interface, and it must be shared, or it will get assigned to someome, and then be unavailable to the other user, and a deadlock condition may exist, that never recovers (one isn't using it, but has it, the other waits for its release, forever....).

[henningsahlbach]

Austin,

I used this afternoon and our logic analyzer for a more detailed analysis of the problem.

I am able to transfer 43752 configuration frames without any issues. Starting at frame 43753, I get strange ICAP outputs (frames consisting of only 0x0 and 4 x 0x0002000 in a distance of 9 cycles). Starting at frame 43754, FRAME_ECC_V5 indicates errors. Finally, the data transfer breaks at frame 45548.

Looks like the ICAP interface stops operating correctly after frame 43752. Are there special frames that I should not touch with ICAP? Or is there a timeout for the ICAP interface?

My current ICAP clock frequency is 62,5 MHz. Although this should be within the spec, might this be a reason for an error?

Kind regards,

Henning

[austin]

h,

I have not heard of any issues.  The placement of the logic near the ICAP may lead to timing problems, but stopping at a specific frame address is just odd.

Are you at the end?  Are you trying to read beyond the last frame?

[henningsahlbach]

Austin,

I changed my design so I can dynamically modify the contents of the FAR register and FDRO header contents. When I split the read procedure in segments of 32 frames, readback completes. However, the readback content is invalid, only the first 32 frames are valid.

How do I have to increment the address in FAR for a SX240t when I want to readback the complete configuration? My current setup is:

FDRO bits:

[31:27]: "01001"        -- Type 2 header

[26:0]  : size               -- 32+1 frames * 41 words = 1353

FAR Bits:

[31:24]: x"00"

[32:21]:  "000"                 -- Conf. bits

[20:0]  :  address            -- starts at 0x0

The address field is incremented by 32 after each successful read of 32 frames, which is obviously wrong. How do I calculate the correct address offsets for configuration readback? The row address part is quite obvious, however, where can I find the correct number of rows and columns for my FPGA? Unfortunately, the description of the column address calculation in UG191 has not been helpful. Especially Figure 6-12 and Table 6-16 are quite confusing. How can I determine the correct major and minor address offsets for configuration readback?

Kind regards,

Henning

[austin]

h,

That information is in XAPP864, which is now supported as an application (not just an applications note).  For newer devices, it is inside the SEM IP cores (just look in the VHDL).