Pg370 Oran Radio If WTMKX
Pg370 Oran Radio If WTMKX
Pg370 Oran Radio If WTMKX
n
rib I ma tio
n te
ist rch Li ma
LogiCORE IP Product Guide
i o i tu
-D ea iro for
Vivado Design Suite
ut nst
Re es C In
PG370 (v3.0) May 17, 2023
or R to ial
t f do ed nt
No ra os de
do cl nfi
El is o C
D
AM
D
at
n
rib I ma tio
n te
Table of Contents
ist rch Li ma
i o i tu
-D ea iro for
Chapter 1: Introduction.............................................................................................. 4
ut nst
Features........................................................................................................................................ 4
IP Facts..........................................................................................................................................6
Re es C In
Chapter 2: Overview......................................................................................................7
or R to ial
Navigating Content by Design Process.................................................................................... 9
Unsupported Features................................................................................................................9
Licensing and Ordering............................................................................................................ 10
t f do ed nt
Chapter 3: Product Specification......................................................................... 11
No ra os de
Core Functionality..................................................................................................................... 12
Standards................................................................................................................................... 59
do cl nfi
Performance.............................................................................................................................. 59
Resource Use............................................................................................................................. 60
Port Descriptions.......................................................................................................................60
El is o
Register Space........................................................................................................................... 96
C
Example System........................................................................................................................ 96
D
Clocking...................................................................................................................................... 98
Resets..........................................................................................................................................99
Protocol Description............................................................................................................... 100
Using the Example System in IP Integrator.........................................................................101
n
Appendix A: Upgrading........................................................................................... 115
rib I ma tio
Upgrading from RoE Framer to the O-RAN Radio Interface..............................................115
Appendix B: Debugging...........................................................................................116
n te
ist rch Li ma
Finding Help with AMD Adaptive Computing Solutions.....................................................116
i o i tu
Debug Tools............................................................................................................................. 117
Hardware Debug..................................................................................................................... 118
-D ea iro for
ut nst
Appendix C: Application Software Development......................................122
Re es C In
Overview...................................................................................................................................123
Sample Application................................................................................................................. 123
or R to ial
Appendix D: O-RAN Support Matrix................................................................. 124
Chapter 1
n
rib I ma tio
n te
ist rch Li ma
Introduction
i o i tu
-D ea iro for
The AMD O-RAN Radio Interface (O-RAN Radio IF) core is part of a system solution developed
ut nst
on the AMD Versal™ adaptive SoC, AMD Zynq™ UltraScale+™ MPSoC, and Zynq UltraScale+
RFSoC, relying on both hardware and software to provide a comprehensive and efficient
Re es C In
computing platform required to implement an O-RAN radio unit. The core supports the use of
the following protocols: eCPRI, IEEE 1914.3 (NGFI), IEEE 1588, Synchronous Ethernet, and Node
and Network OAM. The core enables radio data transmission through a packet-based transport
or R to ial
network connecting Remote Radio Units (RRUs) to the centralized Baseband Unit (BBU).
t f do ed nt
Features
No ra os de
• The core implements O-RAN Control, User and Synchronization Plane Specification v11.0 (O-
RAN Specification v11.0). The core supports up to four 10 Gbps or four 25 Gbps Ethernet
ports. Mixed rate mode is not supported.
El is o
Currently supports eight component carriers (CCs), with independent uplink and downlink
C
timers. Twelve and sixteen CCs are supported for remapping Spatial/Antenna data onto the
same resource.
D
○ Supports a resolution of down to one resource block (RB) per section message.
U-Plane support for up to 20 spatial streams for downlink, 16 spatial streams for uplink,
AM
D
one additional separate stream for SSB traffic (PSS, SSS, PBCH), PRACH, and four shared
unsolicited data streams (for use in SRS).
○ One PRACH uplink data port.
○ The core implements the radio fronthaul interface, managing both the control and user
planes, implementing the appropriate timing advances and compensating for the delay
variations of packets coming from different BBUs. User radio blocks with related beam IDs
at
are extracted from received packets at the appropriate symbol period and forwarded
through AXI4-Stream outputs to external double buffers interfacing the beamforming
function.
• Supports eCPRI and 1914.3 over standard IEEE 802.1 Ethernet packets, optionally including a
single VLAN tag, as well as UDP over IPv4 or IPv6, over Ethernet.
• Fully programmable filtering rules allow the hardware to identify and manage user plane
n
packets.
rib I ma tio
• Each Ethernet and IP/UDP header field is fully programmable.
• Alignment to an external 10 ms Start of Radio Frame pulse, enabling 1588 synchronization.
n te
ist rch Li ma
• An optional ORAN channel processing block (OCP) is available for up to 8x8 Spatial Stream/
Antenna designs to correctly order RBs and pass full symbol data and from a Precoding/
i o i tu
Beamforming/(i)FFT block in a macro radio system.
-D ea iro for
ut nst
Related Information
Re es C In
or R to ial
t f do ed nt
No ra os de
do cl nfi
El is o C
D
AM
D
at
n
IP Facts
rib I ma tio
LogiCORE IP Facts Table
n te
ist rch Li ma
Core Specifics
Family1 3
i o i tu
Supported Device AMD Versal™ adaptive SoC, AMD Kintex™ UltraScale+™, AMD Virtex™
UltraScale+™, AMD Zynq™ UltraScale+™ MPSoC, AMD Zynq™ UltraScale+™ RFSoC,
AMD Kintex™ UltraScale™, AMD Virtex™ UltraScale™
-D ea iro for
Supported User Interfaces AXI4-Stream
ut nst
Resources Performance and Resource Use web page (registration required)
Provided with Core
Re es C In
Design Files Encrypted RTL
Example Design Verilog
or R to ial
Test Bench
Constraints File
Verilog
Xilinx Design Constraints (XDC)
Simulation Model Verilog
t f do ed nt
Supported S/W Driver Linux user space driver (Libmetal)
Tested Design Flows2
No ra os de
Chapter 2
n
rib I ma tio
n te
ist rch Li ma
Overview
i o i tu
-D ea iro for
The O-RAN Radio Interface allows the development of a complete solution to support all the
ut nst
features required by an advanced fronthaul interface. In the LTE and 5G radio mobile
architectures, fronthaul is the transport network interconnecting the Remote Radio Units (RRUs)
Re es C In
to the Baseband Units (BBUs) and relies on different topologies, such as point-to-point, point-to-
multipoint, and ring. To match modern network requirements in efficiency and flexibility, the
fronthaul network is packet-based, relying either directly on the Ethernet network protocol or on
or R to ial
a UDP/IP stack.
The O-RAN Radio IF system, shown in the following figure, built from the O-RAN Radio Interface
t f do ed nt
and other AMD IP, is a computing platform designed to support the management of the user,
control, and synchronization planes, working as an intelligent and adaptable network interface
No ra os de
UL
BF/ Custom
Optical Ethernet Pipe to oDU
C
Data UL ADC
Pre/ DFE
FFT
Ethernet
D
BID UL DL
MAC 10/25G Packet
Deskew/ BF/ Custom
Optical Protocol BID DL DAC
TimeAdv Pre/ DFE
Interface Filtering
AM
Data DL iFFT
D
Management Plane
AXI4-Stream to
CPU
RFSoC with
Ethernet O-RAN Radio IF
System
O-RAN DISTRIBUTOR UNIT (O-DU)
X23887-041023
The O-RAN Radio IF supplies IP, drivers, and software APIs to implement supported protocols.
n
The O-RAN Radio IF IP is implemented in the programmable logic (PL), and the drivers and
rib I ma tio
software APIs run on Linux on the Arm® processor. In the following figure, the O-RAN Radio IF C
library, the libmetal driver, and the O-RAN Radio IF IP core comprise the solution and are
n te
required for full protocol support; the O-RAN Radio IF C example application provides code to
ist rch Li ma
demonstrate the solution.
i o i tu
Figure 2: O-RAN Radio IF IP Solution
-D ea iro for
ut nst
O-RAN Radio IF C Example Application
Re es C In
O-RAN Radio IF C Library
Arm Processor
or R to ial Libmetal Driver
Linux
t f do ed nt
No ra os de
Programmable
O-RAN Radio IF Core
Logic
do cl nfi
X23888-022321
El is o
The C-Plane and U-Plane are handled in hardware. The subsystem configuration and other user
services can be handled by a software API library running on the embedded processor with
C
dedicated hardware features, such as packet timestamping at the PCS/PMA level. Because no
more circuit-based interconnections are available, it is also necessary to synchronize each node
D
through the packet network; the synchronization plane therefore relies on a PTP protocol such as
IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and
AM
The O-RAN Radio IF system provides a platform to run the Linux PTP Precision Time Protocol
(ptp4l) software application for IEEE 1588 hardware timestamping and control of the hardware-
based timer. The O-RAN Radio IF core can realign its internal timers to the Start of Radio Frame
information transported by the synchronization plane. Control plane management relies on
protocols such as SNMP and ICMP, running on an IP stack and implemented in software on the
at
embedded processor.
The O-RAN Radio IF system deals with two different packet flows:
• O-RAN C-Plane and U-Plane traffic: Time-sensitive and high-priority flow handled by
dedicated and adaptable O-RAN Radio IF hardware
• Lower priority traffic flows: Including O-RAN S-Plane and M-Plane and other non-O-RAN
n
protocols, all of which can be managed by the AMD Zynq™ UltraScale+™ MPSoC processor,
rib I ma tio
or CIPS in AMD Versal™ adaptive SoCs.
The O-RAN Radio IF can filter each incoming downlink packet in real time, recognize messages
n te
ist rch Li ma
carrying antenna-carrier data, and forward them to the managing hardware, while redirecting all
remaining traffic to the embedded processor through a DMA interface. In the uplink direction,
i o i tu
the subsystem must arbitrate access to the supported Ethernet ports between the higher priority
stream generated by the O-RAN Radio IF core and that coming from the embedded processor.
-D ea iro for
ut nst
Re es C In
Navigating Content by Design Process
or R to ial
AMD Adaptive Computing documentation is organized around a set of standard design
processes to help you find relevant content for your current development task. All AMD Versal™
adaptive SoC design process Design Hubs and the Design Flow Assistant materials can be found
t f do ed nt
on the Xilinx.com website. This document covers the following design processes:
No ra os de
• Hardware, IP, and Platform Development: Creating the PL IP blocks for the hardware
platform, creating PL kernels, functional simulation, and evaluating the AMD Vivado™ timing,
resource use, and power closure. Also involves developing the hardware platform for system
integration. Topics in this document that apply to this design process include:
do cl nfi
• Port Descriptions
El is o
• Register Space
C
• Clocking
• Resets
D
Unsupported Features
For the compliance matrix with respect to O-RAN Control, User and Synchronization Plane
at
Specification v11.0 (O-RAN Specification v11.0), an O-RAN Support Matrix appendix is available
in the O-RAN Radio IF Product Guide.
Related Information
n
Licensing and Ordering
rib I ma tio
This AMD LogiCORE™ IP module is provided under the terms of the Core License Agreement.
n te
ist rch Li ma
The module is shipped as part of the AMD Vivado™ Design Suite. For full access to all core
functionalities in simulation and in hardware, you must purchase a license for the core.
i o i tu
Evaluation licenses and hardware timeout licenses are available for this core. Contact your local
sales representative for information about pricing and availability.
-D ea iro for
Note: To verify that you need a license, check the License column of the IP Catalog. Included means that a
ut nst
license is included with the AMD Vivado™ Design Suite; Purchase means that you have to purchase a
license to use the core.
Re es C In
For more information about this core, visit the O-RAN lounge web page.
or R to ial
Information about other AMD LogiCORE™ IP modules is available at the Intellectual Property
page. For information about pricing and availability of other AMD LogiCORE IP modules and
tools, contact your local sales representative.
t f do ed nt
License Checkers
No ra os de
If the IP requires a license key, the key must be verified. The AMD Vivado™ design tools have
several license checkpoints for gating licensed IP through the flow. If the license check succeeds,
do cl nfi
the IP can continue generation. Otherwise, generation halts with an error. License checkpoints
are enforced by the following tools:
El is o
• Vivado Synthesis
C
• Vivado Implementation
• write_bitstream (Tcl command)
D
IMPORTANT! IP license level is ignored at checkpoints. The test confirms a valid license exists. It does not
AM
D
Ordering Information
To purchase this IP core, contact your local Sales Representative referencing the appropriate part
number in the following table.
at
Chapter 3
n
rib I ma tio
n te
ist rch Li ma
Product Specification
i o i tu
-D ea iro for
The functional block diagram of the core is shown in the following figure.
ut nst
Figure 3: Core Block Diagram
Re es C In
1-4 unsolicited channels (SRS), no O-RAN framing
Separate UL/DL per CC Timing and Synchronization 1– Processing Pipelines 1– Physical Ports
t f do ed nt
PUxCH
Sub-Section PUxCH BFP
O-RAN
Buffer Data 9/12/14
Framing
No ra os de
Oran Stats
PUxCH C-Plane PUxCH Control
Oran window
Multi CC Symbol Buffer Beam ID Mgr
eAxC Map
X23910-051223
n
rib I ma tio
1-4 unsolicited channels (SRS), no O-RAN framing
n te
ist rch Li ma
UL/DL per CC Timing and Synchronization 1– Processing Pipelines 1– Physical Ports
i o i tu
PUxCH
Sub-Section PUxCH BFP
O-RAN Ant*32Bits
Buffer Data 9/12/14
Framing UL OCP Single AXIS
1– Ethernet Processing Pipelines DBL Buffer
-D ea iro for
eCPRI/
Ethernet 21 to 1 PUxCH Section Request PUxCH Data
ut nst
1914.3
FIFO Pipelined Mux Multi CC, RB Section info, Double Buffer Request
Framer
Request Mgr
Re es C In
2048 FlowId Table
oDU Dest/Vlan lookup
1 – 20 Spatial Stream Storage 1 – 20 Physical Ports
or R to ial
Ethernet
FIFO
eAxC Map
Packet Filter
eCPRI/1914.3
RAW/IP
O-RAN
Parser
Multi O-DU Ring
Buffer (CIRC)
4 to X Pipelined
Interconnect
PDxCH C-Plane
Multi CC Symbol Buffer
PDxCH Control
Beam ID Mgr
DL OCP
DBL Buffer
Ant*32Bits
Single AXIS
AXIS Ethernet message pipe to U-Plane & PRACH Beam Weights PRACH BID List
ARM for all non HW processed Unsupported Section Messages
messages. Bypass ports
Timestamps from the Ethernet
interface are included for each
packet, enabling 1588 support
El is o
X28013-051423
C
Note: PUxCH expands to PUSCH and PUCCH, with PDxCH expanding to PDSCH and PDCCH.
D
Core Functionality
AM
D
The main functions of the O-RAN Radio IF core are described in the following sections. The core
also features a common AXI4-Lite interface, which is connected to the embedded processor and
is used by the software to configure and monitor the core. The FIFOs and buffers required at the
interfaces to the Ethernet ports and for the spatial stream Delay Compensation buffering are also
included in the core. These are optimally sized during block configuration. Internally, the data
at
path is optimized to guarantee high throughput to support designs featuring multiple Ethernet
ports working at full bandwidth.
O-RAN Overview
n
rib I ma tio
The O-RAN Radio IF core partially supports the O-RAN Control, User and Synchronization Plane
Specification v11.0 (O-RAN Specification v11.0) . If you are new to O-RAN and 5G, a useful
n te
resource for numerology and resource block (RB) limits is available here.
ist rch Li ma
Note: Contact your local Support contact to request additional features and enhancements to better suit
i o i tu
the core to your needs.
-D ea iro for
To use the core successfully, you must consider the following O-RAN parameters, the maximum
ut nst
bounds of which are programmed in the Vivado IDE:
Re es C In
1. Subcarriers (SCs): These are resource elements (REs). There are 12 REs in an RB.
2. Component carriers (CCs) and occupied bandwidth. The bandwidth of each CC = (number of
REs) × ( maximum number of RBs) × (SC spacing).
or R to ial
3. The numerology of each CC.
t f do ed nt
You must specify the maximum number of SCs. If you only have one CC, and the bandwidth of
each CC = (number of REs) × (maximum number of RBs) × (SC spacing), this is 12 × 275 = 3,300,
which yields a bandwidth of 3,300 × 15 kHz = 49.5 MHz at numerology 0, 99 MHz at
No ra os de
numerology 1, and so on. If you wish to use more than one component carrier, the bandwidth of
each of these accumulates to give the occupied bandwidth. To optimize resources, these
do cl nfi
component carriers all share the same memory resources, and these limits must be defined
through the AXI4-Lite interface.
El is o
In a mixed use case, you must consider the occupied bandwidth, numerology, component carrier,
and delay requirements when calculating the worst case memory usage for this scenario. These
C
worst-case figures must be used to define the memory limits of the core. When the core is in
operation, the memory usage can be reconfigured through the AXI4-Lite interface, as long as
D
O-RAN also gives complete control of the radio unit (O-RU) to the O-RAN distributed unit (O-
AM
D
DU). In downlink, the oran_radio_if terminates the O-RAN transport protocol for both the
C-Plane and the downlink U-Plane and passes the data to the radio functional blocks.
In Uplink, the core normally relies on C-Plane messages coming from the O-DU to request data
from the radio processing functions, and then encapsulates and sends that data back to the O-
DU in uplink U-plane messages.
at
Note: The O-RAN Radio IF core provides unsolicited ports, the purpose of which might be to transport SRS
data, and are not expected to carry spatial stream data.
Through the O-RAN interface each O-DU can control the behavior of the O-RU, which forwards
beam IDs and data packets relying on a local timer synchronized to the fronthaul network. Each
O-DU requests the O-RU to send back the uplink data and PRACH packets. Other uplink
channels are available to send unsolicited traffic to the O-DU (for example, SRS data).
Note: The core orders uplink traffic following a strict priority rule: PRACH packets are sent only if there are
n
no PUxCH data ready and unsolicited traffic is sent only when there are neither PUxCH nor PRACH
rib I ma tio
packets to be sent.
The following table shows how the number of symbols and their duration are calculated based
n te
ist rch Li ma
on the numerology in use. Key 5G NR parameter limits are shown to help in understanding the
subsequent calculations and explanation of the O-RAN Radio IF core functionality.
i o i tu
Table 2: Numerology Table
-D ea iro for
ut nst
Numerology (µ): 0 1 2 2 (Ext1) 3 4
Subcarrier Spacing (kHz) 15 30 60 60 120 240
Re es C In
Maximum Number of RBs 275 275 275 275 275 137
Maximum Bandwidth (MHz) 49.5 99 198 198 396 394.56
Per
Frequency Domain Samples 3300 3300 3300 3300 3300 1644
or R to ial
FFT Size
Symbol
4096 4096 4096 4096 4096 2048
CP Length (= sym==0 | sym==7 × 2µ) 320 352 416 N/A2 544 400
t f do ed nt
CP Length (all other symbols) 288 288 288 1024 288 144
Symbols Per Slot 14 14 14 12 14 14
No ra os de
Slots Per 1 2 4 4 8 16
Time Domain Samples Subframe 61440 122880 245760 245760 491520 491520
Duration (= sym==0 | sym==7 × 2µ) (µs) Per 71.88 36.2 18.36 N/A2 9.44 4.98
do cl nfi
Duration (all other syms) (µs) Symbol 71.35 35.68 17.84 20.83 8.92 4.46
Symbols Per 10 ms 140 280 560 480 1120 2240
El is o
Clks @ 245.76 (sym= 0 | 7 × 2μ) Symbol 17664 8896 4512 - 2320 1224
Clks @ 245.76 (all other syms) 17536 8768 4384 5120 2192 1096
AM
D
Related Information
at
n
rib I ma tio
The IP core provides separate Downlink and Uplink External Radio Frame Start input ports, which
must be driven correctly with respect to the Air 10 ms Reference, and the overall system timing,
n te
for correct operation of the IP core and the downstream processing functions external to the IP
ist rch Li ma
core. These external radio start signals are used as 10 ms reference signals. They should be
driven by a synchronous single clock cycle wide pulse at the system aligned 10ms period.
i o i tu
-D ea iro for
Note: System timing alignment functions (S-plane) are external to the IP core.
ut nst
The following figure shows the interaction of radio_start with the Symbol counter behavior
of a single CC timer.
Re es C In
Figure 6: Symbol Timing shows the general intent of the Downlink/Uplink radio_start signals
and their relationship to the Air 10 ms reference and the Downlink/Uplink Symbol timing.
or R to ial
The internal timing generator creates symbol windows based on the numerology and clock rate,
which are programmed using the register interface.
t f do ed nt
Each provisioned component carrier is provided with its own numerology symbol timer (CC
No ra os de
Timer) configured through the AXI4-Lite register interface. The rising edge of the radio start
signal is the master, and resets the timing logic at every pulse. This ensures there are no drift
issues over time, even if the timer logic is driven by the internal clock.
do cl nfi
The current symbol, slot, and subframe counter values for each CC Timer are provided as core
outputs, to be reused in local logic or for verification. The interface works in the same way for
El is o
You can optionally enable external symbol strobes to increment the numerology counters. This
removes all time dependency from the core. This is also the recommended approach if you plan
D
to modify the clock while in operation, for example if dynamically switching between 10G and
25G MAC operation.
AM
D
n
rib I ma tio
n te
ist rch Li ma
i o i tu
-D ea iro for
ut nst
Re es C In
or R to ial
A separate radio_start can, if required, be enabled for each component carrier. This is
t f do ed nt
enabled in the GUI using the parameter Individual_10ms_Strb_Enable. In this case,
xxxm_radio_start_10ms is used for component carrier 0, xxxm_radio_start_10ms_cc1
No ra os de
Symbol Timing
do cl nfi
Both the uplink and downlink spatial stream interfaces are governed by separate per-CC symbol
El is o
timers (CC Timers). These timers determine when data appears on the downlink data interface
and when it is requested on the uplink data request interface. The timers must be the same
C
numerology, but can be offset relative to each other using the external radio start signals.
D
A packet containing C-Plane or U-Plane messages must arrive within a relative window of N
n
symbol periods, where N represents the total number of symbols that the O-RAN Radio IF core is
rib I ma tio
provisioned to buffer. If it arrives outside the window, the data does not appear on the spatial
stream ports. The O-DU must send these packets in a timely manner, accounting for network
n te
delays and the capabilities of the radio unit containing the IP. In short, the core aligns the
ist rch Li ma
incoming data and control messages to the timing information it is given.
i o i tu
According to the O-RAN standard, the definition of the reception window for control messages
relies on the two parameters listed below. You must define these parameters according to your
-D ea iro for
architectural considerations.
ut nst
• TCP_ADV_DL: This is the minimum advance time the downlink C-Plane messages must arrive
Re es C In
before the corresponding U-Plane messages.
• T2A_MIN_CP_UL: This is the minimum advance time the uplink C-Plane messages must arrive
or R to ial
before the corresponding U-Plane messages are received at the antenna.
In the O-RAN Radio IF, the period in picoseconds of the internal clock is captured by the
t f do ed nt
Xran_Timer_Clk_Ps parameter. As an example, assume the following values:
No ra os de
You also need to take an estimate of the minimum latency of a downlink data packet in the
do cl nfi
fronthaul interface, that is, the time a packet takes to go from the Ethernet port input to any
memory buffer placed in front of any beam former or suitable radio block. This value is referred
to as tDECAP.
El is o C
For the Uplink direction, T2A_MIN_CP_UL has to be referred to the Air interface, you need to
introduce an estimate of the latency of the upstream uplink radio processing chain, to the O-RAN
Radio IF AXI4-Stream input interface. This latency is modeled by the oRU_Processing_Latency
D
Under these assumptions, you can compute the total advance time of DL and UL C-Plane:
Next, to compute the setup values, consider the actual symbol period for the numerology of the
n
component carrier:
rib I ma tio
SYMBOL_PERIOD_mu0 = 71428571ps
SYMBOL_PERIOD_muX = SYMBOL_PERIOD_mu0 / (2muX)
n te
ist rch Li ma
Convert to the internal clock cycles:
i o i tu
ACTUAL_PERIOD_CP = SYMBOL_PERIOD_muX / Xran_Timer_Clk_Ps
-D ea iro for
The main O-RAN Radio IF DL timer, per CC, is used to determine when the core must deliver
ut nst
data packets belonging to each symbol period. Each CC Timer is aligned by
defm_radio_start_10ms and visible on the m<C>_dl_sym_num output as previously
Re es C In
described.
Now, to determine if a U-Plane data packet arrived either on time or late, you need to set
or R to ial
another internal timer, which must be advanced with respect to the main one by tDECAP.
Also, to determine if a C-Plane control packet arrived either on time or late, you need to set the
t f do ed nt
DL control Reception Window timer, again per component carrier, also visible as
m<C>_dl_cta_sym_num. This counter is advanced with respect to the main one by
No ra os de
(TCP_ADV_DL + tDECAP).
Therefore, set the following three register values (in this example, assume numerology = 0 and
do cl nfi
Xran_Timer_Clk_Ps) = 28570
C
quotient)
DL_CTRL_RXWIN_ADV_CP
= 5143
In uplink, the main timer determines when the core must deliver U-Plane Ethernet packets
bearing data for each symbol period and is in phase with fram_radio_start_10ms. Also, it is
available on the m<C>_ul_sym_num output.
at
To determine if a C-plane control packet arrived either on time or late, you must set the UL
n
control Reception Window timer, also available as m<C>_ul_cta_sym_num. This counter is
rib I ma tio
advanced with respect to the main one by (T2A_MIN_CP_UL + oRU_Processing_Latency). Set the
following:
n te
ist rch Li ma
cc_ul_setup_c_abs_symbol= (UL_CTRL_RXWIN_ADV_CP / ACTUAL_PERIOD_CP) +
1 = 3
i o i tu
(that is the smallest integer greater than the
quotient)
-D ea iro for
cc_ul_setup_c_cycles = (cc_ul_setup_c_abs_symbol * ACTUAL_PERIOD_CP) -
ut nst
UL_CTRL_RXWIN_ADV_CP
= 25714
Re es C In
eAxC_ID
or R to ial
eAxC ID Bit Allocation
t f do ed nt
The eAxC ID field is a 16-bit field that defines the source O-DU and intended endpoint in the O-
RU. Field selection width can be modified, within limits, using shift and mask variables. The
No ra os de
RU_Port_ID can then be further broken down to indicate PDxCH/PUxCH, PRACH, and SSB
streams.
do cl nfi
Decoding of eAxC ID to the streams and physical ports of the IP core can be configured via one
of the two modes described in the following two sections.
El is o
The default mode of operation of the IP core is the Mask/Value decoding mode.
C
By default, the IP core is configured for a 4/1/3/8 bit eAxC ID allocation as follows:
D
Note that while the three upper fields can be 6 bits, in practice these are
limited to
4 oDU in total,
16 Component carriers in total
at
BandSector can only be used with the Mapping table enabled and in mode 2 &
3.
The default mode of operation of the IP core is the Mask/Value mode, and the default decode
n
allocation of the RU_Port_ID is as shown below. A mask is applied to the upper bits of the
rib I ma tio
RU_Port_ID to determine the routing of the Spatial streams. The lower bits index Spatial streams
from 0 to Max.
n te
ist rch Li ma
RTCID DDDD_BCCC_RRRR_RRRR / Mask Compare
PXxCH ...._...._00.._.... 0xC0 0x00 (0)
i o i tu
SSB ...._...._01.._.... 0xC0 0x40 (64)
PRACH ...._...._10.._.... 0xC0 0x80 (128)
-D ea iro for
While this mode does not offer full remapping capability, it offers some flexibility that should be
ut nst
applicable to most use cases. More complex remapping needs should be supported using the
eAxC Table Mapping mode(s).
Re es C In
For both modes, the basic eAxC ID bit allocations must be configured to suit the overall system.
As an example, to allocate as 3/2/3/8:
or R to ial
• Three-bit DU ID
t f do ed nt
• Two-bit BandSector ID
• Three-bit CC ID
No ra os de
• Eight-bit RU Port ID
You would call the API function with the following arguments:
do cl nfi
xorif_set_fhi_eaxc_id(3, 2, 3, 8)
El is o
All MSBs can be considered zero stuffed when the mask is less than the internal maximum bus
size for the parameter. The Shift takes place first, then the mask. The maximum widths of each
result are mentioned in the field breakdown above.
Note: There is no Shift/Mask of the RU_Port_ID. This always starts at bit 0, and its masking is managed
n
separately to allow distinction between PXxCH/PRACH/SSB. There is a restriction on the values used in
rib I ma tio
the SS Mask to identify the Spatial Stream. PDxCH channels map from 0 to 19, PUxCH from 0 to 15, and
SSB is 0.
n te
Several separate functional data streams need to be decoded from the RU_Port_ID:
ist rch Li ma
• PUxCH
i o i tu
• PDxCH
-D ea iro for
• PRACH
ut nst
• SSB (as this mask is provided)
Re es C In
Several MSBs can determine the data stream with the LSBs providing the port ID.
Assuming you use the upper two bits to determine the stream, you need to supply the mask for
or R to ial
this as 0xC0. You also need to supply the value to match each stream to.
For example, to allocate the RU_Port_ID you can call the following:
t f do ed nt
xorif_set_ru_ports(8, 5, 0xC0, 0, 0x80, 0x40)
No ra os de
Note: LTE, SSB, and PRACH detection can be disabled by writing 0x0 to the Mask value. Further API
programming examples are available on GitHub.
n
rib I ma tio
An optional mapping look-up table can be implemented, and supports several Modes and sub-
modes to provide flexibility to decode/route from eAxC ID to the various functional streams and
physical ports of the IP core.
n te
ist rch Li ma
It is enabled using the Defm_Map_Table_Width parameter. Its default value is 0, disabled with bit
i o i tu
widths 5-11 supported. This gives possible table sizes of 32, 64, 128, 256, 512, 1024, and 2048
entries.
-D ea iro for
ut nst
Each table entry contains a stream type and a Stream Port ID. The register field
defm_cid_map_wr_stream_portid is used to set the internal stream Port ID. All IP streams are
Re es C In
indexed from 0 to the MaxNumOfStreamsForType.
The register field defm_cid_map_wr_stream_type sets the internal stream Type. The IP
or R to ial
interpreted types are shown in the following table. Other types can be used to identify other
streams not processed by the IP.
t f do ed nt
Table 3: IP Interpreted Types
No ra os de
Type Value
IP Unknown All Ones
User Defined 5 Upwards
do cl nfi
IP LTE 4
IP PRACH 3
El is o
IP SSB 2
C
IP PUxCH 1
IP PDxCH 0
D
The table can be addressed in three modes, and these are set via defm_cid_map_mode. The
addresses cannot be wider in bits than the supported table width (5 to 11 bits).
AM
D
The following tables show the bits used in each mode. From v3_0, selection has been updated to
use the register defm_cid_map_submode to control the bit selection. This enables the bits used
to be separated from the width definitions of each field in the eAxC ID. If an oDU requests an ID
that is outwidth, the available range, it should be rejected.
Mode 1 allows the Direction bit and RU Port ID to be used for basic flexible Stream Type and
at
Mode 2 and 3 offer options to additionally use BandSector ID and/or CC ID in combination with
RU Port ID to share PDxCH and PUxCH processing logic for LUT savings.
n
Table 4: Mode 1: Bits to Make Up Table Read Address
rib I ma tio
Sub Mode Direction BSID CCID RU_Port_ID Total Bits
0 1 2 3
n te
ist rch Li ma
1 1 3 4
2 1 4 5
i o i tu
3 1 5 6
4 1 6 7
-D ea iro for
5 1 7 8
ut nst
6 1 8 9
Re es C In
Table 5: Mode 2: Bits to Make Up Table Read Address
Sub Mode
or R to ial Direction BSID CCID RU_Port_ID Total Bits
0 1 3 3 2 9
1 1 3 2 2 8
t f do ed nt
2 1 3 1 2 7
3 1 3 3 3 10
No ra os de
4 1 3 2 3 9
5 1 3 1 3 8
6 1 3 3 4 11
do cl nfi
7 1 3 2 4 10
8 1 3 1 4 9
El is o
9 1 2 3 5 11
10 1 2 2 5 10
C
11 1 2 1 5 9
D
AM
D
at
n
rib I ma tio
PDxCH Data Mgr SS0
n te
ist rch Li ma
SS1 CC1 SS1 CC0
i o i tu
SS2 CC1 SS2 CC0
-D ea iro for
PDxCH Data Mgr SS3
Standard non-shared example
with four physical Spatial Stream
ut nst
Lanes in the IP SS3 CC1 SS3 CC0
Re es C In
PDxCH Data Mgr SS0
SS3 CC1 SS3 CC0 SS2 CC1 SS2 CC0 SS1 CC1 SS1 CC0 SS0 CC1 SS0 CC0
(VCC7) (VCC6) (VCC5) (VCC4) (VCC3) (VCC2) (VCC1) (VCC0)
X27984-051223
t f do ed nt
Table 6: Mode 3: Bits to Make Up Table Read Address
No ra os de
1 1 5 4 10
2 1 4 4 9
3 1 3 4 8
El is o
4 1 2 4 7
C
5 1 1 4 6
6 1 3 6 10
D
7 1 2 6 9
8 1 1 6 8
AM
D
9 1 2 8 11
10 1 1 8 10
You should generally not select a submode that uses more bits than set in the GUI for the
MapTable.
## The following are eAxC ID field widths given in the IOT Specification
at
## 2.6.4.4
## 4.2.4.6
## 5.1.2.8
## 2.3.3.8
## 4.3.3.6
## Mode 1 Example
If 2.6.4.4 was used for the Field widths, a submode greater than 2 should
not be used.
Using 0-2 gives 2-4 of the RuPortID used for the address field.
eAxC ID = DDBBBBBB_CCCCRRRR
n
SubMode2 = ........_....**** (4-Bits + the Direction Bit = 5 Bits in Total
for the Address.)
rib I ma tio
## Mode 2
If 2.6.4.4 was used for the Field widths, submodes 0-7 can be used.
n te
ist rch Li ma
The widths 5.1.2.8 do not have a suitable SubMode selection.
eAxC ID = DDBBBBBB_CCCCRRRR
i o i tu
SubMode0 = .....***_.***..** (8-Bits + the Direction Bit = 9 Bits in Total
for the Address.)
-D ea iro for
## Mode 3
ut nst
If 2.6.4.4 was used for the Field widths, submodes 0-5 can be used.
In this case 5.1.2.8 does have a suitable SubMode at 5.
Re es C In
eAxC ID = DDBBBBBB_CCCCRRRR
SubMode0 = ..******_....**** (10-Bits + the Direction Bit = 11 Bits in
Total for the Address.)
or R to ial
Note: API programming examples are available on GitHub.
Downlink Datapath
t f do ed nt
No ra os de
The downlink datapath is composed by the interconnection of 1–4 Ethernet processing pipelines
and 1–20 downlink processing pipelines (one per supported spatial stream). Between them, in
principle, a bussed interconnection with 4–20 pipelines allows any O-DU using one or more
Ethernet ports to feed data into any spatial stream control or data buffer.
do cl nfi
Related Information
El is o
• Packet filter
• Packet parser
• O-RAN window – multi O-DU ring buffer
The maximum packet size, which is programmable independently for Framer or Deframer, can
support packets up to 16310 payload bytes, plus the overhead of the selected encapsulation
at
formats.
Note: The GUI configuration parameter, which is setting the Framer Maximum User Data payload length is
also bounding the value to be assigned in the fram_mtu_size register to drive the application layer
fragmentation being performed by the ORAN Framing for PUxCH.
Note: Depending on the MTU size, the number of RBs requested and the fragmentation method the
resulting packet size may not fully occupy the available MTU bytes.
Related Information
n
rib I ma tio
Packet Parser
Packet Filter
O-RAN Window – Multi O-DU Ring Buffer
n te
ist rch Li ma
Naming Conventions for Multi-Port Signals
i o i tu
The following conventions are used for naming multipport signals with different iterators:
-D ea iro for
ut nst
• <m/s><E>_*: Port number determined by the number of Ethernet ports.
Re es C In
• <m/s><S>_*: Port number determined by the number of spatial streams.
Depending on the selected protocol, the packet filter locates the eCPRI or the IEEE 1914.3
header and analyzes the included fields to handle the incoming packets.
do cl nfi
The expected message types are those specified by the standard. In the case of eCPRI
encapsulation, the data and the control messages must be h00 and h02, respectively. In the IEEE
El is o
All the packets arriving through the instantiated Ethernet ports are analyzed by the packet filter
according to a set of filtering rules that can be defined by programming the user_data_filter
D
words and mask registers, described in the defm_ section of the O-RAN Radio IF register map
(see Register Space). You can decide which fields (belonging to the Ethernet or IP/UDP headers)
AM
D
must be checked to recognize each incoming packet. The following figures illustrate examples of
each possible encapsulation method.
Note: Filter words are 128 bits or 16 bytes wide. In total, there are 64 bytes available in the filter.
at
n
rib I ma tio
Byte_15 Byte_14 Byte_13 Byte_12 Byte_11 Byte_10 Byte_9 Byte_8 Byte_7 Byte_6 Byte_5 Byte_4 Byte_3 Byte_2 Byte_1 Byte_0
Transport
word_0 EtherType Source MAC Destination MAC
Header
n te
ist rch Li ma
word_1 ORAN Header Transport Header
i o i tu
word_2
-D ea iro for
word_3
ut nst
X23893-042620
Re es C In
Figure 9: Standard Ethernet with VLAN Tag
word_0
or R to ial
Byte_15 Byte_14 Byte_13
VLAN_Tag
Byte_12 Byte_11 Byte_10 Byte_9 Byte_8
Source MAC
Byte_7 Byte_6 Byte_5 Byte_4 Byte_3 Byte_2
Destination MAC
Byte_1 Byte_0
t f do ed nt
word_1 ORAN Header Transport Header EtherType
No ra os de
word_2
word_3
do cl nfi
X23891-042620
El is o
Byte_15 Byte_14 Byte_13 Byte_12 Byte_11 Byte_10 Byte_9 Byte_8 Byte_7 Byte_6 Byte_5 Byte_4 Byte_3 Byte_2 Byte_1 Byte_0
DSCP,
word_0 45 00 08 Source MAC Destination MAC
ECN
D
IPv4 – Destination IPv4 - Header IPv4- Time to IPv4 – Flag, IPv4 - IPv4 – Total
word_1 IPv4 – Source IP Address
IP Address Checksum Protocol Live Fragment Offset Identification Length
AM
D
X23890-042620
at
n
rib I ma tio
Byte_15 Byte_14 Byte_13 Byte_12 Byte_11 Byte_10 Byte_9 Byte_8 Byte_7 Byte_6 Byte_5 Byte_4 Byte_3 Byte_2 Byte_1 Byte_0
n te
ist rch Li ma
Hop_ Next_ IPv6 –
word_1 IPv6 – Source IP address IPv6-Flow_Label
Limit Header Payload_Length
i o i tu
word_2 IPv6 – Destination IP address IPv6 – Source IP Address
-D ea iro for
word_3 Transport Header UDP Checksum UDP Length UDP Destination Port UDP Source Port IPv6 – Destination IP Address
ut nst
X23892-042620
Re es C In
The software programs the fields to be verified by writing the expected value in the proper
position within each user_data_filter_word. At the same time, it disables the corresponding byte
or R to ial
mask bit within the user_data_filter_word_mask register. If an Ethernet frame satisfies the
programmed filtering rules and also holds the packet type in the transport header (as defined by
O-RAN Control, User and Synchronization Plane Specification v11.0 (O-RAN Specification v11.0)), its
t f do ed nt
extracted payload is forwarded to the de-framer buffer manager. Otherwise, the entire packet is
passed to the m_message AXI4-Stream interface to be made available to the embedded
No ra os de
processor.
In the register map (see Register Space), the packet filter function (defm_err_packet_filter) can be
do cl nfi
configured to discard all messages received with errors. Alternatively, it can be set to keep
messages whose header and length are formally correct but whose payload is affected by
incorrect bits, which generates a bad frame check sequence at reception.
El is o C
common in both the uplink and downlink directions, you need to define the type of Ethernet
frames the packet filter should receive by programming the FRAM_PROTOCOL_DEFINITION
AM
D
• bit[0]
○ bit[0] = 0 to select the eCPRI protocol.
at
• bit[4]
○ bit[4] = 1 to insert a VLAN tag.
n
○
rib I ma tio
• bit[6:5]
○ bit[6:5] = 01 to generate UDP/IPv4 encapsulation.
n te
ist rch Li ma
○ bit[6:5] = 11 to generate UDP/IPv6 encapsulation.
i o i tu
○
-D ea iro for
When modifying the filter settings, Ethernet traffic to the IP core should be externally gated and
ut nst
stopped from entering the core.
Re es C In
Minimum Ethernet frame with Frame Check Sequence (FCS) is 64 bytes, min payload size of 46
bytes. This means that the minimum size of packet the core should see is 60 bytes or 7.5 64-bit
or R to ial
words.
t f do ed nt
Figure 12: Short Packet Timing
No ra os de
do cl nfi
El is o C
D
AM
D
This means that a RAW Ethernet packet with only one control section, whose eCPRI
Payload_Size is 20, then it includes 12 bytes for the MAC addresses, 2 bytes for the
at
Ethernet_Type and other 4 bytes for the eCPRI header, needs to be padded with exactly 22
octets, which will be dropped by the filter while accepting and forwarding it.
The filter always checks that the actual length of each received O-RAN packet matches the
n
declared Payload_Size, according to the following algorithm:
rib I ma tio
IF ((Payload_Size +
expected_frame_overhead) < 60 AND measured_length = 60) OR
n te
ist rch Li ma
((Payload_Size +
expected frame overhead) == measured_length)
THEN the packet is accepted
i o i tu
and forwarded
ELSE the packet is flagged
-D ea iro for
as runt_packet_len and dropped
ut nst
Note: The algorithm is also extended to support the case of VLAN tagged and padded control packets
holding in total 68 octets, including the FCS, as allowed by the IEEE 802.1Q, when the tag is appended by
Re es C In
an intermediate switch.
Note: The algorithm is applicable to O-RAN control packets only. U-Plane downlink data packets are always
assumed to be larger than the minimum standard size and thus never padded.
or R to ial
Packet Parser
t f do ed nt
While the packet filter terminates the L2 or L3 encapsulation protocol and the selected eCPRI or
IEEE1914.3 protocol transport layer, the packet parser looks for O‑RAN features, collects the
No ra os de
information carried within the O-RAN header, distinguishes the control from the data packets,
and delimits the sections and section extensions within each received O-RAN message.
do cl nfi
After terminating the O-RAN protocol and processing each section and extension, the block
forwards any new beam weights and associated Beam ID. These should be stored in the
El is o
associated beam weights storage memory (outside the ORAN Radio I/F core), for the DL and UL
data channels as well as the supported PRACH channels.
C
A dedicated output presents each unsupported section type instance, properly decapsulated and
realigned, thus allowing the feeding of a user-defined block to receive them.
D
According to the O-RAN protocol, each incoming packet must be checked to determine if it has
arrived within the associated data or control reception window.
The O-RAN Radio IF core computes the offset between the symbol position declared in the
O‑RAN header and the current symbol number according to the associated DL or UL timer. If the
offset is found to be within the reception window, the packet is accepted and forwarded to the
at
addressed spatial stream data or control buffer; otherwise, it is dropped. The computed offset
also determines the address where the packet must be stored in the selected buffer.
To reduce the latency of the Ethernet processing pipeline, this computation is done in parallel
with the packet parser. Consequently, when a decapsulated packet exits the packet parser, it is
possible to write it directly into the selected buffer resource.
n
feeding up to 20 spatial streams. If all four pipelines receive an O-RAN packet at the same time,
rib I ma tio
and those packets are sent to four different spatial streams, they can be delivered with the
minimum possible latency and without any need to store them in the Ethernet pipeline. These
n te
packets are still written to the circular buffer, but reading starts as they are being written.
ist rch Li ma
However, as soon as two packets addressed to the same data or control spatial stream buffer
i o i tu
enter two different Ethernet ports, congestion occurs. One packet must be stored somewhere
while the other is written in the final buffer destination.
-D ea iro for
ut nst
To manage any possible congestion, each Ethernet processing pipeline ends in a temporary
circular buffer. In the circular buffer, the received and decapsulated packet can be stored if its
Re es C In
final spatial stream destination buffer is busy with the traffic coming from a different Ethernet
port. To minimize the latency of each packet and optimize the interconnection between Ethernet
and spatial stream pipelines, the available circular buffer ensures the following:
or R to ial
• Packets are stored in the circular buffer only if their destination is found to be busy.
t f do ed nt
• If a packet is waiting in the circular buffer for the spatial stream resource to become available,
any subsequent packet arriving through the same Ethernet port can be forwarded, overtaking
No ra os de
abs10,p1
X27983-041823
The above example is broken into four stages. In stage one, four packets arrive for Spatial Stream
n
Zero at the same time on Ethernet interfaces 0 and 1. These are for the absolute symbol 10 of
rib I ma tio
the radio frame. In this case, Eth1 was given access first and its packets are moved first to SS0 as
shown in the second step. Stage three shows SS0 filled with Eth1 packets; Eth0 packets are now
n te
moved over. Stage four then shows the packets in SS0. They will be released in order from right
ist rch Li ma
to left, so p3, p1, p0, and finally p2. If the OCP is in the core however, they will appear in the RB
order requested.
i o i tu
In the current implementation, each circular buffer can store at least four O-RAN packets each of
-D ea iro for
the maximum configured length, depending on the Maximum User Payload Length
ut nst
(Defm_Eth_Pkt_Max) parameter.
Re es C In
There is also a side table used to store packet metadata. In order to avoid to overfill the side
table, you should configure the required depth of the circular buffer meta table, choosing
between 8, 16, or 256 entries. This depends on the maximum number of consecutive short C-
or R to ial
Plane packets, which might potentially arrive soon after one or more high size U-Plane packets.
Note: Multiple short ctrl packets arriving while a long data packet is being read can result in the latest
t f do ed nt
received packets being discarded, as there is no room to store them. This results in a circular buffer
overflow, but the circular buffer will continue to operate as expected.
No ra os de
The downlink per spatial stream pipeline consists of three circular buffers. One buffer is
dedicated to U-Plane downlink data, and the other two buffers are dedicated to downlink and
El is o
U-Plane messages are buffered until their symbol, slot, and sub-frame numbers match the
current symbol, when they are generated on the m<S>_defm_data_tdata required Spatial
Stream port. The minimum size of the data buffer is one symbol.
D
Data messages are stored on a per-component-carrier and per-symbol basis and can be written
AM
D
out of order. Each section header is kept, allowing the individual radio blocks to be unrolled and
stored in an external double buffer, which can be implemented to feed the beamforming
function. Refer to the m<S>_defm_data_tuser description in Downlink U-Plane Data Ports
for details about all the associated information fields.
In the same way, control messages are stored in the corresponding circular buffer, ready to be
generated on the respective beam ID forward port according to the symbol timing shown in
at
Symbol Timing.
The minimum size of the control buffer is one symbol plus the equivalent in symbol periods of
the advance time control messages need to arrive with respect to data.
The circular buffer for uplink C-Plane messages, even though part of the downlink processing
n
pipeline is managed relying on the uplink block timer. Refer to Uplink Beam ID Forward Ports and
rib I ma tio
Downlink Beam ID Forward Ports for details about the information associated to the different
fields.
n te
ist rch Li ma
Downlink ORAN Processing Block
i o i tu
An optional Channel Processing Block (OCP) is available at the output of the U-Plane processing
-D ea iro for
pipeline. In the downlink (DL) direction, the OCP orders the incoming, potentially unordered
ut nst
ORAN sections into a RB ordered list. This stream can then be fed to a downstream beamformer,
precoder, or iFFT block.
Re es C In
The output of the downlink processing pipeline consists of a U-Plane interface for each antenna.
These are in a 64-bit data format (two uncompressed samples per cycle). The samples might not
or R to ial
be in the order required by the downstream beamformer, precoder, or iFFT block. In addition,
samples might not be present if not received from the Ethernet.
t f do ed nt
The OCP block re-orders the samples, zeroing out any missing samples, and enables the
interleaving of antenna data.
No ra os de
The following figure shows a block diagram of the downlink section of the OCP block.
Downlink
C
From SS0
downlink SS1 Write Engine Ping Pong
SS2 Output to OFDM
processing Memory Read Engine
….
….
….
pipeline SSn
D
AM
D
AXI4-
LITE AXI4-Lite Register Control
Sequence Table
CTRL Interface
X27901-031723
at
The OCP block takes data from the downlink U-Plane data ports of the downlink processing
pipeline. Each antenna has its own AXI4-Stream interface on the OCP block (SS0 to SSn). The
data is contained in packets of 64-bit words which correspond to two 32-bit samples.
As shown in the downlink OCP block diagram, each antenna interface is first input to a write
n
engine. This block parses the out-of-band information sent with the packet received from the
rib I ma tio
downlink U-Plane interface. This information gives the component carrier (CC) pertaining to the
data packet, along with the start position and number of resource blocks (RBs) contained in the
n te
data packet. The CC and RBs for each antenna can arrive in any order. The information is used to
ist rch Li ma
write each data word into a ping pong memory. The structure of the memory for the case of four
supported CCs is shown in the following figure.
i o i tu
-D ea iro for
Figure 15: Ping Pong Memory Structure
ut nst
Re es C In
CC3 CC3
or R to ial
t f do ed nt
No ra os de
CC2 CC2
do cl nfi
El is o C
CC1 CC1
D
AM
D
RB272
....
CC0 CC0
RB1
at
RB0
X27297-101722
The ping and pong sides of the memory are arranged in sections corresponding to the number of
CCs supported by the system. Each CC is made up of a maximum of 273 resource blocks. Each
resource block consists of twelve 32-bit resource elements (REs). The memory holds up to eight
CCs and is implemented in UltraRAM (URAM). The size of the memory is set by the maximum
number of subcarriers (SCs) to be supported.
The CC and RB information from the U-Plane data ports of the downlink processing pipeline is
n
used to write the data into a specific section of the memory. Timing strobe inputs to the OCP
rib I ma tio
block indicate the symbol period for each CC. These strobes are used to switch between the two
sides of the memory. When the ping side of the memory is being written for a particular CC, the
n te
pong side can be read. When the pong side of the memory is being written, the ping side can be
ist rch Li ma
read.
i o i tu
The read engine at the OCP block output takes data from each of the memories and reformats it
according to the information stored in the sequence table. One 32-bit RE from one or more of
-D ea iro for
the memories is output on each cycle. The order of the CCs and the REs at the output, along with
ut nst
the interleaving sequence of the antennas, is set by the programming of the sequence table. The
sequence table also enables the setting of the size of each CC, its identifier, and the delay
Re es C In
between symbols at the output. An example of the AXI4-Stream output for an OCP block with
four antennas and two CCs is shown in the following figure.
or R to ial Figure 16: OCP Output Example
t f do ed nt
No ra os de
do cl nfi
El is o
The above example illustrates an interleave factor of 2. There are four antennas and the data for
two antennas is interleaved together at the output. The sequence table has been programmed to
C
output the REs for antenna 0 and 1 on the first interleave cycle, and to output the REs for
antenna 2 and 3 data on the second. The two CCs have identifiers 2 and 5. The sequence table
D
has been programmed to output CC 2 first, followed by CC 5. The order of the REs in each
packet is also set by the sequence table.
AM
D
Memory Structure
The O-RAN Radio IF core has multiple memory buffers. Given the flexibility of the core and its
ability to support multiple component carriers of different numerology (μ), care must be taken in
ensuring that these buffers are sized correctly. You must calculate this sizing for all the use cases
you wish to support, and then generate the core to support the worst-case memory parameters.
at
The number of slots varies with numerology and, by extension, the radio frame structure. The
calculation methods are given below.
n
rib I ma tio
Uplink
DEPTH = MAX_SCS/12 Uplink U-Plane DATA Requests
Request
Buffer
n te
ist rch Li ma
DEPTH = MAX_UL_CTRL_1kWORDS
i o i tu
Parsed Uplink CTRL (Sections) Uplink BeamID Forward
Uplink Control Buffer Uplink Control
Management
-D ea iro for
ut nst
DEPTH = MAX_DL_CTRL_1kWORDS
Re es C In
Downlink Downlink BeamID Forward
Parsed Downlink CTRL (Sections)
Downlink Control Buffer Control Downlink U-Plane Symbol/RB ID
Management
or R to ial
Parsed Downlink U-Plane Data
DEPTH = MAX_DL_DATA_1kWORDS
RAM
do cl nfi
X22882-051319
• Uplink Request Buffer: Double/ping-pong buffer shared by all active CCs. Each CC uses an
assigned portion, sized by the number of RBs it uses, for uplink U-Plane RB data request
El is o
information.
C
• Uplink Control Buffer: Buffer shared by all active CCs to provide control advance and Delay
Compensation. Each CC uses an assigned portion holding control information for multiple
D
symbols.
AM
• Downlink Control Buffer: Buffer shared by all active CCs to provide control advance, Delay
D
Compensation, and ordering. Each CC uses an assigned portion holding control information
for multiple symbols.
• Downlink Data Buffer: Buffer shared by all active CCs to provide U-Plane data Delay
Compensation. Each CC uses an assigned portion as holding U-Plane data for multiple
symbols.
at
• Downlink Data Pointers RAM: Buffer shared by all active CCs. Each CC uses an assigned
portion holding multiple symbol pointers to the starting location of the associated U-Plane
data in the downlink data buffer.
• Uplink Data Buffer (not shown): Sizing is fixed at the maximum Ethernet packet size. There is
one per spatial stream. The uplink data buffers are independent to support maximum spatial
stream to Ethernet flexibility.
n
rib I ma tio
The bandwidth of all the component carriers (CCs) should sum to less than the total available
bandwidth. Consider the following example:
n te
ist rch Li ma
• The available bandwidth is 200 MHz, and this is to be filled with numerology 1 30 kHz
subcarriers.
i o i tu
• 200,000 / 30 = 6,666 subcarriers.
-D ea iro for
• In 5G NR, the number of RBs per CC is limited to 275, giving (275 RBs × 12 subcarriers per
ut nst
RB) = 3,300, which is the maximum number of subcarriers.
• Two component carriers are therefore required to fill 200 MHz: 3,300 × 2 = 6,600 SCs, filling
Re es C In
approximately 198 MHz.
• In the Vivado IDE, set the Max Number of SubCarriers to 6600, if the CC bandwidth is 200
or R to ial
MHz.
The actual depth of either the DATA or the CTRL buffers depends on the amount of packet delay
do cl nfi
variation you want to compensate in the fronthaul memory and on the minimum advance time
mandated for the C-Plane with respect to the U-Plane packets. For each type of buffer, you can
define the respective Maximum Delay Compensation values, referring to O-RAN specification:
El is o
You also have to consider the time each packet will take to go through the fronthaul interface,
from the ingress Ethernet Port to the proper output interface. This latency is represented in the
diagram below by the Data Forward Window. In the design of the core, effort is made to keep
this latency as small as possible, even though its actual value depends on a number of factors
(mostly the payload size and the waiting time in the circular buffer when congestion occurs). In
real examples, this time has proven to be between 1 and 3 μs, however in the computation a
at
n
rib I ma tio
n te
ist rch Li ma
i o i tu
-D ea iro for
ut nst
Re es C In
or R to ial
t f do ed nt
No ra os de
do cl nfi
Consider the following example. For uplink and downlink control messages, Delay Compensation
and control advance are summed as follows:
n
• Maximum Delay Compensation time = 30 μs
rib I ma tio
• Total advance + Delay Compensation time = 120 μs
n te
ist rch Li ma
• At μ(numerology) = 1, there are two slots, so 14 (symbols) × 2 (slots) × 10 (subframes) =
280 symbols in a 10 ms radio frame
i o i tu
• Symbol period = 0.01 / 280 = 35.7 μs
-D ea iro for
• 120 / 35.7 = 3.36
ut nst
• Round 3.36 up to four symbols at μ = 1
Re es C In
For downlink data, only Delay Compensation applies:
• Maximum Delay Compensation time = 70 μs (the value can be different from the one chosen
or R to ial
for control)
• 70 / 35.68 = 1.96
t f do ed nt
• Round 1.96 up to 2, resulting in two symbols at μ = 1
No ra os de
m<C>_dl_sym_num output. This counter is used to address the segment, whose content has to
be read out of the SS outputs at any symbol period. It counts the total amount of symbol periods
that you have in a 10 ms radio frame, depending on the numerology assigned to each CC. Then,
El is o
it is reset to zero value at every 10 ms strobe and reaches the number of symbols for the chosen
C
If a U-Plane data packet arrives with a symbol number (computed based on subframeID, slotID,
D
and startSymbolID declared in its header) equal to the current status of the internal symbol
counter, it can still be accepted, provided the core still has enough time to transfer its content to
AM
D
If the packet arrives in advance by at least tDECAP with respect to the end of the period, it is
accepted and successfully transferred to the connected radio chain; else, if it comes closer to the
end of the period or bearing a symbol number lower than the current one, it is considered "late"
and is dropped.
at
The minimum latency of each packet within the core actually depends on a lot of factors, such as
the traffic state and the presence of other packets for the same destination arriving at the same
time, and cannot be estimated with absolute precision. As a general indication, each packet has
to first be entirely written and read out of the input Ethernet FIFO and then again, it is stored
and downloaded from the selected DL_DATA_buffer, even without any traffic interference, so its
actual latency mostly depends on its length.
n
CC_DL_DATA_SYM_NUM_INDEX defined in the register map. Each packet with a symbol
rib I ma tio
number that is not greater than the current state for the internal symbol counter, plus the value
set in CC_DL_DATA_SYM_NUM_INDEX – 1 is accepted and stored in the proper segment of the
n te
internal Delay Compensation buffer. If the symbol number was larger, the packet is considered to
ist rch Li ma
have arrived too early and is dropped. In short,
i o i tu
if (transported_symbol_number < (internal_symbol_number + CC_DL_DATA_SYM_NUM_INDEX))
-D ea iro for
then the packet is accepted. else the packet is dropped.
ut nst
Similar considerations apply for downlink C-Plane control packets. According to the O-RAN
Re es C In
specification, C-Plane packets concerning a given 5G-NR symbol must arrive in advance to allow
the O-RU to configure all the computation blocks to be applied to each data stream, such as
beamforming. The minimum advance time is represented by the TCP_ADV_DL parameter.
or R to ial
Another internal counter per configured CC, called m<C>_dl_cta_sym_num, is available in the
core and visible on the same name output. The counter is advanced by TCP_ADV_DL with
t f do ed nt
respect to m<C>_dl_sym_num.
No ra os de
When a control message arrives, the control message transported symbol number is compared
against the state of the m<C>_dl_cta_sym_num to decide if it has arrived on time.
do cl nfi
However, the actual width of the reception window is determined by the value set in the
CC_DL_CTRL_SYM_NUM_INDEX register, which corresponds to the number of symbol periods
that can be kept in the Delay Compensation buffer. When setting the proper value for
El is o
In other words, the actual starting point of the control messages reception window is determined
D
For uplink control packets, it is necessary to remember that according to the O-RAN specification
the minimum advance time parameter, T2A_MIN_CP_UL, has to be measured starting from the
arrival time of the uplink data at the antenna. Then, to determine the right position of the uplink
control message reception window, it is necessary to know the latency of the uplink data from
the antenna up to the core's input interface.
In the uplink case, two different counters per CC, called m<C>_ul_sym_num and
at
m<C>_ul_cta_sym_num, are available, with the latter to be advanced with respect to the
former to define the end boundary of the uplink control reception window, while the value set in
CC_UL_CTRL_SYM_NUM_INDEX is again used to determine the width of the reception window
itself.
For more information on symbol timing, see the timing diagram in the Symbol Timing section.
Related Information
n
rib I ma tio
Symbol Timing
Control Buffers
n te
ist rch Li ma
In the Vivado IDE, you can set the amount of memory you want to allocate for the Control
i o i tu
Buffers by configuring the UL Ctrl Delay buffer size in 1K entries and DL Ctrl Delay buffer size in
1K entries parameters.
-D ea iro for
ut nst
In general, the required buffer size depends on the number of sections you need to define per
symbol, per component carrier, and the number of consecutive symbol periods you want to
Re es C In
include in the buffer to compensate for packet delay variation.
In the case of numPrb=numBundPrb, the above does not apply and just one word per section
C
has to be counted.
• Extension Type 1, however, does not add any further word because its content is filtered out
D
Also, only for UL Control Buffer, you need to add one further memory word per UL C-plane
AM
D
Consider the following example for a DL control buffer which spans over four symbol periods,
assuming you have two CCs and want to assign one single RB per section, Section Type 1 and no
extensions:
Consider the same example for a UL control buffer, assuming you are grouping five sections in
each UL packet, resulting in 55 packets per CC per symbol:
n
((275 + 55) × 2 × 4) / 1,024 = 2.58
rib I ma tio
• Round 2.58 up to 3
n te
ist rch Li ma
• In the Vivado IDE, set the UL Ctrl Delay buffer size in 1K entries to 3
Now, assume you want to distribute all the RBs in DL between three sections only (numPRB
i o i tu
respectively 100, 100, and 75) but attaching to each an Extension Type 11, holding a different
-D ea iro for
beamID every couple of RBs (that is, numBundPrb = 2):
ut nst
• For the first and the second section you have:
Re es C In
1 + 1 + ((100 / 2) – 2) / 4) = 14
• While for the third you have:
or R to ial
1 + 1 + ((75 / 2) – 2) / 4) = 11
• Summing up the three, you have:
t f do ed nt
((14 + 14 + 11) × 2 × 4) / 1024 = 0.30
• Round up to 1
No ra os de
Downlink Buffers
For data, you must decide which compression methods are to be used and from this calculate the
El is o
RB block size in bytes (DL Data Delay buffer size in 1K entries in the Vivado IDE). Consider the
C
following example:
• IQ compression:
D
case of 15 Ethernet frames for a symbol, this is an additional 15 × 11 = 165 bytes, per CC
so 330 bytes in total.
○ 275 sections per symbol, two symbols, and two CCs:
(275 × 32 × 2 × 2) = 35,200 + (330 × 2) bytes = 4,483 memory words (8 bytes per word).
○ 4,483 / 1,024 = 4.38, round up to 5.
In the Vivado IDE, set the DL Data Delay buffer size in 1K entries parameter to 5.
n
○
rib I ma tio
• Data pointer RAM sizing:
○ Two symbols per CC and two CCs results in four pointers.
n te
ist rch Li ma
○ In the Vivado IDE, set the DL Data Delay buffer pointers parameter to 4.
i o i tu
Example IDE Configuration
-D ea iro for
The following table illustrates how the Vivado IDE for the core would be configured using the
ut nst
example values calculated above.
Re es C In
Table 7: Example IDE Configuration
Note: Similar considerations also apply to SSB Data and CTRL Delay buffers. You have to determine the
sizes of both the SSB Data and CTRL buffers, expressed in 512 word entries, starting from the actual
El is o
number of required RBs (usually 20) and applying the usual adjustments depending on the required SSB
C
sections and extensions. However, no delay compensation buffers are available in the current
implementation for C-Plane messages carrying PRACH related information.
D
Performance Counters
AM
D
A set of counters monitoring the performance of the fronthaul interface are available in the
register map, in conformance with the O-RAN Control, User and Synchronization Plane Specification
v11.0 (O-RAN Specification v11.0) (see Chapter 9). Each counter is 64-bit, wrap around,
unsigned, and resettable. There is an independent set of counters for each configured Ethernet
port.
The following first subset of counters concern the whole packets that are received at the
at
Counter Description
ETH_STATS_TOTAL_RX_GOOD_PKT_CNT Total number of received packets marked as correct by the MAC.
ETH_STATS_TOTAL_RX_BAD_PKT_CNT Total number of received packets marked as not correct by the MAC.
n
Table 8: Counters Received at the Ethernet MAC Output Interface (cont'd)
rib I ma tio
Counter Description
Total number of received packets marked as not correct by the MAC due to
ETH_STATS_TOTAL_RX_BAD_FCS_CNT
wrong FCS only.
n te
ist rch Li ma
ETH_STATS_TOTAL_RX_BIT_RATE Bit rate of all incoming Ethernet packets.
ETH_STATS_ORAN_RX_BIT_RATE Bit rate of all incoming packets identified as O-RAN ones.
i o i tu
-D ea iro for
Concerning the reception window management described in the previous section and
ut nst
considering all received O-RAN packets, there are the following counters.
Re es C In
Counter Description
or R to ial
ORAN_RX_TOTAL
ORAN_RX_ON_TIME
Total number of O-RAN U-Plane packets received.
O-RAN U-Plane packets arrived within the configured reception window.
O-RAN U-Plane packets that arrived early, that is before the start of the
t f do ed nt
ORAN_RX_EARLY
respective reception window.
O-RAN U-Plane packets that arrived late, that is after the end of the respective
ORAN_RX_LATE
reception window.
No ra os de
The following subset of counters is dedicated to the C-Plane control packets only.
do cl nfi
Counter Description
ORAN_RX_TOTAL_C Total number of O-RAN control packets received.
C
O-RAN control packets that arrived within the configured control reception
ORAN_RX_ON_TIME_C
window.
D
O-RAN control packets that arrived early, before the start of the configured
ORAN_RX_EARLY_C
control reception window.
O-RAN control packets that arrived late, after the end of the configured control
AM
ORAN_RX_LATE_C
D
reception window.
For O-RAN received packets, other two counters concern packets that are dropped because they
contain errors.
Counter Description
Total number of O-RAN packets carrying unexpected or corrupted header fields.
ORAN_RX_CORRUPT
This includes unsupported message type and invalid RTCID endpoints.
Total number of O-RAN packets of whose actual length did not match with the
ORAN_RX_ERROR_DROP
declared size.
Moreover, the following two counters are dedicated to O-RAN transmitted packets.
n
Table 12: Counters for O-RAN Transmitted Packets
rib I ma tio
Counter Description
ORAN_TX_TOTAL Total number of generated O-RAN packets.
n te
ist rch Li ma
ORAN_TX_TOTAL_C Total number of generated O-RAN C-Plane packets.
i o i tu
The last subset holds two registers that are not actual counters but record the highest measured
offset, that is, the difference between the current and the transported symbol numbers
-D ea iro for
respectively for U-Plane and C-Plane packets. These registers are made available for debugging
ut nst
purposes, to help to understand during a test session if the packets are arriving too early or
where are they coming from with respect to the reception window (see paragraph on
Re es C In
troubleshooting in Hardware Debug).
The counters in the first set are actually counting all the incoming packets at each port, including
do cl nfi
the packets that are delivered to the embedded microprocessor. The bit rate counters are useful
during hardware test and in perspective for hardware demos.
El is o
All the remaining counters are mandated by the O-RAN specification and take into account only
the packets which were accepted as good by the MAC. Then, corrupted packets are those that
C
are holding unexpected subfields in the transport header, either the protocol revision or a
message type that is not accepted by O-RAN, or a PC_ID that was not configured, or a
D
subsequenceID field different from 8’h80. Dropped packets are essentially those whose
measured length do not match the one declared as “Payload_Size.”
AM
D
Addition of counters detecting SequenceID errors per eAxC is for further study.
Every counter works in an “accumulate and freeze” fashion: by writing any value to the single
DEFM_SNAP_SHOT register, all the accumulated values are uploaded and made available on the
respective read only register. In this way, a snapshot of the state of each counter is captured
while they are still being incremented at their own pace.
at
If you write 0x1 to DEFM_SNAP_SHOT, the snapshot is captured but the accumulators are not
affected. If you write any “1” to the register bits [19:4], it resets a subset of the counters
according to the following description:
• Bit[6] = 1 resets all oran_rx corrupt and error_drop counters, regarding Ethernet Port 0
n
• Bit[7] = 1 resets all oran_tx counters regarding Ethernet Port 0
rib I ma tio
• Bits[11:8] concern Ethernet Port 1 with the same distribution
n te
ist rch Li ma
• Bits[15:12] concern Ethernet Port 2 with the same distribution
• Bits[19:16] concern Ethernet Port 3 with the same distribution
i o i tu
Related Information
-D ea iro for
ut nst
Register Space
Re es C In
Early BeamID Forwarding
While the downlink BeamID Forward interface provides the indexes to be used for each spatial
or R to ial
stream in parallel with the corresponding data, the manager of the beamforming function might
need to know in advance a list of the actual BeamIDs to be used, for example, allowing time to
t f do ed nt
move beam weights from a global repository to a local memory cache. To support this, the O-
RAN Radio IF core generates a single Early BeamID list common to all spatial streams on the
No ra os de
Early BeamID Forward interface as soon as the control message reception window for a given
symbol closes. The Early BeamID Forward interface is triggered on the previously described
m<C>_dl_cta_sym_num or m<C>_ul_cta_sym_num counters.
do cl nfi
For either direction, the closure of the reception window starts the collection from each Spatial
Stream CTRL buffer of all the stored BeamIDs for the given (advanced) symbol period. All the
El is o
collected BeamIDs, together with their associated numSymbol, StartPrb and NumPrb, are listed in
a single FIFO, to allow the core to generate the sequence of BeamIDs that are used for any
C
The following timing diagram shows how the common Early BeamIDs interface generates the
D
BeamID list in advance with respect to each spatial stream BeamID Forward Port.
AM
D
Note: The single state machine at the Early BeamID interface, together with the single FIFO, allows to
consecutively poll all the spatial streams independently from any backpressure applied either at the Early
BeamID or at each BeamID Forward interface. This is also assuming that such a single state machine has
priority over each spatial stream BeamID Forward function in accessing the correspondent CTRL buffer.
n
rib I ma tio
The Synchronization Signal Block (SSB) is comprised of the Primary Synchronization Signal (PSS),
the Secondary Synchronization Signal (SSS), and the Physical Broadcast Control Channel (PBCH).
n te
Within one subframe, there can be 0 or 1 SSBs per CC. The SSB is comprised of 20 contiguous
ist rch Li ma
RBs (or 240 contiguous SCs) on four contiguous OFDM symbols. SSB configuration information
can be transmitted over the O-RAN interface using either Section Type 1 or 3 control messages.
i o i tu
-D ea iro for
This block is independent from any supported spatial stream, and for that reason, the O-RAN
Radio IF core optionally supports a single set of dedicated interfaces to convey SSB-related data,
ut nst
BeamIDs and Early BeamIDs streams.
Re es C In
There must be one SSB per supported CC and each SSB referred to any CC is multiplexed on the
single output, similarly to what is done for spatial stream traffic. In principle, the subcarrier
spacing of SSB can be different from the related PDxCH. However, in the present release,
or R to ial
assume that each SSB uses the same numerology of the corresponding CC.
t f do ed nt
It is necessary to define an appropriate setting for the bit masking feature defined in the rtcid/
pcid section, so that data or control packets are correctly identified as bearing SSB traffic.
No ra os de
A specific set of parameters and registers are available to configure the handling of the SSB for
each supported CC, independently from the configuration of the related PDxCH memory
structures:
do cl nfi
1. First, in the AMD Vivado™ IDE, you define the number of blocks of 512x64 bit words that
must be allocated to implement the SSB control and data deskew buffers respectively,
El is o
2. Then, for each CC, the SSB configuration must be defined by programming the
correspondent series of available registers. In the current release, CC_SSB_SYMPERSLOT,
CC_SSB_NUMEROLOGY, CC_SSB_SETUP_C_ABS_SYMBOL, CC_SSB_SETUP_C_CYCLES,
D
and CC_SSB_SETUP_D_CYCLES must take the same values written in the corresponding
PDxCH register for the same CC, while CC_SSB_NUMRBS and CC_SSB_SECTS_X_SYMBOLS
AM
D
csn take values more appropriate to the SSB case (typically CC_SSB_NUMRBS=20 and
CC_SSB_SECTS_X_SYMBOLS=16).
3. Last, depending on the actual number of RBs and sections that have to be supported for SSB
streams and following exactly the same method described in the Configuring the Core
section, the proper values are computed and assigned respectively to the following registers:
• CC_SSB_CTRL_OFFSETS, to partition the CTRL_buffer among the CCs
at
Also, the compression method to be used for the SSB data samples must be defined relying on
n
the CC_SSB_UD_IQ_WIDTH, CC_SSB_UD_COMP_METH and
rib I ma tio
CC_SSB_MPLANE_UDCOMP_PARAM registers.
n te
ist rch Li ma
Uplink Datapath
i o i tu
-D ea iro for
The uplink path is shown in the core block diagram under Chapter 3: Product Specification. The
ut nst
input stage consists of one uplink data pipe per spatial stream (from 1 to 16 AXI4-Stream ports).
Each uplink spatial stream pipe consists of an internal double buffer interface, a buffer manager, a
Re es C In
preframer, and an interface to any of the available Ethernet pipelines. The main operation of the
uplink spatial stream pipe is as follows:
or R to ial
1. Each uplink pipe reads an internal double buffer, which has been populated by processing the
received Uplink C-plane messages and their sections. This defines the requested Sections/
Radioblocks to be returned via the Uplink Ethernet path.
t f do ed nt
2. This double buffer is read every symbol time and all entries are processed by the end of that
symbol time. This gives a latency of one symbol through this buffer.
No ra os de
3. Each entry of the internal double buffer generates a request for user (RB) data to be supplied
by the upstream logic the relevant spatial stream ports.
do cl nfi
Note: Only rb bit = 0 is supported in the C-Plane messages. See section 7.5.3.2 of O-RAN Control, User
C
and Synchronization Plane Specification v11.0 (O-RAN Specification v11.0) for more information about
the resource block indicator.
D
6. The Ethernet packet generation uses the Maximum User payload length setting in the Vivado
IDE to group either a number of sections or a number of RBs belonging to one or more
sections into each issued Ethernet packet, thus performing Application Layer fragmentation
when necessary. This can now be reduced for PUxCH using the fram_mtu_size register. If the
register value is less than the max packet size defined in the GUI, the register value is used.
The uplink datapath features one uplink Ethernet pipeline per instantiated Ethernet port. This
at
block performs the encapsulation of each incoming payload, providing the programmed headers
to complete the network (raw Ethernet or IP/UDP, VLAN tagged or untagged) and transport
(eCPRI or IEEE1914.3) framing layers.
The oran_radio_if generates only uplink U-Plane packets. It also generates the sequence ID,
which must be incremented independently for each different packet stream, that is for each
individual unique eAxC ID value. There are limitations to the range of unique eAxC IDs for which
the oran_radio_if can support Sequence ID generation, as follows.
The IP supports up to a maximum of 2048 individual Sequence ID counters. Eight modes are
n
provided for the selection of bits from the eAxC ID field to be used to select which counter to
rib I ma tio
use. Use register fram_cid_seqtable_mode to select an appropriate mode for your system
requirements.
n te
ist rch Li ma
Mode 0 is the default and should be used if the mapping table is not being used.
i o i tu
If the eAxC ID Mapping Table mode is use, one of mode 1 to 7 is likely to be required.
-D ea iro for
// Mode RtPcid Bits selected. 11 Bits in total. Shown Left 15-0
ut nst
// Concatanated Leftmost bit is the MSB.
// 1 xx...xxx_..xxxxxx
// 2 xx....xx_.xxxxxxx
Re es C In
// 3 ..xx.x.x_xx.xxxxx
// 4 ....xxxx_.xxxxxxx
// 5 .x..x.xx_.xxxxxxx
// 6 ..xx.xx._xx.xxxxx
// or R to ial
7 ...x..xx_xxxxxxxx
Each Ethernet pipeline accepts data from all the instantiated spatial stream pipelines, as well as
t f do ed nt
from the PRACH and unsolicited port AXI4-Stream interfaces. The U-Plane traffic coming from
the spatial streams has the highest priority. The PRACH port is served only when there are no U-
No ra os de
Plane packets to encapsulate. The unsolicited ports are served only when neither spatial stream
nor PRACH data is ready. Each unsolicited port is expected to indicate that it has a packet ready
to deliver by raising the corresponding s<U>_fram_unsol_tvalid signal, and must be able to
do cl nfi
The radio function is expected to respond to each Uplink U-Plane data request as soon as
El is o
possible, and within the same symbol period. Any unanswered request still pending at the end of
the corresponding symbol period is flushed. While there is a data request still pending, the
C
Ethernet pipeline is not able to serve either the PRACH or the unsolicited ports.
D
An optional table with eight entries is provided to enable programming of specific MAC
Addresses and VLAN tags associated with up to 8 different oDU DU_ID values (from the
AM
associated Uplink C-plane messaging). This overrides the single value available in the default
D
You should then write the VLAN tag to the eth_dutbl_w_vlan register. Then, write the MAC
address to eth_du_table_rd_dest_addr_31_0 and eth_du_table_rd_dest_addr_47_32. Finally to
complete the write to the table, the register eth_dutbl_w_wr must be written with the oDU
address in bits[3:0] and a 1 in bit[31]. Refer to the register map for more details.
at
The uplink Ethernet pipeline also includes an output FIFO to transfer packets into the
transmission transmitting Ethernet port clock domain.
Additionally, the buffer in the uplink datapath can be used for crossing a clock domain from
fram_logic_clk to internal_bus_clk. This is enabled via the GUI. Once enabled, the
additional clock port will be seen at the top level of the core.
It is possible for the Framer to generate packets that are shorter that the minimum Ethernet
n
packet size of 64 bytes, for example is one RB is sent using BFP9 and was placed in a packet all
rib I ma tio
by itself. If this is a requirement, external logic to deal with the padding requirement should be
placed in the datapath, between the core and the Ethernet MAC being used.
n te
ist rch Li ma
Related Information
i o i tu
Product Specification
-D ea iro for
Uplink ORAN Processing Block
ut nst
The OCP in the uplink datapath performs the opposite function to the downlink OCP.
Re es C In
Figure 21: Uplink Top Level Block Diagram
or R to ial
t f do ed nt
AXI4-LITE
AXI4-Lite Register Control Interface Sequence Table
CTRL
No ra os de
Uplink
SS0
do cl nfi
….
….
SSn
El is o C
D
X27902-031723
AM
D
The data from the a Precoding/Beamforming/(i)FFT block is first input to a write engine. The
write engine writes the incoming data into a ping pong memory depending on the sequence
programmed into the sequence table. A separate area of the sequence table is used for uplink.
This allows different data mappings in each direction. The ping pong memories are the same as
those in the downlink path. There is one memory and one read engine for each antenna. Each
read engine has an AXI4-Stream interface (SS0 to SSn) that connects to the uplink U-Plane
at
datapath. The uplink datapath outputs a request containing a CC number, starting RB, and a
number of RBs. The read engine uses this information to access the required area of memory and
output the required data.
Interrupts
n
rib I ma tio
Interrupts are available to indicate when faults have occurred that require your attention. The O-
RAN Radio IF interrupts do not require real-time management, and should not trigger if the
n te
system is correctly configured. Repeated triggering indicates that there is an issue in the
ist rch Li ma
configuration of the IP or the system in which it has been placed, and the design needs to be
reassessed. Refer to the register map for the breakdown of the interrupt control. By default, the
i o i tu
interrupts are disabled.
-D ea iro for
ut nst
Related Information
Re es C In
Register Space
the latest functions for programming the internal memory pointers. It is available on GitHub.
Worked examples are provided in this section. These examples are also demonstrated using API
do cl nfi
calls; details are available on GitHub (see the O-RAN lounge web page (registration required) for
further information). The following examples can be found inside the FHI XORIF C library, and
demonstrate how to configure the core using the FHI XORIF C library.
El is o
When programming these registers, you must ensure that the memory limits you define in the
C
IDE for the core are not exceeded. The following pseudo code provides guidance on the
procedure to be followed:
D
1. Configure the numerology of each CC, the following constraints are as follows:
AM
D
of the oRU.
oran_init_componentcarrier (0, 1, 275); // CC, Numerology, RbsMax
oran_init_componentcarrier (1, 1, 275); // CC, Numerology, RbsMax
3. Configure an integer number of symbol periods you want to include in each Data and Control
n
buffer.
rib I ma tio
Downlink DATA_Buffer:
- Amount of packet delay variation your buffer has to compensate for:
assume T2a_max_up = 140 µs; T2a_min_up = 80 µs;
n te
ist rch Li ma
SYMBOL_PERIOD_mu1 = 35.71 µs (numerology 1);
tDELAY_COMP_UP = T2a_max_up - T2a_min_up = 60 µs
i o i tu
- Internal latency of a data packet in the oran_radio_if:
tDECAP = 5 µs
-D ea iro for
- Number of symbol segments included in the buffer (the smallest integer
ut nst
greater than)
Re es C In
CC_DL_DATA_SYM_NUM_INDEX[X] = (tDELAY_COMP_UP+tDECAP) /
SYMBOL_PERIOD_mu1 =
= 2 Symbols
or R to ial
Downlink CTRL_Buffer:
- Amount of packet delay variation your buffer has to compensate for:
assume T2a_max_cp_dl = 210 µs; T2a_min_cp_dl = 180 µs;
t f do ed nt
tDELAY_COMP_CP_DL = T2a_max_cp_dl - T2a_min_cp_dl = 30 µs
CC_DL_CTRL_SYM_NUM_INDEX[X] =
= (tDELAY_COMP_CP_DL+Tcp_adv_dl+tDECAP) /
SYMBOL_PERIOD_mu1 =
El is o
= 4 Symbols
C
Uplink CTRL_Buffer:
- Amount of packet delay variation your buffer has to compensate for:
assume T2a_max_cp_ul = 80 µs; T2a_min_cp_ul = 50 µs;
D
the antenna:
ORU_UL_Latency = 60 µs
CC_UL_CTRL_SYM_NUM_INDEX[X] =
= (tDELAY_COMP_CP_UL+T2a_min_cp_ul+ORU_UL_Latency) /
SYMBOL_PERIOD_mu1 =
at
= 4 Symbols
4. Define how many words per symbol per component carrier must be allocated in the
n
CTRL_Buffer. For the sake of this introductory example, one word per section is always been
rib I ma tio
counted. For more advanced assignments describing the structure of control buffers, see
Control Buffers.
n te
ist rch Li ma
Downlink CTRL_Buffer:
- Amount of words to be allocated in each symbol segment:
assume 275 RBs and 2 Sections for each RB
i o i tu
CC_NUM_CTRL_PER_SYMBOL_DL[X] = 550 words
-D ea iro for
- The total amount of memory for a given CC = X is given by the product:
CC_NUM_CTRL_PER_SYMBOL_DL[X] * CC_DL_CTRL_SYM_NUM_INDEX[X]
ut nst
= 2200 words
Re es C In
Uplink CTRL_Buffer:
- Amount of words to be allocated in each symbol segment:
assume 275 RBs and 1 Section for each RB, all grouped in a single
packet
or R to ial CC_NUM_CTRL_PER_SYMBOL_UL[X] = 275 + 1 = 276 words
5. Allocate the amount of memory required for each symbol period of data in the DATA buffer.
Again, here for simplicity, it is assumed to rely on BFP9 compressed data, one RB per Section,
and that all the sections are fragmented among 30 Ethernet packets.
do cl nfi
- 275 RBs, 28 bytes per RB; 275 Sections, 4 bytes for each section
header:
(28 + 4) * 275 = 8800 Bytes
El is o
- Add the overhead for each fragmented packet: 4 bytes for the ORAN
C
header, 7 trailing bytes which may remain unused at the end of each
packet
(4 + 7) * 30 = 330 Bytes
D
- In total:
8800 + 330 = 9130 Bytes = 1142 words
AM
D
n
- For any further CCX is CC_DL_CTRL_OFFSETS[X] = CC_DL_CTRL_OFFSETS[X-1] +
rib I ma tio
+ CC_NUM_CTRL_PER_SYMBOL_DL[X-1] * CC_DL_CTRL_SYM_NUM_INDEX[X-1]
=> CC_UL_CTRL_OFFSETS[1] = 2200 = x0898
n te
ist rch Li ma
Downlink Data Buffer:
- CC0 operates at the base of the Buffer, uses 2 Symbols
=> CC_DL_DATA_SYM_START_INDEX[0] = x0000
i o i tu
- CC1 operates above CC0, uses 2 Symbols
=> CC_DL_DATA_SYM_START_INDEX[1] = x0002
-D ea iro for
The Unroll pointer offsets are spaced to provide 1 Symbols worth of memory space
ut nst
=> CC_DL_DATA_UNROLL_OFFSET[0] = x0000
=> CC_DL_DATA_UNROLL_OFFSET[1] = 1142 = x0476
=> CC_DL_DATA_UNROLL_OFFSET[2] = 2284 = x08EC
Re es C In
=> CC_DL_DATA_UNROLL_OFFSET[3] = 3426 = x0D62
The following diagram depicts how the values calculated above apply to the memory
resources available in the core.
or R to ial
t f do ed nt
CC0: 100 MHz oBW, u=1
CC1: 100 MHz oBW, u=1 CC1
Uplink U-Plane PUxCH Requests
No ra os de
CC0
CC_UL_BASE_OFFSET[1] = x0113
do cl nfi
CC_UL_BASE_OFFSET[0] = x0000
S0 S1 S2 S3 S0 S1 S2 S3 Management
CC_UL_CTRL_SYM_NUM_INDEX[0] = x0004
C
CC_DL_CTRL_SYM_NUM_INDEX[0] = x0004
D
CC_DL_CTRL_OFFSETS[0] = x0000
CC_DL_CTRL_SYM_NUM_INDEX[1] = x0004
CC_DL_CTRL_OFFSETS[1] = x0898
Parsed Downlink U-Plane Data CC0 CC0 CC1 CC1 PDxCH Symbol DATA
S0 S1 S0 S1
X22879-111720
7. Set the cc_reload bit(s) (one per CC) in the cc_reload register to trigger the use of the
values configured above. This should be done after any changes in the configuration, because
some internal values are calculated by the core and those calculations need to be rerun when
the configuration changes.
reload_componentcarrier ('h1);
8. Finally, set the cc_enable bit(s) (one per CC) to enable the CC paths and begin processing
n
real data.
rib I ma tio
enable_componentcarrier ('h1);
n te
ist rch Li ma
Reconfiguring the Core
i o i tu
The following use case uses the same worst-case sizing configuration as in the previous example,
-D ea iro for
but with a different component carrier configuration, which does not exceed any of the sizing
limitations.
ut nst
1. Configure the number of resource blocks (RBs) to assign to each CC. This is programmed into
Re es C In
the oran_cc_numerology registers.
oran_init_componentcarrier (0, 0, 275); // CC, Numerology, RbsMax
or R to ial
oran_init_componentcarrier (1, 0, 137); // CC, Numerology, RbsMax
oran_init_componentcarrier (2, 0, 137); // CC, Numerology, RbsMax
greater than)
C
CC_DL_DATA_SYM_NUM_INDEX[X] = (tDELAY_COMP_UP+tDECAP) /
SYMBOL_PERIOD_mu0 =
= 2 Symbols
D
Downlink CTRL_Buffer:
AM
D
CC_DL_CTRL_SYM_NUM_INDEX[X] =
= (tDELAY_COMP_CP_DL+Tcp_adv_dl+tDECAP) /
SYMBOL_PERIOD_mu0 =
= 2 Symbols
Uplink CTRL_Buffer:
- Amount of packet delay variation your buffer has to compensate for:
assume T2a_max_cp_ul = 80 µs; T2a_min_cp_ul = 50 µs;
tDELAY_COMP_CP_UL = T2a_max_cp_ul - T2a_min_cp_ul = 30 µs
n
- Delay of the UL_radio_start_10ms reference wrt the same reference at
the antenna:
rib I ma tio
ORU_UL_Latency = 60 µs
- Number of symbol segments included in the buffer (the smallest integer
n te
ist rch Li ma
greater than)
CC_UL_CTRL_SYM_NUM_INDEX[X] =
i o i tu
= (tDELAY_COMP_CP_UL+T2a_min_cp_ul+ORU_UL_Latency) /
SYMBOL_PERIOD_mu0 =
= 2 Symbols
-D ea iro for
ut nst
3. Define how many words per symbol per component carrier must be allocated in the
CTRL_Buffer.
Re es C In
Downlink CTRL_Buffer:
- Amount of words to be allocated in each symbol segment:
assume 275 RBs and 2 Sections for each RB
or R to ial CC_NUM_CTRL_PER_SYMBOL_DL[0] = 550 words
CC_NUM_CTRL_PER_SYMBOL_DL[1] = 274 words
CC_NUM_CTRL_PER_SYMBOL_DL[2] = 274 words
t f do ed nt
- The total amount of memory for a given CC = X is given by the product:
CC_NUM_CTRL_PER_SYMBOL_DL[0] * CC_DL_CTRL_SYM_NUM_INDEX[0]
= 1100 words
No ra os de
CC_NUM_CTRL_PER_SYMBOL_DL[1] * CC_DL_CTRL_SYM_NUM_INDEX[1]
= 548 words
CC_NUM_CTRL_PER_SYMBOL_DL[2] * CC_DL_CTRL_SYM_NUM_INDEX[2]
= 548 words
do cl nfi
Uplink CTRL_Buffer:
- Amount of words to be allocated in each symbol segment:
El is o
assume 275 RBs and 1 Section for each RB, all grouped in a single
packet
C
= 552 words
D
CC_NUM_CTRL_PER_SYMBOL_UL[1] * CC_UL_CTRL_SYM_NUM_INDEX[1]
= 276 words
CC_NUM_CTRL_PER_SYMBOL_UL[2] * CC_UL_CTRL_SYM_NUM_INDEX[2]
= 276 words
4. Allocate the amount of memory required for each symbol period of data in the DATA buffer.
For simplicity is assumed to rely on BFP9 compressed data, one RB per Section.
at
- CC0:
- 275 RBs, 28 bytes per RB; 275 Sections, 4 bytes for each section
header:
(28 + 4) * 275 = 8800 Bytes
- Assume the 275 section are fragmented in 15 U-plane packets, add the
overhead for each fragmented packet: 4 bytes for the ORAN header, 7
trailing bytes
(4 + 7) * 15 = 165 Bytes
- In total:
n
rib I ma tio
- CC1, CC2:
- 137 RBs, 28 bytes per RB; 137 Sections, 4 bytes for each section
header:
n te
ist rch Li ma
(28 + 4) * 137 = 4384 Bytes
- Assume the 137 section are fragmented in 8 U-plane packets, add the
i o i tu
overhead for each fragmented packet: 4 bytes for the ORAN header, 7
trailing bytes
(4 + 7) * 8 = 88 Bytes
-D ea iro for
ut nst
- In total:
4384 + 88 = 4472 Bytes = 559 words for each of the two
CCs.
Re es C In
5. For each CC, configure the memory pointers:
Register CONFIGURATION:
or R to ial
Uplink Control Offsets: => CC_UL_CTRL_OFFSETS[0]
=> CC_UL_CTRL_OFFSETS[1] = 552
= x0000
= x0228
=> CC_UL_CTRL_OFFSETS[2] = 828 = x033C
t f do ed nt
- Uplink Table to generate data requests:
=> CC_UL_BASE_OFFSET[0] = x0000
No ra os de
The Unroll pointer offsets are spaced to provide 1 Symbols worth of memory space
AM
D
The following diagram depicts how the values calculated above apply to the memory
resources available in the core.
at
n
CC0: 50 MHz oBW, u=0
rib I ma tio
CC1: 25 MHz oBW, u=0
CC_UL_BASE_OFFSET[2] = x019C
CC2
CC2: 25 MHz oBW, u=0
CC_UL_BASE_OFFSET[1] = x0113 CC1 Uplink U-Plane PUxCH Requests
n te
ist rch Li ma
CC0
i o i tu
CC_UL_BASE_OFFSET[0] = x0000
-D ea iro for
Parsed Uplink CTRL (Sections) CC0 CC0 CC1 CC1 CC2 CC2 Uplink Control PUxCH BEAM ID Forward
ut nst
S0 S1 S0 S1 S0 S1 Management
Re es C In
CC_UL_CTRL_OFFSETS[1] = x0228 CC_UL_CTRL_SYM_NUM_INDEX[1] = x0002
CC_UL_CTRL_OFFSETS[2] = x033C CC_UL_CTRL_SYM_NUM_INDEX[2] = x0002
CC_DL_CTRL_SYM_NUM_INDEX[0]
CC_DL_CTRL_SYM_NUM_INDEX[1]
= x0002
= x0002
CC_DL_CTRL_OFFSETS[1] = x044C
CC_DL_CTRL_SYM_NUM_INDEX[2] = x0002
t f do ed nt
CC_DL_CTRL_OFFSETS[2] = x0670
Parsed Downlink U-Plane Data CC0 CC0 CC1 CC1 CC2 CC2 PDxCH Symbol DATA
S0 S1 S0 S1 S0 S1
No ra os de
CC_DL_DATA_SYM_NUM[0] = x0002
CC_DL_UNROLL_OFFSET[0] = x0000 CC_DL_DATA_SYM_START[0] = x0000
CC_DL_UNROLL_OFFSET[1] = x0461 CC_DL_DATA_SYM_NUM[1] = x0002
CC_DL_UNROLL_OFFSET[2] = x0AF1 CC_DL_DATA_SYM_START[1] = x0002
do cl nfi
6. Set the cc_reload bit(s) (one per CC) in the cc_reload register to trigger the use of the
C
values configured above. This should be done after any changes in the configuration, because
some internal values are calculated by the core and those calculations need to rerun when
the configuration changes.
D
reload_componentcarrier ('h1);
AM
D
7. Finally, set the cc_enable bit(s) (one per CC) to enable the CC paths and begin processing
real data.
enable_componentcarrier ('h1);
The oran_radio_if can accept all O-RAN specification messages. However, there is only a
subset of these that are actively processed by the hardware data path.
Messages with content not actively used by the core are still available to the user on several
interfaces.
All O-RAN header content can be found on the O-RAN Parser Ports, specifically the Transport
and Radio Header interface ports.
If the section type is 0, 1, or 3, its section header content is available on the Section Header
n
Interface ports. If Extensions are received for this section that are not processed in the
rib I ma tio
oran_radio_if, they will appear on the bypass/unsupported extension port.
If a section type is not type 0, 1, or 3, its content will appear on the bypass/Raw section port.
n te
ist rch Li ma
These ports allow the core to pass all O-RAN traffic with the user being able to add custom logic,
i o i tu
where appropriate to add customized HW message processing that is not included in the
oran_radio_if.
-D ea iro for
ut nst
Re es C In
Standards
or R to ial
This core adheres to the following standards:
• IEEE 1914.3-2018 IEEE Standard for Radio Over Ethernet Encapsulations and Mappings (IEEE
t f do ed nt
1914.3)
• eCPRI Specification v2.0 (eCPRI Specification V2.0)
No ra os de
• O-RAN Control, User and Synchronization Plane Specification v11.0 (O-RAN Specification v11.0)
• IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement
do cl nfi
Performance
C
D
Latency
AM
D
There is a minimum time of passage through the core for U-Plane and C-Plane messages arriving
in the core. This time must be accounted for when considering the latest time a message can
arrive and be forwarded in the same symbol window.
There are independent timers per component carrier and direction, which must all be
programmed using the AXI4-Lite interface. Refer to the XORIF Lib API for the latest minimum
latency figures; see the O-RAN lounge web page (registration required).
at
Throughput
The O-RAN Radio IF core can operate to fill the total bandwidth available on the selected
number of Ethernet ports. To achieve this performance, set the clock rate of the internal
datapath accordingly at configuration. The minimum internal clock frequency depending on the
Ethernet port selection is shown in the table below.
n
Table 14: Maximum and Minimum Internal Clock Frequency
rib I ma tio
Minimum Internal Clock Maximum Internal Clock
Ethernet Port Selection
Frequency (MHz) Frequency (MHz)
<E> ports at 10 Gb/s1 156.25 4002
n te
ist rch Li ma
<E> ports at 25 Gb/s1 390.625 4002
Notes:
i o i tu
1. The port number is determined by the number of Ethernet ports (<E>).
-D ea iro for
2. Maximum clock frequency may not be achievable for configurations that use large amounts of device resources. Use
the example design to evaluate configuration feasibility.
ut nst
Re es C In
Resource Use
or R to ial
For full details about performance and resource use, visit the Performance and Resource Use web
page (registration required).
t f do ed nt
No ra os de
Port Descriptions
do cl nfi
Clock
Port Name I/O Description
Domain
D
n
Table 15: AXI4-Lite Control Interface (cont'd)
rib I ma tio
Clock
Port Name I/O Description
Domain
s_axi_awaddr[15:0] I Write Address.
n te
ist rch Li ma
s_axi_awvalid I Write Address Valid.
s_axi_awready O Write Address Ready.
i o i tu
s_axi_wdata[31:0] I Write Data.
-D ea iro for
s_axi_wstrb[3:0] I Write Data Byte Strobe.
ut nst
s_axi_wvalid I Write Data Valid.
s_axi_wready O Write Data Ready.
Re es C In
s_axi_bresp[1:0] O Write Response.
s_axi_bvalid O s_axi_aclk Write Response Valid.
s_axi_bready
or R to ial I Write Response Ready.
s_axi_araddr[15:0] I Read Address.
s_axi_arvalid I Read Address Valid.
t f do ed nt
s_axi_arready O Read Address Ready.
s_axi_rdata[31:0] O Read Data.
No ra os de
The following ports are optionally available if enabled in the GUI. They connect to eight register
inputs and outputs in the s_axi_aclk domain. These provide control/status signals for use in
El is o
Clock
Port Name I/O Description
Domain
AM
D
n
Table 17: Framer (from Antenna) AXI4-Stream Interface (cont'd)
rib I ma tio
Port Name I/O Clock Description
High when reset is active in the
Ethernet clock domains. This signal can
n te
ist rch Li ma
be optionally used to reset
fram<E>_reset_active O tx<E>_eth_port_clk
downstream logic. The signal level can
also be read using the AXI4-Lite
i o i tu
register bank.
internal_bus_clk/
s<S>_fram_data_tdata[63:0] I Framer data input.
-D ea iro for
fram_logic_clock
ut nst
s<S>_fram_data_tkeep[7:0] I Framer data used octets input.
s<S>_fram_data_tvalid I internal_bus_clk/ Framer data valid.
Re es C In
s<S>_fram_data_tlast I fram_logic_clock Framer data last.
s<S>_fram_data_tready O Framer data input ready.
or R to ial
De-Framer (to Antenna) AXI4-Stream Interface Ports
t f do ed nt
Table 18: De-Framer (to Antenna) AXI4-Stream Interface
No ra os de
n
rib I ma tio
Table 20: From Framer to Ethernet
n te
ist rch Li ma
m<E>_eth_fram_tdata[63:0] O Framer data output.
i o i tu
m<E>_eth_fram_tkeep[7:0] O Framer data used octets output.
m<E>_eth_fram_tvalid O tx<E>_eth_port_clk Framer data valid.
-D ea iro for
m<E>_eth_fram_tlast O Framer data last.
ut nst
m<E>_eth_fram_tready I Framer data output ready.
Re es C In
From Ethernet to De-Framer
Table 21: From Ethernet to De-Framer
or R to ial
Port Name I/O Clock Description
t f do ed nt
s<E>_eth_defm_tdata[63:0] I De-framer data input. This port carries
PDxCH data.
s<E>_eth_defm_tkeep[7:0] I De-framer data used octets input.
No ra os de
tx<E>_eth_port_clk
MAC TX Bad FCS output, which flags any
s<E>_eth_mac_bad_fcs I
packet with a carried FCS that shows
C
n
Table 22: Internal Bus (cont'd)
rib I ma tio
Port Name I/O Clock Description
Low when the framer is flushing buffers or under
reset. Use is optional. The signal level can also be
n te
ist rch Li ma
read using the AXI4-Lite register bank. The signal is
fram_ready O
kept Low while the system resets the table used by
internal_bus_clk the framer sequence counter generator upon a
i o i tu
fram_reset activation.
Low when the de-framer is flushing buffers or
-D ea iro for
defm_ready O under reset. Use is optional. The signal level can
also be read using the AXI4-Lite register bank.
ut nst
Related Information
Re es C In
Throughput
or R to ial
Message AXI4-Stream Interface Ports
t f do ed nt
The filter in the de-framer reroutes all relevant packets to this interface.
No ra os de
internal_bus_clk
m<E>_message_tlast O Incoming message data last.
C
While it is possible to push back, using tready, on this port, is it not recommended as this can
result in the loss of radio data, particularly in high bandwidth scenarios, with many short CTRL
packets. You should ensure that either the DMA to the processor can keep up with the peak data
rate, or that packets and their associated timestamps are cleanly dropped, between this interface
and the DMA. Software protocols, i.e., TCP/IP, will ensure the message eventually gets to the
processor.
at
n
rib I ma tio
A number of interfaces from the O-RAN parser block inside the core can be combined to extract
all the information required either for further processing or for debugging. For instance,
n te
Beamweights transported over the C-Plane can be obtained at the Parser Ports to be inserted in
ist rch Li ma
an external Beamweights store, or section extensions not yet supported by the core itself can be
sent to an external processing block.
i o i tu
-D ea iro for
Note: Unused outputs can be left unconnected.
ut nst
Transport Header Interface Ports
Re es C In
Table 24: Transport Header Interface
Port Name
or R to ial Width I/O Clock Description
All fields below valid when this is
m<E>_t_header_offset_valid 1 O
signal is 1.
t f do ed nt
Runt packet length: 1 indicates that
the actual size of a received packet
m<E>_runt_packet_len 1 O
does not match the size declared in
No ra os de
000 = U-Plane
m<E>_messagetype [2:0] O
010 = C-Plane
internal_bus_clk
m<E>_seqid [7:0] O Sequence ID.
El is o
n
rib I ma tio
Table 25: Radio Application Header Interface
n te
ist rch Li ma
All fields below are valid when this
m<E>_radio_app_head_valid 1 O
signal is 1.
i o i tu
0 = Uplink
m<E>_datadirection 1 O
1 = Downlink
-D ea iro for
Number of sections in this packet
ut nst
m<E>_numsections [7:0] O message. Valid only when
messageType ==2.
Re es C In
Type of section = 0, 1, or 3 (others are
m<E>_sectiontype [2:0] O unsupported). Valid only when
messageType == 2.
highest numerology.
First symbol number within the slot
m<E>_symbolid [5:0] O
to be considered.
do cl nfi
n
rib I ma tio
Table 26: Section Header Interface
n te
ist rch Li ma
All fields below are valid when this
m<E>_section_header_valid 1 O
signal is 1.
i o i tu
Number of consecutive symbols to
m<E>_numsymbol [3:0] O which the section control is
-D ea iro for
applicable.
ut nst
The total number of RBs to apply
m<E>_numprbc [7:0] O
section information to.
Re es C In
The first RB to apply section
m<E>_startprbc [9:0] O
information to.
m<E>_sectionid [11:0] O Section ID
internal_bus_clk
or R to ial
m<E>_rb 1 O
Contiguous RBs (0) or alternate RBs
(1).
The resource elements (REs) in the
m<E>_remask [11:0] O
RB to apply section information to.
t f do ed nt
Beam ID to apply to designated REs
m<E>_beamid15 [14:0] O in designated RBs in designated
No ra os de
symbols.
Frequency offset to be passed to the
PRACH processing function out of
m<E>_freqoffset [23:0] O
scope. Valid only for sectionType ==
do cl nfi
3.
Notes:
1. These ports only show C-Plane Section Header information.
El is o
This interface provides PRACH section type 3 control message data. You can use outputs as the
D
required downstream. All fields required by the O-RAN Control, User and Synchronization Plane
Specification v11.0 (O-RAN Specification v11.0) are provided, as well as some additional signals.
AM
Beam-weights can be sent using Extension 1 or 11. However, if Extension 11 is used only one,
bundle is supported. Therefore, essentially the extension 11, looks similar to an extension 1.
Note: When the message exits the uplink data packet header, it is also stored internally, so that the
returning PRACH data, provided on the PRACH AXIS channel, can be correctly formatted as a U-Plane
data packet. The returning uplink data must have the matching section ID, Ru_Port_Id and Component
at
Note: There is currently only one PRACH Beam ID (BID) port, but the port names use the naming
convention m0_prach_. The number in the name has been retained in case more are needed in the future.
n
Table 27: PRACH BID Interface
rib I ma tio
Port Name Width I/O Clock Description
All the signals below are valid when
m0_prach_tvalid 1 O
this signal is High. Single cycle per BID.
n te
ist rch Li ma
High when the external logic is ready
m0_prach_tready 1 I
to receive BIDs
i o i tu
m0_prach_cc [3:0] O Component carrier
m0_prach_ss [7:0] O Ru_Port_Id
-D ea iro for
m0_prach_section_id [11:0] O Section ID
ut nst
Ethernet port on which the PRACH
m0_prach_return_port [3:0] O control message has arrived and from
Re es C In
which the data message must be sent
m0_prach_filter_index [3:0] O Filter index
m0_prach_f [7:0] O Frame Number
or R to ial
m0_prach_sf
m0_prach_sl
[3:0]
[5:0]
O
O
Sub-frame number
Slot number
t f do ed nt
m0_prach_sy [5:0] O Symbol number
m0_prach_time_offset [15:0] O Time offset
No ra os de
m0_prach_rb 1 O RB bit
m0_prach_syminc 1 O Symbol inc
D
n
rib I ma tio
n te
ist rch Li ma
i o i tu
-D ea iro for
ut nst
Re es C In
or R to ial
Precode Ports
To ease the external development of a precoding function to manage LTE channels, the core
t f do ed nt
outputs on the Precode interface all information such as codebook, transmission scheme and
beamIDs (one per Antenna Port to be supported) which are included in each Extension Type #3
No ra os de
carried by C-Plane Section Type 1 or 3 control messages. This data is valid for an entire
subframe. Each codeword can be mapped either on 1, 2, or 4 layers. Precoding generates 1, 2, or
4 Antenna Ports, each with an associated individual beamID.
do cl nfi
[15:0] Rtc_id
D
[23:16] frameid
[27:24] subframeid
AM
[28] rb
D
[38:29] startPrb
[46:39] numPrb
[54:47] codebookIndex
m_lte_precod_tdata [143:0] O [58:55] layerid
[62:59] numLayers
internal_bus_clk [66:63] txScheme
[78:67] crsReMask
[79] crsShift
[83:80] crsSymNum
[98:84] beamID AP0
at
n
rib I ma tio
The beam weights vector which have been extracted from either an Extension Type 1 or Type 11
are streamed onto this output interface. Any series of vectors is preceded by a Word holding the
n te
relevant ID metadata taken from the ORAN common header and from the respective section
ist rch Li ma
header.
i o i tu
Each individual beam weights vector stream starts with a Word 0, identifying the channel type
-D ea iro for
and the symbol period of the vector, followed by all the data content of the extension. In case of
Extension Type 1, the beam ID defined in the section is reported as the two less significant
ut nst
octets of Word 1.
Re es C In
For Extension Type 11, the beam IDs assigned for each group are reported as they are written in
the extension body. Then, the beamID for the first group occupies either the two most
significant bytes of Word 1, if the bfwCompParam is not present, or it spans between the end of
or R to ial
Word 1 and the first byte of Word 2.
t f do ed nt
Also in case of Extension Type 11, you need to know how many elements are in a vector
(Number of Antennas supported by the radio), to delineate each group and correctly read the
following bfwCompParam and beamID.
No ra os de
do cl nfi
El is o C
D
AM
D
at
n
Table 29: Beam Weight Data Interface
rib I ma tio
Port Name Width I/O Clock Description
Carries PUxCH/PDxCH/PRACH/SSB
beam weight data. The first word
n te
ist rch Li ma
(Word 0) carries the stream
metadata, while the following
words hold beam ID and weight
i o i tu
data.
Information included in the first
-D ea iro for
word (Word 0) for both Ext1 and
Ext11:
ut nst
[63:62] Reserved
[61:52] StartPrbc
Re es C In
[51:48] SubFrameId
[47:42] SlotId
[41:36] StartSymbolId
or R to ial [35:32] Number of Symbols
m<E>_beamweights_tdata [63:0] O [31:28] CC_Id
[27:20] NumPrbc
[19:18] Reserved
t f do ed nt
[17:12] StreamType:
'h3F - Unknown
No ra os de
0 - Stream is PDxCH
C
[11:0] RuPortId
m<E>_beamweights_tvalid 1 O Beam weight data is valid.
m<E>_beamweights_tlast 1 O Last word indication.
D
When *_valid is asserted, the first word (Word 0) contains the ID metadata for the
n
beamweight. tuser[0] is valid for this first cycle to mark Word 0. tuser[1] will be asserted on the
rib I ma tio
subsequent cycle, marking Word 1, with the beamweight extension data content following.
n te
ist rch Li ma
oran_radio_if core, apart from the first two bytes, where the beam ID given in the section
definition is reported into the stream. The last word has the beamweights_last signal
i o i tu
asserted together with tuser[2]. If asserted, tuser[2] marks that only the four least significant
-D ea iro for
bytes are valid and belong to the extension.
ut nst
When a C-Plane message contains more than one section, each carrying a Type 1 or Type 11
Extension, and the first extension spans over an odd number of 32-bit units, the Word 0 for the
Re es C In
following extension will start in the same word as the last four bytes of the preceding extension.
In this case, the data content belonging to the following extension will appear staggered on the
beamweights_tdata output, as shown in Figure 24.
or R to ial
The format of the first and last data words is shown below, along with the tuser signaling.
t f do ed nt
Note: There is no facility for pushback on this interface. Data must be consumed with the tvalid
indication to prevent data loss.
No ra os de
n
rib I ma tio
n te
ist rch Li ma
i o i tu
-D ea iro for
ut nst
Re es C In
The following tables provide the bit-field breakdown of Word 1 for Extension Type 1 and Type
11. These fields are as defined in the ORAN specification for Extension 1 and 11.
or R to ial
Table 30: Ext 1, Word 1
t f do ed nt
Position ORAN Field Additional Notes
No ra os de
[47:40] bfwXX
C
[55:48] bfwXX
[63:56] bfwXX
D
n
rib I ma tio
C-Plane messages that are not type zero, one, or three are diverted to this interface where an
external block must be able to accept data as it arrives.
n te
ist rch Li ma
Table 32: Bypass/Raw C-Plane Message Interface
i o i tu
Port Name Width I/O Clock Description
-D ea iro for
m<E>_raw_cplane_tdata [63:0] O C-Plane message data.
ut nst
m<E>_raw_cplane_tvalid 1 O C-Plane message data valid.
C-Plane message data start of frame
m<E>_raw_cplane_tuser 1 O
Re es C In
internal_bus_clk (SOF).
C-Plane message data end of frame
m<E>_raw_cplane_tlast 1 O
(EOF).
or R to ial
m<E>_raw_cplane_tkeep [7:0] O C-Plane message data byte enables.
The following timing diagram shows the signaling on this bus. A start of frame indicator is also
t f do ed nt
provided to assist and decode logic.
No ra os de
The raw_cplane_keep signal is set to all 1s, except possibly in the EOF cycle. Bit 0 of
raw_cplane_keep enables bits [7:0] of raw_cplane_data. The first word is the transport
header.
at
n
Table 33: Unsupported Extension Interface
rib I ma tio
Port Name Width I/O Clock Description
m<E>_unsupport_ext_tdata [63:0] O Extension message data.
n te
ist rch Li ma
m<E>_unsupport_ext_tvalid 1 O Extension message data valid.
Extension message data start of
frame (SOF).
i o i tu
[26:24] sectiontype
m<E>_unsupport_ext_tuser 1 O [23] direction
-D ea iro for
internal_bus_clk [22:16] exttype
ut nst
[15: 8] ss_number
[ 7: 0] cc_id
Re es C In
Extension message data end of
m<E>_unsupport_ext_tlast 1 O
frame (EOF).
Extension message data byte
m<E>_unsupport_ext_tkeep [7:0] O
or R to ial enables.
A single Early BeamID list common to all Spatial Streams is made available on the Early BeamID
Forward interface as soon as the reception window for a given symbol ends, respecting the time
advance between control and data messages.
n
Table 34: Uplink Early BID Interface
rib I ma tio
Port Name Width I/O Clock Description
[47] reserved
[46] rb
n te
ist rch Li ma
[45:36] startPrbc
[35:28] numPrbc
i o i tu
m_fram_ebid_tdata [47:0] O [27] reserved
[26:24] Component Carrier
-D ea iro for
[23:19] Spatial Stream
internal_bus_clk
ut nst
[18:15] Number of Symbols
[14: 0] Early BeamID
Re es C In
m_fram_ebid_tvalid 1 O Data is valid.
Indicates this is the last BID for all Spatial
m_fram_ebid_tlast 1 O Streams, i.e., early BID is done for this
symbol.
or R to ial
m_fram_ebid_tready 1 I Interface is ready to accept data.
t f do ed nt
Figure 27: Uplink Early BID Interface
No ra os de
do cl nfi
El is o
Related Information
C
Symbol Timing
D
This early extraction of the information might be necessary, for example, to allow time to move
Beam Weights from a global to a local memory.
A single Early BeamID list common to all Spatial Streams is made available on the Early BeamID
Forward interface as soon as the Reception Window for a given symbol ends, that is respecting
the time advance between control and data messages that you set.
at
n
Table 35: Downlink Early BID Interface
rib I ma tio
Port Name Width I/O Clock Description
[47] reserved
[46] rb
n te
ist rch Li ma
[45:36] startPrbc
[35:28] numPrbc
i o i tu
m_defm_ebid_tdata [47:0] O [27] reserved
[26:24] Component Carrier
-D ea iro for
[23:19] Spatial Stream
internal_bus_clk
ut nst
[18:15] Number of Symbols
[14: 0] Early BeamID
Re es C In
m_defm_ebid_tvalid 1 O Data is valid.
Indicates this is the last BID for all Spatial
m_defm_ebid_tlast 1 O Streams, i.e., early BID is done for this
symbol.
or R to ial
m_defm_ebid_tready 1 I Interface is ready to accept data.
t f do ed nt
Figure 28: Downlink Early BID Interface
No ra os de
do cl nfi
El is o
Related Information
C
Symbol Timing
D
The beam ID forward ports provide all the information required to manage their application to
the beam former uplink U-plane data. The number of spatial streams is determined in the signal
name (<S>). The symbol is implied from the system timing. You are now allowed to program
when the O-RAN Radio IF core outputs this data, depending on what is required by the uplink
beam former. Referring to the timing described in Symbol Timing, you will set the output
generation somewhere between the delivery of the Early Beam ID interface, that is at the end of
the corresponding control messages reception window, and the symbol period preceding the
at
generation of the UL Data Request for the same symbol. Notice that this latest opportunity is
described in Figure 5. To tune the output issue time, you have to set a couple of dedicated
registers available in the register map. All the data for one symbol and component carrier is
output at one time. There is no guarantee that all the resource blocks are in order; only that they
appear in a contiguous chunk of data.
n
Table 36: Uplink (PUxCH) Beam ID Forward Interface
rib I ma tio
Name Width I/O Clock Description
Indicates all the following fields are
m<S>_fram_bid_valid 1 O
valid.
n te
ist rch Li ma
Marks the end of the BID sequence
m<S>_fram_bid_tlast 1 O for a given component carrier in a
given symbol period.
i o i tu
Allows the reading function to push
m<S>_fram_bid_ready 1 I
-D ea iro for
back the streaming output.
ut nst
Set to 1 when a Section Type 0 CTRL
message was received for this
m<S>_fram_bid_off 1 O section. It can be used to save power
Re es C In
(the BID at the same time is forced to
0, though should be ignored).
The 15-bit beam ID from the C-plane
m<S>_fram_bid_beamId15 [14:0] O
message.
or R to ial
m<S>_fram_bid_remask [11:0] O
Beam mask. Paired with the
associated 15-bit beam ID.
m<S>_fram_bid_rb 1 O RB bit.
t f do ed nt
internal_bus_clk
m<S>_fram_bid_start_prbc [9:0] O Starting PRB.
Number of PRBs to apply beamID15
No ra os de
m<S>_fram_bid_num_prbc [7:0] O
to.
Number of symbols to apply
m<S>_fram_bid_num_symbol [3:0] O
beamID15 to.
do cl nfi
The following timing diagram depicts the timing on this interface. All signals are valid on the
valid signal. Signals such as m<S>_fram_bid_cc_id are high for complete symbols, whereas
the resource block changes state from cycle to cycle. A message for one CC can be as short as
one cycle, however it will always include all the sections defined for that CC.
at
n
rib I ma tio
n te
ist rch Li ma
i o i tu
-D ea iro for
ut nst
Re es C In
or R to ial
The mechanism to determine the output generation time is very similar to the one described in
Symbol Timing. You must set a proper value in the registers cc_ul_bidf_c_abs_symbol and
t f do ed nt
cc_ul_bidf_c_cycles.
No ra os de
Note: The Beam ID Forward interface can be adjusted between the Early BID interface (that is, at the
El is o
closing of the C-Plane Reception Window) and one symbol period in advance with respect to the main UL
timer, when the FHI gets ready to issue the UL data requests and clears the UL CTRL_buffer. Therefore,
C
• 2 ≤ cc_ul_bidf_c_abs_symbol ≤ cc_ul_setup_c_abs_symbol
D
> cc_ul_setup_c_cycles
D
outputs this data at a known point relative to the 10 ms external radio start signal. All the data
for one symbol and component carrier is output at one time. There is no guarantee that all the
resource blocks are in order; only that they appear in a contiguous chunk of data.
n
Table 37: Downlink (PDxCH) Beam ID Forward Interface
rib I ma tio
Port Name Width I/O Clock Description
Indicates that all the following fields are
m<S>_defm_bid_valid 1 O
valid.
n te
ist rch Li ma
Marks the end of the BID sequence for a
m<S>_defm_bid_tlast 1 O given component carrier in a given
symbol period.
i o i tu
Allows the reading function to push back
m<S>_defm_bid_ready 1 I
-D ea iro for
the streaming output.
ut nst
Set to 1 when a Type 0 CTRL message
was received for this section. It can be
m<S>_defm_bid_off 1 O used to save power (the BID at the same
Re es C In
time is forced to 0, though should be
ignored).
The 15-bit beam ID from the C-Plane
m<S>_defm_bid_beamId15 [14:0] O
message.
or R to ial
m<S>_defm_bid_remask [11:0] O
Beam mask. Paired with the associated
15-bit beam ID.
m<S>_defm_bid_rb 1 O internal_bus_clk RB bit.
t f do ed nt
m<S>_defm_bid_start_prbc [9:0] O Starting PRB.
m<S>_defm_bid_num_prbc [7:0] O Number of PRBs to apply beamID15 to.
No ra os de
m<S>_defm_bid_cp_length [15:0] O
sent to this port.
AM
D
n
rib I ma tio
These ports are used to request sections of processed uplink data. Uplink U-Plane data must be
returned in response to the requests on req, for onward formation of uplink U-Plane Ethernet
frames. U-Plane data must be returned in order as requested. The ul_uplane_keep signal is
n te
ist rch Li ma
set to all 1s, except possibly in the EOF cycle. Bit 0 of ul_uplane_keep enables Bits 7:0 of
ul_uplane_data.
i o i tu
The following timing diagram depicts the timing on this interface. The uplink controller creates
-D ea iro for
requests for a range of RB data from a data buffer downstream. It expects a response for every
ut nst
request. A request is considered complete when a tlast is received. The O-RAN Radio IF core
expects as many tlast signals as data_req signals are issued. A request only lasts one clock
Re es C In
cycle. No pushback is available on this interface.
Note: If the fram_logic_clock is enabled, the following timing diagram will use it and not
or R to ial
internal_clk.
The input data format depends on the inclusion of the data compressor. If included only BFP
AM
9/12 can be used. The additional logic provides only bit shifting and rotation.
D
If not included, the data format should follow Table 8.3.2-1: IQ data frame format in O-RAN
Control, User and Synchronization Plane Specification v11.0 (O-RAN Specification v11.0).
The data bus signaling mode is shown in the following figure for each mode.
Note: Note transactions are not shown in full. When compression logic is external, Byte B0 should be
at
asserted on Bits 7:0 of the data bus, tdata_noComp, and so on. When compression logic is in the core, the
input format is IQ, starting with I0 at Bits 15:0.
If the compression logic is included, but the mode is for uncompressed data the output format
behaves in the same way as if there is no compression logic.
n
rib I ma tio
n te
ist rch Li ma
i o i tu
-D ea iro for
ut nst
Re es C In
or R to ial
t f do ed nt
No ra os de
do cl nfi
El is o C
D
AM
D
this governs the size of the data for the RB. The first word of the data is aligned to Bit 0, with
tlast and tkeep indicating the last word and byte. These signals are valid when
m<S>_defm_data_tvalid is High.
n
Table 39: Downlink U-Plane Data Interface
rib I ma tio
Port Name/Field Width I/O Clock Description
Used as a Start of Symbol marker. Used to indicate
m<S>_defm_data_tuser[90] 1 O
the start of a symbol of RB sections.
n te
ist rch Li ma
Modulation Compression ReMask2 (valid if [33:32]
m<S>_defm_data_tuser[89:78] 12 O == 2'd3). In case of double Extension Type #4, it
replicates the second section's reMask.
i o i tu
m<S>_defm_data_tuser[77] 1 O Constellation Shift Factor 2 (valid if [33:32] == 2'd3).
-D ea iro for
Modulation Compression Scaler Value 2 (valid if
m<S>_defm_data_tuser[76:62] 15 O
ut nst
[33:32] == 2'd3).
Modulation Compression ReMask1 (valid if [33:32] !
m<S>_defm_data_tuser[61:50] 12 O = 2'd0). In case of Extension Type #4, it replicates
Re es C In
the section's reMask.
m<S>_defm_data_tuser[49] 1 O Constellation Shift Factor 1 (valid if [33:32] != 2'd0).
Modulation Compression Scaler Value 1 (valid if
or R to ial
m<S>_defm_data_tuser[48:34] 15 O
[33:32] != 2'd0).
Modulation Compression support:
0 = absent (should never occur if tuser[31]=1;
t f do ed nt
1 = Extension Type #4, only CSF1 and ModComp
Scaler1 are significant, while the ReMask1 field
replicates the content of the section field;
No ra os de
RB.
Defines the component carrier that the block of
data pertains to. The usable width depends on
D
The following timing diagram depicts the timing on this interface. The U-plane data is forwarded
n
as received, with the decompression information delivered out of band. This information might
rib I ma tio
not be in the packet, so the core and receiver must be configured using the M-plane in this case.
Every symbol is marked with an SOF. Every section is marked with a tlast.
n te
ist rch Li ma
Note: If sections need to be split across multiple packets, there is a tlast for each section, even though
they might carry the same section ID.
i o i tu
Figure 32: O-RAN Downlink Data Interface
-D ea iro for
ut nst
Re es C In
or R to ial
t f do ed nt
No ra os de
The output data format depends on the inclusion of the data decompressor. If included only BFP
do cl nfi
9/12 or Modulation Compression 1/2/4 bit widths can be used. The additional logic provides
only bit shifting and rotation.
El is o
In case of Modulation Compression, the scaler values and remasks carried by either Extension
Type#4 or #5 are associated out of band to the corresponding RBs, as illustrated in the table
C
above.
Note: Only an Extension Type#5 holding up to two different scaler values and associated ReMasks can be
D
supported. Also, the alternative of associating two different Extensions Type #4 to the same radio
resources is supported; in case of Extension Type #4, the associated ReMask field holds the value carried in
AM
D
If not included, the data format should follow Table 8.3.2.-1: IQ data frame format in O-RAN
Control, User and Synchronization Plane Specification v11.0 (O-RAN Specification v11.0).
To complete modulation decompression, the final unshift operation must be performed outside
the core. An example of this is available in the Example System on GitHub. This allows the user
at
For BFP, the PDxCH is assumed to be LSB aligned. This means if BFP 12 is used, the maximum
value that udCompParam can be is 4. This data is then zero stuffed from the LSB. If 0x7FF was
sent by the oDU, this would appear on the output as 0x7FF0, assuming udCompParam was 0.
For each mode, the data bus signaling is shown below. Note transactions are not shown in full.
n
When decompression logic is external, Byte B0 appears on Bits 7:0 of the data bus
rib I ma tio
tdata_noComp, and so on. When Decompression logic is in the core, the output format is IQ,
starting with I0 at Bits 15:0.
n te
ist rch Li ma
If the decompression logic is included, but the mode is for uncompressed data the output format
behaves in the same way as if there is no decompression logic. If the parameter
i o i tu
Comp_Decomp_Uc_Swap is set true, uncompressed with behave in the same way as when BFP
9/12/14 are enabled.
-D ea iro for
ut nst
Figure 33: Downlink U-Plane Data Bus Signal
Re es C In
or R to ial
t f do ed nt
No ra os de
do cl nfi
El is o C
D
AM
D
at
From O-RAN Radio IF v2_2, if static decompression is used, it can be configured on a per SS
basis. This can be configured via register defm_defm_decomp_ss at address 0x6910. It is
configured on a per SS basis. See the register map and the demo_tb for examples of use.
Note: There is a limitation that all CC for each SS will use the same decompression mode.
Related Information
n
rib I ma tio
Register Space
n te
ist rch Li ma
Downlink SSB data is passed per section. Additional data is passed out of band, to route this data
i o i tu
to the correct buffers downstream. The compression mode is known from the M-Plane, and this
-D ea iro for
governs the size of the data for the RB. The first word of the data is aligned to bit 0, with tlast
ut nst
and tkeep indicating the last word and byte. These signals are valid when
m_ssb_data_tvalid is High.
Re es C In
Table 40: SSB Data Interface
or R to ial
Port Name
m_ssb_data_tdata[63:0]
I/O
O
Clock Description
SSB data output.
m_ssb_data_tkeep[7:0] O SSB data used octets output.
t f do ed nt
m_ssb_data_tvalid O internal_bus_clk SSB data valid.
m_ssb_data_tlast O SSB data last.
No ra os de
n
Table 41: Tuser Breakdown
rib I ma tio
Port Name/Field Width I/O Clock Description
Modulation Compression RE mask 2 (valid if [33:32]
m_ssb_data_tuser[89:78] 12 O
== 2'd3).
n te
ist rch Li ma
m_ssb_data_tuser[77] 1 O Constellation Shift Factor 2 (valid if [33:32] == 2'd3).
Modulation Compression Scalar Value 2 (valid if
i o i tu
m_ssb_data_tuser[76:62] 15 O
[33:32] == 2'd3).
Modulation Compression RE mask 1 (valid if [33] ==
-D ea iro for
m_ssb_data_tuser[61:50] 12 O
'b1).
ut nst
m_ssb_data_tuser[49] 1 O Constellation Shift Factor 1 (valid if [33:32] != 2'd0).
Modulation Compression Scaler Value 1 (valid if
m_ssb_data_tuser[48:34] 15 O
Re es C In
[33:32] != 2'd0).
Modulation Compression (0 = absent; 1 = only CSF1
m_ssb_data_tuser[33:32] 2 O and ModComp1; 2 = only CSF1, ModComp1 and
ScaleReMask1).
or R to ial
m_ssb_data_tuser[31] 1 O
ModParamValid. When 1 the parameters apply to
the current RB. Currently the second cycle of the RB.
internal_bus_clk
Defines the component carrier that the block of
t f do ed nt
m_ssb_data_tuser[30:28] 3 O data pertains to. The usable width depends on
number of component carriers defined in the IP.
No ra os de
m_ssb_data_tuser[9:0] 10 O
pertains. Valid values are 0–274.
AM
D
The following timing diagram depicts the timing on this interface. The U-Plane data is forwarded
as received, with the decompression information delivered out of band. This information might
not be in the packet, so the core and receiver must be configured using the M-Plane in this case.
Every symbol is marked with an SOF. Every section is marked with a tlast.
Note: If sections need to be split across multiple packets, there is a tlast for each divided portion of the
same section, even though they might carry the same section ID.
at
n
rib I ma tio
n te
ist rch Li ma
i o i tu
-D ea iro for
ut nst
Re es C In
or R to ial
t f do ed nt
No ra os de
Related Information
Register Space
do cl nfi
This early extraction of the information might be necessary, for example, to allow time to move
C
Beam Weights from a global to a local memory. This information is made available to update, for
instance, the mapping tables, which are constructed outside of the O-RAN block.
D
A single Early BeamID list common to all Spatial Streams is made available on the Early BeamID
Forward interface as soon as the reception window for a given symbol ends, that is respecting
AM
D
the time advance between control and data messages that you set. The 5gnr timer is generating
the proper signals to trigger the generation of the Early BeamID Forward interface. The single list
of Early BeamIDs collected in each Spatial Stream CTRL buffer is stored in a single FIFO
(tentatively 256 × 32), to allow the external logic to download it in the most convenient way.
at
n
Table 42: SSB Early BID Interface
rib I ma tio
Port Name Width I/O Clock Description
[47] Reserved (Pad)
[46] rb
n te
ist rch Li ma
[45:36] startPrbc
[35:28] numPrbc
i o i tu
m_ssb_ebid_tdata [47:0] O [27] Reserved (Pad)
[26:24] Component Carrier
-D ea iro for
[23:19] Spatial Stream the BID is used for
internal_bus_clk
ut nst
[18:15] Number of symbols
[14:0] Early BID list for Framer (UL)
Re es C In
m_ssb_ebid_tvalid 1 O Data is valid.
Indicates this is the last BID for all Spatial
m_ssb_ebid_tlast 1 O Streams, i.e., early BID is done for this
symbol.
or R to ial
m_ssb_ebid_tready 1 I Interface is ready to accept data.
t f do ed nt
Figure 35: SSB Early BID Interface
No ra os de
do cl nfi
El is o
The beam ID forward ports provide all the information required to manage their application to
the beam former downlink SSB data. The symbol is implied from the system timing. The O-RAN
D
Radio IF core outputs this data at a known point relative to the 10 ms external radio start signal.
All the data for one symbol and component carrier is output at one time. There is no guarantee
AM
D
that all the resource blocks are in order; only that they appear in a contiguous chunk of data.
at
n
Table 43: SSB Beam ID Forward Interface
rib I ma tio
Port Name Width I/O Clock Description
Indicates that all the following fields are
m_ssb_bid_tvalid 1 O
valid.
n te
ist rch Li ma
Indicates the end of the BID sequence
m_ssb_bid_tlast 1 O for a given component carrier in a given
symbol period.
i o i tu
Allows the reading function to push back
m_ssb_bid_tready 1 I
-D ea iro for
the stream.
ut nst
When it is 1 can be relied to turn off the
m_ssb_bid_off 1 O beam former to save power (the BID at
the same time is forced to 0).
Re es C In
The 15-bit beam ID from the C-Plane
m_ssb_bid_beamId15 [14:0] O
message.
Beam mask. This is paired with the
m_ssb_bid_remask [11:0] O
or R to ial internal_bus_clk associated 15-bit beam ID.
m_ssb_bid_rb 1 O RB bit.
m_ssb_bid_start_prbc [9:0] O Starting PRB.
t f do ed nt
m_ssb_bid_num_prbc [7:0] O Number of PRBs to apply beamID15 to.
Number of symbols to apply beamID15
m_ssb_bid_num_symbol [3:0] O
No ra os de
to.
Component carrier for this ID. Not all
m_ssb_bid_cc_id [7:0] O
bits are required.
do cl nfi
n
rib I ma tio
Table 44: Uplink U-Plane Unsolicited Interface
n te
Port Name I/O Clock Description
ist rch Li ma
s<S>_fram_unsol_tdata[63:0] I Framer unsolicited data input.
i o i tu
s<S>_fram_unsol_tkeep[7:0] I Framer unsolicited data used octets input.
Framer unsolicited data valid. A complete
-D ea iro for
packet of data must be available when this is
s<S>_fram_unsol_tvalid I
set. This should be raised when this condition
ut nst
is met.
s<S>_fram_unsol_tlast I Framer unsolicited data last.
Re es C In
Framer unsolicited data user.
internal_bus_clk
[31:16] eAxC ID
[15:13] Ethernet Port
s<S>_fram_unsol_tuser[31:0]
or R to ial I [12:0] Incoming packet length in Bytes. Room
for 8K packets. Length is required as there is
no packet buffering inside the core. Valid on
the first cycle of tvalid and tready.
t f do ed nt
Framer unsolicited data input ready. This is
only raised once tvalid is High and the framer
s<S>_fram_unsol_tready O
has determined it can send the data on the
No ra os de
The s<S>_fram_unsol ports can be used for data such as sounding reference signals (SRS).
do cl nfi
Note: The O-RAN header must be supplied along with data. The O-RAN Radio IF core only adds the
transport header.
El is o
n
rib I ma tio
Table 45: Uplink U-Plane PRACH Interface
n te
Port Name Width I/O Clock Description
ist rch Li ma
s<P>_fram_prach_tdata [63:0] I Data bus.
i o i tu
Bytes valid on this data beat. Only
s<P>_fram_prach_tkeep [7:0] I
evaluated when tlast is set.
-D ea iro for
s<P>_fram_prach_tvalid 1 I Data is valid.
ut nst
s<P>_fram_prach_tlast 1 I Last data beat.
s<P>_fram_prach_tready 1 O Interface is ready to accept data.
Re es C In
tuser is sampled on the first tvalid and
tready of a data burst. It must be correct
internal_bus_clk
at this time. The section ID, CC and
Ru_Port_Id must match a one that was
or R to ial
s<P>_fram_prach_tuser [31:0] I
sent from the O-DU and that came out of
the PRACH BID port. If this information
does not match, the packet is flushed and
not sent out.
t f do ed nt
[31:24] Reserved
[23:20] CC
No ra os de
[19:12] Ru_Port_ID
[11:0] Section ID
do cl nfi
If a packet is requested with a non-matching section ID, Ru_Port_Id, and Component Carrier,
s<P>_fram_prach_tready is immediately asserted and the data is flushed.
The amount of data presented on the interface must match the number of RBs and the
compression mode requested for this section on the PRACH BID interface.
If Num_Symbol for the section was greater than one, that is, used to signal repetitions, then the
n
interface expects Num_Symbol AXIS packet data. These are with the same section ID,
rib I ma tio
Ru_Port_Id, and Component Carrier. Internally a count of these incoming matches is maintained
and once this is equal to Num_Symbol requested, then the O-RAN header information for this
n te
Section ID is removed.
ist rch Li ma
Note: PRACH is only sent when no PUxCH data is pending. This means that requests can be in flight. Once
i o i tu
PUxCH requests are fulfilled, PRACH data will be accepted.
-D ea iro for
Radio Start Alignment
ut nst
Re es C In
Table 46: Radio Start Alignment Interface
Timer Outputs
do cl nfi
These timer ports can be used for debug, or in user logic downstream of the IP. The timers use
the 10 ms strobes for alignment. There are separate timers for both uplink and downlink.
El is o C
D
AM
D
at
n
Table 47: Timer Ports
rib I ma tio
Port Name Width I/O Clock Description
UL Current Symbol Number. It is used to
address the segment whose content has
n te
ist rch Li ma
to be read out of the SS outputs at any
symbol period.
m<C>_ul_sym_num [11:0] O It counts the total amount of symbol
i o i tu
periods you have in a 10 ms radio frame.
Then it is triggered to zero value at every
-D ea iro for
10 ms strobe and reaches the number of
symbols you have for a given numerology
ut nst
just before the following 10 ms trigger.
UL Ctrl Time Advance CurrentSymbol
Re es C In
Number. This is offset from the
m<C>_ul_cta_sym_num [11:0] O
_ul_sym_num counter by the Ctrl Time
Advance for the system.
m<C>_ul_update 1 O UL Current symbol updated.
or R to ial
m<C>_ul_toggle 1 O
Flips level on UL Current symbol updated.
Use for external scope debug/
internal_bus_clk measurement.
t f do ed nt
UL Increment Current Symbol Number
m<C>_ul_symbol_inc 1 I
(optional).
m<C>_dl_sym_num [11:0] O DL Current Symbol Number. As UL.
No ra os de
OCP Block
D
This section contains information on the interfaces of the OCP block. The widths of the data
buses within the m_dl_ft and s_ul_ft AXI4-Stream interfaces are determined by the number
of antennas (NUM_ANTENNA), and the antenna interleaving factor (INTERLEAVE) that is chosen
when the core is customized.
at
These interfaces carry multiplexed data for multiple component carriers and antennas. The width
is defined as (NUM_ANTENNA/INTERLEAVE) × 32 bits. For example, with eight antennas and an
antenna interleaving factor of two, the data buses consist of four lanes, each of 32 bits. Each 32-
bit lane carries the data for one antenna. For correct operation of the OCP block, the IP must be
configured with the same number of downlink and uplink antennas.
If the core has been configured to use the ORAN core clock to drive the OCP block, then these
n
interfaces are synchronous to the internal_bus_clk; otherwise, they are synchronous to
rib I ma tio
ft_aclk.
n te
ist rch Li ma
the maximum number of CCs that are supported (NUM_CC).
i o i tu
Clock and Reset Ports
-D ea iro for
ut nst
Table 48: Clock and Reset Ports
Re es C In
ft_aclk 1 I If the ORAN IP clock is not being used to clock the OCP
block in the IP, this port provides the clock for the internal
operation of the OCP block.
or R to ial
ft_aresetn 1 I Active-Low reset for the ft_aclk domain. The deassertion of
the reset should be synchronous to ft_aclk.
t f do ed nt
Downlink U-Plane Interface
No ra os de
m_dl_ft_tvalid is High.
m_dl_ft_tvalid 1 O ft_aclk The signals are valid when the m_dl_ft_tvalid
C
output is asserted.
m_dl_ft_tlast 1 O ft_aclk A High on this signal indicates the end of a
symbol for a particular CC.
D
n
Table 50: Uplink U-Plane Interface (cont'd)
rib I ma tio
Port Name Width I/O Clock Description
s_ul_ft_tlast 1 I ft_aclk A High on this signal indicates the end of a
symbol for a particular CC.
n te
ist rch Li ma
s_ul_ft_tid 8 I ft_aclk Carries information on the identity of the CC that
is currently being sent to the OCP block and for
what antennas the data pertains to.
i o i tu
s_ul_ft_tready 1 O ft_aclk A high indicates that the OCP block can receive
-D ea iro for
data. The OCP block will not assert s_ul_ft_tready
until s_ul_ft_tvalid is asserted.
ut nst
Timing Interface
Re es C In
Table 51: Timing Interface
or R to ial
Port Name Width I/O Clock Description
ocp_dl_update NUM_CC*2 I internal_bus_clk Downlink timing information. This input
t f do ed nt
consists of 2-bits per CC.
• Bit 1: CC enabled. This can be driven by the
m<C>_cc_enabled output of the IP core.
No ra os de
IP core.
D
Register Space
AM
D
The O-RAN Radio IF IP core registers are accessible in a .csv format at the O-RAN lounge web
page (registration required).
at
Example System
The O-RAN Radio IF example system, which is generated by block automation, is composed of
the following main blocks:
• DMA infrastructure to allow the embedded processor to access the Ethernet ports and the
n
transmitted and received timestamps
rib I ma tio
• AXI4-Stream arbiter, which manages the concurrent transmission over Ethernet of the packets
coming from the O-RAN Radio IF and from the processor
n te
ist rch Li ma
• Block supporting the IEEE 1588 PTP implementation, which includes the software controlled
timer, generating the local Time of Day and 1PPS signal
i o i tu
Related Information
-D ea iro for
ut nst
Using the Example System in IP Integrator
Re es C In
or R to ial
t f do ed nt
No ra os de
do cl nfi
El is o C
D
AM
D
at
Chapter 4
n
rib I ma tio
n te
ist rch Li ma
Designing with the Core
i o i tu
-D ea iro for
ut nst
General Design Guidelines
Re es C In
Registering Signals
or R to ial
To simplify timing and increase system performance in a programmable device design, keep all
inputs and outputs registered between the user application and the core. This means that all
t f do ed nt
inputs and outputs from the user application should come from, or connect to, a flip-flop. While
registering signals might not be possible for all paths, it simplifies timing analysis and makes it
No ra os de
easier for the AMD tools to place and route the design.
The constraints provided with the example design identify the critical signals and timing
El is o
You should not modify the core. Any modifications can have adverse effects on system timing
and protocol compliance. Supported user configurations of the core can only be made by
AM
D
selecting the options in the customization IP dialog box when the core is generated.
Clocking
at
Clock Description
Continuous clock used to drive the AXI4-Lite interface. Operating range is 10.5 - 250 MHz. It can
s_axi_aclk
be generated either by the embedded processor or by an independent clock generator.
Clocks driving the AXI4-Stream interface with the Ethernet MAC cores. E = 0–3, one for each
Ethernet port enabled. These must be connected to the same signal used on the Ethernet MAC
tx<E>_eth_port_clk
transmission port (tx_clk_out) signal when the AMD 10G/25G High Speed Ethernet Subsystem is
instantiated. At 10G, this clock is fixed at 156.25 MHz. At 25G, it is fixed at 390.625 MHz.
n
Table 52: Clocks (cont'd)
rib I ma tio
Clock Description
Independent continuous clock driving the internal datapath within the O-RAN Radio IF core. Its
minimum frequency requirement is described in the Throughput section. The frequency must be
n te
internal_bus_clk
ist rch Li ma
between the minimum required for a given configuration. It is possible to generate the
internal_bus_clk again from the Ethernet MAC clock for ease of use, but this is not mandatory.
Optional clock that can be used to drive the PUxCH Framer logic all the way to the sub-section
i o i tu
fram_logic_clk buffer. Its maximum rate for external use is 390.625 MHz. This clock can be enabled in the GUI
using the Use_Frame_Clock parameter. It is not used for PRACH or Unsolicited data.
-D ea iro for
If the O-RAN Radio IF IP clock is not being used to clock the OCP block in the IP, this port provides
ft_aclk
ut nst
the clock for the internal operation of the OCP block.
Re es C In
Related Information
A specific reset signal is provided for each data path direction and the AXI4-Lite configuration
interface. The datapath resets are internally synchronized with the respective clock for each
do cl nfi
section. An indicator is provided for each reset to show when it has been deasserted in all
domains. This signal can be used as a downstream reset, or it can be ignored. These signal levels
El is o
can also be read using the AXI4-Lite configuration interface. The following table associates each
reset signal to the corresponding core clock input.
C
s_axi_aresetn s_axi_aclk
D
ft_aresetn ft_aclk
fram_reset Asynchronous
defm_reset Asynchronous
Reset Signals (Out)
fram<E>_reset_active tx<E>_eth_port_clk
defm_reset_active internal_bus_clk
at
The following diagram illustrates the internal reset distribution for the core.
n
rib I ma tio
fram_disable (register bank reset retimed on internal_bus_clk from s_axi_aclk)
fram_reset
n te
ist rch Li ma
Reset Synchronizer
internal_bus_clk
Optional Reset Synchronizer
i o i tu
(only included if the port is included)
fram_logic_clk
(optional)
-D ea iro for
fram<X>_reset_active
ut nst
Framer Frame Clock
Framer Ethernet Clock Framer Internal Clock Domain
Domain Domain (This domain is internally connected to
Re es C In
internal_bus_clk if the optional port is
not used)
fram_ready
or R to ial defm_ready
defm_reset_active
syncpath
sync path
tx<X>_eth_port_clk sync
Resetpath
Synchronizer
do cl nfi
Reset
Synchronizer defm_restart (register bank reset retimed on internal_bus_clk from s_axi_aclk)
El is o
defm_reset
C
X22811-042622
D
The fram<E>_reset_active output is provided as a bus so that multiple Ethernet cores can
be connected to the core. This signal can be used as a reset for this core. The _ready signals
AM
D
reflect when the internal register control has enabled each direction. The use of
fram<E>_reset_active, fram_ready, defm_ready, and defm_reset_active is
optional. States of all of these signals can be read using the AXI4-Lite interface.
Protocol Description
at
See Vivado Design Suite: AXI Reference Guide (UG1037) for the AXI protocol.
n
Using the Example System in IP Integrator
rib I ma tio
Note: To run the example system, you need license for both the O-RAN Radio IF IP core and the 10G/25G
n te
ist rch Li ma
High Speed Ethernet Subsystem.
The O-RAN Radio IF comes with a complete IP integrator based demonstration platform,
i o i tu
including Linux PTPv2 support to demonstrate a synchronized system. The system can be
-D ea iro for
generated using the IP integrator block automation and is a useful reference for any design. The
system is available in AMD Vivado™ IP integrator. When implementation is complete, the
ut nst
hardware description file (.xsa) can be used to seed PetaLinux and build a working Linux image
Re es C In
for the target board. The supported platforms are the Zynq UltraScale+ MPSoC ZCU102
Evaluation Kit and the Zynq UltraScale+ RFSoC ZCU111 Evaluation Kit.
Note: This is not a production quality 1588 reference design. It is intended for lab use, to allow
or R to ial
synchronization to oDU for demonstration/evaluation purposes. Only one Ethernet message path is
connected to the Arm®. Clock rates and FIFO sizes on this path are also conservative as this is not
intended to demonstrate high bandwidth traffic to the Arm. You are free to upgrade the reference design
t f do ed nt
as required.
No ra os de
System Breakdown
The O-RAN Radio IF system makes use of hierarchy to partition the diagram and concentrate
do cl nfi
function where most relevant. The following sections give an overview of the location of the
main system blocks and also provide guidance on where to start customizing the system.
El is o
Top Level
C
The following diagram shows the main blocks in the top level of the design.
D
AM
D
at
n
rib I ma tio
Zynq UltraScale+ MPSoC
Interrupts
n te
ist rch Li ma
i o i tu
UART
AXI4-Lite
1G Ethernet Processor
-D ea iro for
Interconnect
Datapath GT Serial
ut nst
JTAG AXI
Re es C In
LED
LED Driver Reset/Retime 1PPS
DIP Switches
or R to ial
t f do ed nt
X20846-052318
• JTAG AXI (jtag_axi_0): Allows connection through AMD Vivado™ Hardware Manager to the
AXI4-Lite address space in the PL. Use this interface for low-level debug in the system.
do cl nfi
• Reset/Retime (reset_retime): Clock and reset generation block. MMCMs create the following
clocks. Resets retimed to the following clocks are also generated here:
El is o
• AXI4-Lite clock
C
• 10G/25G High Speed Ethernet Subsystem DRP clock. The system reset (sys_reset) for
the 10G/25G High Speed Ethernet Subsystem is located in the following block in the IP
integrator design hierarchy: datapath/xxv_eth_subs/xxv_local_resets.
• Interrupts: All interrupts to the Arm processor must recombine through this block.
• AXI4-Lite Interconnect (axi4lite_ic): AXI4-Lite interconnect. This connects the Arm processor
to all device AXI4-Lite IP core interfaces.
at
• Datapath: Main data processing block that 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.
Datapath
n
rib I ma tio
There are two main blocks in the datapath level of the design; the 10G/25G High Speed Ethernet
Subsystem and the O-RAN Radio IF. This section provides a high-level description for both
blocks.
n te
ist rch Li ma
Note: You can modify the shaded blocks to customize the solution.
i o i tu
Figure 41: Datapath Block Diagram
-D ea iro for
ut nst
datapath
Re es C In
framer_datapath xxv_eth_subs
xxv_wrap
or R to ial 10G/25G High Speed Ethernet
Subsystem
(xxv_ethernet_0)
O-RAN Radio IF
t f do ed nt
roe_radio_top
(oran_radio_if)
support_1588
No ra os de
X20852-012720
• roe_radio_top: Basic incrementing data generation and checker. Replace this block with your
custom digital front end (DFE) processing datapath. In this example, this block does not have
AM
D
• xxv_wrap: This block wraps the 10G/25G High Speed Ethernet Subsystem and the PTP timing
solution when used.
• TX/RX DMA Logic: Multiple AMD IP blocks, including some RTL read using the Module
Reference feature of IP integrator (see the Vivado Design Suite User Guide: Designing IP
at
Subsystems using IP Integrator (UG994)), multiplex in the data from the Arm processor to the
10G/25G High Speed Ethernet Subsystem and O-RAN Radio IF cores where appropriate. This
logic does not require modification unless a full recustomization of the datapath between the
O-RAN Radio IF and the 10G/25G High Speed Ethernet Subsystem is being undertaken.
• support_1588: When IEEE 1588v2 support is requested in the O-RAN Radio IF system, this
n
block contains all the logic required to correctly interface the out-of-band PTP control to the
rib I ma tio
10G/25G High Speed Ethernet Subsystem and return the timestamps from it. The 1588 timer
currently runs with a 250 MHz clock.
n te
ist rch Li ma
Note: This is a usage example only, supplied for only one of the 10G/25G High Speed Ethernet
Subsystem links. A complete system would require all 10G/25G High Speed Ethernet Subsystem links
i o i tu
to manage PTP traffic correctly, which is outside the scope of this example.
-D ea iro for
AXI4-Stream Arbiter
ut nst
An arbiter is interposed between the O-RAN Radio IF output and the corresponding Ethernet
Re es C In
transmit port, and for this reason a packet FIFO is embedded on the core output. The arbiter
allows both the constant bit rate flow generated by the hardware core and packets produced by
the Ethernet driver on the processor to access the same Ethernet transmission port. It is assumed
or R to ial
that the former flow has the higher priority; however, no frame pre-emption capability is
currently supported.
t f do ed nt
1588 Timer
No ra os de
The synchronization plane solution available on the O-RAN Radio IF system consists of
cooperating hardware and software elements. The hardware allows the collection and forwarding
of the timestamps, taken at transceiver level, to the processor, while the software relies on the
do cl nfi
PTP packets it exchanges with the remote counterpart to regulate the local time. The
synchronization solution is able to act either as a 1588 clock master or slave, depending on the
El is o
position of the instance in the network. To achieve sufficient accuracy, when the node is acting
as a slave, it is mandatory that the high-speed clock driving the timer is frequency-locked with
C
the master counterpart. This is achieved through synchronous Ethernet, by using the Ethernet
receiver recovered clock as the reference source of the clock driving the timer.
D
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. The following diagram shows
how this clocking structure is implemented, with the shading representing blocks that are in the
same clock domain.
at
n
rib I ma tio
Refclk Master Refclk Local
n te
ist rch Li ma
i o i tu
TX AXI 10G/25G High 10G/25G High RX AXI
Stream GT Serial Stream
Data Generation Speed Ethernet Speed Ethernet Data Consume
-D ea iro for
Subsystem Subsystem
ut nst
Re es C In
rx_clk_out tx_clk_out rx_clk_out tx_clk_out
Upstream Downstream
1 0 1 0
or R to ial MMCM MMCM
t f do ed nt
1588 Timer 1588 Timer
No ra os de
X20869-052118
On the master board, the 1588 timer and data generation logic is clocked from tx_clk_out
from the 10G/25G High Speed Ethernet Subsystem. On the downstream node, the 1588 timer
El is o
and data generation/sink logic is clocked from the recovered clock, rx_clk_out, therefore
C
achieving timing synchronization with the upstream reference clock. The clocks for the shaded
blocks are derived from the same single master clock source.
D
If additional feed through 10G/25G High Speed Ethernet Subsystem connections are added, the
recovered clock must be used as a reference clock (refclk) for these subsystems. This requires
AM
D
using IP integrator.
n
Table 54: Block Automation Options
rib I ma tio
Feature Options Description
Selects the processor architecture to use. This is
limited to the Arm processor on AMD Zynq™
n te
Select processor to use1 ARM_Linux
ist rch Li ma
UltraScale+™ MPSoC and Zynq UltraScale+ RFSoC
devices.
Enables PTPv1 on the 10G/25G High Speed Ethernet
i o i tu
XilinxPtpV1 Subsystem interface. Configures the MAC and adds
Select timestamping architecture1 all the appropriate interfaces to pass data between
-D ea iro for
None the Linux kernel driver and the 10G/25G High Speed
Ethernet Subsystem hardware.
ut nst
This is an optional reset, to the Arm processor–
True 10G/25G High Speed Ethernet Subsystem datapath,
Re es C In
Auto reset on Block Lock rising edge1 False on the rising edge of stat_rx_block_lock_0. If it is set
to False, you can monitor and apply a reset in the
application code.
Notes:
or R to ial
1. These options can only be selected the first time block automation is run.
t f do ed nt
Run Block Automation
1. Open an IP integrator block design (BD) canvas.
No ra os de
2. Insert a O-RAN Radio IF IP on the canvas. A box appears on the upper left of the IP
integrator design viewer.
do cl nfi
3. Select the box and run the block automation for the O-RAN Radio IF.
El is o
The Vivado Design Suite command line interface uses Tcl, which offers a means to extend the
design. Full details are hosted on GitHub; for more information, go to the O-RAN lounge web
D
Software
Software is available to demonstrate the use of the driver and API for the O-RAN Radio IF core.
AMD also supplies a run manager script that configures the system after the PetaLinux boot.
This can be found in the xorif-auto-start PetaLinux app and serves as a basic example of
one method of starting a system manager. The run manager Bash script within this app is
at
called runXorif.bash, and it is fetched using the flow described in Appendix C: Application
Software Development.
Chapter 5
n
rib I ma tio
n te
ist rch Li ma
Design Flow Steps
i o i tu
-D ea iro for
This section describes customizing and generating the core, constraining the core, and the
ut nst
simulation, synthesis, and implementation steps that are specific to this IP core. More detailed
information about the standard AMD Vivado™ design flows and the IP integrator can be found in
Re es C In
the following Vivado Design Suite user guides:
• Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
or R to ial
• Vivado Design Suite User Guide: Designing with IP (UG896)
• Vivado Design Suite User Guide: Getting Started (UG910)
t f do ed nt
• Vivado Design Suite User Guide: Logic Simulation (UG900)
No ra os de
This section includes information about using AMD tools to customize and generate the core in
El is o
If you are customizing and generating the core in the Vivado IP integrator, see the Vivado Design
Suite User Guide: Designing IP Subsystems using IP Integrator (UG994) for detailed information. IP
integrator might auto-compute certain configuration values when validating or generating the
D
design. To check whether the values do change, see the description of the parameter in this
AM
chapter. To view the parameter value, run the validate_bd_design command in the Tcl
D
console.
You can customize the IP for use in your design by specifying values for the various parameters
associated with the IP core using the following steps:
Note: If you want to add custom HDL to your block design in IP integrator, a complete reference guide can
be found in the "Referencing RTL Modules" chapter in Vivado Design Suite User Guide: Designing IP
Subsystems using IP Integrator (UG994).
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) and the Vivado
n
Design Suite User Guide: Getting Started (UG910).
rib I ma tio
Vivado IDE Configuration Tabs
n te
ist rch Li ma
The AMD Vivado™ Design Suite Integrated Design Environment (IDE) contains three tabs with
i o i tu
settings to configure the IP and the system generation. A fourth tab is also present, which
showcases the expected size of the memories used if the IP was synthesis and implemented
-D ea iro for
using the current configuration as set in the IDE.
ut nst
Furthermore, the Vivado Design Suite IDE provides a method of applying preset configurations.
Re es C In
From the Presets menu, several fixed configurations are available. These presets can then be
customized using the options found on the three tabs mentioned prior.
or R to ial
Spatial Stream Settings Tab
Ethernet Configuration
t f do ed nt
Table 55: Ethernet Configuration
No ra os de
Option Description
Ethernet ports Number of 10/25G Ethernet ports.
do cl nfi
Mode Settings
C
Option Description
D
Option Description
Antenna DEFM Output Streams De-framer AXI4-Stream ports.
Maximum length of data payload bytes to be encapsulated
Maximum User Data payload length
in a single Ethernet packet.
n
rib I ma tio
Table 58: Framer - Antenna to Ethernet Datapath (Uplink)
Option Description
n te
ist rch Li ma
Antenna FRAM Input Streams Framer AXI4-Stream ports.
Maximum length of data payload bytes to be encapsulated
i o i tu
Maximum User Data payload length
in a single Ethernet packet.
-D ea iro for
O-RAN Settings Tab
ut nst
Table 59: O-RAN Settings Tab
Re es C In
Option Description
or R to ial
Max Number of Component Carriers
Maximum number of component carriers to support in the
system. The maximum value is currently 8.
Guidance Numerology Use to estimate memory use.
t f do ed nt
Number of subcarriers or resource elements (REs) in the
Max Number of Subcarriers
system.
Size of uplink control delay buffer. For buffer size
No ra os de
DL Data Delay buffer pointers table. This is shared among all component carriers and
must be sized for your worst case.
C
timers.
D
Option Description
Enables eight GPIO as I/O and makes them addressable
Enable user GPIO ports (AXI4-Lite Clock domain)
through the O-RAN Radio IF register map.
Add inputs for you to increment numerology counters. One
Enable individual CC symbol increment strobe
per CC for UL and DL.
n
Table 60: General Settings Tab (cont'd)
rib I ma tio
Option Description
Enable internal core decompression logic on PDxCH Add the internal decompression logic.
n te
ist rch Li ma
Enable internal core Compression logic on PUxCH Add the internal compression logic.
Swap sample order for internal DeCompression logic. When true, the sample format into the compressor and out
of the decompressor is the same in Uncompressed and
i o i tu
Compressed modes. The default is to have uncompressed
default to RAW mode.
-D ea iro for
Add the precoding logic interface. This reports Ext 3
Enable precoding logic
ut nst
messages.
Set PDxCH Extension 4/5 support level Enable support for 1 Extension type 4 message or 1 or 2
Extension Type 5 messages for PDxCH.
Re es C In
Set SSB Extension 4/5 support level Enable support for 1 Extension type 4 message or 1 or 2
Extension Type 5 messages for SSB.
Set the depth of the FRAM UL request buffer Allows the number of FRAM requests to be selected from 2,
or R to ial
Enable RtCID mapping table
3, 4, 5, or 6. The default and maximum is 6.
When greater than one, enables the Remap table. The
depth is set to the 2^^bits, which is set in the GUI.
t f do ed nt
Supported bit widths are 0, 5, 6, 7, 8, 9, 10, or 11. For
example, selecting 8 gives 256 table entries that can be
used. The default is 0, meaning behavior is unchanged from
previous core releases.
No ra os de
Set number of unsolicited data ports Set the number of unsolicited data ports. Supported values
are 1, 2, 3, and 4. 1 port is the default.
Default antenna count to use for Ext 11 Required to correctly calculate the length of Extension type
do cl nfi
Use Radio Clock in UL datapath Creates an additional clock domain, using the per PUxCH as
a clock crossing.
Set the depth of the CIRC Meta Table Can be set to 8, 16, or 256. Sets the number of descriptors in
D
settings can be used if the core is only being used with one
or two antennas and therefore will not get bursts of short
CTRL packets for SRS for example.
Instantiate the ORAN Channel Processing (OCP) block in the Add the Channel processing block to the IP. This block
IP reorders the RBs on the IP interface. Its I/O towards the FFT
logic is a single AXI4-Stream bus, with antennas ordered in
multiples of 32-bits. This block is aimed at macro
applications of up to eight antennas. Using more than eight
UL or DL streams is not supported.
at
Use the ORAN core clock to clock the ORAN Channel Use the ORAN core clock (internal_bus_clk) to clock the OCP
Processing (OCP) block in the IP block
Maximum interleave factor for the ORAN Channel Set the interleave factor for the OCP block. Can be set to 1,
Processing (OCP) block in the IP 2, or 4.
Additional SSB Timer Allows the SSB to have a different numerology from the DL
Data.
User Parameters
n
rib I ma tio
The following table shows the relationship between the fields in the AMD Vivado™ IDE and the
user parameters (which can be viewed in the Tcl Console).
n te
ist rch Li ma
All other parameters should not be modified.
i o i tu
Table 61: User Parameters
-D ea iro for
Vivado IDE Parameter User Parameter Default Value
ut nst
Ethernet ports Physical_Ethernet_Ports 1
Re es C In
Ethernet rate Physical_Ethernet_Rate 10G
Antenna DEFM Output Streams: Axis_Ports_Defm 8
Maximum User payload length Defm_Eth_Pkt_Max 1024
or R to ial
Antenna FRAM Input Streams
Maximum User payload length
Axis_Ports_Fram
Fram_Eth_Pkt_Max
8
1024
Max Number of Component Carriers Xran_Max_Comp_Carr 1
t f do ed nt
Max Number of SubCarriers Xran_Max_Scs 3300
UL Ctrl Delay buffer size in 1K entries Xran_Max_Ul_Ctrl_1kWords 2
No ra os de
logic.
Enable precoding logic Defm_Precoding_Support 0
Set PDxCH Extension 4/5 support level PDXCH_Ext45_Support None
Set SSB Extension 4/5 support level SSB_Ext45_Support None
Set the depth of the FRAM UL request buffer Fram_Request_Pipe 6
Enable RtCID mapping table. 0=disabled Defm_Map_Table_Width 0
at
n
Table 61: User Parameters (cont'd)
rib I ma tio
Vivado IDE Parameter User Parameter Default Value
Instantiate the ORAN Channel Processing (OCP) Use_OCP_In_IP 0
block in the IP
n te
ist rch Li ma
Use the ORAN core clock to clock the ORAN Channel OCP_Use_Core_Clk 0
Processing (OCP) block in the IP
i o i tu
Maximum interleave factor for the ORAN Channel OCP_Max_Interleave 0
Processing (OCP) block in the IP
-D ea iro for
Additional SSB Timer Xran_indep_SSB_num 0
ut nst
Output Generation
Re es C In
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896).
or R to ial
t f do ed nt
Constraining the Core
No ra os de
Required Constraints
Clock Frequencies
D
Clock Management
Clock Placement
Banking
Transceiver Placement
n
rib I ma tio
This section is not applicable for this IP core.
n te
ist rch Li ma
Simulation
i o i tu
-D ea iro for
For comprehensive information about AMD Vivado™ simulation components, as well as
ut nst
information about using supported third-party tools, see the Vivado Design Suite User Guide: Logic
Simulation (UG900).
Re es C In
Synthesis and Implementation
or R to ial
For details about synthesis and implementation, see the Vivado Design Suite User Guide: Designing
t f do ed nt
with IP (UG896).
No ra os de
do cl nfi
El is o C
D
AM
D
at
Chapter 6
n
rib I ma tio
n te
ist rch Li ma
Example Design
i o i tu
-D ea iro for
The example design supplied demonstrates a basic IP integrator-based design. This is best used
ut nst
to explore its interfaces in simulation. Minimal configuration using AXI4-Lite register accesses
and IP configuration is also demonstrated.
Re es C In
The example design is supplied with a basic O-RAN traffic example, consisting of spatial stream
data and accompanying Type 1 C-Plane messages. When incorporating the core in custom test
or R to ial
harnesses, O-RAN packets must be correctly aligned and formatted to be fed into the core. The
packets should also be early with respect to their position in the 10 ms strobe cycle for data to
transit the core. For example, in numerology 0, there are 140 symbol periods between the 10 ms
t f do ed nt
strobes, and data for each of these symbol periods must arrive before its symbol period appears
on the spatial stream output.
No ra os de
Note:
IMPORTANT! In general, AMD recommends starting with a single Ethernet, component carrier, and
C
spatial stream configuration. The O-RAN Radio IF only accepts O-RAN data packets within a small
window, generally <200 μs, and only with the correct sub-frame, slot, and symbol IDs. Ensuring you are
meeting this requirement in your test harness is recommended before progressing with further test
D
scenarios.
AM
D
To demonstrate full system capability, the O-RAN Radio IF core requires a processor. The
example design is therefore not recommended as a starting path to a functional hardware design.
Instead, see the example generated by the block automation.
For help with demonstrating the O-RAN Radio IF, consult with your local Support contact.
Related Information
at
Appendix A
n
rib I ma tio
n te
ist rch Li ma
Upgrading
i o i tu
-D ea iro for
ut nst
Upgrading from RoE Framer to the O-RAN
Re es C In
Radio Interface
or R to ial
If you have an existing IP integrator (IPI) block design diagram, place the RoE Framer v2.1 IP (see
Radio Over Ethernet Framer LogiCORE IP Product Guide (PG312) (registration required)) in a
separate layer of hierarchy before upgrading the project to AMD Vivado™ 2023.1. At this point,
t f do ed nt
the RoE Framer IP is deleted, but you can insert the new O-RAN Radio IF IP and connect the
signals to ports on the hierarchy. When this connection is complete, you can dissolve the
No ra os de
hierarchical layer.
IMPORTANT! Adding this temporary layer of hierarchy prevents signal connections from being lost
do cl nfi
completely, and makes it much easier to reconnect them. If you upgrade without performing this step,
many signal routes might be lost.
El is o C
D
AM
D
at
Appendix B
n
rib I ma tio
n te
ist rch Li ma
Debugging
i o i tu
-D ea iro for
This appendix includes details about resources available on the Support website and debugging
ut nst
tools.
If the IP requires a license key, the key must be verified. The AMD Vivado™ design tools have
Re es C In
several license checkpoints for gating licensed IP through the flow. If the license check succeeds,
the IP can continue generation. Otherwise, generation halts with an error. License checkpoints
or R to ial
are enforced by the following tools:
• Vivado Synthesis
t f do ed nt
• Vivado Implementation
• write_bitstream (Tcl command)
No ra os de
IMPORTANT! IP license level is ignored at checkpoints. The test confirms a valid license exists. It does not
check IP license level.
do cl nfi
El is o
Solutions
D
To help in the design and debug process when using the core, the Support web page contains key
AM
resources such as product documentation, release notes, answer records, information about
D
known issues, and links for obtaining further product support. The Community Forums are also
available where members can learn, participate, share, and ask questions about AMD Adaptive
Computing solutions.
Documentation
at
This product guide is the main document associated with the core. This guide, along with
documentation related to all products that aid in the design process, can be found on the Support
web page or by using the AMD Adaptive Computing Documentation Navigator. Download the
Documentation Navigator from the Downloads page. For more information about this tool and
the features available, open the online help after installation.
Answer Records
n
rib I ma tio
Answer Records include information about commonly encountered problems, helpful information
on how to resolve these problems, and any known issues with an AMD Adaptive Computing
product. Answer Records are created and maintained daily to ensure that users have access to
n te
ist rch Li ma
the most accurate information available.
i o i tu
Answer Records for this core can be located by using the Search Support box on the main
Support web page. To maximize your search results, use keywords such as:
-D ea iro for
ut nst
• Product name
• Tool message(s)
Re es C In
• Summary of the issue encountered
or R to ial
A filter search is available after results are returned to further target the results.
Technical Support
do cl nfi
AMD Adaptive Computing provides technical support on the Community Forums for this AMD
LogiCORE™ IP product when used as described in the product documentation. AMD Adaptive
Computing cannot guarantee timing, functionality, or support if you do any of the following:
El is o
• Implement the solution in devices that are not defined in the documentation.
C
Debug Tools
There are many tools available to address O-RAN Radio IF design issues. It is important to know
at
n
rib I ma tio
The AMD Vivado™ Design Suite debug feature inserts logic analyzer and virtual I/O cores
directly into your design. The debug feature also allows you to set trigger conditions to capture
n te
application and integrated block port signals in hardware. Captured signals can then be analyzed.
ist rch Li ma
This feature in the Vivado IDE is used for logic debugging and validation of a design running in
AMD devices.
i o i tu
-D ea iro for
The Vivado logic analyzer is used to interact with the logic debug LogiCORE IP cores, including:
ut nst
• ILA 2.0 (and later versions)
Re es C In
• VIO 2.0 (and later versions)
See the Vivado Design Suite User Guide: Programming and Debugging (UG908).
or R to ial
Reference Boards
t f do ed nt
Various AMD development boards support the O-RAN Radio IF core. These boards can be used
to prototype designs and establish that the core can communicate with the system.
No ra os de
Hardware Debug
C
It is important to start debugging the downlink path, because most of the uplink traffic can be
D
properly configured and generated only if the corresponding C-Plane packets are correctly
received in the opposite direction.
AM
D
The first issue to keep in mind is that the O-RAN Radio IF core, to process in hardware all O-RAN
C-Plane packets and U-Plane packets, has to receive all the incoming Ethernet traffic, including
those packets that have to be managed in the software.
For this reason, there is a packet_filter in the O-RAN Radio IF core that is directly connected to
the Ethernet MAC's receiver output. The filter identifies all O-RAN C-Plane packets and U-Plane
at
packets and forwards them to the remaining hardware processing blocks. Conversely, any
unidentified packets are diverted towards the embedded processor through a DMA structure,
out of the scope of the core. The AXI4-Stream interface described in Message AXI4-Stream
Interface Ports represents the output of the core towards the embedded processor and transfers,
not only the Ethernet packets but also the attached timestamps.
To allow the filter to recognize the O-RAN packets, properly set the following registers.
n
eCPRI or IEEE 1914.3.
rib I ma tio
• FRAM_GEN_VLAN_TAG: Specify if Ethernet packets are VLAN tagged.
n te
• FRAM_SEL_IPV_ADDRESS_TYPE: Specify if the packets are transported either over raw
ist rch Li ma
Ethernet frames, or IPv4/UDP, or IPv6/UDP datagrams.
i o i tu
Notice that all O-RAN packets are expected to come in the chosen packet format; all packets
which somehow do not comply with the expected frames depending on the settings in the above
-D ea iro for
registers are automatically forwarded to the embedded processor. Moreover, always with the
ut nst
purpose of distinguishing the O-RAN packets from any other type of incoming traffic, the filter
can look for specific sub field within the first 64 octets of each packet. Specify the content the
Re es C In
filter has to look for by properly setting the USER_DATA_FILTER_W* registers. Remember that
the filtering, based on the content of each octet, can also be disabled by setting 1 as the
or R to ial
correspondent masking bit.
To establish a working downlink path, the first step is to understand whether the O-RAN packets
t f do ed nt
are actually recognized. To confirm they are recognized, three possible actions can be performed:
ORAN_RX_TOTAL counters:
• if only the former is improving, then also the O-RAN packets are not being recognized and
do cl nfi
that the packets are not looking formally correct from an O-RAN perspective, and
therefore they are discarded even if recognized as O-RAN packets by the filter.
D
2. Check how the Linux driver running on the embedded processor is receiving the Ethernet
packets; in case all the O-RAN traffic is diverted to the processor, it is highly probable that
AM
D
The following step consists in confirming that all incoming O-RAN packets are arriving within the
respective reception windows. Several actions are available:
at
2. When the test system is sending the packets too early with respect to the reception window,
n
as it was defined in terms of CC_DD_DATA_DYM_NUM_INDEX, or
rib I ma tio
CC_UL_CTRL_SYM_NUM_INDEX, it might also be useful to check the
OFFSET_EARLIEST_U_PKT, OFFSET_EARLIEST_C_PKT registers, because they record the
highest observed offset between its declared symbol number and the current symbol number
n te
ist rch Li ma
at the moment the packet was received: then, by comparing such an offset against the
number of symbol segments available in the Delay Compensation buffer and knowing the
i o i tu
required numerology, you can estimate the delay variation it has to be applied; you can also
increase either CC_DL_DATA_SYM_NUM_INDEX, or CC_UL_CTRL_SYM_NUM_INDEX, to
-D ea iro for
allow a wider reception window, provided these configurations are not becoming larger than
ut nst
those which were allocated in the GUI.
3. Probe the signals at the Transport Header Interface outputs (Transport Header Interface
Re es C In
Ports), triggering each packet on m<E>_t_header_offset_valid and observing in
particular m<E>_rtc_pc_id, to check that the eAxC identifier is the expected one,
m<E>_packet_in_window and m<E>_offset_in_symbol, where the latter is holding
or R to ial
the current measured offset between the transported symbol number and the current symbol
one. Be aware that for internal reasons, such an offset appears reduced by one for downlink
t f do ed nt
control packets and by two for uplink control ones. It is also a signed value, and viewing it as
such is clearer to understand.
No ra os de
counts the total amount of symbol periods you have in a 10 ms radio frame. Then it is
triggered to zero value at every 10 ms strobe and reaches the number of symbols you
have for a given numerology just before the following 10 ms trigger, that is 1119 with
El is o
numerology 3.
C
the same value on the previous counter, you should obtain exactly the TCP_ADV_DL value
you wanted to program.
AM
D
The last step requires to check that the contents of each transmitted packet are actually
appearing on the expected output interfaces:
1. Downlink data packets have to appear on the respective De-Framer AXI4-Stream interface
output (De-Framer (to Antenna) AXI4-Stream Interface Ports) aligned with dl_sym_num
timer;
at
2. Downlink ctrl packets have to appear on the respective Downlink BeamID Forward Ports
(Downlink Beam ID Forward Ports) again aligned with dl_sym_num timer;
3. The Early BeamID list for all supported Spatial Streams has to come out on the single De-
Framer Early BID interface (Downlink Early Beam ID Ports), aligned with dl_cta_sym_num.
To debug the uplink path, the first step is to check that uplink control messages are being
n
received regularly by the downlink core function. Then, if C-Plane packets bearing D_Direction =
rib I ma tio
0 have been assessed as formally correct and arriving within their respective reception window,
they should appear on the respective Uplink BeamID Forward Ports (Uplink Beam ID Forward
n te
Ports).
ist rch Li ma
Second, the core should start requesting U-Plane data through the s<S>_fram_data_req
i o i tu
ports (Uplink U-Plane Data Ports).
-D ea iro for
Finally, the Ethernet encapsulated packets should appear on the addressed core's transmission
ut nst
interface to be connected to the MAC (Framer (from Antenna) AXI4-Stream Interface Ports) and
the corresponding ORAN_TX_TOTAL counter should increase. Notice that in the current version
Re es C In
ORAN_TX_TOTAL_C will always be 0 because the uplink generation of control packets is not
currently supported.
or R to ial
For uplink PRACH packets, it is again necessary to verify that the section ID and RuPort_ID being
received over downlink C-Plane packets and appearing on the PRACH BID Interface (PRACH
Beam ID Ports) are matching the corresponding input signals being part of the
t f do ed nt
s<P>_fram_prach_tuser bus (Uplink U-Plane PRACH Ports).
No ra os de
Tready on the Beam ID forward and Early ports must be connected. Failing to connect this can
cause a stall in the CTRL pipe.
do cl nfi
There is a new Spatial Stream monitor block. This can be used to report the number of sections
and bytes that are seen on the chosen PDxCH stream. There is only one set of counters, so you
must select a stream of interest. Refer to the register guide or the xorif-app for more details.
El is o C
General Checks
Ensure that all the timing constraints for the core were properly incorporated from the example
D
• If using MMCMs in the design, ensure that all MMCMs have obtained lock by monitoring the
locked port.
• If your outputs go to 0, check your licensing.
at
Appendix C
n
rib I ma tio
n te
ist rch Li ma
Application Software Development
i o i tu
-D ea iro for
The following section provides a high-level overview of the software architecture and the
ut nst
interfaces provided. The technical documentation for the O-RAN Radio IF drivers, libraries, and
application software is included in the source distribution, which is available in the following
Re es C In
GitHub repositories: The Official Linux Kernel, OpenAMP / Libmetal.
C Library API
C
D
AM
D
Libmetal
User Space
Kernel Space
at
10/25G
1588 Timer
Ethernet UIO Driver
X20872-111720
The O-RAN Radio IF, 10G/25G High Speed Ethernet Subsystem, 1588 timer drivers, PTP
n
application, and C library API are ready to be included in your system with no further
rib I ma tio
modification. The communications, message parsing, and protocol modules are not specifically
designed for use in your system, but are provided as an example of how to use the software and
n te
hardware.
ist rch Li ma
i o i tu
Overview
-D ea iro for
ut nst
The software provided for the O-RAN Radio IF consists of the following modules and
Re es C In
applications (other AMD drivers and applications are also required for full system operation):
• Libmetal: The libmetal library provides common user APIs to access devices, handle device
or R to ial
interrupts, and request memory on Linux and bare-metal environments. As well as providing
abstraction, it also allows the O-RAN Radio IF device drivers to be written as user space code.
t f do ed nt
• C Library API: The C library API makes use of the libmetal library and encapsulates all of the
low-level code and utility functions in a shared library that can be included in a user
application.
No ra os de
• Sample Application: The sample application demonstrates how to use the C library API to
control the O-RAN Radio IF IP, and also provides a sample implementation of a protocol stack
do cl nfi
Sample Application
D
The sample application, xorif-app, demonstrates how the O-RAN Radio IF software stack
operates. It is not a complete implementation, and is not intended to be used in a production
AM
system. The sample application is composed of the following modules and libraries:
D
• C Library API: Full documentation for this library is provided in the source code distribution
package. This library is ready for reuse in an unmodified form.
• Communications Module: This module provides an interface for command line operation and
TCP/IP and UDP/IP socket interfaces for remote operation.
at
Appendix D
n
rib I ma tio
n te
ist rch Li ma
O-RAN Support Matrix
i o i tu
-D ea iro for
The following table details the extent to which this core supports O-RAN Control, User and
ut nst
Synchronization Plane Specification v11.0 (O-RAN Specification v11.0). Unmentioned features
should be considered unsupported.
Re es C In
Table 62: O-RAN Support Matrix
or R to ial
Clause Description Comments
The core implements the fronthaul interface for an O-RU
supporting a 7.2x Cat A split point. Precoding in the O-RU is
t f do ed nt
4.2 Functional Split not currently supported, and all radio digital elaboration
functions (FFT/iFFT, PRACH and SRS extraction, etc.) are out
of the scope of the core.
No ra os de
All data flows listed in table 4.3-3 are supported with the
4.3 Data Flows
exception of C-Plane 2b, 2c (LAA LBT).
The reception window for control or data messages is the
period between the minimum and maximum acceptable
do cl nfi
4.4.4.2 Fronthaul Timing Domain eCPRI Type 5 messages relying on proper timestamping at
Ethernet transceivers.
AM
4.4.7 Non-Delay Managed U-Plane Traffic generate traffic over Ethernet only when there are no U-
Plane data or PRACH packets available to be sent.
Supported: Packets arriving outside of respective reception
window are dropped, and monitoring counters are available
to detect whether the packets are arriving either too early
4.5 Reception Window Monitoring
or too late. The core keeps a measure of the earliest
received U-Plane and C-Plane packets to ease the
performance evaluation of the transport network.
at
n
Table 62: O-RAN Support Matrix (cont'd)
rib I ma tio
Clause Description Comments
Only endpoints that support a single numerology are
supported.
n te
ist rch Li ma
Sub field selection can be handled either by means of shift
5.1.3.2.7 ecpriRtcid/Pcid and mask variables or relying on a programmable mapping
table. Within the RU_Port_ID assignment, a rule must be
i o i tu
defined to distinguish packets carrying OCP traffic, from
those transporting either SSB or PRACH content.
-D ea iro for
Partially supported. Sequence checkers are not
implemented, and each message is dealt relying only on its
ut nst
transported symbol number.
5.1.3.2.8 ecpriSeqid Currently, only application layer fragmentation is supported,
Re es C In
therefore the Sequence ID field is regularly incremented per
eAxC after any generated packet. The subSequence is
always 0 and E-bit is always set to 1.
5.1.3.3 IEEE 1914.3 Transport Header Supported.
or R to ial
5.2.1 C-Plane Supported.
5.2.2 U-Plane Supported.
t f do ed nt
Supported. Timestamping is done at the transceiver level.
5.2.3 S-Plane
The PTP protocol is handled by the processor.
5.3 QoS Not applicable. Outside of the scope of the core.
No ra os de
Mixed Numerology and PRACH each section, as well as the Time Offset and other relevant
7.2.3 information associated to the header are extracted.
Handling
In case of PRACH both the frameStructure and the
frequencyOffset associated to each section in a Section Type
3 are extracted, thus allowing to manage different
Frequency Blocks.
Currently the core does not include any precoding function.
However, it terminates each Extension Type 3 and makes
7.2.4 DL Precoding
the relevant information available to an external precoding
at
n
Table 62: O-RAN Support Matrix (cont'd)
rib I ma tio
Clause Description Comments
Currently, Section Type 0, 1, and 3 messages are supported
7.3.1 Section Types for OCP and SSB traffic. Section Type 3 is usable for PRACH
n te
ist rch Li ma
control packets too.
Supported in core and externally via the bypass
7.3.2 Section Extensions
unsupported_extension port.
i o i tu
7.5.2.1 dataDirection Supported.
-D ea iro for
7.5.2.2 payloadVersion Supported, currently always payloadVersion=3'b1
ut nst
Partially supported: the value carried in the field is
7.5.2.3 filterIndex presented at UL and DL BID forward interfaces for Section
Type 0 and 3 control messages.
Re es C In
Supported. Each value carried in a C-Plane message is
7.5.2.4 frameId
assigned to the corresponding U-Plane packets.
Supported. Checked against internal counter to determine if
or R to ial
7.5.2.5 subframeId
the packet is in window.
Supported. Checked against internal counter to determine if
7.5.2.6 slotId
the packet is in window.
t f do ed nt
Supported. Checked against internal counter to determine if
7.5.2.7 startSymbolId
the packet is in window.
No ra os de
control messages.
Assignment of numerology through Sub Carrier spacing sub
AM
7.5.2.13 frameStructure
D
7.5.3.1 sectionID are used to form the UL U-Plane messages that are sent to
the O-DU.
Partially supported: the bit value is transferred to the UL
and DL BID forward interfaces, but the assignment of any
7.5.3.2 rb
other RBs is not supported yet neither for DL Modulation
Compression scalers, nor for UL U-Plane.
7.5.3.3 symInc Not currently supported.
7.5.3.4 startPrbc Supported.
n
Table 62: O-RAN Support Matrix (cont'd)
rib I ma tio
Clause Description Comments
7.5.3.5 reMask Supported.
n te
ist rch Li ma
Supported, including the numPrbc=0 value meaning all
7.5.3.6 numPrbc
PRBs for the given carrier.
7.5.3.7 numSymbol Supported.
i o i tu
7.5.3.8 ef Supported.
-D ea iro for
Supported. The value beamID=0 is always forced on the UL
7.5.3.9 beamID
and DL BID forward interfaces for Section Type 0 messages.
ut nst
7.5.3.10 ueId Not supported.
Re es C In
7.5.3.11 freqOffset Supported for Section Type 3 messages.
7.5.3.12-7.5.3.50 Not currently supported.
Partially supported; at the moment two dedicated output
or R to ial interfaces are available, one generating the beamweights
transported either by Extension Type 1, or by Extension
Type 11, thus fully supporting Flexible BF weights, and the
7.6 Section Extension Elements other to deliver the precoding configuration, included in
Extension Type 3. Scalar values and other related
t f do ed nt
information held in Extension Type 4 and 5 are dynamically
associated to the relative data streams on each spatial
stream output.
No ra os de
7.6.1 Section Extension commands All those included in extType 1, 3, 4, 5, 11 are supported.
Supported. Concatenation of extType 1 or 11 with extType4
7.6.2 Common parameters
or 5 supported in any order.
do cl nfi
n
Table 62: O-RAN Support Matrix (cont'd)
rib I ma tio
Clause Description Comments
Section Extensions not currently supported: the content of
7.7.12 -7.7.23 the extension together with the section description fields
n te
ist rch Li ma
are available on the unsupport_ext interface.
Basically it's always achieved via frequency and time but the
sectionId value assigned in corresponding C-Plane
i o i tu
messages is reported in each generated UL U-Plane packet,
7.8.1 Coupling of C-Plane and U-Plane also complying with application layer fragmentation rules.
-D ea iro for
Coupling through Frequency and Time with priorities is not
supported.
ut nst
Core resources are basically instantiated per endpoint but
O-RU per endpoint and per C-Plane
7.8.2 the user can specify the maximum number of sections to be
Re es C In
message limits
supported to optimize allocation.
7.9 C-Plane Optimizations Not supported.
7.9.9 U-Plane Operation without C-Plane Supported through uplink unsolicited ports.
or R to ial
8.1.1 U-Plane Transport Supported.
Partially supported; BFP compression/decompression is
available in the core on UL/DL, either programmed through
t f do ed nt
M-Plane, or through C-Plane (UL only). Additionally, DL
Modulation decompression unpacking is provided with the
final calculation to be performed externally.
No ra os de
8.1.2 U-plane Data Compression Note: If the compression is not performed by the core, but
external to it, the core still requires the compression mode
and bit width to pass the data correctly.
do cl nfi
8.1.3 Digital Power Scaling Out of scope for the fronthaul core.
C
PRACH and SRS. For SRS, the control of the data to be sent
8.3.5 Data Transfer for Special Cases and the definition of the PC_ID to be associated are left to
the user's design, while for PRACH rely on received C-Plane
packets.
Combination of data sections that are continuous in
8.4 U-Plane Optimizations frequency as well as Data blanking are not currently
supported.
Fully supported with the only exception of the optional
9.1 Counters
RX_SEQID_ERR counters.
n
Table 63: Mandatory and Optional Features
rib I ma tio
Clause Description Comments
n te
ist rch Li ma
Cat-B RU Extension 3 passed though core for external precoder.
Beam Index Supported.
i o i tu
Supported. Early BID interface available to allow updating of
Real-Time Beamforming Weights
BF Weights from a common storage
-D ea iro for
Real-Time Beamforming Attributes Not supported.
ut nst
Real-Time UE Channel Info Not supported.
Beamforming
Predefined beam tilt for BeamIndex
Not supported.
Re es C In
based Beamforming
Antenna Calibration Support Not supported.
Null-layer info for ueId-based BF Not supported.
or R to ial User port group indication
IQ Data Formats
Not supported.
Modulation compression passed out with data. Scaling to be performed externally for
optimal resource use.
Block floating point compression +
Bandwidth Saving Not supported.
selective RE sending
D
n
Table 63: Mandatory and Optional Features (cont'd)
rib I ma tio
Clause Description Comments
Defined Transport Method
n te
ist rch Li ma
Measured Transport Delay Method
O-DU - O-RU Supported.
(eCPRI message #5)
Timing
External Antenna Delay handling using
i o i tu
Not supported.
Minimal O-DU Impact Method
Synchronization Sync using G.8275.1, G.8275.2 Supported externally.
-D ea iro for
L2 Ethernet Supported.
ut nst
Supported. (IPv4 checksum is ignored in DL, external
L3 IPv4, IPv6 (CUS Plane)
generation required in UL).
Re es C In
QoS over Fronthaul Supported externally.
Prioritization of different U-Plane traffic
Supported.
types
or R to ial
Transport
Features Support of Jumbo Ethernet frames
eCPRI
Supported up to 16k bytes.
Supported.
t f do ed nt
support of eCPRI concatenation Not supported.
IEEE 1914.3 Supported.
No ra os de
Others
port.
C
Extension Types
Type 5 Supported in core.
Type 11 Supported in core.
AM
D
Appendix E
n
rib I ma tio
n te
ist rch Li ma
Additional Resources and Legal
i o i tu
Notices
-D ea iro for
ut nst
Re es C In
Support Resources
or R to ial
For support resources such as Answers, Documentation, Downloads, and Forums, see Support.
t f do ed nt
No ra os de
Documentation Portal
The AMD Adaptive Computing Documentation Portal is an online tool that provides robust
El is o
search and navigation for documentation using your web browser. To access the Documentation
C
Portal, go to https://docs.xilinx.com.
Documentation Navigator
D
Documentation Navigator (DocNav) is an installed tool that provides access to AMD Adaptive
AM
D
Computing documents, videos, and support resources, which you can filter and search to find
information. To open DocNav:
Design Hubs
AMD Design Hubs provide links to documentation organized by design tasks and other topics,
which you can use to learn key concepts and address frequently asked questions. To access the
Design Hubs:
n
rib I ma tio
Note: For more information on DocNav, see the Documentation Navigator webpage.
n te
ist rch Li ma
References
i o i tu
These documents provide supplemental material useful with this product guide:
-D ea iro for
ut nst
1. O-RAN Control, User and Synchronization Plane Specification v11.0 (O-RAN Specification v11.0)
Re es C In
2. O-RAN Fronthaul Management Plane v11.0 (O-RAN.WG4.MP.0-v11.00)
3. IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement
and Control Systems (IEEE 1588)
or R to ial
4. AMBA AXI4-Stream Protocol Specification (ARM IHI 0051A)
5. AMBA AXI and ACE Protocol Specification (ARM IHI0022E)
t f do ed nt
6. Vivado Design Suite: AXI Reference Guide (UG1037)
No ra os de
7. Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
8. Vivado Design Suite User Guide: Designing with IP (UG896)
do cl nfi
Revision History
The following table shows the revision history for this document.
n
Section Revision Summary
rib I ma tio
Number of Symbols Required Updated uplink diagram.
Downlink ORAN Processing Block Added topic.
Uplink Datapath Added basic on sequence table.
n te
ist rch Li ma
Uplink ORAN Processing Block Added topic.
Downlink U-Plane Data Ports • Updated note on parameters.
i o i tu
• Updated CC width and SOSM.
-D ea iro for
OCP Block Added ports for ORAN channel processing block.
ut nst
Vivado IDE Configuration Tabs Added information relating to the memory stats table and
presets.
General Settings Tab •
Re es C In
Updated Comp_Decomp_Uc_Swap.
• Added option related to separate SSB Timer.
User Parameters Added OCP parameters.
or R to ial
Entire document
11/18/2022 Version 2.3
Updated references to O-RAN v9.0 specification.
Short (Padded) Ethernet Frames Updated diagram.
t f do ed nt
eAxC (rtcid/pcid) Updated note.
Ethernet Processing Pipeline Added clarification on GUI configuration parameters.
No ra os de
• Reformatted table.
05/06/2022 Version 2.2
Chapter 3: Product Specification Updated block diagram.
eAxC (rtcid/pcid) Added mode 1 and mode 3 example.
Framer (from Antenna) AXI4-Stream Interface Ports Updated clocks.
PRACH Beam ID Ports Added notes.
Uplink U-Plane Data Ports Added new clock option.
n
Section Revision Summary
•
rib I ma tio
Downlink U-Plane Data Ports Added static decomp notes.
• Updated diagram.
Clocking Added frame_logic_clock.
n te
ist rch Li ma
Resets Updated figure.
User Parameters Added parameters.
i o i tu
Software Added link to GitHub repository.
-D ea iro for
O-RAN Settings Tab Updated options descriptions.
ut nst
General Settings Tab Updated parameters.
11/17/2021 Version 2.1
Re es C In
Packet Filter Updated to v6.0 and added Short Packet figure.
O-RAN Overview Added Clks rows to Numerology table.
Symbol Timing Updated Symbol Timing figure and description.
or R to ial
Number of Symbols Required Updated section.
Control Buffers Updated section.
t f do ed nt
Downlink Buffers Updated data buffer sizing description.
Example IDE Configuration Added SSB Data and CTRL Delay note.
No ra os de
• Bypass/Raw Section Extension Message Ports Added new topics under Port Descriptions.
• Precode Ports
at
n
Section Revision Summary
rib I ma tio
11/24/2020 Version 1.1
General updates Added information to support O-RAN Control, User and
Synchronization Plane Specification v4.0 (O-RAN Specification
v4.0).
n te
ist rch Li ma
• The Reception Window in Detail Added new sections under Core Functionality.
• Performance Counters
i o i tu
• Early BeamID Forwarding
•
-D ea iro for
Dedicated SSB Interface
ut nst
• Radio Frame 10 ms Synchronization Updated diagrams.
• Memory Structure
Re es C In
• Early BeamID Forwarding
• Configuring the Core
• Reconfiguring the Core
•
•
or R to ial
O-RAN Parser Ports
Uplink Beam ID Forward Ports
• Downlink U-Plane Data Ports
t f do ed nt
• SSB Beam ID Forward Ports
• Uplink U-Plane Unsolicited Ports
No ra os de
The information presented in this document is for informational purposes only and may contain
technical inaccuracies, omissions, and typographical errors. The information contained herein is
D
subject to change and may be rendered inaccurate for many reasons, including but not limited to
product and roadmap changes, component and motherboard version changes, new model and/or
AM
product releases, product differences between differing manufacturers, software changes, BIOS
D
flashes, firmware upgrades, or the like. Any computer system has risks of security vulnerabilities
that cannot be completely prevented or mitigated. AMD assumes no obligation to update or
otherwise correct or revise this information. However, AMD reserves the right to revise this
information and to make changes from time to time to the content hereof without obligation of
AMD to notify any person of such revisions or changes. THIS INFORMATION IS PROVIDED "AS
IS." AMD MAKES NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE
at
n
rib I ma tio
AUTOMOTIVE PRODUCTS (IDENTIFIED AS "XA" IN THE PART NUMBER) ARE NOT
WARRANTED FOR USE IN THE DEPLOYMENT OF AIRBAGS OR FOR USE IN APPLICATIONS
THAT AFFECT CONTROL OF A VEHICLE ("SAFETY APPLICATION") UNLESS THERE IS A
n te
ist rch Li ma
SAFETY CONCEPT OR REDUNDANCY FEATURE CONSISTENT WITH THE ISO 26262
AUTOMOTIVE SAFETY STANDARD ("SAFETY DESIGN"). CUSTOMER SHALL, PRIOR TO USING
i o i tu
OR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE PRODUCTS, THOROUGHLY TEST
SUCH SYSTEMS FOR SAFETY PURPOSES. USE OF PRODUCTS IN A SAFETY APPLICATION
-D ea iro for
WITHOUT A SAFETY DESIGN IS FULLY AT THE RISK OF CUSTOMER, SUBJECT ONLY TO
ut nst
APPLICABLE LAWS AND REGULATIONS GOVERNING LIMITATIONS ON PRODUCT
LIABILITY.
Re es C In
Copyright
or R to ial
© Copyright 2020-2023 Advanced Micro Devices, Inc. AMD, the AMD Arrow logo, Kintex,
Versal, Virtex, Vivado, Zynq, and combinations thereof are trademarks of Advanced Micro
t f do ed nt
Devices, Inc. CPRI is a trademark of Siemens AG. AMBA, AMBA Designer, Arm, ARM1176JZ-S,
CoreSight, Cortex, PrimeCell, Mali, and MPCore are trademarks of Arm Limited in the US and/or
elsewhere. Other product names used in this publication are for identification purposes only and
No ra os de