The Abstract Shell design flow is nearly identical to the standard non-project Dynamic Function eXchange design flow. The differences are limited to the steps where the static design checkpoint is written from the initial (parent) implementation and where the static design is opened to begin implementation of the second RM (and beyond) for each RP.
Synthesis and implementation of the first configuration is no different with Abstract Shell than it is with the DFX standard flow. Once the initial full design checkpoint is implemented, an Abstract Shell for each RP can be created. If a design has more than one RP, each one has its own Abstract Shell. Any RMs for these RPs can be independently processed.
UltraScale+ and Versal devices are supported by the Abstract Shell flow, but only UltraScale+ is supported in non-project mode. The commands in this section summarize the details about how the flow is run, but users should only apply these directly via Tcl for UltraScale+ targets. For Versal designs, use the IP integrator project flow described in Vivado Project Flow.
With the fully routed initial design image open in memory, with an RM
present in each RP, use the
command to create an Abstract Shell for a target RP. If more than one RP exists within a
design, the command must be run separately for each RP. This command does the
- Carves out the target RP (using
- Locks the remaining design (including any other RMs, using
lock_design -level routing)
- Writes the Abstract Shell for the target RP (using
pr_verifyfor this checkpoint compared to the original fully routed design
write_abstract_shell -cell <arg> [-force] [-quiet] [-verbose] <file>
||Specifies the full hierarchical name of the RP. Only one RP can be selected.|
||Overwrites an existing checkpoint of the same name.|
||Ignores command errors.|
||Suspends message limits during command execution.|
||Specifies the full or relative path to the checkpoint (DCP) to be written.|
When you look at the Abstract Shell checkpoints, you see they are smaller than the full design static checkpoint. For simple designs with large dynamic regions, they can be 80-90% of the size, depending on the floorplan and implementation. For larger designs, with more static logic, the size reduction is more considerable.
Abstract Shells contain only the logic and routing at the periphery of the target RP needed to implement new RMs into that RP. This includes any routing within not only the target RP Pblock but the expanded routing region as well. Much of the surrounding logic, including logic within the expanded region, is removed, and this configuration information is skipped in the resulting partial bitstream. Timing and boundary constraints are included in the shell as new modules implemented in this context inherit these goals from the static design.
Before continuing with Abstract Shells, you can confirm they have been
constructed successfully by running two types of checks. First, consistency with the
full static design it was created from is automatically confirmed when
write_abstract_shell is called by running PR Verify. You
can also perform this PR Verify check manually by comparing the Abstract Shell
checkpoint to the static-only design after black boxes have been established and
lock_design has been run.
The second check validates the routing status of the shell itself. This
can be done by opening the Abstract Shell and calling
report_route_status to check the status of the checkpoint.
write_abstract_shellcommand returns this error:
ERROR: [Common 17-69] Command failed: Failed to create design checkpoint. In general, if tool errors or issues with place and route for new RMs in an Abstract Shell checkpoint are encountered, check the behavior using a full static design checkpoint first.