In the previous article of the AI Engine Series we had a look at the Vitis full system example which includes an AI Engine application. In this new entry, we will build the system, look at some of the generated outputs and run the system in hardware emulation using QEMU.
In the previous AI Engine Series articles (1 to we looked at an AI Engine application on the AI Engine domain.
However, as we have seen in part one of the AI Engine Series, to run an AI Engine application on Versal hardware you will most likely need to use three domains working together: the AI Engine, The Processing System (PS) and the Programmable Logic (PL).
The integrated block for PCIe Rev. 4.0 with DMA and CCIX Rev. 1.0 (CPM4) consists of two PCIe controllers, DMA features, CCIX features, and Network on Chip (NoC) integration.
The Versal™ ACAP CPM Mode for PCI Express enables direct access to the two high-performance, independently customizable PCIe controllers. The CPM4 uses up to 16 Versal device GTY channels over the XPIPE.
Application designs can also interface to the CPM4 with soft logic and clocking resources in the programmable logic. Because CPM4 is an integrated block, the user cannot probe the internal signals with Vivado ILA for debugging purpose.
The CPM4 block records various statuses and its configurations in registers. These registers are documented in (AM012).
This blog will illustrate how to read these registers and provides suggestion on which registers to read for debugging purpose.
Currently the DDR calibration done signal is controlled by a register poll in the PLM.
This is a useful signal for users that want to verify that the DDR is indeed calibrated from the PL. In this demo, I have modified the PLM to add this functionality, and re-packaged the PDI with the updated PLM prior to exporting from Vitis™.
However, The techniques seen here can also be used for other applications where the user wants to add custom CDO or applications to the PDI prior to the Software Hand-off.
The demo below shows how to launch and debug a standalone application from the Vitis GUI on a VCK190 running Linux. The usual flow is to include the R5 standalone application ELF in the PDI. In this case the power up of the cores and setting up of the TCM memories is handled by the PLM.
Because the PLM is already running when Linux is booted, the instructions below describe how to do the same functions as the PLM by using power management API calls in Linux.
This blog demonstrates the use of Vivado ILA for debugging of a Versal™ ACAP in CPM Mode for PCI Express Designs designs.
The interface inside the CPM or the interface between the CPM and NOC cannot be probed using Vivado ILA as they are part of an integrated hard block. However, the interface between the NOC and the PL for the BRAM Controller can be probed using Vivado ILA.
This is particularly helpful as it allows you to monitor the incoming packets from a PCIe link or data being transferred from the PL region to the NOC and CPM and then finally to the link partner via a PCIe link.
This Blog covers how to use the AXI Interrupt Controller (INTC) in cases where you need to route more that 16 interrupts to the PS from IP cores in the PL. We are using Xilinx peripherals including GPIOs in the Vivado design.
The example design is created in the 2020.2 version of Vivado, targeting a VCK190 evaluation board. Interrupts are tested on PetaLinux 2020.2, and the design Tcl and system-user.dtsi file are attached.
In this blog I will share the steps for running the Hello world on industry first 7nm Versal ACAP devices. You will learn about the similarities and differences between the Zynq MPSoC and Versal ACAP design flow.
This Versal™ example design will show how to run AXI DMA standalone application example on a VCK190 evaluation board and is intended to demonstrate use of the AXI DMA standalone driver which is available as part of Vivado and Vitis™.
In this blog, we will discuss how to run an AXI DMA bare-metal application to make use of DMA standalone driver in the 2019.2 release. To quick test with design files in the 2020.2 version, refer to this AXI DMA GitHub Example.
The Multirate Ethernet MAC (MRMAC) provides high-performance, low latency Ethernet ports supporting a wide range of customization and statistics gathering. The MRMAC includes a variety of new features and design flows that enable seamless rate change, statistics management and integration with the GT blocks.
This blog is intended to help customers with 100G Ethernet (CMAC) hard block or soft 10G/25G/40G or 50G Ethernet IP core experience to design efficiently with Versal™ MRMAC. The blog will cover key differences between the UltraScale+ and Versal IP including:
AXI Stream Interface for Packet Data
New MRMAC Flex Port Feature
Statistics and Management
1588 PTP Support
Design Flow Considerations
Getting Started with the Versal MRMAC Example Design
In the first 3 articles of the AI Engine Series, we went through the different files needed for an AI Engine application. In this entry we will run the AI Engine compiler for an X86 target and have a look at the different output it produces.
There are a host of IP cores available on the Versal™ Control, Interfaces and Processing System (CIPS) that users can access from the APU or RPU on the CIPS.
However, in this blog we will instead discuss how we can leverage these IP cores from a Soft Processor in the Programmable Logic. In this blog the Soft Processor will be the MicroBlaze. I will show how you how to execute from the PS DDR and how to leverage the UART on the CIPS.
There are also some neat tricks on how to modify the PDI to include a bootloop and custom CDO files that would have other application outside of the scope of this blog.
Inthe previous entry in the AI Engine Series, we had a look into the graph file which is the top level of the AI Engine application. We have seen how this graph file is used to instantiate and connect kernels together and to the ports of the AI Engine array.
In this entry we will look at the kernel. In the template we are looking at, the 2 kernels called first and second are implementing the same function which is called simple.
Inthe previous article, we had a first look at an AI Engine (AIE) application for Versal within the Vitis 2020.2 unified software platform.
We have seen the structure of an AIE application project and how an AIE graph is connected to a simulation platform. We also looked at some APIs to initialize, run and terminate the graph. In this article we will have a closer look at the AIE graph inside the project.
Last July, in the article titled Versal ACAP AI Engines for Dummies I introduced the AI Engine (AIE) array which is present in some Versal™ ACAP devices. In this new series of articles, the AI Engine Series, we will provide some examples of how to use the AI Engine tools integrated into the Vitis™ 2020.2 unified software platform.
This first article is an introduction to the AIE programming environment.
To create a transceiver setup for several quads for Versal it is recommended to start with the transceiver bridge IP, choose your settings there and then let Vivado create the necessary quads for this setup through block automation.
The bridge IP allows for only one setup. So, how is it possible to have separate setups for TX and RX in the same transceiver?
This blog entry contains some examples of how to do this.
In the Versal™ families, the System Monitor is a part of the PMC block.
In this blog entry we will walk through an example of how to set up the System Monitor in the Control, Interfaces and Processor System (CIPS) Wizard in IP Integrator and read the values in the Vivado Hardware Manager.
This Blog entry is intended to illustrate how to access the AXI BRAM from the Versal™ APU through the NoC.
The example design is created in the 2020.2 version of Vivado® and targets a VCK190 evaluation board. The Tcl script for this design and application code are available in the attachments to this blog entry.