System validation planning for Versal® ACAP requires that you build key infrastructure into the system, as defined in the previous chapters. This enables systematic validation of overall design features, performance, power consumption, and so forth, which are required to qualify a system as production worthy. This chapter covers key areas of focus when planning for system validation based on your system design type. For information on validation, see this link in the Versal ACAP System Integration and Validation Methodology Guide (UG1388).
Following are the typical steps when planning for system-level validation:
- Power-up and power supply check
- Basic boot and device configuration
- Bring-up of functional subsystems of the device
- Bring-up of software stack and any run time drivers or application
programming interfaces (APIs)Note: This step is optional for some systems.
- Performance validation
- Power validation
In the power-up and supply validation phase, the system designer must
refer to the
Versal
Architecture and Product Data Sheet: Overview (DS950) to ensure all
supplies are at the expected level and current consumption in various domains is as
expected. The system designer must plan to conduct testing on the voltage domains on the
boards based on the supply merging done in the system. The designer can obtain currents
in different domains using either XPE or report_power
based on the estimates for the design.
After the power supply and current consumption looks healthy, the next bring-up phase is usually device configuration. A typical method for initial device bring-up is to use the JTAG port on the Versal device. The device can be detected and addressed from the standard Vivado® Hardware Manager, as described in the Vivado Design Suite User Guide: Programming and Debugging (UG908). In addition, Versal ACAP has a sophisticated System Monitor that allows monitoring of the on-chip supplies and temperature. The hardware system designer can follow the requirements in the Versal ACAP System Monitor Architecture Manual (AM006) to enable the use of the System Monitor.
After initial bring-up, the focus in hardware-only systems is to bring up the internal hardened IP subsystems, including any complex GT and I/O as well as DDRMC subsystems in the design. For more information, see the hardware validation sections in the following resources:
- For NoC/DDR memory bring-up on silicon, see the Vivado Design Tutorials: Versal Network on Chip/Multiple DDR Memory Controllers and this link in the Versal ACAP Programmable Network on Chip and Integrated Memory Controller LogiCORE IP Product Guide (PG313).
- For initial bring-up of the AI Engine subsystem, see the Vitis Tutorials: Versal AI Engine Beamforming.
- For the PS subsystem, see the Versal ACAP Embedded Design Tutorial.
After the health of the overall Versal ACAP subsystems is established through the basic tests, the system designer can start the bring up of the actual functional model of the system. This typically involves some test development at a system level driven by the functionality of the overall system design. The test development might involve a software stack, depending on the type of system.
After establishing the basic functionality of the system design, the system designer can run performance-level test cases to calibrate and validate the key performance requirements. Following are examples:
- Signal processing throughput of a 64-antenna system, as shown in the Vitis Tutorials: Versal AI Engine Beamforming
- Images per second for image recognition in the Modified National Institute of Standards and Technology (MNIST) database using the LeNet convolutional neural network (CNN), as shown in the Vitis In-Depth Tutorial: AI Engine LeNet
- For hardware-only systems, NoC/DDR performance, as shown in the Vivado Design Tutorials: Versal Network on Chip/DDR Memory Controller Performance Tuning
With the design running at performance, the system designer can make power measurements for both static and dynamic power on the Versal device. To plan for power measurements, the system designer must ensure that the board design allows access to the power management integrated circuit (PMIC) interfaces, which enable live current measurements on the system running at performance.
The following table summarizes system validation based on your design type.
Design Type | Boot and Device Configuration | Subsystem Functional Validation | System Functional Validation | System Performance Validation Examples | System Power Validation |
---|---|---|---|---|---|
Hardware-only system |
|
Use tools like:
|
Hardware only |
|
|
Embedded system |
|
Use tools like:
|
Requires XRT or Linux for interaction |
|
|
Embedded AI Engine system |
|
Use tools like:
|
Requires aiecompiler, XRT, Linux, and AI Engine drivers for interaction |
|