System Validation Planning - 2022.1 English

Versal ACAP System and Solution Planning Methodology Guide (UG1504)

Document ID
UG1504
Release Date
2022-05-25
Version
2022.1 English

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:

Tip: You can bring up a majority of these hardened IP subsystems independent of the final system functional designs to check the basic functionality of the overall system integration.

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:

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.

Table 1. System Validation Summary
Design Type Boot and Device Configuration Subsystem Functional Validation System Functional Validation System Performance Validation Examples System Power Validation
Hardware-only system
  • JTAG
  • QSPI/OSPI
  • SD/eMMC
Use tools like:
  • IBERT
  • XSDB/XSCT
  • AXI-ILA/AXI-VIO
  • System Monitor
Hardware only
  • MAC throughput
  • Memory throughput
  • XPE for estimation
  • Merge power domains and evaluate on board
Embedded system
  • JTAG
  • QSPI/OSPI
  • SD/eMMC
Use tools like:
  • IBERT
  • Vitis™ Embedded Software Tools
  • ACAP Cockpit
  • System Monitor
  • XSCT
  • Linux Target Communications Framework (TCF), GDB, and Valgrind
Requires XRT or Linux for interaction
  • Software performance like PS benchmarks
  • Hardware performance
Embedded AI Engine system
  • JTAG
  • QSPI/OSPI
  • SD/eMMC
Use tools like:
  • IBERT
  • Vitis™ Embedded Software Tools
  • Vitis AI Engine Debugger
  • Vitis Analyzer
  • ACAP Cockpit
  • System Monitor
Requires aiecompiler, XRT, Linux, and AI Engine drivers for interaction
  • Software performance with AI cores with images/sec
  • Mega samples per second (MSPS) for wireless designs
  • AXI Performance Monitor (APM) core
Note: For more information on subsystem functional validation, see this link in the Vivado Design Suite User Guide: Programming and Debugging (UG908). For more information on the ACAP Cockpit, see the Xilinx Wiki: ACAP Cockpit.