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.
Even though project mode is not supported for Abstract Shell runs, the initial parent configuration can be set up and implemented using project mode within the Vivado IDE. All subsequent RM implement runs, however, must be implemented outside the project.
With the fully routed initial design image open in memory, with an RM present in
each RP, use the
write_abstract_shell 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.
- 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 may 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 may 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.