Changed Behavior - 2023.2 English

Vitis Unified Software Platform Documentation: Embedded Software Development (UG1400)

Document ID
UG1400
Release Date
2023-12-13
Version
2023.2 English

The following table specifies differences between this release and prior releases that impact behavior or flow when migrating.

Table 1. Changed Behavior Summary
Area Behavior
Vitis IDE

The Vitis Unified IDE is now the default GUI when launching with the vitis command. To launch the classic Vitis IDE, run vitis --classic.

To refer to information about the classic Vitis IDE, visit the 2023.1 or earlier version of the documentation.

v++ The --freqhz command has been introduced to replace most other clock management commands. Use --freqhz to specify clocks for AI Engine components, HLS components, and v++ --link commands for System projects, as described in Managing Clock Frequencies.
Vitis HLS

xparameters.h no longer contains DEVICE_ID definitions. Instead the BASEADDR definition is used. AMD drivers and libraries handle this change. However, if you have legacy code, you need to be aware of this change. You need to change the way your software application addresses the hardware module through X<DUT>_Initialize and X<DUT>_LookupConfig driver functions.

Vitis HLS

The initialization behavior of ap_int/ap_uint/ap_fixed/ap_ufixed is changed to be more compatible with the C builtin type (int, float...).

ap_int<N> A[N]; // uninitialized, both 23.2 and previous releases
ap_int<N> B[N] = {0}; // With 23.2, the whole array is initialized \
to zero. With previous releases, only the first element is initialized to \
zero, other elements are uninitialized. 
ap_int<N> B[N] = { }; // With 23.2, the whole array is initialized \
to zero. With previous releases, it is uninitialized.
Vitis HLS

The original qdma_axis<w, 0, 0, 0> has been removed from clib and is replaced with:

template <std::size_t WData, std::size_t WUser, std::size_t
                        WId, std::size_t WDest>
using qdma_axis = hls::axis<ap_uint<WData>, WUser, WId,
                        WDest, AXIS_ENABLE_ALL ^ AXIS_ENABLE_STRB, false>;
Vitis HLS

In the 2023.2 release the timing model used by the scheduler was changed so that the HLS compiler timing predictions more closely match the Vivado Design Suite. This causes the delay model to be more pessimistic. Major changes include the delay of an AXIS stream interface, and the use of complex enabling conditions for pipeline control. As a result of these changes it is expected that both latency and II can change for designs that were passing before this release.

If a design was meeting timing in HLS and Vivado before, you can restore the original II and latency by adding such constraints via pragmas or directives. You can also reduce clock uncertaintly using the add_clock or set_clock command. With a better HLS timing model, uncertaintly can be reduced. But II constraints (and latency constraints if needed) are a more deterministic mechanism to achieve the same goal.

Vitis HLS Assert is now supported.
Vitis Embedded Software Development The SDT (System Device Tree) is a new concept in the Vitis Unified flow. Previously, in the Vitis Classic flow, the HW metadata was extracted directly from the XSA using the HSI API in an "AD Hoc" manner as required by Vitis tools, such as extracting processors for platform creation or extracting IP for BSP creation. In the Vitis Unified flow, the SDT is generated when you generate the platform. This is used to provide the hardware metadata to Vitis via the Lopper framework.
Lopper is a Python based framework that is used to extract system metadata from the System Device Tree. The Lopper Framework API is not exposed to you via Vitis. Instead, the Vitis Python API such as Platform component creation would use the underlying Lopper Framework API. The Lopper framework is also used to generate the xparameters.h, and the driver initialization files too.

MLD/MDD MSS filesets are removed and replaced by YAML and CMake filesets.

While xparameters.h is still generated by Lopper Framework, it does not contain DEVICE_ID definitions. Instead, the BASEADDR definition is used. AMD drivers and libraries handle this change. However, users with legacy code need to be aware of this change.