05-10-2017 03:41 AM
Hi
I was exploring using hierarchical design flow for ultrascale projects - then I came across this reference in
05-10-2017 08:35 AM
Hi Simon,
This is correct. For new architectures (UltraScale and beyond), the PR tools are the correct approach for solving hierarchical design flows. The PR flow is very mature, and is much easier to setup/use than the HD flow described in UG905. While it may not meet the need of every design, let me explain how this can be used.
First off, OOC (bottom up) synthesis can be used regardless of any HD or PR flow. Our IP use OOC synthesis for this same reason, and there isn't any reason you can't break up your design into OOC modules for synthesis as well.
Once you have the design partitioned into OOC modules, and are saving time on synthesis, you can then decide if the PR tools can help save you time on implementation. The primary supported use case for this is implement a fixed top-level/platform/static, with lower level modules set has HD.RECONFIGURABLE. These partitions required OOC synthesis (which you'll already be using), as well as Pblocks. The pblocks need to follow the rules of the PR flow (no overlaps with other partition pblocks, etc), and other PR rules/recommendations should be followed (see UG909 for more information).
If you get the design all setup this way, the PR flow will allow you implement the top-level Platform once, and then choose which revision of the modules you want to plug into the partitions for each run without have to reimplement/re-close timing on the fixed portion of the design.
Hopefully this flow will fit your needs!
05-10-2017 08:35 AM
Hi Simon,
This is correct. For new architectures (UltraScale and beyond), the PR tools are the correct approach for solving hierarchical design flows. The PR flow is very mature, and is much easier to setup/use than the HD flow described in UG905. While it may not meet the need of every design, let me explain how this can be used.
First off, OOC (bottom up) synthesis can be used regardless of any HD or PR flow. Our IP use OOC synthesis for this same reason, and there isn't any reason you can't break up your design into OOC modules for synthesis as well.
Once you have the design partitioned into OOC modules, and are saving time on synthesis, you can then decide if the PR tools can help save you time on implementation. The primary supported use case for this is implement a fixed top-level/platform/static, with lower level modules set has HD.RECONFIGURABLE. These partitions required OOC synthesis (which you'll already be using), as well as Pblocks. The pblocks need to follow the rules of the PR flow (no overlaps with other partition pblocks, etc), and other PR rules/recommendations should be followed (see UG909 for more information).
If you get the design all setup this way, the PR flow will allow you implement the top-level Platform once, and then choose which revision of the modules you want to plug into the partitions for each run without have to reimplement/re-close timing on the fixed portion of the design.
Hopefully this flow will fit your needs!