The figure above shows two paths through the linking process, starting with
the v++ --link
command. The first path is the
Vitis Integrated Flow in which the v++
command links the elements of the system,
automatically launches the Vivado tools for
implementation of the design, and outputs an .xclbin
or .xsa
file. The second path is the Vitis Export to Vivado flow in which the v++
command
links the elements of the system and outputs a .vma file for you to use in the Vivado tools for synthesis, implementation, and timing closure. These two
paths are explained below.
Vitis Integrated Flow
As shown in the figure above, the PL kernel compilation process results in
an object (.xo
) file whether the kernel is written
in C/C++ or RTL. During the linking stage, one or more PL kernels are linked with
the extensible platform to create the FPGA binary container file (.xclbin). For Versal adaptive SoC devices, the linking process also includes an
AI Engine graph application (libadf.a) and creates a fixed hardware platform
(.xsa) for use by the Vitis packaging process as described in Packaging the System.
vadd
kernel (.xo) with a
libadf.a graph archive and a Versal adaptive SoC platform, specifying the
.xsa file as the
output:v++ -t hw_emu --platform xilinx_vck190_base_202310_1 --link vadd.xo libadf.a \
--config ./system.cfg -o binary_container.xsa
This command contains the following arguments:
-
-t <arg>
- Specifies the build target. When linking, you must use the
same
-t
and--platform
arguments specified when compiling the PL kernels and AI Engine graph application. -
--platform <arg>
- Specifies the platform to link with the system design. In
the example command above the
custom_vck190
platform is a custom platform designed to work with the--export_archive
command. -
--link
- Link the kernels and platform into a system design.
-
<input>.xo
- Input object file. Multiple object files can be specified.
-
libadf.a
- Input AI Engine graph application.
-
--config ./system.cfg
- Specify a configuration file that is used to provide
v++
command options for a variety of uses. Refer to v++ Command for more information on the--config
option. - -o binary_container.xsa
- Specifies the output file name. The output file in the link stage will be an .xsa file due to the use of a Versal platform. The default output name is a.xsa.
Vitis Export to Vivado Flow
v++ --link --export_archive
creates a Vitis Metadata Archive (.vma)
file for export to the Vivado Design Suite. This
flow lets you open the linked system design in the Vivado tools for more directed synthesis, place and route, and timing
closure. v++ --platform custom_vck190 --link vadd.xo libadf.a --config ./system.cfg \
--export_archive -o hw-vadd.vma
This command is similar to the prior command, with the following differences:
-
--export_archive
- Specifies the creation of the
.vma
file to export to the Vivado Design Suite. This option stopsv++
from automatically running Vivado synthesis and place and route, and instead lets you manually launch and direct the implementation and timing closure of the design as described in Vitis Export to Vivado Flow. -
--platform custom_vck190
- The
--export_archive
command can only be used with a custom Versal platform designed with block design containers (BDC) required for this design flow. Refer to Introduction to Block Design Containers for more information. -
-o hw-vadd.vma
- Specifies the output file name for the
.vma
file produced by the--export_archive
command.
After Linking
After the linking step is complete, any reports generated during this process are collected into the <kernel_name>.link_summary. This collection of reports can be viewed by opening the link_summary in the Analysis view of Vitis analyzer, and includes a Summary report, System Estimate providing timing and resources estimates, System Guidance offering any suggestions for improving linking and the performance of the system. Refer to Working with the Analysis View (Vitis Analyzer) for additional information.
The linking process defines important architectural details of the system design. In particular, this is where the design is enabled for profiling or debug, where you specify the number of compute unit (CUs) to instantiate into hardware, where CUs are assigned to SLRs, and where you define connections from PL kernel ports to global memory or to AI Engine applications. The following sections discuss some of these build options.