Step 3: Set Up DFX Design Runs - 2023.2 English

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

   This creates all the IP and RTL products, and launches synthesis for all the components of the static design and IP within RMs. Generation and synthesis of the Reconfigurable Modules top levels will occur later, as they are in separate block designs.

   When synthesis completes, the DFX Wizard appears in the Flow Navigator.

2. Click Dynamic Function eXchange Wizard in the Flow Navigator.

   The steps in this wizard allow you to create full design “configurations” that combine static and dynamic portions of the design. With only a single Reconfigurable Partition, this design shows the simplest use case.

3. Click Next two times to step through the DFX Wizard until you get to the Edit Configurations page. Click the automatically create configurations link. This action results in three configurations to cover the three Reconfigurable Modules in the design.
4. 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
   
   
   
5. Click Next again.

   On the Edit Configuration Runs page, you will manually create the configuration runs to explore the options for the two flows. Note however that you have options to have full complements of Standard DFX or Abstract Shell runs created automatically.

   • Selecting Standard DFX creates one run per configuration as declared on the prior page. The first configuration on the list will be the parent run and the remaining ones will be child runs of that parent.
   • Selecting Abstract Shell creates one parent run, then one child run per Reconfigurable Module. In this design that also totals three runs, but for designs with multiple RPs, the number would be higher.
   
   
   

   There is no option to create a “mixed” set of run types – a parent run will only permit child runs of one type or the other. In this lab, you will create the full set of runs for both of these approaches, which means it is necessary to create two parent runs to accommodate the two flows.

6. Click the + icon in the upper left six times in total to create six runs. Enter the following for each run:

   Parent Run using Standard DFX

   • Run: impl_std
   • Parent: synth_1
   • DFX Mode: STANDARD
   • Configuration: config_up_ila
   • Uncheck the Auto Create Child Runs option

   First Standard Child Run

   • Run: impl_std_child_1
   • Parent: impl_std
   • Configuration: config_down_vio

   Second Standard Child Run

   • Run: impl_std_child_2
   • Parent: impl_std
   • Configuration: config_2count_ila

   Parent Run using Abstract Shell

   • Run: impl_abs
   • Parent: synth_1
   • DFX Mode: ABSTRACT SHELL
   • Configuration: config_up_ila
   • Uncheck the Auto Create Child Runs option

   First Abstract Child Run

   • Run: impl_abs_child_1
   • Parent: impl_abs
   • RM Instance: design_1_i/rp1:rp1_rm2_inst_0

   Second Abstract Child Run

   • Run: impl_abs_child_2
   • Parent: impl_abs
   • RM Instance: design_1_i/rp1:rp1_rm3_inst_0

   At this point, the DFX Wizard will look like this:

   
   
   
7. Click Next then Finish to create these Design Runs. The Design Runs tab shows these selections as defined in the wizard.
   
   
   Note: impl_1 is a default run that is always created, but in this case, you have not defined its properties in the DFX Wizard. This run can be removed by first setting impl_std or impl_abs as the active run (right-click on one of those other parent runs and select Make Active), then deleting impl_1 (right-click on impl_1 and select Delete).
8. Click Run Synthesis from the Flow Navigator. This runs synthesis for the top layer of each RM as well as for the top-level design. When synthesis completes, open the synthesized design.

   In the Netlist view there are black boxes for the Debug Hubs. These will be inserted later during opt_design.

   
   
   
9. In the Design Runs window, shift-click to select all the implementation runs. Right-click in this area and select Launch Runs.

   This action will kick off runs in the necessary order. Each parent run will run in parallel, as they do not depend on each other. Then after each parent run completes, each child below the parent runs will run in parallel.

   The insertion of Debug Hubs and stitching to debug cores happen during opt_design of implementation phase. For each implementation runs you will observe the following lines of code in the log file. Debug Hub insertion for the static part of the design happens only during parent implementation. For child implementation it happens within the context of a locked static design (standard or abstract) derived from the parent implementation.

   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
   

When comparing the results, this is what you will see:

• Parent run results will have identical results (timing score, critical warnings, etc.).
  • These runs use the same sources and options so the resulting placed and routed checkpoints will be identical.
• Compile time for the Abstract Shell parent run (impl_abs) will be slightly longer overall than the Standard DFX parent run (impl_std). The divergence point for these flows is after the full routed design checkpoint is written.
  • The Standard DFX run carves out the RP (using update_design -black_box) then locks the remaining static (using lock_design -level routing) to create a static-only checkpoint, design_1_wrapper_routed_bb.dcp.
  • The Abstract Shell run embeds these two steps in write_abstract_shell, and additional carving and associated checks are done to remove the bulk of the static design. This process takes longer, and results in abstract shell file abs_shell_design_1_i_rp1.dcp.
  • Compare the file sizes of design_1_wrapper_routed_bb.dcp and abs_shell_design_1_i_rp1.dcp. The full shell will be more than 3x the size of the abstract shell for this design.
• Compile time for the child runs will be longer when using the Standard DFX flow than for the Abstract Shell flow.
  • 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 will be reduced.

The final Design Runs window will show numbers that look like this:

On this machine, the Abstract Shell child runs took less than half the time of the Standard DFX child runs. For larger designs, especially those with multiple and/or relatively small Reconfigurable Partitions, the savings are even more dramatic.

• If you plan to continue to the hardware portion of the lab, select runs, right-click and select Generate Device Image. The runs you select what you would like to accomplish.
  • If you are only going to run the design on hardware, select one parent run with both of its child runs. This will provide the minimum file set to programming and then partially reconfiguring the target to explore ChipScope™ debug features.
  • If you would like to compare the standard and Abstract Shell flows through PDI generation, select all six runs to generate all device images.