At this point, all remaining Reconfigurable Modules can be implemented within these shells. Each RM can be implemented in parallel in separate Vivado sessions if desired, as each RP can be managed independently. This can be done not only for a specific shell, e.g. for the u_count instance, but for all Reconfigurable Partitions in the design. Unlike within the project flow where the focus is on full design configurations, the focus for the Abstract Shell approach is on the Reconfigurable Modules.
- Start a new Vivado session to work independent of the initial VCU118 example
design project. In the Tcl Console, navigate to the tutorial directory.Important: Use the same methodology in the Abstract Shell run as was used in the run that created the original implementation. Vivado project mode uses the add_files / link_design approach, and that is continued here. If you used open_checkpoint and read_checkpoint -cell to build the initial design, continue that approach for the Abstract Shell implementation run.
- Load an Abstract Shell checkpoint instead of the full static
checkpoint.
add_files ./abstract_shell/ab_sh_count.dcp
- Then add the post-synthesis netlist for only the count_down
module.
add_files ./project_dfxc_vcu118/project_dfxc_vcu118.runs/count_down_synth_1/count.dcp
set_property SCOPED_TO_CELLS {u_count} [get_files ./project_dfxc_vcu118/project_dfxc_vcu118.runs/count_down_synth_1/count.dcp]
- When linking the design, only reference the u_count RP.
link_design -mode default -reconfig_partitions {u_count} -part xcvu9p-flga2104-2L-e -top top
- Implement the design normally, then when it is time to save the routed design, save both the
complete current image (Abstract Shell plus Reconfigurable Module) as well as
the RM-only
checkpoint.
opt_design
place_design
route_design
write_checkpoint -force ./abstract_shell/abs_count_down/abstract_shell_count_down_routed.dcp
write_checkpoint -force -cell u_count ./abstract_shell/abs_count_down/rm_count_down_route_design.dcp
Repeat these steps for the shift_left module, adjusting the file names and commands accordingly. Tcl scripts for both count_down and shift_left abstract shell implementation can be found in the tutorial directory to automate these steps. Script names are:-
abs_impl_count_down.tcl
-
abs_impl_shift_left.tcl
In the following images compare the count_down RM within the Count RP Abstract Shell with the module-level checkpoint for the count_down RM alone. Only the former should be used for partial bitstream generation, as the latter does not contain static design information in the dynamic region.
Figure 1. RM count_down within the RP Count Abstract ShellFigure 2. RM count_down without its Abstract ShellAt this point you will have a collection of routed static and RM checkpoints, where all the RM checkpoints are in sync with the static design.
Note: Before considering partial bitstream generation, PR Verify should always be done. PR Verify compares multiple design images where RMs differ but static is the same to ensure all DFX rules have been followed. If full configuration assembly is done, then PR Verify can be run in the standard way, comparing the entire static design for each checkpoint. However, PR Verify can also be done in the Abstract Shell context, comparing the initial Abstract Shell to the shell with the routed Reconfigurable Module. -
- Using the checkpoints created above, this verification check can be done if
no checkpoints are currently open:
pr_verify ./abstract_shell/ab_sh_count.dcp ./abstract_shell/abs_count_down/abstract_shell_count_down_routed.dcp
Alternatively, if a routed Abstract Shell checkpoint is still open in Vivado, you can use the -in_memory option to compare to the original shell. For example, if the Abstract Shell for u_count with count_down implemented within it is still open use this command to run PR Verify:
pr_verify -in_memory -additional ./abstract_shell/ab_sh_count.dcp
Note that the comparison here is between the Abstract Shell for u_shift with a black box and the Abstract Shell for u_shift with either shift_left or shift_right implemented within it. The goal is to compare different RM implementations with command static checkpoints. PR Verify will fail if:
- A full static design checkpoint is compared to an Abstract Shell checkpoint
- An RM checkpoint is loaded without its Abstract Shell
- Abstract Shells for different Reconfigurable Partitions are compared