M2 SSD-to-FPGA adapter supports Gen4 PCIe

M2 SSD-to-FPGA adapter supports Gen4 PCIe
One of the projects I’ve been working on in the last few months has been upgrading our M2 SSD to FPGA adapter product (FPGA Drive FMC) to support the new Gen4 PCIe SSDs. It’s now available to buy so I thought that I would share some photos and write a bit about the changes that we made. The photos were taken with these two Gen4 PCIe SSDs: Corsair Force Series MP600 1TB Gen4 PCIe NVMe M. [Read More]

Processorless Ethernet: Part 3

State machine based Ethernet on FPGA

Processorless Ethernet: Part 3
For those of you who want to experiment with processorless Ethernet on FPGAs, I’ve just released a 4-port example design that supports these Xilinx FPGA development boards: Artix-7 AC701 Evaluation board Kintex-7 KC705 Evaluation board Kintex Ultrascale KCU105 Evaluation board Virtex-7 VC707 Evaluation board Virtex-7 VC709 Evaluation board Virtex UltraScale VCU108 Evaluation board Virtex UltraScale+ VCU118 Evaluation board Here’s the Git repo for the project: Processorless Ethernet on FPGA [Read More]

Processorless Ethernet: Part 2

Modularizing the TEMAC example design

Processorless Ethernet: Part 2
This article was written by Pablo Trujillo, an FPGA developer and consultant based in Valencia, Spain; a place that I happen to be very fond of, because of the many tapas bars and good eating/drinking to be done there. Pablo writes his own blog on FPGAs called Control Paths and he’s also a very active contributor to Hackster.io. In this article, Pablo explains how he has helped me to modularize the TEMAC example design that we looked at in an earlier post. [Read More]

PetaLinux build artifacts

How to keep them and where to find them

PetaLinux build artifacts
These tips apply to PetaLinux 2020.2. To save disk space, the PetaLinux tools deletes all build artifacts at the end of the build process. If you want to keep them for debugging or to help you develop a patch, you can add the following line to the project-spec/meta-user/conf/petalinuxbsp.conf file: RM_WORK_EXCLUDE += "recipe" Where recipe must be substituted with a valid recipe name such as the following: Sources Recipe name Kernel linux-xlnx FSBL fsbl U-Boot u-boot-xlnx PMU firmware pmu-firmware Device tree device-tree If you want to preserve the build artifacts of more than one component, you can append the recipe names, separated by spaces, for example, to preserve the kernel sources and the FSBL: [Read More]

Driving Ethernet ports without a processor

How to do it on an FPGA and why

Driving Ethernet ports without a processor
Gigabit Ethernet can be a very useful medium for transferring data very quickly from one point to another. It’s low-cost, high-bandwidth, well established technology and the cabling is easily obtained and installed. In embedded applications however, the throughput of Ethernet links is often held back by one thing: the processor. When using an FPGA, we can relieve the processor significantly by offloading work to the FPGA fabric, but often the only way to exploit the full potential of a Gigabit Ethernet link is to do away with the processor altogether. [Read More]

How to program configuration flash with Vivado Hardware Manager

Writing an .mcs file to Quad SPI or Linear BPI flash

How to program configuration flash with Vivado Hardware Manager
Most FPGA/SoC dev boards have a flash device for non-volatile storage. Typically it would be either a Quad SPI flash (serial interface) or a Linear BPI flash (parallel interface). Although it can be used for storing anything, it’s typically used for storing the configuration for the FPGA or SoC (eg. the bitstream, FSBL, U-Boot, Linux Kernel). If the boot mode of the FPGA or SoC is appropriately set, on power-up it should read from the flash, load the bitstream into the FPGA and then load and run the software components. [Read More]

How to Modify U-Boot Environment Variables in PetaLinux

How to Modify U-Boot Environment Variables in PetaLinux
In this post we will look at two methods for modifying the U-Boot environment variables. The first method is changing the values stored in flash from the UBoot command prompt. The second method is changing the hard-coded default values in the PetaLinux project. We’ll be assuming a boot from QSPI flash, although the concepts also apply to booting from SD card or other non-voltatile storage devices. The U-Boot environment variables determine exactly how a board is supposed to boot. [Read More]

How to decompile a device tree in PetaLinux

Converting a .dtb to .dts

How to decompile a device tree in PetaLinux
One of the output products of a PetaLinux project is a compiled (binary) device tree. Sometimes we’d like to be able to read that compiled device tree to see exactly what is inside it. This can help with debugging a problem, or you may just want to make sure that your device tree additions are actually being pulled in. Either way, a compiled device tree can be “decompiled” using a tool that you can find hidden away in the PetaLinux build collateral. [Read More]

How to Patch PetaLinux

Modifying the kernel, drivers and standalone components

How to Patch PetaLinux
When we build PetaLinux for custom hardware we invariably need to modify components of the boot image: FSBL, U-Boot, or the kernel itself. I use the words “modify” and “patch” interchangably here because the accepted way to make changes to the boot components is to apply “patches” to them. A patch is simply a “diff” between the original source code and the modified source code. To generate the “diff” file, we can use Linux command diff or other similar commands, but in this post we will use the command git diff. [Read More]

How to Build PYNQ v2.6 for Ultra96

How to Build PYNQ v2.6 for Ultra96
In this post we’re going to setup a virtual machine with the tools for building PYNQ and we are going to build PYNQ release v2.6 (tool version 2020.1) for the Ultra96 board. We’re going to start with the virtual machine that we setup in the previous post How to Install PetaLinux 2020.1. That VM has Vitis 2020.1 and PetaLinux 2020.1 installed, both of which we will need to build PYNQ. If you want to avoid issues along the way, I highly recommend that you follow that post and recreate the same VM with exactly the same tool versions and OS. [Read More]