Partial Reconfiguration to reduce Synthesis and Implementation run times for Ultrascale Projects

[simonh_bwt]

Hi

I was exploring using hierarchical design flow for ultrascale projects - then I came across this reference in

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug905-vivado-hierarchical-design.pdf

This document applies only to 7 series devices, not UltraScale™ or UltraScale+™ devices. For more information about applications of hierarchical design in UltraScale and UltraScale+ devices, see Vivado Design Suite User Guide: Partial Reconfiguration (UG909)

  So I presume I am forced to use Partial Reconfiguration flow for Ultrascale projects?

The reason I wanted to use the hierarchical design or PR  methods is to reduce the total synthesis and implementation time for an ASIC to FPGA project. We usually want to swap in revisions of existing modules joined together by a stable bus structure. Synth time of complete design is 20 hours, Implementation time is 17 hours, so if we can reduce this to a few hours it would be good.

Regards Simon

[woodsd · Accepted solution]

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!