Step 3: Set Up DFX Design Runs - Step 3: Set Up DFX Design Runs - 2025.2 English - UG947

1. Generate the block design:
   1. With design_1.bd open and active, click Generate Block Design in the Flow Navigator.
   2. Select Out of context per IP, then click Generate.
      
      

      This creates IP and RTL products and runs synthesis for static design components and IP inside RMs. RM top-level generation and synthesis occur later in separate block designs.

2. Open the DFX wizard:
   1. When synthesis completes, the DFX Wizard appears in the Flow Navigator.
   2. Click Dynamic Function eXchange Wizard to begin creating complete design configurations from static and dynamic portions.

      With one RP, this design shows the simplest use case.

3. Edit configurations:
   1. Click Next to get to the Edit Configurations page.
   2. Click automatically create configurations to generate three configurations for the three RMs.
   3. Use the pencil icons to change the names of each of these configurations. Name them as follows:
      • config_up_ila
      • config_down_vio
      • config_2count_ila
   4. Click + to add a fourth configuration named config_gb, then click OK.
   5. Assign <greybox> to the RP.
      
      
   6. Click OK, then Next.
4. Edit configuration runs:
   1. On the Edit Configuration Runs page, manually create the configuration runs to explore the options for the Standard DFX or Abstract Shell runs flows.
      • Standard DFX creates one run per configuration from the prior page. The first configuration becomes the parent run; the rest are child runs of that parent.
      • Abstract Shell creates one parent run, and one child run per RM. In this design, you also create three runs. For designs with multiple RPs, you create more runs.
      • Select Both to create one parent run then one child run per RM, matching the Abstract Shell option. This choice also creates full and abstract shells, enabling extra child runs using full configurations.
   
   
   
5. Create minimum configuration runs:
   1. Click Both to generate the minimum set of configuration runs for the project.
   2. In this design, you create one parent and two child runs.
   3. This action creates implementation results for the static design and all the RMs defined by block designs.
   4. Because no child run exists for the greybox configuration, create one manually:
      • Run: child_gb_impl_1
      • Parent: impl_1
      • Child Run DFX Mode: STANDARD
      • Configuration: config_gb
6. Finalize configuration runs and build:
   1. Click OK.
   2. The DFX Wizard displays your defined configuration runs:
      
      
   With the Configuration Runs defined as shown, the following results are generated:

   impl_1

   Implements a full design with the count_up_ila module included. Both a static black box checkpoint and an abstract shell checkpoint generate.

   child_0_impl_1 and child_1_impl_1

   Use abstract shell to implement the count_down_vio and 2count_ila modules.

   child_gb_impl_1

   Uses the full static shell for the greybox configuration.

7. Click Next, then Finish to create these design runs. The Design Runs tab now lists your defined selections.
   
   
8. Run synthesis:
   1. In the Flow Navigator click Run Synthesis, then click OK. This runs synthesis for the top layer of each RM and for the top-level design.
   2. When synthesis completes, open the synthesized design.
   3. In the Netlist view there are black boxes for the debug hubs. These are inserted later during opt_design.
      
      
9. Launch implementation runs:
   1. In the Design Runs window, shift-click all implementation runs.
   2. Right-click in this area and select Launch Runs, then OK. This action kicks off runs in the necessary order.
   3. The parent run compiles first.
   4. After the parent run completes, each child below the parent runs in parallel.
10. Debug hub insertion:
    1. Debug hubs insert and connect to debug cores during opt_design in implementation.
    2. For each implementation run, observe the following lines of code in the log file.
       • Parent implementation: insertion happens in the static design.
       • Child implementation: insertion happens inside a locked static design from the parent.

       Phase 2 Generate And Synthesize Debug Cores
       INFO: [Chipscope 16-329] Generating Script for core instance : design_1_i/rp1/axi_dbg_hub_0 
       INFO: [IP_Flow 19-3806] Processing IP xilinx.com:ip:axi_dbg_hub:2.0 for cell rp1rm1_inst_0_axi_dbg_hub_0_0_bb.
       INFO: [Chipscope 16-329] Generating Script for core instance : design_1_i/static_region/axi_dbg_hub_0 
       INFO: [IP_Flow 19-3806] Processing IP xilinx.com:ip:axi_dbg_hub:2.0 for cell design_1_axi_dbg_hub_0_0_bb.
       INFO: [Chipscope 16-324] Core: design_1_i/rp1/axi_dbg_hub_0 UUID: 2ba56efa-44aa-5cff-b4f7-161e160672ee 
       INFO: [Chipscope 16-324] Core: design_1_i/static_region/axi_dbg_hub_0 UUID: a46ff48e-6629-59e0-a9fe-ed94bf289898
       

11. Compile time for the parent run takes longer than child runs due to static design implementation and multiple checkpoint creation.
    1. Tools carve out the RP (using update_design -black_box) , lock static design (using lock_design -level routing), and create design_1_wrapper_routed_bb.dcp.
    2. The routed checkpoint reopens and the tools embed these two steps in write_abstract_shell. The additional carving and associated checks are remove the bulk of the static design, resulting in the abstract shell file abs_shell_design_1_i_rp1.dcp.
    3. Compare the file sizes of design_1_wrapper_routed_bb.dcp and abs_shell_design_1_i_rp1.dcp. The full shell is almost four times the size of the abstract shell for this design.
12. Standard DFX flow child runs compile slower than abstract shell runs due to larger checkpoints.
    • This is where the Abstract Shell flow provides benefit. These runs have smaller checkpoints to open and less information to process so the overall compile times are reduced.
    • In this design this is even true with the simple greybox configuration, but that is not the case in most true designs.
13. Select runs, right-click and select Generate Device Image.
14. The following results are generated:
    • impl_1 generates full and partial bitstreams (complete design image).
    • child_0_impl_1 and child_1_impl_1 generates partial bitstreams only (abstract shell).
    • child_gb_impl_1 generated full and partial bitstreams (uses the full static shell to implement a greybox configuration).

On this machine, the Abstract Shell child runs take about half the time of the Standard DFX child runs. For larger designs with multiple or small RPs, the savings are even more dramatic. The greybox run takes less time than the parent run because you do not compile the static design, but more time than the complex RM runs using abstract shells.

If you want to boot to a specific initial configuration, create a standard DFX run with your desired configuration to generate a full device bitstream. Alternatively, assemble a full design from the black box checkpoint of the parent run combined with the routed RM checkpoint from an abstract shell run. Generate the full design bitstream using write_device_image (Versal targets) or write_bitstream (FPGA targets).