Understanding how DRC connects to HDL Assembly at application runtime

Application Development
, , ,
1

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.

2

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.