Partial reconfiguration using ICAP

HI all, I am trying to download Partial bit streams created by Planahead , through ICAP port.The Xilinx board i am using is XUP (xc 2vp 30). I download bitstreams into DDR ,then i am trying to transfer the bitstreams through ICAP to FPGA. All this procedure is taken care of by a program in Power PC. I am using Set Configuration function to do this job.

  1. So when i try doing this the program is not completely get written and gets hanged in between. But when i generated raw bit files (using

- b option in bitgen) i am able to transfer the whole content , but after downloading, the system is not functioning as expected ( no change in the display). The other thing is that the size of original .bit file is 158kB, and .rbt file is 1356kB - so what makes the .rbt fle so big.

  1. I tried downloading .bin file (generated using - g binary : yes option in bitgen) again the whole data is not getting transfered but gets stuck up in between. but the size of this file is only 157kB with header removed.

So could please someone help me out with this problem. ajith.

Reply to
ajith.thamara
Loading thread data ...

Open it in a text editor and you'll see. The .rbt is a text file containing the ASCII characters '0' and '1' for all the bits. This you cannot send through ICAP, it is meant to be used to do very simple bit-banging with a uC (you just read in the rbt byte by byte and set an IO according to the byte to toggle the external serial data input). For use with ICAP, you have to use the bit-file, not the rbt. If you transfer the rbt, the configuration logic detects that this is not a valid bitstream, and that might be what hangs your program (not sure, I've never tried sending an invalid bitstream).

If you do send a valid bitstream (the .bit-file) and it doesn't change the system's behaviour, it could be several things:

- The new partial bitstream isn't really different from the original

- It's not a valid partial bitstream (wrong startup clock, CRC incorrect...)

Have you tried loading the partial bitstream with iMPACT over JTAG instead of using ICAP? If it doesn't work then, there's something wrong with the bitstream.

Hmm, the bin should be loaded completely... the only thing I can think of why it would not be is that the configuration logic requires some clock cycles after the configuration data to empty it's internal pipeline. At least when I'm loading a bitstream via the external interface, I always have to generate several clock cycles after the configuration data before the done pin goes high.

Not sure, but maybe it is the same with ICAP.

HTH, Sean

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...
Reply to
Sean Durkin

I may have steered you wrong when I mentioned raw bitstreams; the terminology is sometimes misleading. The bitgen -b (Create Rawbits File) is *not* what you want, so the fact that the .rbt is enormous is irrelevant.

The -b binary:yes option is indeed what you want, because it generates a regular bitstream without the human-readable header. The fact that the regular .bit and the binary .bin are nearly identical in size makes sense.

So the question now is why the .bin download is not working correctly.

The first thing I would do is try to download the .bit file to the board from iMPACT, as Sean suggested. You absolutely should get the correct results when you try that, and if you do not, you will have to verify that your design really does what it's supposed to do.

Once you've verified that the .bit works correctly from iMPACT, you'll need to figure out why the .bin does not work correctly from your PowerPC code. Until you are able to feed the bitstream through the ICAP with no errors, you shouldn't expect the design to work. A few things to be aware of on that point:

- Read

formatting link
if you have not already done so. You can either correct XhwIcap_SetConfiguration(), or you can call a modified version of it.

- Overwriting configuration frames that touch LUT RAM (including shift registers) or dual-ported BRAM resources can do Undefined Things. Which is to say that you could be killing your design unintentionally. (But perhaps PlanAhead protects against that; I'm not really sure since I don't use PlanAhead.) It's somewhat unlikely that this is the source of your problems, but it is possible.

Furthermore, you may have to do what many of us do when approaching a new problem: Take a ridiculously simple design and try to debug it first. Driving an LED high or low is a time-tested favorite.

Reply to
Neil Steiner

hi sean,

Can you explain how to do this. What modification should I do in the code. Thanking you, ajith.

Reply to
ajith.thamara

Probably just send a few bytes after the bitstream (just send some zeroes). At least that's what I often have to do if I load bitstreams from the outside (using a microcontroller on the FPGA's slave serial interface).

HTH, Sean

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...
Reply to
Sean Durkin

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.