The abstract shell feature was released in the Vivado Design Suite 2020.2 for all AMD UltraScale+™ devices and provides a few key advantages over the standard DFX flow.
What are Abstract Shells?
The standard DFX flow in Vivado tools requires multiple passes through the implementation tools. The first pass establishes the place and route results for the static design along with one reconfigurable module (RM) per reconfigurable partition (RP). This static design image is the platform that is configured into the target device to remain operational during subsequent partial reconfiguration events. Each successive pass through implementation uses the locked static image as the framework to implement all remaining RMs. You are not permitted to modify the static design to ensure consistent context, but the static design must be opened in memory to allow the Vivado tools to understand the working design environment. Even if a target reconfigurable region is very small, the full static design image must be opened, which takes time and memory.
The abstract shell flow creates a trimmed down version of static design for a given RP. Fundamentally, an abstract shell is the minimal design image needed to provide the context for implementing a new RM and generating a partial bitstream for that module. The logical design of the shell contains the boundary interface to the module instantiation. The Pblock of the partition, including the expanded routing region, is captured as part of the design constraints, as are any clocking and boundary timing requirements. All logical and physical resource usage within the region is included to ensure the RM does not try to use anything already consumed by the static design. A partial bitstream is built for a physical region of the device and contains programming information for both static and dynamic parts of the design. It is critical that the static parts of these bitstreams remain absolutely identical.
The optimized abstract shell provides the following key benefits:
- The shell checkpoints can be significantly smaller than a full shell. This lowers the compile time and memory use for new RMs.
- For designs with more than one RP, runs can be set up to implement all RMs in parallel, because full design configurations are not needed.
- For scenarios where multiple users are involved, design security is a benefit. Because the vast majority of the static design is removed, the vast majority of proprietary design information is not visible in the abstract shell.
- Any licensed IP in the static design are not included in their entirety in the abstract shell. This means that license checks are bypassed during abstract runs.