ICAP attached to Microblaze on Virtex 2-pro..

Hi Amir,

What you do is quite > Hi everybody,

This is correct. Also be aware that the Persist bit shouldn't be set; otherwise ICAP will be disabled.

I would suggest you to transit to the EDK, ISE 9.1+SP2. Moreover, EAPR tools would help you boosting your design. Check the link

We have not tried the readback operation but...are you sure that you read the correct address the XHI_DUMMY_PACKET is stored in? Why don't you first try to write and then read what you wrote? Use the functions XHwIcap_StorageBufferWrite() and XHwIcap_DeviceWrite().

Also notice that if you use JTAG to initially program the device, and then ICAP you can use them on the same design but, between each mode the configuration logic has to be desynchronized. In order to use the ICAP port you should use the XhwIcap_CommandDesync() function.

The on-chip reconfiguration operates in a read-modify-write manner. The date frame is read back from the ICAP port and stored in the BRAM of the HWICAP (see below) in which the processor modifies the data. Afterwards, the HWICAP downloads the new data back to the configuration memory through the ICAP port.

The "xhwicap_i.h" header file contains the XHI_MAX_BUFFER_INTS constant which defines the size of the ICAP BRAM . The HWICAP BRAM, i.e. storage buffer, is implemented with a BRAM of which the 512 words at maximum are used (at least the above stands for EDK 7.1.i in which we conducted the experiments).

Yes, this is the ICAP's frequency for the Virtex-2 when BUSY signal is checked (50 MHz when not checked). New devices like Virtex-4 embed an 100 Mhz ICAP.

I hope this helps. Keep up the good work and let me know about the result. Besides PR entails a hell of details!:)

Take care, Kyprianos

Amir,

In which way to you load the initial configuration? Do you load it through the ICAP and you don't use ICAP at all?Did you check the Persist option? As a second thought check the ICAP configuration. Has it been configured appropriately? Have the base address and the high address been added in the xparameters.h file?

Take care, Kyprianos

Hi Kyprianos, Thanks a lot for your comments. I checked to make sure that persist bit is also not set. I also checked the base and high address in xparameters.h file and they are as I had set them before. I'm actually configuring my device using parallel cable 4 and through JTAG (I guess!). I wasn't desynchronizing before using ICAP but now I tried doing that to make sure that I'm not doing anything wrong. I'm not sure how I can verify ICAP's correct configuration, but I actually print ICAP's base address (using putnum(my_icap.BaseAddress); statement) to make sure that it is the same as what I'd set before and it is actually the same! However the result for me is still the same! I tried changing the Major and Minor address that I'm writing to. Nothing really changes if I just read it. But when I try writing to it (just writing an arbitrary value (0xFFFFFFFF) to some address in the storage buffer!) and then reading it exactly as the following code, sometimes the output of DeviceReadFrame method is that the device is busy and just then it gives me some numbers that some of them actually are not 0. However it never happens that I actually read the same value that I'm writing! I'm wondering, for example in your case, how is the content of the storage buffer when you read back the configuration? Is it mostly 0 and a few of them are non-zero? Should I be reading words or bytes? Because I realized that when I'm reading from compact flash I'm actually reading in bytes not words! So when I'm writing to the storage buffer of ICAP should I be writing in bytes or in words? If it should be in words then it means that I have manipulate the data I'm reading from Compact Flash! Well that's another problem but for now I can't get the ICAP work and appreciate any suggestion and comment! For now I'll try installing ISE and EDK 9.2 instead of 8.2 and am keeping my fingers crossed that may work!

Thanks a lot,

Amir

My code is as follows:

XHwIcap my_icap;

XStatus icap_stat;

icap_stat = XHwIcap_Initialize(&my_icap, XPAR_OPB_HWICAP_0_DEVICE_ID, XHI_READ_DEVICEID_FROM_ICAP);

if(icap_stat != XST_SUCCESS) print("\n There is something wrong in initializing the ICAP!! \n");

icap_stat = XHwIcap_CommandDesync(&my_icap);

if(icap_stat != XST_SUCCESS) print("\n Desynchronization was not successful!\n");

XHwIcap_StorageBufferWrite(&my_icap, 25, 0xffffffff);

icap_stat = XHwIcap_DeviceWriteFrame(&my_icap, XHI_FAR_CLB_BLOCK,

print("A frame has been written to the device\n");

if(icap_stat != XST_SUCCESS) print("There is something wrong in writing to the device!");

Xuint32 frame_content;

icap_stat = XHwIcap_DeviceReadFrame(&my_icap, XHI_FAR_CLB_BLOCK,

print("The same frame is read from the configuration\n");

if(icap_stat != XST_SUCCESS) print("\n There is something wrong in reading a frame with col =

if(icap_stat == XST_DEVICE_BUSY) print("\n Device is busy right now!\n");

if(icap_stat == XST_BUFFER_TOO_SMALL) print("BUFFER is TOO SMULL!\n");

if(icap_stat == XST_INVALID_PARAM) print("XST_INVALID_PARAM!\n");

for(i = 0; i < my_icap.WordsPerFrame; i++) { print("word number"); putnum(i+1); print(" is equal to: "); frame_content = XHwIcap_StorageBufferRead(&my_icap, i); putnum(frame_content); putchar('\n'); }

On Feb 29, 8:29 pm, kyprianos wrote:

Let me clear this. You load the initial configuration through the JTAG. As you first load the data from JTAG you should set up the configuration mode pins as M2M1M0=101. Then XHwIcap_CommandDesync() allows you to transit to the ICAP. Also try the function XHwIcap_DeviceWrite() instead of XHwIcap_DeviceWriteFrame(). The same stands for read, i.e. use XHwIcap_Device instead of XHwIcap_DeviceReadFrame().

Did you also do assign OPB_Clk to sys_clk_s?

The writing to the storage buffer is executed in a word by word fashion. When the buffer is full it sends the data to the ICAP port, all with one function call, and then continues copying. When it is finished copying and there is still data in the buffer, it writes it to ICAP and the function finishes. This is due to the API provided with the opb_hwicap (at least for the EDK 7.1i with which we conducted the experiments) Therefore, yes! you should manipulate the data you transfer from the Compact Flash. This depends on the API provided with the compact flash driver which can only read ASCII character data types from a file. This fact introduces extra programming effort: The characters that compose a 32 bit word have to be read and combined to form the 32 bit word-number. A typical configuration with bitsreams from the compact flash consists of the following steps:

-Open the bitstream file stored in the compact flash, identify and read the header information,

-Read a data chunk equal to a multiple of a compact flash sector i.e. x 512 bytes,

-Synthesize a 32-bit ICAP word from every 4 bytes of the data chunk,

-Load the synthesized word into the ICAP BRAM storage buffer .....

I can't say anything about ISE+EDK 9.2. We have conducted experiments only using ISE+EDK 7.1i (for difference-based performance evaluation) and ISE 9.1i.02 (for module-based application development)

I hope this help. Let me know about the progress

Good luck, Kyprianos

Hi Kyprianos, Thank you so much for your invaluable suggestions and help. It actually worked. Now I can use ICAP and I'm reading data from CF and load it to ICAP.

I'm planning to put a complete kind of tutorial for those who want to do the same thing and pass on the favor I've been given by people like you. I'm also recommending everyone who is trying to do the same to read your paper "Methodology and Experimental Setup for the Determination of System-level Dynamic Reconfiguration Overhead" if they want to do dynamic reconfiguration through ICAP.

Best wishes,

Amir

Hi Amir, Please, can you put a complete kind of tutorial? Thank you