At the end of these implementation and bitstream generation processes, you have full and partial bitstreams just as you do with the standard DFX flow. For single-user scenarios, follow the recommendations and considerations outlined in Design Considerations and Guidelines for All Xilinx Devices, Design Considerations and Guidelines for 7 Series and Zynq Devices, and Design Considerations and Guidelines for UltraScale and UltraScale+ Devices in this document.
It is critical to keep all partial bitstreams in sync with the same implementation version as the full device bitstream. This must be part of the partial reconfiguration controller functionality, wherever and however this is managed. This is especially important when using Abstract Shell, as bitstreams can be created in different environments by different users. PR Verify confirms consistency, but once these bitstreams leave Vivado, it is up to the system design to maintain that consistency.
For multi-user environments, there are scenarios where the designer of the RMs does not have access to the static platform design. If you only have access to an Abstract Shell, you can only generate partial bitstreams. In such a scenario, you must also be given an initial device bitstream to program the static design. This full device bitstream could have a gray box (no functionality, just LUT tie-offs) in the target RP, or any other initial “hello world” type of application. Configure the device with this initial image, then use Dynamic Function eXchange to load (and reload) their custom applications with the partially created bitstreams.
Any changes to the static platform design require updates to the full device bitstream and any Abstract Shell checkpoints to keep all bitstreams in sync.