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.
The Vivado Simulator provides an interactive mechanism to force a signal, wire, or register to a specified value at a specified time or period of time. You can also force values on objects to change over a period of time. This blog describes techniques to create test cases in simulation using Vivado Simulator by forcing certain data pattern on core interfaces.
When designing a system with Versal™ ACAP Integrated Block for PCI Express IP, designers can run into issues where the system halts due to a certain incoming packet or incorrect toggling of signals. To debug such issues in hardware could be difficult and time consuming as this would require debugging using tools such as ChipScope.
Vivado Simulator's 'force' command feature can be used to reproduce issues by injecting packets and toggling signals at any specified time.
The ILA core can be configured at core generation or insertion time to have advanced trigger capabilities that include the following features:
• Trigger state machine (TSM) consisting of up to 16 states. • Each state can consist of one-, two-, or three-way conditional branching. • Up to four counters can be used in a trigger state machine program to keep track of multiple events. • Up to four flags can be used in a trigger state machine program to indicate when certain branches are taken. • The state machine can execute "goto", "trigger", and various counter and flag related actions.
If the ILA core in the design that is running in the hardware device has advanced trigger capabilities, the advanced trigger mode features can be enabled by setting the Trigger mode control in the ILA Properties window of the ILA Dashboard to ADVANCED_ONLY or ADVANCED_OR_TRIG_IN.
For more information on using the ILA Advanced Trigger Features, see (UG908).
This blog illustrates how the ILA advanced Trigger feature can be used to debug designs with the Versal ACAP Integrated Block for PCI Express IP. The same approach could be used for debugging any other Xilinx PCI Express IP cores or any designs.
ORAN Hardware projects on GitHub are designed to demonstrate different use cases on ZCU102 or ZCU111 boards. This blog will show you how to generate the design and use the API to configure your CC settings after the board is booted.
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.
This Blog entry is intended to illustrate an AXI DMA Linux user space example which sends data to the AXI Stream Data FIFO from the PS DDR and writes data on the PS DDR which is received from the AXI Stream Data FIFO.
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.
This article explains how a sequential always block in Verilog code is interpreted by a Synthesis tool to determine the clock and any asynchronous control signals, along with their active values/polarity.
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