How configuration data gets passed to RFDC driver in Baremetal and Linux in 2018.3

In this brief tutorial, we shall discuss how the RFDC configuration data gets passed from Hardware to Software in both the Baremetal, and Linux using the HSI API and how the driver uses this information to initialize the RFDC driver.

Extracting Information from HDF:

When users export to SDK from Vivado, this creates a (Hardware Definition File) HDF file. This HDF is a container file which (among other files), will contain all the Hardware Information needed to build a software application for your target.

There is a suite of API called HSI that is used to extract the information from this HDF file. There is a comprehensive Wiki here on this topic. However, below is a quick demo of how to extract the RFDC configuration information from a HDF file

using HSI commands run in XSCT (Xilinx CommandLine Tool) in SDK.

The commands above can be placed in a TCL script and ran from the XSCT. This will open the HDF, and get all IP in the PL (using the filter to filter out only IP in the PL). It will then read the IP_NAME property, and if this matches the usp_rf_data_converter, then it will dump out all the rfdc properties into a dump.txt file:

For example. Here we can see the Base Address. This will be be discussed later in this wiki

Baremetal:

In SDK, the user will build the Board Support Package (BSP). The BSP will use the information in the HDF to know what IP are in hardware, and will add the respective driver for this hardware. it will also allow the user to add any

Libraries too. Each driver has a TCL file in its data folder. This TCL file is used to populate the xparameters.h file in the BSP with the configuration information. The TCL uses HSI API to extract the configuration information from the HDF.

Below is the TCL file for the RFDC driver in the SDK install directory (SDK\2018.3\data\embeddedsw\XilinxProcessorIPLib\drivers\rfdc_v5_0\data):


Here, we can see the MDD (Microprocessor Driver Descriptor) file. This is the file that is cross-checked against to find the supported peripheral. The TCL file is used to populate the xparameters.h file with the specific configuration information extracted for the RFDC IP.

The xparameters.h file is used when initializing the driver via the xrfdc_g.c file in the RFDC driver.

Linux:

The configuration is passed differently when using the Linux flow. Here, this is passed via a devicetree node generated by the DeviceTree Generator (DTG). The DTG is a TCL based tool, that used the HSI API to extract the node information from the HDF file.

The DTG will get all the corresponding drivers for the IP detected in the HDF. Each driver has its own TCL file for populating the devicetree node parameters.

Below is the RFDC node for the HDF file used in the Extracting Information from HDF section of this wiki:



The param-list used here is used to pass the configuration information from the HW to the SW. This param-list is generated in the TCL file for the RFDC driver in the DTG.

Below is the path to the RFDC TCL in the DTG:

Note: On line 27, there is an add_param_list_property. This starts with the DEVICE_ID, then C_BASEADDR, C_High_Speed_ADC,  ect. This is extracted from the HDF the exact same way as I have shown above with my example TCL script in the first section.

This populates the param-list in the RFDC devicetree node as a bytelist. The param-list can be cross checked against the dump.txt file created above. 

For example, the C_BASEADDR. In our dump.txt file we seen that this was set to 0xb0080000. Since the DEVICE_ID is always 00 00 00 00, as there is only one RFDC IP on the device. Then the C_BASEADDR is 00 08 b0 00. If we swap the endianness (for AXI), then we can see that this matches what we see in the dump.txt.

Taking the next two parameters:

  • C_High_Speed_ADC =  00 00 00 01, or 1
  • C_Sysref_Master = 00 00 00 E4 (228 dec)

These both match too.

This param-list in the devicetree RFDC node is used in the RFDC driver to init the drivers struct:

This uses the libmetal API to read the devicetree, and maps the param-list to the struct: