Abstract Shell Creation and Usage - 2023.2 English

After defining Reconfigurable Partitions (RPs), building the design sources, and generating output products (IP integrator flow) for your DFX design, open the DFX Wizard. The first few pages through the wizard are the same as 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:

Figure 1. Automatically Create Configuration Runs

Clicking the Standard DFX option uses the basic DFX project flow that uses a full static design image for each configuration run. 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.

Figure 2. Standard DFX Configuration Runs

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.

Figure 3. Abstract Shell Configuration Runs

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 determines the design checkpoints written out at the end of the parent configuration run. The parent run always creates 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, is created.

DFX Mode = ABSTRACT SHELL

One or more checkpoints each containing the abstract shell for one Reconfigurable Partition are 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.

Figure 4. Create a New Parent Run

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. After you set the Parent to the Abstract Shell parent implementation, the DFX Mode and Configuration fields are 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.

Figure 5. Create a Child Run for the Existing Parent Run

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.

Figure 6. Set the RM Instance for the Child Run

When implementing the design, the parent run is compiled first, then all child runs can be launched in parallel. It is expected that in nearly every case, Abstract Shell runs are faster than an equivalent full configuration child run. With designs containing more than one Reconfigurable Partition, compiling each Reconfigurable Module in parallel further reduces overall compile time.