ORAN Hardware projects on GitHub are designed to demonstrate different use cases on ZCU102 or ZCU111 boards. This blog will show you how to generate the design and use the API to configure your CC settings after the board is booted.

1. Hardware Design Architecture
2. Design generation
3. PTP test setup
   1. board2board PTP test
   2. Third party O-DU to board PTP test.
4. Showcase on how to configure the CC on ZCU102 board with Keysight studio

Design Architecture

The top level of the demo design contains process, which is to configure the different IP used in datapath through AXI Lite interface.

DIP Switches are used to switch whether the board is operating in PTP master or Slave mode.

The Datapath module converts between radio data and received GT serial data. It contains the O-RAN Radio IF and the 10G/25G High Speed Ethernet Subsystem. All supporting IP cores for the Arm processor to 10G/25G High Speed Ethernet Subsystem control is contained within this block, as well as PTP support and a simple radio emulation block.

For more detail on submodules inside the Datapath, please refer to the Datapath section in Chapter 4 of (PG370)

Design Generation

The ORAN demo is provided through the GitHub repository: https://github.com/Xilinx/wireless-xorif

1.  Before generating the design, we need to install the latest v2020.2 patch for ORAN, which can be downloaded from (Xilinx Answer 76049)
2.  Then we need to clone the GitHub repository:

    git clone https://github.com/Xilinx/wireless-xorif.git

3. Checkout the tags with the release.

   cd wireless-xorif
   git checkout tags/2020.2

4. The Scripts folder contains scripts to generate the Vivado project, and run through the PetaLinux flow. We need to cd to the scripts folder before running the Tcl command:

cd /wireless-xorif/scripts

     5. In this blog, we want to generate a demo design for a ZCU111 board with a25G link. We can run the script as follows:

vivado -mode tcl -source ./xil_vivado_build.tcl -tclargs zcu111 -tclargs om5_25     -tclargs implNodateExit

This command generates the Vivado example design, completes synthesis and implementation, and then generates the XSA, which will be used in the PetaLinux project.

Note : there are 3 different example designs

• The Example design is generated by right clicking the ORAN IP in Vivado Source View, and selecting Open IP example: This example provides a simple example design, which only contains the ORAN IP and associated testbench files.
• The Block Automation flow generates a complete system level simulation example, which includes the 10G/25G Ethernet IP, DMA infrastructure, and block supporting the IEEE 1588 PTP implementation. For more details, please refer to Using the Example System in IP Integrator in Chapter 4 of (PG370).
• GitHub example : This is the example we use in this blog. It’s very similar to the example generated by block automation. In addition to the example system generated by block automation, xil_vivado_build.tcl inserts necessary debug signals (highlighted in the screenshot below). 

6. Copy the XSA file from wireless-xorif/output/zcu111_om5_exs_2020_2_AR76049/vivado/zcu111_om5_exs_2020_2_AR76049.sdk, to the wireless-xorif/xsa/zcu111_om5_exs folder, and then rename it to system.xsa. 

7. As per Petalinux Build Instructions, run the following makefile commands:

make zcu111_om5_exs

This command creates a PetaLinux project under wireless-xorif/output/zcu111_om5_exs_2020_2. Run though the PetaLinux build flow based on the system.xsa located under wireless-xorif/xsa/zcu111_om5_exs

  8. After the make command is completed, the boot images are generated in wireless-xorif/output/zcu111_om5_exs_2020_2/petalinux/images/linux. Copy boot.scr, BOOT.BIN, and image.ub to the SD card. Now we can boot ZCU111 board.

PTP Test Setup

After the design is generated, you can either run board2board PTP test or Third party O-DU to board PTP test.

Board2board PTP

As mentioned in (PG370), when using two O-RAN Radio IF subsystems, with one acting as the 1588 master and the other as the 1588 slave, timing synchronization can be demonstrated.

Let’s see how to implement this with two ZCU111 boards.

1. First we need to use the DIP switch to configure one board as master, and the other as slave.

Once the Vivado design is generated, you can find DIP switch settings for ZCU102/ZCU111 in oran_radio_if_basic.xdc

The screenshot below shows how it looks on a ZCU111 board:

2. Copy boot image files (from step 7 of Design generation) to the SD cards of both ZCU111 boards and ensure that SW6 is in SD card mode (OFF, OFF, OFF, ON = 1110)

3. After both boards are booted, first type “ifconfig”. Both boards have the same MAC by default

Now change one of them using following command, and then type “ifconfig” again to ensure that the two boards have different HWaddr

ifconfig eth0 hw ether 00:0A:35:00:22:02

4. Now we can start the PTP test with the following commands.

// Master

ptp4l -m -A -i eth0

// Slave

ptp4l -m -A -i eth0 -f /usr/bin/xroe-ptp4lsyncE.cfg -s

Note : xroe-ptp4lsyncE.cfg sets clock_servo              nullf

The clock_servo is used to synchronize the local clock. Valid values are

– “pi” for a PI controller,

-“linreg” for an adaptive controller using linear regression,

– “ntpshm” for the NTP SHM reference clock to allow another process to synchronize the local clock (the SHM segment number is set to the domain number)

– “nullf” for a servo that always dials frequency offset zero (for use in SyncE nodes). The default is “pi.”

You might observe some Synchronization Fault messages on the terminal, but these do not affect the 1pps synchronization.

For example:

When the master offset is +/- 1, there is one cycle difference (2560ps for 390.625MHz as shown below).

