03-05-2015 11:48 AM
I'm trying to use partial reconfiguration in my design on an artix 7 chip; I'm trying to use the ICAP, to have it self reconfigure from the SPI, controlled by a FSM.
I'm using the multiboot method as given in the 7 series configuration user guide (ug470 pg139), but I can't get it to work, if I use the address for a full bit file it seems to work, but if I give it the address of a partial bit file it seems to fail as it will reset and load the original configuration after a short time.
Can anyone tell me if the instructions for the ICAP are different for partial reconfiguration than in multiboot, or if there is something else I might be missing?
04-24-2015 03:41 AM
Same problem here, I believe that the problem is related to the IPROG command (0x0000000F). I guess there might be another value to specify the ICAPE2 that it doesn't have to reset the FPGA as the bitfile is just partial.
The situation you are watching is just the system trying to boot from another bit file, and as it is partial (different headers, etc..) it fails and loads again the golden image.
So, bottom question here.. is there any other IPROG command to specify the load of a partial bitfile?
04-29-2015 03:34 AM
It seems that that is the only way to use the ICAP automaticaly..
Now I'm trying to read the bitflile from the flash memory and send the data to the ICAPE2.
I'll post as soon as I get any result.
04-29-2015 07:23 AM
It still doesn't work, but at least now the FPGA doesn't fully restart..
I'm generating a MCS file with the static part of the design at the beginning of the flash and several PR modules at concrete addresses (all of them bitfiles).
Once the external trigger launches the FSM (external sw on the KC705 board), it reads the memory from the corresponding addres (for each PR module) and keeps reading (in blocks of 128 by 32 bits) until it reaches the 0x0000000D word.
Internally there is a fifo between the ICAPE2 and the flash control modules, so between block writes into the ICAPE2 there are periods where is not enabled (may it be a problem?). The section the module reads is quite bit despite having a small PR module (from 0xAF0000 to 0xB64xxx). Should it be a continous write into the ICAPE2?
Reading UG470 page 140, it shows the data sequence to be writen into the ICAPE2 for bitfile load. I've checked the data in the generated MCS file and it doesn't look very similar..
The first two and a half lines doesn't seem to be useful (following UG470 "guide"). Should I start reading from the xFFFFFFFF word before 0xAA995566 word?
Note that prior to sending the data to the ICAPE2 I do a bit swaping (byte boundary).
I wish someone from Xilinx could bring some light into this problem because the only thing I have achieved until now is PR bitfile generation (usign a nice xilinx UG) and I really need to be able to implement PR form non volatile memories using ICAPE2, which, by the way, doesn't sound that weird.
I'll keep digging and hopefully I'll get some results..
05-04-2015 06:45 AM
I think I found the problem.
When setting the reset_after_reconfig flag, the DONE signal never got high after loading the bitstream, fact that stalled the FPGA.
I've turned off that feature and now the partial bitstreams are working fine. I guess I will have to reset the modules manually after the reconfiguration.
It works with multiboot and single mcs files (on single mode, the partial bitfiles are loaded as data, like .elf and .mem files).
12-04-2017 02:50 PM
Yes we do, it's called Partial Reconfiguration. Note that these bit files are partial bit files not full design bit files (so only part of the design is reconfigured), and an ICAP loader such as the PR Controller IP is needed. For more information, please see this page: