Vitis Environment Design Methodology - 2022.1 English

Versal ACAP Design Guide (UG1273)

Document ID
UG1273
Release Date
2022-04-27
Version
2022.1 English

Prerequisites

Prior to starting development, you must choose the Versal device that is best suited for your application and partition the design into functions targeted to the PS, AI Engine, and PL, depending on the application requirements. At this point, you must have an understanding of the following:

  • System design considerations, such as throughput and latency
  • Domain and inter-domain capabilities, including compute and bandwidth
  • Dataflow and control flow throughout the entire system and the various subsystems

In addition, you must consider the type of platform to target. You must plan and design for the peripherals and interfaces on the board and the memory resources available on your custom board.

Methodology Overview

The following figure shows a high-level representation of the development methodology based on the Vitis environment design flow.

Figure 1. Development Methodology for the Vitis Environment Design Flow

The Vitis environment development methodology reflects the heterogeneous nature of Versal ACAP systems, which typically consist of PS, PL and AI Engine functionality. Using the Vitis tools, you can develop and verify these components independently and gradually integrate them to form the final system.

The Vitis environment design flow is an iterative process that might loop through each step multiple times, adding layers or elements to the adaptable system through subsequent iterations. Teams can iterate through the early steps more quickly and take more time with later steps, which provide more detailed performance data.

Best Practices

The foundation of the Vitis environment design methodology is an iterative approach and parallel development. As a result, Xilinx strongly recommends the following best practices:

  • Develop the adaptable subsystem and the custom platform in parallel.

    A well-partitioned system means that these two elements can be developed and verified independently, saving time and effort.
  • Debug and verify the AI Engine graph and each of the PL kernels individually before proceeding with integration.

    Taking this approach maximizes the chances of rapid convergence during the integration phase. It is much easier to debug integration issues when all components are known to be correct.
  • Use a standard Xilinx platform (such as the vck190) to integrate and verify the adaptable subsystem comprised of the AI Engine graph and PL kernels before targeting the custom platform.

    Xilinx platforms are pre-verified and ready to be deployed on hardware. By using a standard Xilinx platform, developers of AI Engine graphs and PL kernels can verify the adaptable subsystem using simulation or hardware boards without the uncertainties and the complexities of the custom platform.
  • Ensure performance goals are met at each stage of the flow.

    Performance results do not improve when running the full system in hardware versus simulating individual components in isolation. Therefore, it is essential to thoroughly check for and debug any performance issues as early as possible in the flow. Ensuring that performance goals are met at the component level is easier than in the context of a complex system that includes interactions between all of the components.