System Validation Planning - 2021.1 English

Versal ACAP System and Solution Planning Methodology Guide (UG1504)

Document ID
UG1504
Release Date
2021-07-26
Version
2021.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).

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

Use tools like IBERT

Hardware only

MAC throughput

Memory throughput

XPE for estimation

Merge power domains and evaluate on board

Embedded system

JTAG

QSPI

Use tools like IBERT

Requires XRT or Linux for interaction

Software performance like PS benchmarks

Hardware performance

Embedded AI Engine system

JTAG

QSPI

Use tools like IBERT

Requires XRT, Linux, and AI Engine drivers for interaction

Software performance with AI cores with images/sec

Mega samples per second (MSPS) for wireless designs

Note: For more information on subsystem functional validation, see this link in the Vivado Design Suite User Guide: Programming and Debugging (UG908).