ICAP in V4 FX20 only working after Reset

Hello,

I am trying to use the ICAP module of a Virtex-4 FX20. I built a project with EDK8.1 using the OPB-ICAP module from EDK 9.1.2.

My configuration is a basic microblaze system with the usual debug/timer/lmb-bram/uart-modules clocked at 50 MHz. When executing the example applications from Xilinx on the system, the ICAP seems to work only after at least one system reset.

Writing to the BRAM buffer of the ICAP-module works but if I try to execute a Read Device ID command, no device id gets written to the BRAM buffer therefore the high level Xilinx supplied ICAP functions like XHwIcap_Initialize() will also fail.

The hardware and software part of the system builds without warning.

How do I correctly initialize the ICAP without applying an other reset after configuration?

Best regards,

Andreas

Reply to
Andreas Hofmann
Loading thread data ...

Andreas,

This may not be your problem, but if I read from the ICAP first thing after programming I have had it routinely fail. I've chalked this up to the device coming alive before the final dummy configuration frame contained in the bitstream has finished writing to the device (may not be the true cause). Thus my ICAP read conflicts with the device programming.

If I delay the read to the ICAP it behaves perfectly.

Stephen

Reply to
stephen.craven

Stephen,

thanks for the quick reply. I've tested delaying the first access to the ICAP and now reading the device ID works perfectly. Using the Xilinx microkernel I have to wait about 30 ms after the start of the kernel to successfully talk to the ICAP. I've searched the Virtex-4 configuration guide (ug071) and the Xilinx website but found no information about this topic.

Best regards, Andreas

snipped-for-privacy@gmail.com schrieb:

Reply to
Andreas Hofmann

Andreas,

I suspect that the ICAP core must wait until the configuration logic is completely finished, and idle.

There is no means for resolving access to the configuration logic (that is on the list for 45nm).

If there is a contention for access, there is no defined "winner" and both applications requesting access will lose.

I will ask to see what the sequence might be, and why it appears you have to wait as long as you do.

Austin

Reply to
austin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.