How to configure Redhawk waveform to work with USRP RFNoC

Question

I’m relatively new to SDR/FPGA game, therefore apologies if I get terminology wrong. I’m aware this will have quite a few fairly specific details, but I hope someone might have done something similar. I’m trying to run a simple Redhawk 2.2.1 waveform on Ettus USRP E312 with UHD v3.14 with RFNoC. The Redhawk domain is running on USRP and I’m attaching Redhawk IDE from Centos7 virtual box. The code I’m using is built using https://github.com/Geontech/redhawk-rfnoc-build The bit file for FPGA was made using Vivado as instructed in Ettus knowledge base. The waveform itself consists of single psd component with cpp-rfnoc implementation that has a dependency on RFNoC_RH shared library. There is an RFNOC_Programmable Device and two RFNoC Personas controlled by a Device Manager.

The problem I have is that Redhawk can not create application for the waveform. I’ve tried changing configuration, adding more logging, and some minor tinkering with the Redhawk code but the whole process usually fails due to failure to resolve either component or soft package dependencies. I’ve tried running a GPP on USRP, but it doesn’t seem to be considered since it seem to be filtered once the psd component is allocated to the persona. It will then try to allocate soft package dependency to the already selected devices, but there is no match.

I have two questions

• what is the minimal set of redhawk modules for this setup to work (so far I have waveform with one psd component, Device manager running one Programmable device and two Personas)
• what should be the relationship between the modules?

In particular I’d like to know/understand where is psd component supposed to be allocated/running? Do I need a GPP device for it? The Psd component receives/sends the data from blocks in fpga via RFNoC interface and at the same time interfaces to other components via redhawk’s bulkio which makes me think that it does need a GPP device to be running. Or am I missing something else?

Answer 1

I must admit, I'm a bit rusty on this project, and it's overdue for a refresh. Ettus' build for RFNoC and the E3xx no longer use the layer stack version this build points to right now. I began making inroads to this on our meta-redhawk-sdr thud-next branch at the start of the year but ran into some bugs in the 2.2.6 REDHAWK update that I was not expecting to see. That ultimately held up refreshing both builds to Ettus' latest source tree (i.e., the vanilla E3xx image(s) and the RFNoC variant).

That said, in reviewing the XML, the rh.psd component's RFNoC implementation (cpp_rfnoc) shows that the target executable device's processor property must be RF-NoC-Default. That requirement is being met by the RFNoC_DefaultPersona device (correctly, based on your log).

That implementation of the rh.psd also depends on the RFNoC shared library (SoftPkg dependency, RFNoC_RH), which, its implementation requires an armv7l processor according to its SPD. That comparison against available executable devices fails.

I don't see anything in the default build configuration providing a device in the device manager with that processor name (e.g., the GPP). That might be an oversight. Can you please try adding and running the GPP in your system?

Update: after reproducing the setup and some investigation, it appears a few hot patches and the bump to 2.2 in 2019 broke the design through the introduction of a few things.

First, the shared library SPD likely needs a second processor declaration for RF-NoC-Default so that the Executable Persona can satisfy the dependency (hot patches...).

Second, the Application Factory creates a ComponentHost to handle running any SharedLibrary Component implementations being launched (2.2), which causes a problem because the Persona is expecting to dlopen everything that is passed in through the Load API, which is why simply adding back the ComponentHost (with a processor patch of its own) does not resolve the problem.

Fixing the first is an SPD XML patch. Fixing the second is a REDHAWK core framework patch that likely should be upstreamed since most likely any Executable Persona device will want to deploy Components into the process space setup by the parent Programmable device (for all the performance reasons of why the ComponentHost now exists).