Understanding how DRC connects to HDL Assembly at application runtime

I have an Open CPI project I’ve inherited and have a gap of understanding in how components know how to link correctly at application run time. We have a single RX and TX channel working and can successfully execute the FSK DRC application. We are trying to get multiple RX and TX channels working on our platform.

We have our own OSP with a Zynq Ultra HDL platform and a Xilinx RCC platform. Call it “myplat”

On the HDL side:

  • We have defined ADC and DAC HdlDevices based on the qadc and qdac specs respectively (myplat_adc and myplat_dac).

  • Our HdlPlatform definition has a single instance of each device with devsignals connected.

  • We then have an HdlConfig that lists both the DAC and ADC as devices.

  • We then have an HdlContainer using this HdlConfig. In this container we define connections from the DAC and ADC into the assembly (by assembly port name) and then from the assembly to the zynq_ultra interconnect (by assembly port name). This container does NOT connect the myplat_dac or myplat_adc to the zynq_ultra interconnect.

  • The assembly is essentially a copy of the example assets fsk_modem assembly. We are able to build this assembly and use the resulting FPGA .bitz file during application runtime.

On the RCC side:

  • We have an RccWorker that implements the drc spec, myplat_drc.rcc

  • This DRC implementation has a “<slaves>” assembly that configures the external RX and TX ports and connects them through several workers to and from myplat_adc.hdl and myplat_dac.hdl worker instances. (the overall structure of this is mostly similar to the drc_e31x.xml, we use different workers in our slave assembly)

  • The DRC C++ code configures our platform’s RF frontend using the configuration provided in the application

On the application side:

  • This is pretty much a complete copy of the assets’ fsk_dig_radio_ctrl example except we’re specifying our myplat_drc as the drc worker.

As I said, this all works and we can run the FSK DRC app successfully but I don’t understand how the DRC connecting its external ports to a myplat_adc or myplat_dac instance correlate to the HDL container and the fact that it only connects ports from the assembly to the interconnect. I am not referencing myplat_adc or myplat_dac instances in the DRC by their names as defined in the myplat.xml.

This becomes more confusing when trying to implement the dual FSK modem, for example. I understand how increase external port counts in the DRC and add more Device instances of the the DAC and ADC in the myplat.xml, HdlConfig, and then connect them in the assembly container. But I don’t understand what dictates how they are connecting to the DRC and application side of things.

If my language is too generic I can provide more details.

Any insight is appreciated, thank you.

The DRC is basically an abstraction layer for the application xml. For example if the DRC didn’t exist, the application XML would need to instance all components that match HDL assembly.

Remember in the application XML you do not specify the boundaries of the interconnect, at execution time OpenCPI will determines which artifacts to use to satisfy the application XML. The DRC only applies to the application side of the xml. Think of it as sub assembly for the application. Anything that is instanced in the DRC is not required to be instanced in the application XML anymore and its connected using the external ports.

You can add as much or as little workers you want into the DRC to abstract them away in the application XML. For instance if you had additional filtering or int/dec workers they can be incorporated into the DRC . The connections out of the DRC external ports are used to determine where that line is.

Understood. I guess my confusion lies more in the DRC than the application.

If I add multiple “myplat_adc” HDL Device workers in the DRC, how does Open CPI know which of the “myplat_adc” instances listed in my HdlPlatform to connect to?

The HdlContainer defines connecting specific “myplat_adc” instances to the HdlAssembly but I don’t see a correlation from the DRC to the Assembly. There is no naming overlap.

The E31x platform has an example that highlights this ambiguity in the dual_drc_e31x_csts.xml(hdl/cards/dual_drc_e31x_csts.rcc/dual_drc_e31x_csts.xml · develop · OpenCPI / OpenCPI System support Projects (OSP) / E3xx · GitLab) , under the hood OpenCPI adds suffix indexes to multiple device instances, for example data_sink_qdac_csts0 and data_sink_qdac_csts1.

There are times that this isn’t enough, for example if you look at the the hitech global platform it demonstrates a workaround where developers created unique device workers to address this ambiguity, hdl/devices · develop · OpenCPI / OpenCPI System support Projects (OSP) / HiTech Global · GitLab.

This is definitely an area we recognize needs improvement in OpenCPI.

1 Like