Video Series 33 is a continuation of Video Series 32. In this Video Series, we will walk through the steps needed to create and update the Video Mixer example design application so that it can be output through the ZCU702 board 's On-Board HDMI.
This video Series entry shows an example of the Hardware Design which can use the On-Board HDMI output of the Zynq®-7000 SoC ZC702 evaluation kit using the ADV7511 to visualize the Video Mixer example design.
The Video Mixer example design is originally described in Chapter 5 of (PG243).
Note: the design will need a software application to work. This will be done in the following Video Series entry (Number 33). This series also has a prerequisite of Video Series 19 and Video Series 20, which describe the ADV7511.
In Zynq UltraScale+ boards such as the Zynq UltraScale+ MPSoC ZCU102 Evaluation Kit, the QSPI Flash is connected to the PS portion of the device and does not have a direct physical connection to the PL side.
In such configurations, it is not possible to write a bitstream (.mcs file) directly to the flash via the Hardware Manager. In fact, when attempting to configure the bitstream to be loaded via QSPI, Vivado will only make the Boot via JTAG option available, as it knows that there is no flash available in the PL.
In order to configure and boot such devices via Flash, the PS portion of the device must be booted (even if it is not desired or will not be used in the actual project), in order to allow the bitstream to be transmitted from the Flash to the PS and to reach the PL through the MIO pins.
The process consists of creating a new Zynq MPSoC project in Vivado Block Design (or adding this block to an existing design) in order to include the PS in the project, and using the SDK to create a First Stage Boot Loader (FSBL) for the PS, an optional PS application, and finally creating the flash image which will contain the boot files for both the PS and PL.
This blog entry is the first lab in a series which will be targeted at beginners in FPGA design entry using Vivado.
These labs are organized to give the user a quick start and to help them to get a feel for how the tool flow works. We have picked a very simple design that is easy to understand so that different steps in the flow can be explained easily.
The labs will be presented in this order – RTL Flow, IP based Flow, HLS based Flow, IP Integrator based Flow, and then finally creating a design using a mix of the earlier flows.
This blog entry is a continuation of Introduction to PetaLinux Part 1. It is aimed at anyone who wants to get started with PetaLinux and learn about its key tools, concepts, and capabilities. In the first blog entry we looked at how to create a PetaLinux project and how to modify an image. In the second blog entry, we will continue with the project created in Part 1 and look at how to build the system image and boot it on a Zynq® UltraScale+™ ZCU102 evaluation kit.
I will run through the basic steps needed in this tutorial, however, the scope of the blog is limited. You can find out more information about PetaLinux on the Xilinx website here.
Incremental synthesis is a production feature since the 2019.1 release. It addresses the need for fast iterations during the synthesis phase, significantly reducing compile time while also ensuring predictable results, with no cost of QoR loss.
Compile time is always a key concern in design cycles. In this blog, we will cover the techniques for design compile time reduction, following the flow of design entry, synthesis, and implementation. This blog will be updated regularly, with more subtopics links added as they completed.
Clock gating in RTL is a common way of reducing power in ASICs, however it not translate well to FPGAs. Because of that, FPGA synthesis tools will have a feature that can convert gated clocks. This article will speak to how Vivado Synthesis converts gated clocks and how to control the feature.
The Platform Management Unit Firmware (PMUFW) is a part of the software stack on Zynq® MPSoC devices that users expect to work out of the box, and so don't tend to pay much attention to until something goes wrong.
However, as the name states, this software manages the whole platform, so it has a huge impact on a lot of use cases that you might be using right now.
This blog entry is intended to be the starting point of a series where I will be covering different aspects of the PMU Firmware, from buildling or debugging it up to discovering its role in different system use cases.
Xilinx offers a wide range of IPs for hardware debugging of FPGAs and SoC resources, such as the ILA, VIO, and IBERT cores. Traditionally, such cores are accessed via JTAG connection, which requires the device to be locally and physically accessible.
this constraint is impracticable in many applications where the FPGA is in a hard-to-access location, there is no direct access to the FPGA JTAG pins, or the system is deployed in the field.
To resolve such issues, Xilinx introduced the Xilinx Virtual Cable (XVC), which is a TCP/IP-based protocol that acts like a JTAG cable and provides a means to access and debug the FPGA or SoC design without using a physical cable.
This blog entry describes how to create an XVC design for Zynq® UltraScale+™ devices using Vivado and Petalinux 2018.3. The design is capable of connecting to the PS side of a device via Ethernet and enables PL debugging cores to be remotely accessed.
Note: this article was co-authored by Andre Guerrero and Matt Piazza.
The data on the PIPE interface is encrypted at Gen3 speed. When debugging PCIe issues, it is helpful to be able to look at the packets on the PCIe link.
To do so, users need to have a Protocol Link Analyser. Due to the high cost, not many users would have access to such a piece of equipment. The packet analysis tool provided with a Protocol Link Analyzer is very extensive and provides in-depth analysis of the link traffic.
The Xilinx UltraScale+ Devices Integrated Block for PCI Express Gen3 IP has a feature to integrate a descrambler module to decrypt the encrypted data on the PIPE interface. This does not provide the same amount of analytic data as a Protocol Link Analyzer does but this could nevertheless be helpful in identifying a potential issue and in most cases could help in tracking the root cause of the issue.
This blog will provide details on how to analyze the output data from the descrambler module by identifying different types of PCIe packets that are coming from the link and going into the PCIe IP.