09-26-2017 08:16 PM
I am using vivado 2016.4.
1. Is ultrascale plus not supported for OOC implementation?
2. Is there any way that I specify partPin for clk input? In ug909, it seems like it's impossible...
I really need to preserve boundary net. Is there any work around?
4. When I do read_checkpoint all the ooc-implemented modules, it raised the error below:
ERROR: [Constraints 18-4623] Reconfigurable cell 'inst_func_3' is associated with pblock 'inst_func_3_pblock_inst_func_3', which has different ranges from the pblock 'ROOT' in the top design. Reconfigurable partitions of the same cell must have the same ranges. Please reconcile the differences between these two pblocks.
What does this mean?
I am doing a research project, and I want to avoid top-level implementation at all.(in ug 946, it is called "reuse" implementation) So far, issue 2 and issue 3 have been such a disappointment. Hope there's some solution... thanks.
09-27-2017 01:28 AM
OOC implementation would be part of Partial Reconfiguration. This require a specific license.
The is a tutorial available.
Hope that helps,
09-27-2017 08:51 AM
I'm a bit confused about what you are trying to achieve here. You say you don't want to do a top level implementation at all, but then you appear to be reading in OOC modules into a top level. Are you looking to just run a module through place and route on its own just to examine the results? That is the Module Analysis flow, and it's not intended to ever use those results to generate a bitstream. If you want to constrain interfaces on a pblock then look at the HD.PARTPIN_* constraints in UG905:
Note that we do not route clocks in US/US+ devices in this out-of-context implementation flow.
Are you looking to run a module through place and route on its own and then use those results in a top level place and route run? That's Module Reuse and 1. we don't support that for US/US+ devices, and 2. that contradicts what you stated in your post. Why do you need to preserve boundary nets? As woodsd explains in the linked thread, we do not preserve these in the OOC flow to give the tools the opportunity to avoid routing conflicts and improve timing in the assembly phase.
Looking at point #4, you have defined the partition as Reconfigurable. This is approved way to lock and reuse modules in US/US+ devices, but the flow is top-down implementation, not bottom-up. In the PR flow you'll synthesize modules out-of-context but place and route requires that you establish the top-level design results into which all module versions or iterations are compiled. There is no out-of-context implementation in the PR flow, regardless of whether or not you're actually going to use the partial bitstreams. Yes, a license is required, but we include it now with all paid editions at no extra cost (or by request/donation for universities).
09-27-2017 02:51 PM
Thanks for the response.
I understand what I am doing is a bit confusing because I am trying to do something between OOC and PR (I went through both ug 947 and ug 946, but what I want is quite different from both.
Are you looking to run a module through place and route on its own and then use those results in a top level place and route run? That's Module Reuse and 1. we don't support that for US/US+ devices, and 2. that contradicts what you stated in your post. Why do you need to preserve boundary nets?
So, in my purpose, what all "reuse implementation" does is that it simply reads OOC implemented modules. In conventional OOC flow, we do opt_design, place_design, and route_design once it reads OOC implemented modules. But I want to avoid this top-level implementation to save compilation time. I want to put everything in pblock, each pblock OOC implemented, and in the end, want to simply read_checkpoint them.(probably from some empty top design) It seems like I need to do this with 7 series because US/US+ doesn't support this reuse implementation?
09-27-2017 03:57 PM
Let me make sure I understand what you are trying to do. It sounds like you want to build a design in pieces, implementing modules separately and then stitch them together when each piece is done. And when the stitching is done (reading module checkpoints) you don't want to have to implement the top level. In UltraScale/+, this is done using the PR flow.
You first need to implement the top (static) design though, with or without modules within the Reconfigurable Partitions. Once the top level design is implemented, you have one or more regions to implement "reconfigurable" modules in that top-level context. You can iterate on a module, saving a checkpoint for just that module, and then pull together the locked static design and one module for each partition to create a full design. At that point you have a full design that is completely routed. The key detail here is that the module runs here are not implemented OOC, but in the context of the locked static design. That defines the interface routes as well as any other routes (clocks, resets, etc.) that may exist in the pblock you've defined. Place and route of that module works ONLY on that module, as the static part is already done. Then when all the modules are assembled, you can be sure that there will be no resource conflicts.
Now keep in mind that the primary purpose of this flow is to lock down the static module (and then individual sub-modules as you work on others) to make sure it remains 100% unchanged through implementation. Partial Reconfiguration demands this to match what happens in silicon during PR events, but for the general Hierarchical Design flow it achieves the same thing. Runtime savings, while you may see this, is NOT one of the main goals, as it is more important to have that guaranteed preservation and to make sure the fundamental PR rules are met, to ensure silicon design safety. Also note that the PR flow typically has a resource overhead component, which varies based on the design structure. So if you're looking to pack the design as full as possible, this is not the best approach for you.
We do not support a flow where the top level and sub-modules are implemented independent of each other. If there is no top-down or bottom-up context we have no way of resolving conflicts, even if exclusive pblocks are used. The Module Reuse flow was close to this, as you could pblock multiple OOC sub-modules and run them in parallel, but we would need to implement the top level with these modules present to know how to connect things and to know what resources were unused.
Hopefully I'm understanding your goals and I hope this information helps.