Step 3: Create Abstract Shells - 2020.2 English

Vivado Design Suite Tutorial: Dynamic Function eXchange

Document ID
UG947
Release Date
2021-02-23
Version
2020.2 English

By default, in the DFX flow, multiple design checkpoints will be written after place and route of the parent configuration completes. In addition to the full design routed checkpoint, the Vivado project flow will create a static-only design checkpoint that will be the starting point for all child runs by calling update_design -black_box for each Reconfigurable Partition, followed by lock_design -level routing. Moreover, module-level checkpoints are written for each RM in the parent configuration by calling write_checkpoint -cell. No user intervention is necessary to create these files.

  1. Examine the files created for the parent configuration. Within Windows Explorer or in a shell console, navigate to the impl_1 subdirectory:
    \abstract_shell\dfxc_vcu118\project_dfxc_vcu118\project_dfxc_vcu118.runs\impl_1
    Examine the different design checkpoints and their sizes. Note that file sizes listed here may be slightly different depending on Vivado tool version, implementation run options and operating system. Key files include:
    • top_routed.dcp (58,284 KB) – full routed design including one RM per RP
    • top_routed_bb.dcp (55,819 KB) – static only design with locked placement and routing and black boxes for each RP
    • u_count_count_up_routed.dcp (1,267 KB) – routed module-level checkpoint for the count_up RM instance
    • u_shift_shift_right_routed.dcp (463 KB) – routed module-level checkpoint for the shift_right RM instance

    It is no surprise the Reconfigurable Module checkpoints are much smaller than the static design checkpoints given their size and complexity in this design.

    Figure 1. Full Design Checkpoint (left) and Static-Only Checkpoint (right)
  2. Create Abstract Shells for both the u_count and u_shift instances. Make sure your current working directory in the Tcl Console is the <extract_dir> directory, the same place where the project_dfxc_vcu118, sources and abstract_shell folders reside.

    write_abstract_shell -force -cell u_count ./abstract_shell/ab_sh_count.dcp

    write_abstract_shell -force -cell u_shift ./abstract_shell/ab_sh_shift.dcp

    Each call to write_abstract_shell first creates a copy of the full design checkpoint in memory, then runs the following steps automatically:
    • Carves out the target Reconfigurable Partition (using update_design -black_box)
    • Locks the remaining design (including any other Reconfigurable Modules)
    • Writes the Abstract Shell for the target RP
    • Runs pr_verify for this checkpoint compared to the original fully routed design

    This process does take longer than a simple call to write_checkpoint, but in nearly all cases the runtime savings for RM compilation will be worth this initial investment.

  3. Examine the sizes of the Abstract Shells, comparing them to the size of the top_routed_bb.dcp full shell checkpoint.
    Again, sizes may vary, but for the initial release of Vivado 2020.2 in Windows, file sizes for the Abstract Shells are:
    • ab_sh_count.dcp (1,785 KB) – Abstract Shell for the Count RP
    • ab_sh_shift.dcp (1,699 KB) – Abstract Shell for the Shift RP
  4. Open each Abstract Shell checkpoint to examine the contents.

    open_checkpoint ./abstract_shell/ab_sh_count.dcp

    Figure 2. Abstract Shell for the Count RP (top two SLRs only)
    Note how much of the static design is no longer present. Visually this is quite clear for this simple design – compare Figure 1 and Figure 2. You will see that only one RP remains in each Abstract Shell – the shell for u_count does not include u_shift and vice versa. But even though the vast majority of the static design has been removed, parts do remain, including elements from the DFX Controller and DFX Decoupler design, as they have connectivity to each target RP.
    Figure 3. Remaining Hierarchy for the u_count Abstract Shell
  5. Run a routing report to confirm that the Abstract Shell is intact.

    report_route_status

    This step is optional and merely shows that the Abstract Shell is a valid design database with zero routing errors.

  6. Close the Abstract Shell checkpoint.

    close_project