You can use the Dynamic Function eXchange (DFX)-based design flow in the Vivado tools to create an extensible Xilinx support archive (XSA) file for use in the Vitis software platform to create applications for acceleration. Use the following steps in the hardware platform development process in the acceleration platforms. Software developers import the XSA file into the Vivado tools to create an extensible XSA file.
-
Vivado IP integrator block design
container flow
Use the Vivado IP integrator block design container (BDC) flow to create DFX partitions. The BDC feature converts a hierarchical block in the IP integrator canvas into a block design (BD). You can enable DFX in this new BD, which can then can be used in the Vitis environment for linking acceleration logic. For more information, see this link in the Vivado Design Suite User Guide: Designing IP Subsystems Using IP Integrator (UG994).
- Platform setup
Use the IP integrator Platform Setup window to select different interface types in the platform block design, including AXI Port, AXI Stream Port, Clock, Interrupt, and Memory. You can also assign the platform name, version, vendor, and board information in the Platform Setup window. For more information, see this link in the Vivado Design Suite User Guide: Designing IP Subsystems Using IP Integrator (UG994).
For more information on DFX and non-DFX embedded platform creation, see this link in the Vitis Unified Software Platform Documentation: Application Acceleration Development (UG1393).
- DFX Wizard
After the targets are generated for the design sources, the DFX Wizard is available in the Flow Navigator window. You can define DFX configurations and associate the DFX configurations with implementation runs. For more information, see the Vivado Design Suite User Guide: Dynamic Function eXchange (UG909).
- Floorplanning
Use Pblock constraints to assign the DFX partition to a physical region in the device that can be used by the Vitis environment for accelerated applications implementation. For more information, see the Vivado Design Suite User Guide: Dynamic Function eXchange (UG909).
- Minimal implementation for boot image creation
Keep a minimal amount of logic in the reconfigurable partition BDC, which you can use for implementation during platform creation in the Vivado tools. This helps to reduce the device image size, which you can use as a boot image for the platform. While this minimal configuration can be the first image delivered to the device upon power-up, it should not be the parent configuration when compiling the design in Vivado. The parent configuration should be the largest, most complex, and/or most demanding of interfaces of all reconfigurable modules for a given reconfigurable partition.
- Hardware export
After initial implementation is complete, you can use the
write_hw_platform
command to export the extensible XSA file. The XSA file includes the following contents:- DCP for static image of the platform
- Dynamic region block design for the Vitis environment to link to the accelerated software application
- Device image from the initial implementation
- Other metadata required for successful hand-off of hardware design from the Vivado to Vitis tools
To add new PFM properties to an existing platform without changing the initial implementation and device image to avoid updating the boot image update, use the following steps.
- Open the archived project used to create the original platform.
- Modify the BD associated with the reconfigurable partition (RP), and save the BD.
- Make sure that initial implementation results are still up to
date.Note: Only the out-of-context (OOC) run for the modified RP BD should be out of date due to the modification.
- Export the modified platform using the
write_hw_platform
command.
When modifying the platform, be aware of the following:
- Any synthesis and implementation associated with the static region must stay up-to-date after the platform modification process. Reimplementing the static region results in changes to the device image used for implementing the static region.
- Do not change the static-RP interface. Changing the static-RP interface results in the initial implementation becoming out of date, which requires you to re-implement your static region (boot image).