Abstract Shell for Multi-User Environments

Using the abstract shell flow is a tremendous benefit when employing DFX for multi-user environments. DFX enables you to build a solution with a dynamic application space within a AMD device. You can build a platform that can be passed to another user to later fill in the space with any number of applications to be swapped on the fly. The platform built by the primary user locks down key details that must not change including memory interfaces, communication channels, and design safety and security features. The secondary user inserts their functionality into this locked context to be accelerated in hardware. In this scenario, using the standard DFX design flow, the primary user shares the full static design checkpoint with the secondary user, potentially exposing design secrets. The secondary user also needs licenses for any IP contained within the static design, even though they are not implementing that part of the design.

With the abstract shell flow, the bulk of the static design is stripped away, hiding proprietary design information. Some fragments might still remain based on connectivity with the target dynamic region, which means that the primary user needs to examine the contents of the abstract shell before distributing it. However, in nearly all cases, there is not enough information to reverse engineer the functionality. For the same reason, IP license checks are bypassed for any IP in the static shell, because it is impossible to use that IP other than how it is implemented by the primary user.

Important: Because the IP functionality is passed to the secondary user within the static design bitstream, it is the responsibility of the primary user to review the terms and conditions of any IP to ensure they have redistribution rights for that intellectual property.

When programming the device in a single-user environment, the standard DFX approach is still good. Any full design image can be assembled by linking static and reconfigurable routed checkpoints then calling write_bitstream to generate a full device BIT file. However, for multi-user environments, the primary user must supply an initial full-device bitstream to initially program the AMD device. This image can have any sort of default application in the dynamic region, from a functionless gray box, to a hello world, to a test application that exercises some fundamental features of the system. Then, the secondary user partially reconfigures the device to load in their accelerated functions using partial bitstreams generated from abstract shell runs.

Figure 1. Programming Flow for Multi-User Environments

This multi-user environment example shows all the benefits of DFX:

Hardware acceleration of applications with on-the-fly dynamic function swapping
Fast compilation through the Vivado DFX development flow
Removal of any sensitive design information from the static platform

It is critical that all full and partial bitstreams remain in sync for any DFX methodology, including the abstract shell. Even though partial bitstreams can be generated from within the abstract shell environment, they are compatible with the original static design used to create the shell. This can be confirmed by calling pr_verify to compare the abstract shell alone versus the abstract shell with any routed RM, or by reassembling different full-design configurations and running pr_verify again.

Abstract Shell for Multi-User Environments - WP533

Solution Efficiencies for Dynamic Function eXchange Using Abstract Shells (WP533)