Abstract Shell Design Flow - 2023.1 English

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 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. This command does the following:

• Carves out the target RP (using update_design -black_box)
• Locks the remaining design (including any other RMs, using lock_design -level routing)
• Writes the Abstract Shell for the target RP (using write_checkpoint)
• Runs pr_verify for this checkpoint compared to the original fully routed design

write_abstract_shell  -cell <arg> [-force] [-quiet] [-verbose] <file>

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.