Step 3: Create Abstract Shells - 2024.2 English - 2024.1 English

Vivado Design Suite Tutorial: Dynamic Function eXchange (UG947)

Document ID
UG947
Release Date
2024-11-13
Version
2024.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. The following figure shows the full design checkpoint on the left and the static-only checkpoint on the 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


    Note how much of the static design is no longer present. Visually this is quite clear for this simple design – compare the figure in step 1 with the figure in step 4. 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.

  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