08-03-2017 04:25 AM
I've recently tried to create a partial reconfiguration project and I noticed that when a pblock spans between two vertical clock regions there is an area that lies between these two clock regions and is automatically included in the reconfigurable partition. For 7 series these tiles are described as BRKH_XXX (where XXX can be INT, BRAM, DSP or CLB) and for Ultrascale+ as XXX_RBRK (where XXX can be CLEM, INT, DSP etc). I have tried to experiment with reconfigurable partition sizes and I created some configurations with different pblock sizes where for example in one configuration a pblock spans between two clock regions and in the other configuration this pblock is divided into two smaller ones that align with the clock region's borders and where of course static logic, partition pins and the reconfigurable frames are the same. When I run pr_verify -full_check I can see that my configurations are compatible except for the tiles described above, where in one configuration they are used in PR and in the other no, so I get an error. I have tried to find what these tiles are and how to manually include them in my configurations where they are not marked as reconfigurable but without success and I have also downloaded the bitstreams to an fpga where the configurations work as expected but I can't be sure if this can work with every configuration, so my questions are:
- Where can I find what these tiles are?
- Is there a way to manually include these tiles in a pblock that does not span between two vertical clock regions to make my configurations 100% compatible, and if not, can I suppress the error and expect this method to work with all my configurations?
08-03-2017 09:51 AM - edited 08-03-2017 09:52 AM
I would first tell you that you shouldn't do this! ;-) There shouldn't be any need to change the Pblock in this type of manner between the initial and subsequent configurations. Our tools (like pr_verify) are not designed or tested for this type of flow. Following the prescribed methodology for PR is important, and any divergence from this can lead to issues. However, this is an interesting question, so thanks for sharing.
I do not have a definitive answer for you. I think this is just a GUI/Pblock visualization issue. However, a good way to check this would be generate a partial bit file for the initial configuration. Then open the routed DCP from the initial run, and just modify the Pblock in the same way you currently are. The just generate a new partial bit file. The two partial bit files will have identical placement and routing since you didn't reimplement, the two routed designs should fail pr_verify as expected, and you can diff the partial bin files (no header information) to see if there are difference. If one partial bin file has additional frames due to the inclusion of these RBRK tiles, then you cannot ignore the error as you couldn't guarantee these frames were always the same. If there are no programmable bits in these tiles, then the partial bit files should be identical, and would be equivalent in hardware.
I will look into getting the Pblock creation more consistent that that these tiles are always included if a Pblock spans a CLOCK_REGION boundary.
08-04-2017 03:53 AM
Thanks for your reply
To be honest, my project is a little more tricky than I described. If you only divide a large pblock into two adjacent pblocks, vivado merges them automatically, so this ends up to the original pblock. In my configurations I try to mess with resizing multiple pblocks and end up to the same reconfiguration frames as in the initial config. That's why checking the bitstreams is not very feasible in my case. Is it possible to find a way to include these RBRK tiles to my pblocks and find what is the meaning of these tiles?
08-04-2017 09:20 AM - edited 08-04-2017 09:22 AM
I was thinking about this a little more. If the RP Pblock spans the clock_region, these tiles should always be included, regardless of what the Device View shows when displaying the Pblock. A more accurate view of which tiles are included in the RP Pblock is to source the AllTiles hd_visual script.
When you implement a design with PR, the tools will create a sub-directory in the PWD called hd_visual. There are few different scripts in there depending on the architecture you're targeting, but there should be a script called "<pblock>_AllTiles.tcl". Sourcing this script in the GUI will select all the tiles owned by the RP. In the image below, you can see I drew the Pblock in away that the BRKH tiles are not "included" in the Pblock, yet the visualization scripts shows these as part of the RP Pblock. Hopefully you can see this in the image below. The green highlight are the tiles selected by the visualization script. You can also search this script for the tile names. It is the hd_visual scripts that you should rely on, as these are created using the same data write_bistream uses to generate the partial bitfiles.
I do see some PIPs in these BRKH tiles, and it is possible that these frames can be used by the RM if the RP Pblock includes this tile. I don't know of a way to manually include these in your Pblock, and changing the Pblock from one configuration to another makes the resulting bitstream incompatible (hence why pr_verify fails). I would not recommend using partial bit files to program if pr_verify does fail. You may get lucky if these resources are not used, but you could cause contention in the device if they are.
08-04-2017 10:30 AM
I know that these tiles are always included if the pblock spans between 2 clock regions, that's why I asked if there is a way to declare them in the pblock to pass the pr_verify. I was thinking if by downloading a blanking partial bitstream (in which these tiles do not contain any logic) before a normal partial bitstream I could safely pass from one configuration to the other.