If you repeatedly restart the slave you should repeatedly observe this lock behavior on the 1PPS.
If you use the serial console to stop ptp4l on the Remote/slave you will also observe that the 1PPS stays phase locked, demonstrating the synchronized timer clock.

Keysight Studio to ZCU102 PTP test

In this example, we will use Keysight Studio as the PTP master, and perform the PTP test with a ZCU102 board.

1. We need to set up Time sync mode in Keysight studio. It’s under Setup > Instrument Configuration

2. Then set it to master mode and the Domain value to 24:

3. Create a ksightSyncE_min.cfg file, which contains the following content, and then copy it along with the other boot files to the ZCU102 board.

[global]

domainNumber             24

clock_servo              nullf

Note : “nullf” is for a servo that always dials frequency offset zero (for use in SyncE nodes)

“domainNumber” needs to match with the one defined in the PTP master.

4. Run the following command on a ZCU102 board to start the PTP test.

ptp4l -m -A  -i eth0 -f /media/sd-mmcblk0p1/xdc_keysight/ptp/ksightSyncE_min.cfg -s -2

Showcase on a ZCU102 with Keysight configuration

In this part, we will use Keysight Studio as the O-DU, generate the C-Plane/U-Plane packets, and transmit it to the ZCU102 board via a 10G Ethernet cable. In this show case, we need to figure out what commands are needed once ZCU102 is booted, and how to check the status of the fronthaul interface.

1. First we need to use Keysight Signal Studio Pro for 5G NR to configure the Carrier settings we want.

Let’s decide what type of carrier needs to be added: Downlink, Uplink or PRACH.

2. In this blog we configure DL CC1 with 40 RBs, Numerology 1, single slot, 14 symbols per slot. Start symbol ID is 0.

3. Save the setting files as a .scp file, and then close Signal Studio.

4. Then launch Keysight Open RAN Studio and open the .scp file saved in the previous step.

5. Set up the C/U Plane Builder Configuration

6.eAXC ID Field bitwidth is set to 4,1,3,8, and eAXC ID to 0000

Note : For one eAxC channel, the ID should start with 0000. 0001 is not accepted by the ORAN IP.

7. Now assign an eAxC ID for all of the Carriers configured in Signal Studio Pro. if you do not you will get an error in the next step:

8. Expert Stimulus File. This step generates the pcap file, which is the Ethernet packets which are going to transmit between O-DU(Keysight) and O-RU(ZCU102 board)

9. Load Stimulus, and then click “Play”.

10. Keysight setup is complete, now we need to boot the ZCU102 board.

After board is booted, we can refer to xorif-apps examples for how to configure the ORAN IP.

Note : “xorif-app -help” shows the help menu for xorif-app

 a. Firstly, we need to connect socket eth0:

xorif-app -v -s -i -e eth0 &

b. The xorif-app server needs to be initialized before it can correctly accept most commands.

xorif-app -v -c init

c. Now let’s run the command to configure carrier settings

      ## set eAxC_id <DU bits> <BS bits> <CC bits> <RU bits>

xorif-app -c "set eAXC_id 4 1 3 8"

The eAXC_id should match with the GUI setting in step 6.

## set ru_ports <RU bits> <ss bits> <mask> <user value> <PRACH value> <SSB value>

 xorif-app -c "set ru_ports 8 5 192 0 128 64"

Note : This is to set up the ru port ID.

For example, if you use xorif_set_ru_ports (8, 5, 0xC0, 0, 0x80, 0x40), the value 0xC0 needs to be ANDed with other masked bits.

The PRACH mask is 0x80, so the ID is 0xC0 AND 0x80 = 1000 0000 (Binary).[7:6] 10(binary)=2 (DEC), which is the final RU_Port_ID.

If you set the PRACH mask to 0xC0, and then the ANDed value is 1100 0000, [7:6] is 11(binary)=3 (DEC), so the final RU_Port_ID is 3. 

In this blog, the user value is 0. After it is masked with defined bits, the RU port ID is 0000. This is the value for non-PRACH data, which matches what is set in step 6.

## Configuration for CC 0

xorif-app -c “set numerology 0 1 0”
xorif-app -c “set num_rbs 0 40”
xorif-app -c “set ul_iq_compression 0 0 0”
xorif-app -c “set dl_iq_compression 0 0 0”
xorif-app -c “set time_advance 0 160 125 125”
xorif-app -c  “set dl_sections_per_sym 0 10”

xorif-app -c  “configure 0”
xorif-app -c “enable 0”

After each command, status=0 means you’ve successfully set the CC configuration.

If you want to check the status of front haul interface, you can use the following command:

xorif-app -c “set fhi_stats”

As you can see, all of the DL Rx packets have arrived on time, which means the all of the received c-plane and u-plane packets arrive within the reception windows.

ORAN_Tx_* values are all 0 as I only generated the DL channel from Keysight studio.

This blog has worked through the steps from design generation up to the API configurations after the board is booted.

You can get the complete xorif-app API documentation from index.html, which is under GitHub repository oran-radio-ifdochtml

After you open it, go to Modules.

You can get a list of all of the modules with associated descriptions.

Now it’s your turn to play with the different commands.

Have fun!

PlatoAi. Web3 Reimagined. Data Intelligence Amplified.

Click here to access.

Source: https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/ORAN-wireless-xorif-hardware-demonstration/ba-p/1254509