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.
Embedded Linux development is split between the Linux image generation and the Linux application development. Xilinx provides PetaLinux tools for image generation and Vitis™ for the application development. But how you can bring both tools together and develop applications for the Linux image generated with PetaLinux? This blog entry explores how to use the sysroot generated in PetaLinux in Vitis and develop Embedded Linux applications with libraries.
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.
The UHD-SDI Subsystems RX/TX IP cores have several example designs available at the time of writing, but all are a variation of a pass-through design. For information on these designs, please see (PG289) and (PG290).
This Blog entry will instead outline how to create and run a TX only design targeting the ZCU106 development board.
Versal™ is an Adaptive Compute Acceleration Platform (ACAP) that is composed of a number of highly coupled configurable blocks. These blocks such as the NoC, AIE, PL, and CIPS (which itself has different domains; LPD, and FPD), all need to be configured at boot using the configuration set in Vivado.
With so many interconnecting blocks, this sounds complicated... but its not really. In this entry we will discuss these boot files, and how they are used.
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.
The Methodology report is a feature in the Vivado tool which helps to streamline the design process and achieve better QoR using the UltraFast Design Methodology (UFDM).
This blog entry gives some background on this report and the UFDM and also links to six related blog entries which contain examples of how the Methodology Report helps to improve Design QoR and saves you time in debugging the root cause of an issue.
The analysis in this blog entry is based on a real customer issue where they were seeing DDR4 post calibration data errors in hardware. The issue turned out to be timing related, but there was no violation in the timing report. The Methodology report was not the initial method used to pinpoint the root cause, but this blog will show you how this report would help to speed up the debug, or even to avoid the hardware failure.
This is part five of the Using the Methodology Report series. For all entries in the series, see here.
PetaLinux is a great utility that allows designers to easily create Linux images to run on their target platforms. PetaLinux will also create user applications and modules with a template Makefile and BB files so that they can be built and added to a rootfs.
However, for users trying to develop a module, creating, building, and deploying from the command line speeds up the process.
In this blog entry we will discuss how to create a module and then build and deploy it on a ZCU104 board outside of the PetaLinux flow. Once users are content that the module is working, they can then add it to the rootfs.
The analysis in this blog entry is based on a real customer issue where they were seeing rare bit flips in the field. This blog entry will show some of the debug techniques we used to narrow down the root cause and fix the issue.
In the end, the issue was caused by incorrect handling of clock domain crossing (CDC) which was highlighted by the report_methodology and report_cdc reports.
This is part four of the Using the Methodology Report series. For all entries in the series, see here.
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, IIC, UART and timers in the Vivado design.
The example design is created in the 2020.1 version of Vivado, targeting a ZCU106 evaluation board. Interrupts are tested on PetaLinux 2020.1, and the design Tcl and system-user.dtsi file are attached.
The Xilinxs Fast Fourier Transform (FFT) IP has a scaling feature to handle the bit growth in FFT output. This article provides insight into the scaling methods available in the IP and a method to select a scaling schedule to avoid overflow is discussed.
The analysis in this blog entry is based on a real customer issue where they were seeing DDR4 Calibration errors in hardware. The failures were inconsistent from one board to another and from build to build. This blog will show some of the debug techniques we used to narrow down the root cause and fix the issue.
This is part three of the Using the Methodology Report series. For all entries in the series, see here.
This blog provides an example on how a Python script can be used in debugging Xilinx PCIe designs. The script attached to this blog has been created with contribution from the community.
If you have already been using a similar approach to the one that is explained here or if you decide to use the provided script and enhance it further, we would be delighted if you could share your script with us and we will share it with the PCIe community members in this forum.
The provided technique can be applied to all designs and is not specific to PCIe only.
The analysis in this blog entry is based on a real customer issue where they were seeing poor QoR on one OS vs another. Although it was understood that Xilinx does not guarantee repeatability between different OS's as documented in (Xilinx Answer 61599), the magnitude of the difference in this case warranted further investigation.
Initially better results were seen with Windows, but later better results were seen with Linux. In the end, the issue was related to having certain Super Critical Methodology Violations in the design.
The Device Tree Generator (DTG) is a Tcl based utility that uses the HSI API to extract the hardware information from the XSA file to construct a custom device tree. The DTG utility is used in PetaLinux and Yocto. However, debugging DTG issues in PetaLinux can be cumbersome.
In this entry in the PetaLinux Image Debug Series we will discuss how we can isolate the DTG from PetaLinux, how to build the DTS files, how to navigate the DTG source files and how to debug a typical DTG issue. For all entries in this series, see here.