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
In Gen 3 of Zynq UltraScale+ RFSoC devices, programming the CLK104 module can be done via the System Controller UI, but this blog shows you how you can also boot the CLK104 PLLs over I2C/SPI from the RFSoC APU.
We have a driver that makes this possible by taking the I2C and SPI communications and abstracting them so that you just need to worry about what settings you want to program. This driver can also be used for Linux Applications, giving you more possibilities for prototyping on the RFSoC Gen3 Evaluation Boards,.
This blog also takes a look at the new Gen3 Clock Distribution options as part of our CLK104 programming example.
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.
In the design cycle, users can have multiple versions of projects which use the same IPs with the same configurations. Rerunning the whole project can cause regeneration of the IPs every time, and is time-consuming.
In the Vivado project settings, the user IP repositories allow users to add their own IP to the Vivado IP catalog and when used alongside a Remote IP Cache, compile times can significantly reduce. This blog entry explains how to set this up.
You can find all of the entries in the Saving Compile Time Series here.
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.