After defining Reconfigurable Partitions, building the design sources, and generating output products (IPI flow) for your DFX design, open the DFX Wizard. The first few pages through the wizard are no different than the standard DFX flow described earlier in this chapter – manage Reconfigurable Modules and Configurations in the same way regardless of Abstract Shell. The capabilities unique to Abstract Shell start on the Configuration Runs page. The first time through the wizard (or if you remove all configuration runs), you are presented with two choices for automation:
Clicking the Standard DFX option uses the DFX flow that uses a full static design image for each configuration run. This is the basic DFX project flow structure as it has been since its introduction in 2017. Config_1 is the parent run, and all remaining configurations are child runs dependent on that parent run. In the following figure, config_2 and config_3 use the full locked static design checkpoint from config_1 as the starting point for implementing new Reconfigurable Modules.
Selecting the Abstract Shell option creates a similar looking result, and the parent configuration is the same. However, each of the child runs uses an Abstract Shell for a specific target Reconfigurable Partition.
As you can see in these images, the option that tracks the difference between these approaches is the DFX Mode option. The choice made here will determine the design checkpoint(s) written out at the end of the parent configuration run. The parent run will always create a full design image containing the static and dynamic parts of the design (one RM per RP). The difference is which locked static shells are created for child runs.
- DFX Mode = STANDARD
- A single checkpoint containing the entire static design, with a black box for each Reconfigurable Partition and all placement and routing locked, will be created.
- DFX Mode = ABSTRACT SHELL
- One or more checkpoints each containing the abstract shell for one Reconfigurable Partition will be created. Abstract Shells also have a black box for the RP and locked placement and routing for the static design, but the amount of static information is stripped down to a bare minimum to provide context for implementation of a new RM.
The other option that is used only in the Abstract Shell flow is the RM Instance option. This declares which Reconfigurable Partition is the target for a particular child run, along with which Reconfigurable Module is to be implemented in that RP.
If you do not use the Abstract Shell option for automatic configuration run creation, you can set this directly for a new set of configuration runs.
First, click the + icon to create a new parent configuration run that starts with a synthesized design. In the resulting dialog box, set the DFX Mode to ABSTRACT SHELL.
If you choose to create these child runs manually and have disabled the Auto Create option, click the + again to create another run. Set the parent to the recently created run. Once you set the Parent to the Abstract Shell parent implementation, the DFX Mode and Configuration fields will be ignored, as this child run must follow the structure of the parent it relates to. Select the new RM Instance to implement within this Abstract Shell.
Back in the Configuration Runs page, you can review and edit the RM Instances implemented in any of the runs, and can set any constraints or strategies to be used.
When implementing the design, the parent run will be compiled first, then all child runs can be launched in parallel. It is expected that in nearly every case, Abstract Shell runs will be faster than an equivalent full configuration child run. With designs containing more than one Reconfigurable Partition, compiling each Reconfigurable Module in parallel will further reduce overall compile time.