Recently, we developed a capability that combined an Analog Devices FMCOMMS3 dual-transceiver FMC card with a Xilinx ZC706 Development kit and represents that system as a combined REDHAWK FrontEnd Interfaces and Persona Device.

The ZC706 is another Xilinx Zynq -based system similar to the more common ZedBoard and ZC702 development kits except that it provides significantly more programmable logic space. However since it is as easy to build for as the ZedBoard, we developed our capability to target either system with minimal reconfiguration thank to patching Analog Device’s HDL repository and leveraging Yocto.

The result: a choice of scalable integration platforms that each can behave not only as a tuner but also a number of possible Personas, with each of those representing various RF capabilities from entirely in-fabric processing and/or feeding downstream processing in REDHAWK. Moreover, the resulting system can make these changes without restarting.

Programmable Logic Personas

Analog Devices provides a reference design found here for the Programmable Logic (PL) portion of the Zynq SoC in order to provide an interface to the FMCOMMS3. Most notably, this design implements the AD9361 SPI interface as an AXI peripheral for control of the device through their LibIIO driver. Data transfer to and from the Zynq PS is also provided in the reference design through high-performance interconnects. Analog Devices has structured their Vivado build flow within their repository to be able to generate a bitfile for multiple configurations of target platforms (like the ZedBoard and the ZC706) and FMC cards.

AXI-Stream Layer

We quickly identified that the reference design from Analog Devices was an excellent starting place for developing our persona capabilities. Their Vivado build flow provided us an infrastructure for targeting either the ZedBoard or the ZC706 with the FMCOMMS3. However, we found that the data buses within the design were not standardized and therefore not compatible with our IP cores.

In order to interface with the Analog Devices data buses, we designed a layer of logic to implement the AXI-Stream protocol within the Zynq PL. We integrated this AXI-Stream layer directly into the Analog Devices Vivado build flow, allowing us to immediately target multiple platforms.

We also added logic in the AXI-Stream layer for testing and extensibility, including data bus switches that allow us to use the Zynq PS to dynamically reconfigure the data bus routing within the Zynq PL. The dual tranceiver channels of the FMCOMMS3 can be routed to and from our IP cores and the Zynq PS, and the transceiver channels can even be connected to each other in a repeater configuration! This layer of run-time re-configurability provides infrastructure for many future applications.

Repeater Persona

A baseline capability of the AXI-Stream layer is the ability to repeat the received signal out of the transmit channels. This is accomplished by using the Zynq PS software to set up the data bus switches in the Zynq PL.

We proved the functionality of this repeater persona by setting up a standalone hardware test that looped transmit channels back to the receive inputs. We generated a test signal on transmit channel A of the FMCOMMS3, received it on channel B, repeated it through the Zynq PL and back out the transmit channel B, and then successfully captured the data on receive channel A.

Yocto Integration

As of today, the only Analog Devices -suggested route for Linux integration with their HDL repository is to use their own patched Linux kernel as well as their own custom device trees (found here. Additionally, the FSBL (first stage boot loader) is provided through a process within Vivado 2016.2. This association presented a tight-coupling, that for an initial capability, we chose to use directly rather than build into a Yocto layer.

The BSP Layer

First, in both preparation for tighter integration later and a need to differentiate the platforms from the standard definitions, we defined a board support package layer (BSP). It includes new machines as well as LibIIO.

The new machines we used for integration inherit from the related Xilinx base versions (ZC706 and ZedBoard, in meta-xilinx). These new definitions specified our Analog Devices -provided external boot requirements while also identifying the hardware-specific features that help our other recipes select the appropriate bitstreams for the target platform’s packages.

To further streamline integration with the Analog Devices IP, we leveraged adding LibIIO and its examples into this layer. Aside from familiarity and easily-located support for the library, this had several other advantages during integration. The examples helped us sanity-check various issues and having the whole library instaleld ultimately added another interesting feature: the LibIIO Daemon. We could use the platform with other software than REDHAWK as another way to test the design.

Application Layer

Next, we added an application layer for collecting this unique Persona build and integration platform. The goal here looked beyond the first image build. What does this integration process look like for new features? How easily can we add Personas? The answer: very easily.

Since the platform will foremost be a FrontEnd Interfaces 2.0 -compatible transceiver, we developed our recipe and software for this: our top-level FEI Programmable Device. Programmable? Yes, it is a very unique FEI Tuner, since it is also an Aggregate Device — that is, it will be associated with potentially multiple possible Personas. And because of our PL design, any persona installed bitstream is dual-purpose. With a few common register writes, the IP is bypassed, restoring it to pure FEI Tuner operation.

Then we began adding Persona Device recipes. Each of these recipes uses the declared MACHINE name to select the Persona’s matching bitstream for the target FPGA. To further simplify future integration, each recipe also inherits from a class that configures the related dependencies and tasks so that a bitstream package is added to the build automatically.

This mechanism simplified adding new features since the recipe and class are simple templates, leaving the only real effort as backfilling the Persona Device template to make it specific to the new feature. Once finished, one simply runs bitbake my-new-persona to generate all of the necessary packages for that persona (as RPMs, in this case). Those packages are then installed on the target using the associated package manager. Easy.

Finally, the last integration process element: the REDHAWK Node. In our meta-redhawk-sdr layer, we use a script, which calls on REDHAWK’s code generators, to collect any installed Node definitions into one larger one on start-up that represents all installed devices with their custom parameters. For this build process, we envisioned something similar. As before, if the top-level Node is not defined on boot-up, the script runs to create it. Again, we use REDHAWK’s own code generators to locate our FEI Programmable Device, instantiate it, and then associate all installed Personas. When the Node joins the Domain the next time, the new Personas are available for use. Very easy.

Conclusion and Demo

In the preceding sections we have covered in some detail how we developed an integration platform around Analog Devices’ own HDL IP and Linux Kernel with our own Yocto-based build environment. The resulting environment can target a number of Zynq -based platforms including the ZC706 and ZedBoard while providing hot-swappable Personas to a REDHAWK FEI Tuner Device and Node.

So… demo then? Of course!

In the video, we showcase a ZedBoard with an FMCOMMS3. The available personas are the basic tuner and an all in-fabric pass-through capability which operates like a bent pipe. The Persona can still receive data from the tuner interface, but the transmitter is being fed straight from the receiver without having to cross from the FPGA fabric into the ARM processor.