Pg370 Oran Radio If WTMKX

AMD CONFIDENTIAL
O-RAN Radio Interface v3.0
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
AMD Adaptive Computing is creating an environment where

employees, customers, and partners feel welcome and included. To
that end, we’re removing non-inclusive language from our products
and related collateral. We’ve launched an internal initiative to remove
language that could exclude people or reinforce historical biases,
including terms embedded in our software and IPs. You may still find
examples of non-inclusive language in our older products as we work
to make these changes and align with evolving industry standards.
Follow this link for more information.
AMD CONFIDENTIAL
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
Chapter 4: Designing with the Core................................................................... 98

General Design Guidelines.......................................................................................................98
AM
D
Clocking...................................................................................................................................... 98
Resets..........................................................................................................................................99
Protocol Description............................................................................................................... 100
Using the Example System in IP Integrator.........................................................................101
Chapter 5: Design Flow Steps...............................................................................107

at
Customizing and Generating the Core................................................................................. 107

Constraining the Core.............................................................................................................112
Simulation................................................................................................................................ 113
Synthesis and Implementation............................................................................................. 113
Chapter 6: Example Design................................................................................... 114
PG370 (v3.0) May 17, 2023

Send Feedback
O-RAN Radio Interface LogiCORE IP Product Guide 2
AMD CONFIDENTIAL
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
Appendix E: Additional Resources and Legal Notices............................131

t f do ed nt
Support Resources.................................................................................................................. 131
No ra os de
Finding Additional Documentation.......................................................................................131

References................................................................................................................................132
Revision History....................................................................................................................... 132
do cl nfi
Please Read: Important Legal Notices................................................................................. 135

El is o C
D
AM
D
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 1: Introduction
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
• Provides O-RU (O-RAN radio unit) function only.

do cl nfi
• 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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
• 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
O-RAN Support Matrix
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
Design Entry AMD Vivado™ Design Suite

Simulation For supported simulators, see the Vivado Design Suite User Guide: Release Notes,
Installation, and Licensing (UG973).
do cl nfi
Synthesis Vivado Synthesis

Support
El is o
Release Notes and Known Issues Master Answer Record: 73648

All Vivado IP Change Logs Master Vivado IP Change Logs: 72775
C
Support web page

Notes:
D
1. For a complete list of supported devices, see the Vivado IP catalog.

2. For the supported versions of the tools, see the Vivado Design Suite User Guide: Release Notes, Installation, and Licensing
(UG973).
AM
D
3. A -2 or faster speed grade is required for 25G operation.

at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 2: Overview
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
submodule within an implementation of a 5G RRU.
Figure 1: Top Level Overview

do cl nfi
O-RAN RADIO UNIT (O-RU)
O-RAN Radio Interface

El is o
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
1588 Timing Synchronization

ArmTM Processor
Logic
at
RFSoC with
Ethernet O-RAN Radio IF
System
O-RAN DISTRIBUTOR UNIT (O-DU)
X23887-041023
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 2: Overview
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
Control Systems (IEEE 1588), and on Synchronous Ethernet.

D
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 2: Overview
• 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
• Customizing and Generating the Core

AM
• Chapter 6: Example Design

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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 2: Overview
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
check IP license level.
Ordering Information
To purchase this IP core, contact your local Sales Representative referencing the appropriate part
number in the following table.
at
Table 1: Ordering Information
Description Part Number License Key

LogiCORE, O-RAN Radio Interface, site EF-DI-ORAN-RADIO-IF-SITE oran_radio_if
license
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 3: Product Specification
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
or R to ial 1 dedicated PRACH channel, with 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
1– Ethernet Processing Pipelines
Ethernet eCPRI/1914.3 21 to 1 PUxCH Section Request PUxCH Data

FIFO Framer Pipelined Mux Multi CC, RB Section info, Double Buffer Request
do cl nfi
Optional fram_logic_clk Domain
2048 FlowId Table

El is o
oDU Dest/Vlan lookup

1 – 20 Spatial Stream Storage 1 – 20 Physical Ports

C
Oran Stats
PUxCH C-Plane PUxCH Control
Oran window
Multi CC Symbol Buffer Beam ID Mgr
eAxC Map
Ethernet Packet Filter O-RAN Multi O-DU Ring

D
FIFO Parser Buffer (CIRC) 4 to X Pipelined PDxCH C-Plane PDxCH Control

eCPRI/1914.3
Interconnect Multi CC Symbol Buffer Beam ID Mgr
RAW/IP
AM
PDxCH U-Plane PDxCH BFP9/12/14

D
Multi CC Symbol Buffer DataMgr Mod1/2/4
PUxCH Early BID

Aggregator
Arm Networking Trans/oran/section

Interfaces align
PDxCH Early BID
PRACH BID
Aggregator
SSB
Early BID
Beam Id Mgr
Data Mgr
at
PRACH BID List

U-Plane & PRACH Beam Weights
AXIS Ethernet message pipe to ARM for Unsupported Section Messages Bypass ports
all non HW processed messages.
Timestamps from the Ethernet interface
are included for each packet, enabling
1588 support
X23910-051223
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 4: Core Block Diagram with OCP
n
rib I ma tio
1-4 unsolicited channels (SRS), no O-RAN framing
1 dedicated PRACH channel, with 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
Optional fram_logic_clk Domain
Re es C In
2048 FlowId Table
oDU Dest/Vlan lookup
1 – 20 Spatial Stream Storage 1 – 20 Physical Ports

Oran Stats
PUxCH C-Plane PUxCH Control
Oran window
Multi CC Symbol Buffer Beam ID Mgr
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
PDxCH U-Plane PDxCH BFP9/12/14

Multi CC Symbol Buffer DataMgr Mod1/2/4
t f do ed nt
Send Mgr
Aggregator
Transport/ PUxCH Early BID

Arm Networking oran/section
Interfaces align
No ra os de
PDxCH Early BID

PRACH BID
Aggregator SSB
Early BID
Beam Id Mgr
Data Mgr
do cl nfi
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
sufficient resources are available to support the use case programmed.
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).
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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 @ 491.52 (sym= 0 | 7 × 2μ) 35328 17792 9024 - 4640 2448

Clks @ 491.52 (all other syms) 35072 17536 8768 10240 4384 2192
C
Clks @ 390.625 (sym= 0 | 7 × 2μ) 28076.17 14139.81 7171.63 - 3687.54 1945.50

Clks @ 390.625 (all other syms) Per 27872.72 13936.36 6968.18 8138.02 3484.09 1742.05
D
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
Clks @ 156.25 (sym= 0 | 7 × 2μ) 11230.4 5655.9

Clks @ 156.25 (all other syms) 11148.8 5574.4
Notes:
1. Extended cyclic prefix (a special mode when µ = 2).
2. With the extended cyclic prefix, the prefixes for all the symbols have the same length.
Related Information
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Radio Frame 10 ms Synchronization
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
both uplink and downlink.

C
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
If enabled the register DEFM_USE_ONE_SYMBOL_STROBE can be used to switch between

modes, however if using the internal timer, the external symbol increment strobes
(mX_Xl_symbol_inc) should be kept at 0.
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 5: External Radio Start Timing Diagram
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
is used for component carrier 1, and so on.
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
Figure 6: Symbol Timing

AM
D
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
TCP_ADV_DL = 125us = 125000000ps

T2A_MIN_CP_UL = 50us = 50000000ps
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
parameter and depends on the upstream radio design.

AM
D
See the following indicative example:
tDECAP = 5us = 5000000ps (fronthaul latency)

oRU_Processing_Latency = 100us = 100000000ps (uplink radio chain latency)
Under these assumptions, you can compute the total advance time of DL and UL C-Plane:
DOWNLINK (Advance time of C-Plane wrt defm_radio_start_10ms)

at
DL_CTRL_RXWIN_ADV_CP = (tDECAP + TCP_ADV_DL) / Xran_Timer_Clk_Ps.
UPLINK (Advance time of C-Plane wrt fram_radio_start_10ms)

UL_CTRL_RXWIN_ADV_CP = (oRU_Processing_Latency + T2A_MIN_CP_UL) /
Xran_Timer_Clk_Ps
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
internal clock frequency = 400 MHz):
cc_dl_setup_d_cycles = ACTUAL_PERIOD_CP - (tDECAP /

El is o
Xran_Timer_Clk_Ps) = 28570
C
cc_dl_setup_c_abs_symbol= (DL_CTRL_RXWIN_ADV_CP / ACTUAL_PERIOD_CP) +

1 = 2
(that is the smallest integer greater than the
D
quotient)
cc_dl_setup_c_cycles = (cc_dl_setup_c_abs_symbol * ACTUAL_PERIOD_CP) -

AM
D
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
Bit field breakdown

[15:12] DU_Port_ID (D) 4-bits Max Width = 6-bits
[11] BandSector (B) 1-bit Max Width = 6-bits
AM
D
[10:8] CC_ID (C) 3-bits Max Width = 6-bits

[7:0] RU_Port_ID (R) 8-bits Max Width = 8-bits
ASCII representation of bit assignment from 15 to 0:

DDDD_BCCC_RRRR_RRRR
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
This initiates the following register writes:

C
WRITE_REG: DEFM_CID_CC_SHIFT (0x6020)[ 0:3 ] <= 0x8 (8)

WRITE_REG: DEFM_CID_CC_MASK (0x6024)[ 0:5 ] <= 0x7 (7)
WRITE_REG: DEFM_CID_BS_SHIFT (0x6028)[ 0:3 ] <= 0xB (11)
D
WRITE_REG: DEFM_CID_BS_MASK (0x602C)[ 0:5 ] <= 0x3 (3)

WRITE_REG: DEFM_CID_DU_SHIFT (0x6030)[ 0:3 ] <= 0xD (13)
AM
WRITE_REG: DEFM_CID_DU_MASK (0x6034)[ 0:5 ] <= 0x7 (7)

D
LIBXORIF> DEBUG: eAxC ID bits: DDDBBCCCRRRRRRRR

LIBXORIF> DEBUG: DU mask: 111-------------
LIBXORIF> DEBUG: BS mask: ---11-----------
LIBXORIF> DEBUG: CC mask: -----111--------
LIBXORIF> DEBUG: RU mask: --------11111111
set eAxC_id 3 2 3 8 => status = 0
eAxC ID - Mask/Value Decoding Mode

at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
This translates to:

do cl nfi
1. Eight bits assigned to the RU_Port_ID mask

2. Five bits used for PDxCH/PUxCH
El is o
3. 0xC0 used as the Stream Identifying mask

C
4. Zero used to identify PDxCH/PUxCH (0xC0 and 0x00) --> [7:6] == 0

5. 0x80 used to identify PRACH (0xC0 and 0x80) --> [7:6] == 2
D
6. 0x40 used to identify SSB (0xC0 and 0x40) --> [7:6] == 1

AM
This results in the following register writes:

D
WRITE_REG: DEFM_CID_SS_MASK (0x6038)[ 0:7 ] <= 0x1F (31)

WRITE_REG: DEFM_CID_U_MASK (0x603C)[ 0:7 ] <= 0xC0 (192)
WRITE_REG: DEFM_CID_U_VALUE (0x6040)[ 0:7 ] <= 0x0 (0)
WRITE_REG: DEFM_CID_PRACH_MASK (0x6044)[ 0:7 ] <= 0xC0 (192)
WRITE_REG: DEFM_CID_PRACH_VALUE (0x6048)[ 0:7 ] <= 0x80 (128)
WRITE_REG: DEFM_CID_SSB_MASK (0x604C)[ 0:7 ] <= 0xC0 (192)
WRITE_REG: DEFM_CID_SSB_VALUE (0x6050)[ 0:7 ] <= 0x40 (64)
at
LIBXORIF> DEBUG: RU mask: --------11111111

LIBXORIF> DEBUG: SS mask: -----------11111
LIBXORIF> DEBUG: Mask: --------11------
LIBXORIF> DEBUG: User value: --------00------
LIBXORIF> DEBUG: PRACH value: --------10------
LIBXORIF> DEBUG: SSB value: --------01------
Note: LTE, SSB, and PRACH detection can be disabled by writing 0x0 to the Mask value. Further API
programming examples are available on GitHub.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
eAxc ID - Mapping Table Decoding Mode
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
Physical port mapping.
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 7: Using Map Mode 2 for Resource Share
n
rib I ma tio
PDxCH Data Mgr SS0
SS0 CC1 SS0 CC0
PDxCH Data Mgr SS1
n te
ist rch Li ma
SS1 CC1 SS1 CC0
PDxCH Data Mgr SS2
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)
or R to ial Shared example with a single physical Spatial

Stream in the IP. Spatial Stream 1-3 are
overlaid as Component Carriers, which can be
considered Virtual CC in this example.
X27984-051223
t f do ed nt
No ra os de
Sub Mode Direction BSID CCID RU_Port_ID Total Bits

0 1 6 4 11
do cl nfi
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
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
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
Downlink U-Plane Data Ports

C
Ethernet Processing Pipeline

D
The Ethernet processing pipeline is constructed from three consecutive blocks:

AM
D
• 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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
• <m/s><C>_*: Port number determined by the number of component carriers.

or R to ial
• <m/s>_*: Port number determined by the number of PRACH AXIS streams.
• <m/s>_*: Port number determined by the number of unsolicited AXIS streams.

t f do ed nt
Packet Filter
No ra os de
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
1914.3 case, they must be h80 and h82.

C
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 8: Standard Ethernet Without VLAN Tag
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
Figure 10: IPv4 Over Ethernet Without VLAN Tag

C
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
UDP Destination IPv4 – Destination

word_2 Transport Header UDP Checksum UDP Length UDP Source Port
Port IP Address
word_3 O-RAN Header Transport Header
X23890-042620
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 11: IPv6 Over Ethernet Without VLAN Tag
n
rib I ma tio
word_0 T_C, F_L 6, T_C 00 08 Source MAC Destination MAC
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
Packet Filter Configuration Options

Because the choice of the frame format to be used in a O-RAN Radio IF application has to be
D
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
register located in the register map.
The following list summarizes the configuration options.
• bit[0]
○ bit[0] = 0 to select the eCPRI protocol.
at
○ bit[0] = 1 to select IEEE 1914.3.
○ The default value is 0.
• bit[4]
○ bit[4] = 1 to insert a VLAN tag.
○ bit[4] = 0 for no VLAN tag.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
The default value is 0.
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.
The default value is bit[6:5] = 0 to generate a raw type 2 Ethernet frame.
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.
Short (Padded) Ethernet Frames
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
O-RAN Window – Multi O-DU Ring Buffer

AM
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
It is important to remember that an implementation can have up to four Ethernet pipelines
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
the waiting packet, provided that its destination is free.
Figure 13: Multi O-DU Ring Buffer

do cl nfi
Eth Pipe 0 CIRC PDxCH Data Mgr SS0

SS0 CC1 SS0 CC1
abs10,p2 abs10,p0
El is o
Eth Pipe 1 CIRC

SS0 CC1 SS0 CC1
abs10,p1 abs10,p3
C
Eth Pipe 0 CIRC

PDxCH Data Mgr SS0
SS0 CC1 SS0 CC1 SS0 CC1
D
abs10,p2 abs10,p0 abs10,p3
Eth Pipe 1 CIRC

SS0 CC1
AM
D
abs10,p1
Eth Pipe 0 CIRC PDxCH Data Mgr SS0

SS0 CC1 SS0 CC1 SS0 CC1 SS0 CC1
abs10,p2 abs10,p0 abs10,p1 abs10,p3
Eth Pipe 1 CIRC
at
PDxCH Data Mgr SS0

SS0 CC1 SS0 CC1 SS0 CC1 SS0 CC1
abs10,p2 abs10,p0 abs10,p1 abs10,p3
X27983-041823
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
Downlink Processing Pipeline

do cl nfi
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
uplink C-Plane messages respectively.

C
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
Figure 14: Downlink OCP Block Diagram

do cl nfi
El is o
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
Buffer Sizing per Spatial Stream

The following figure shows the buffer sizing per spatial stream.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 17: Buffer Sizing per Spatial Stream
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
Downlink U-Plane Symbol DATA

Downlink Data Buffer
t f do ed nt
DEPTH = MAX_DL_DATA_POINTERS
Downlink Data Pointers

No ra os de
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Number of RBs Required
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.
Number of Symbols Required

t f do ed nt
To calculate how many symbols are required, consider the earliest time a packet can arrive at the
No ra os de
core, and how long it might need to be buffered.
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
• DL DATA buffer: tDELAY_COMP_UP = T2a_max_up – T2a_min_up

C
• DL CTRL buffer: tDELAY_COMP_CP_DL = T2a_max_cp_dl – T2a_min_cp_dl

D
• UL CTRL buffer: tDELAY_COMP_CP_UL = T2a_max_cp_ul – T2a_min_cp_ul

• Also, note that TCP_ADV_DL = T2a_min_cp_dl – T2a_min_up
AM
D
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
default and conservative figure of 5 μs is included.
Considering the Uplink Timing Diagram below, oRU_Processing_Latency introduced above

corresponds to Ta3_min in the O-RAN specification.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 18: Downlink Timing Diagram
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
Figure 19: Uplink Timing Diagram

El is o C
D
AM
D
at
Consider the following example. For uplink and downlink control messages, Delay Compensation
and control advance are summed as follows:
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
• Minimum control advance time = 90 μs
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
The Reception Window in Detail

The current state of the internal symbol counter for each configured CC is visible on the
do cl nfi
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
numerology just before the following 10 ms trigger.
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
the corresponding SS output before the end of the symbol period.
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
The width of the U-Plane packets reception window is determined by
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
CC_DL_CTRL_SYM_NUM_INDEX, it is important to take into account also the segments required

to hold the control packets after the expiration of the C-Plane reception window.
C
In other words, the actual starting point of the control messages reception window is determined
D
by adding the value set in CC_DL_CTRL_SYM_NUM_INDEX to the current state of the

m<C>_dl_sym_num.
AM
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
For each section, you need to count:

or R to ial
• One memory word (64-bit) for Section Type 1.
• Two words for Section Type 0 or 3, to store Time and Frequency Offsets.
t f do ed nt
• One additional word for each attached Extension Type 4 or 5, to store the Scalar values and
No ra os de
other related information.

• One or more additional words for each attached Extension Type 11, depending on the number
of RB groups which are defined within each extension. Precisely the number of additional
do cl nfi
words corresponds to the round up of

1 + ((numPRB / numBundPrb) – 2) / 4)
El is o
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
before the Control buffer.
Also, only for UL Control Buffer, you need to add one further memory word per UL C-plane
AM
D
packet to store FrameId and udCompHdr fields.
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:
• For a worst case of 275 sections per CC, you have:

at
(275 × 2 × 4) / 1,024 = 2.14

• Round 2.14 up to 3
• In the Vivado IDE, set the DL Ctrl Delay buffer size in 1K entries to 3
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:
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
• For a worst case of 275 sections per CC, you have:
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
• Set the DL Ctrl Delay buffer size in 1K entries to 1

do cl nfi
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
○ 9-bit block floating-point(BFP9) => RB size = (9 × 2 × 12) / 8 + 1 = 28 bytes.

AM
D
• Data buffer sizing:

○ The RB size is 28 bytes, plus the worst-case 4-byte section header per RB. This results in
32 bytes per section assuming in the worst case there is one RB per section. This can be
restricted to a more manageable number of sections per symbol, 32 for example.
○ Additional overhead should also be added for the O-RAN header and trailing unused bytes.
In total this is 11 bytes. This is added per Ethernet frame received. Considering a worst
at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
or R to ial Vivado IDE Parameter Value

Max Number of Component Carriers 2
Max Number of SubCarriers 6600
t f do ed nt
UL Ctrl Delay buffer size in 1K entries 3
DL Ctrl Delay buffer size in 1K entries 3
No ra os de
DL Data Delay buffer size in 1K entries 5

DL Data Delay buffer pointers 4
Max number of CTRL Symbols 4
do cl nfi
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
Ethernet MAC output interface.
Table 8: Counters Received at the Ethernet MAC Output Interface
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
Table 9: Counters Concerning the Reception Window Management
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
Table 10: Counters for C-Plane Control Packet

El is o
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.
Table 11: Counters for Erroneous Packets

at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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).
Table 13: Counters That Record the Highest Measured Offset

or R to ial
Counter Description
Largest captured difference between the symbol number transported by a U-
t f do ed nt
OFFSET_EARLIEST _U_PKT
Plane packet and the internal timer counter.
Largest captured difference between the symbol number transported by a C-
OFFSET_EARLIEST _C_PKT
No ra os de
Plane packet and the internal timer counter.
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[4] = 1 resets all eth_stats counters regarding Ethernet Port 0

• Bit[5] = 1 resets all oran_rx counters, except corrupt and error_drop, regarding Ethernet Port 0
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
• 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
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
spatial stream as a single AXI4-Stream interface.
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
Figure 20: Early BeamID Interface

at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Dedicated SSB Interface
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
accumulating all the CCs that must be supported.

C
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
• CC_SSB_NUM_SYM_PER_CC, to define the number of symbol periods that have to be

included in the CTRL_buffer
• CC_SSB_DATA_SYM_START_INDEX, CC_SSB_DATA_SYM_PER_CC, to define how many
symbol periods have to be included in the DATA_buffer
• CC_SSB_DATA_UNROLL_OFFSET, to partition the DATA_buffer among the CCs and the
symbol segments
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
SSB API programming examples are available on GitHub.
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
4. The output request is a 33-bit command on the s<S>_fram_data_req interface, which

defines the RB data to be returned for the specified component carrier and section/number
of RBs.
El is o
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
5. The input is the RB data returned, in a single AXI4-Stream transfer, on the

s<S>_fram_data_axis port.
AM
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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_fram_unsol_tvalid signal, and must be able to
do cl nfi
supply an entire payload without interruption when serviced.
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
register map. This override is signaled via the register eth_multi_odu_support.
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
To Uplink SS1 Read Engine Ping Pong Input from OFDM

Datapath SS2 Memory Write Engine
….
….
….
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
Configuring the Core

or R to ial
Before you use the core, various registers must be configured using the information provided by
the O-RAN control unit (O-CU) through the M-Plane (not defined here).
t f do ed nt
RECOMMENDED: AMD recommends reviewing the code in the FHI XORIF C library. This library contains
No ra os de
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
• Each CC can only have a single numerology.

• Other CCs might have different numerology values.
• The numerology is the same for uplink and downlink.
2. Configure the number of resource blocks (RBs) to assign to each CC. These allocations are
based upon the overall system requirements known only to the oDU. The oDU must query
the oRU to determine its capabilities, and thus make appropriate provisioning configurations
at
of the oRU.
oran_init_componentcarrier (0, 1, 275); // CC, Numerology, RbsMax
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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:
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
- Time advance of the DL control messages wrt the data ones:

No ra os de
Tcp_adv_dl = T2a_min_cp_dl - T2a_min_up = 100 µs

greater than)
do cl nfi
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:
assume T2a_max_cp_ul = 80 µs; T2a_min_cp_ul = 50 µs;
D
tDELAY_COMP_CP_UL = T2a_max_cp_ul - T2a_min_cp_ul = 30 µs

AM
- Delay of the UL_radio_start_10ms reference wrt the same reference at

D
the antenna:
ORU_UL_Latency = 60 µs

greater than)
CC_UL_CTRL_SYM_NUM_INDEX[X] =
= (tDELAY_COMP_CP_UL+T2a_min_cp_ul+ORU_UL_Latency) /
SYMBOL_PERIOD_mu1 =
at
= 4 Symbols
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
- 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:
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

t f do ed nt
CC_NUM_CTRL_PER_SYMBOL_UL[X] * CC_UL_CTRL_SYM_NUM_INDEX[X]
= 1104 words
No ra os de
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
6. For each CC, configure the memory pointers:

Register CONFIGURATION:
To configure the Core to operate at the max provisioned capability as set above
- CC0 : 100 MHz oBW, u=1
- CC1 : 100 MHz oBW, u=1
Uplink Control Offsets:

- CC0 operates at the base of the Buffer => CC_UL_CTRL_OFFSETS[0] = x0000
at
- For any further CCX is CC_UL_CTRL_OFFSETS[X] = CC_UL_CTRL_OFFSETS[X-1] +

+ CC_NUM_CTRL_PER_SYMBOL_UL[X-1] * CC_UL_CTRL_SYM_NUM_INDEX[X-1]
=> CC_UL_CTRL_OFFSETS[1] = 1104 = x0450
- Uplink Table to generate data requests:

=> CC_UL_BASE_OFFSET[0] = x0000
- For any further CCX is CC_UL_BASE_OFFSET[X] = CC_UL_BASE_OFFSET[X-1] + CC_NUMRBS[X-1]

=> CC_UL_BASE_OFFSET[1] = 275 = x0113
Downlink Control Offsets:
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
- CC0 operates at the base of the Buffer => CC_DL_CTRL_OFFSETS[0] = x0000
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
-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
Parsed Uplink CTRL (Sections) PUxCH BEAM ID Forward

CC0 CC0 CC0 CC0 CC1 CC1 CC1 CC1 Uplink Control
El is o
S0 S1 S2 S3 S0 S1 S2 S3 Management
CC_UL_CTRL_SYM_NUM_INDEX[0] = x0004
C
CC_UL_CTRL_OFFSETS[0] = x0000 CC_UL_CTRL_SYM_NUM_INDEX[1] = x0004

CC_UL_CTRL_OFFSETS[1] = x0450
PDxCH BEAM ID Forward

D
Parsed Downlink CTRL (Sections) Downlink

CC0 CC0 CC0 CC0 CC1 CC1 CC1 CC1 Control
PDxCH Symbol/RB ID
S0 S1 S2 S3 S0 S1 S2 S3 Management
AM
CC_DL_CTRL_SYM_NUM_INDEX[0] = x0004
D
CC_DL_CTRL_OFFSETS[0] = x0000
Parsed Downlink U-Plane Data CC0 CC0 CC1 CC1 PDxCH Symbol DATA
S0 S1 S0 S1
CC_DL_UNROLL_OFFSET[0] = x0000 CC_DL_DATA_SYM_NUM[0] = x0002
CC_DL_UNROLL_OFFSET[1] = x0476 CC_DL_DATA_SYM_START[0] = x0000
CC_DL_UNROLL_OFFSET[2] = x08EC CC_DL_DATA_SYM_NUM[1] = x0002
CC_DL_UNROLL_OFFSET[3] = x0D62 CC_DL_DATA_SYM_START[1] = x0002

at
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);
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
or R to ial
2. Configure Data and Control buffers.

t f do ed nt
Downlink DATA_Buffer:
No ra os de
assume T2a_max_up = 150 µs; T2a_min_up = 80 µs;

SYMBOL_PERIOD_mu0 = 71.43 µs
tDELAY_COMP_UP = T2a_max_up - T2a_min_up = 70 µs
do cl nfi
- Internal latency of a data packet in the oran_radio_if:

tDECAP = 5 µs

El is o
greater than)
C
CC_DL_DATA_SYM_NUM_INDEX[X] = (tDELAY_COMP_UP+tDECAP) /
SYMBOL_PERIOD_mu0 =
= 2 Symbols
D
AM
D

assume T2a_max_cp_dl = 200 µs; T2a_min_cp_dl = 170 µs;
tDELAY_COMP_CP_DL = T2a_max_cp_dl - T2a_min_cp_dl = 30 µs
- Time advance of the DL control messages wrt the data ones:

Tcp_adv_dl = T2a_min_cp_dl - T2a_min_up = 90 µs

greater than)
at
CC_DL_CTRL_SYM_NUM_INDEX[X] =
= (tDELAY_COMP_CP_DL+Tcp_adv_dl+tDECAP) /
SYMBOL_PERIOD_mu0 =
= 2 Symbols
Uplink CTRL_Buffer:
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
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
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
CC_NUM_CTRL_PER_SYMBOL_DL[0] * CC_DL_CTRL_SYM_NUM_INDEX[0]
= 1100 words
No ra os de
= 548 words
= 548 words
do cl nfi
Uplink CTRL_Buffer:
El is o
assume 275 RBs and 1 Section for each RB, all grouped in a single
packet
C
CC_NUM_CTRL_PER_SYMBOL_UL[0] = 275 + 1 = 276 words

D

CC_NUM_CTRL_PER_SYMBOL_UL[0] * CC_UL_CTRL_SYM_NUM_INDEX[0]
AM
= 552 words
D
= 276 words
= 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:
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:
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
8800 + 165 = 8965 Bytes = 1121 words
n
rib I ma tio
- CC1, CC2:
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
=> CC_UL_BASE_OFFSET[1] = 275 = x0113

=> CC_UL_BASE_OFFSET[2] = 412 = x019C
Downlink Control Offsets: => CC_DL_CTRL_OFFSETS[0] = x0000

do cl nfi
=> CC_DL_CTRL_OFFSETS[1] = 1100 = x044C

=> CC_DL_CTRL_OFFSETS[2] = 1648 = x0670
El is o
Downlink Data Buffer:

- CC0 operates at the base of Buffer, uses 2 Symbols
C

D
The Unroll pointer offsets are spaced to provide 1 Symbols worth of memory space
AM
D
=> CC_DL_DATA_UNROLL_OFFSET[0] = = x0000

=> CC_DL_DATA_UNROLL_OFFSET[1] = 1121 = x0461
=> CC_DL_DATA_UNROLL_OFFSET[2] = 2242 + 559 = 2801 = x0AF1

=> CC_DL_DATA_UNROLL_OFFSET[3] = 2801 + 559 = 3360 = x0D20
=> CC_DL_DATA_UNROLL_OFFSET[4] = 3360 + 559 = 3919 = x0F4F
=> CC_DL_DATA_UNROLL_OFFSET[5] = 3919 + 559 = 4478 = x117E
The following diagram depicts how the values calculated above apply to the memory
resources available in the core.
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
rib I ma tio
CC_UL_BASE_OFFSET[2] = x019C
CC2
CC_UL_BASE_OFFSET[1] = x0113 CC1 Uplink U-Plane PUxCH Requests
n te
ist rch Li ma
CC0
i o i tu
-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[2] = x033C CC_UL_CTRL_SYM_NUM_INDEX[2] = x0002
Parsed Downlink CTRL (Sections) Downlink Control PDxCH BEAM ID Forward

CC0 CC0 CC1 CC1 CC2 CC2
or R to ial
S0 S1 S0 S1 S0 S1 Management PDxCH Symbol/RB ID
CC_DL_CTRL_SYM_NUM_INDEX[0]
CC_DL_CTRL_SYM_NUM_INDEX[1]
= x0002
= x0002
CC_DL_CTRL_OFFSETS[1] = x044C
t f do ed nt
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
CC_DL_UNROLL_OFFSET[3] = x0D20 CC_DL_DATA_SYM_NUM[2] = x0002

CC_DL_UNROLL_OFFSET[4] = x0F4F CC_DL_DATA_SYM_START[2] = x0004
CC_DL_UNROLL_OFFSET[5] = x117E
X22879-111720
El is o
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);
IP Non-Processed O-RAN Messages

at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
and Control Systems (IEEE 1588)

El is o
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
AXI4-Lite Control Interface Ports

El is o
Table 15: AXI4-Lite Control Interface

C
Clock
Port Name I/O Description
Domain
D
s_axi_aclk I AXI4-Lite clock input. This is a continuous clock.

N/A
s_axi_aresetn I Active-Low asynchronous reset for the aclk domain.
AM
D
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 15: AXI4-Lite Control Interface (cont'd)
rib I ma tio
Clock
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
s_axi_rresp[1:0] O Read Response.

s_axi_rvalid O Read Data Valid.
s_axi_rready I Read Data Ready.
do cl nfi
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
demonstrators, etc. They can be accessed through the IP address map.

C
Table 16: Optional AXI4-Lite Control Interface

D
Clock
Domain
AM
D
Optional 8 bit bus that can be read via the IP

user_ro_in I register map. Inputs must be registered on
s_axi_aclk s_axi_aclk.
Optional 8 bit bus that can be written via the IP
user_rw_out O
register map. Outputs are registered on s_axi_aclk.
Framer (from Antenna) AXI4-Stream Interface Ports

at
Table 17: Framer (from Antenna) AXI4-Stream Interface
Port Name I/O Clock Description

Active-High reset for the framer data
fram_reset I Asynchronous
path.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 17: Framer (from Antenna) AXI4-Stream Interface (cont'd)
rib I ma tio
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

Active-High reset for the de-framer
defm_reset I Asynchronous data path. Retimed internally to all
relevant clock domains.
do cl nfi
High when reset is active in the internal

clock domain. Optionally, this signal
defm_reset_active O internal_bus_clk can be used to reset downstream logic.
El is o
The signal level can also be read using

the AXI4-Lite register bank.
C
m<S>_defm_data_tdata[63:0] O internal_bus_clk De-framer data output.

m<S>_defm_data_tkeep[7:0] O De-framer data used octets output.
D
m<S>_defm_data_tvalid O De-framer data valid

internal_bus_clk
m<S>_defm_data_tlast O De-framer data last.
AM
m<S>_defm_data_tready I De-framer data output ready.

D
Ethernet AXI4-Stream Interface Ports

Common
at
Table 19: Common

156.25 or 390.625 MHz. E = 0–3, one for each
tx<E>_eth_port_clk I N/A
Ethernet port enabled.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
From Framer to Ethernet
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
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
s<E>_eth_defm_tvalid I De-framer data valid.

s<E>_eth_defm_tlast I De-framer data last.
do cl nfi
De-framer input to be connected to the

s<E>_eth_mac_tuser I MAC TX TUSER output, which flags any
wrong packet.
De-framer input to be connected to the
El is o
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
some bit errors.

De-framer input to be connected to MAC
rx_ptp_tstamp_out[79:0] which holds the
s<E>_eth_mac_tstamp_out[79:0] I
D
timestamp value recorded at packet

reception.
De-framer input to be connected to MAC
AM
D
rx_ptp_tstamp_valid_out which indicates

s<E>_eth_mac_tstamp_valid I
when the received packet timestamp is
valid.
Internal Bus Ports

Table 22: Internal Bus
at

This is the clock used to drive the framer/de-framer
datapath. See the Throughput section for the
internal_bus_clk I N/A minimum value. When framer/de-framer antenna
counts are asymmetric, it should be set to meet the
highest bandwidth requirement.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 22: Internal Bus (cont'd)
rib I ma tio
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
Table 23: Message AXI4-Stream Interface

do cl nfi
m<E>_message_tdata[63:0] O Incoming message data output.

m<E>_message_tkeep[7:0] O Incoming message data used octets output.
m<E>_message_tvalid O Incoming message data valid.
El is o
internal_bus_clk
m<E>_message_tlast O Incoming message data last.
C
m<E>_message_ts_tdata[79:0] O Associated timestamp value.

m<E>_message_ts_valid O Associated timestamp is valid.
D
There is a message interface per enabled Ethernet port.

AM
D
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
O-RAN Parser Ports
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
the transport header.

m<E>_rtc_pc_id [15:0] O rtc/pcid.
m<E>_concat 1 O Concat bit.
do cl nfi
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
m<E>_subseqid [6:0] O Subsequence ID.

C
E-bit. Currently always 1 because

m<E>_ebit 1 O radio transport fragmentation is
not supported.
D
m<E>_payloadsize [15:0] O Payload size in bytes.

m<E>_packet_in_window 1 O Packet is valid in window.
AM
D
Advance arrival time of packet

m<E>_offset_in_symbol [11:0] O
expressed in symbol periods.
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Radio Application Header Interface Ports
n
rib I ma tio
Table 25: Radio Application Header Interface
Port Name Width I/O Clock Description
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.
or R to ial Index to the channel filter to be used.

m<E>_filterindex [3:0] O Passed to the PRACH processing
function out of scope.
m<E>_frameid [7:0] O Frame ID
t f do ed nt
m<E>_subframeid [3:0] O internal_bus_clk Subframe ID
Slot ID. Six bits are possible with the
m<E>_slotid [5:0] O
No ra os de
highest numerology.
First symbol number within the slot
m<E>_symbolid [5:0] O
to be considered.
do cl nfi
Compression method and bitwidth of

m<E>_udcomphdr [7:0] O IQ samples. Meaningful for uplink
data and PRACH packets.
Valid only for sectionType==3. Passed
El is o
m<E>_timeoffset [15:0] O to the PRACH processing function

out of scope.
C
Valid only for sectionType==3. Passed

m<E>_framestructure [7:0] O to the PRACH processing function
out of scope.
D
m<E>_cplength [15:0] O Field from header (sectionType==3).

AM
D
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Section Header Interface Ports
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
PRACH Beam ID Ports

C
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
Not all fields are expected to be required.

D
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
Carrier to be forwarded on the PRACH interface.
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 27: PRACH BID Interface
rib I ma tio
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_frame_structure [7:0] O internal_bus_clk Frame structure

m0_prach_cp_length [15:0] O Cyclic prefix length
Compression mode. This can be set in
do cl nfi
the core if static decompression is

used. If dynamic compression this is
expected to be filled by the oDU. This
m0_prach_udcomphdr [7:0] O
value is used internally in the PRACH
framing logic, so this value should be
El is o
used to correctly return the PRACH

data burst length.
C
m0_prach_rb 1 O RB bit
m0_prach_syminc 1 O Symbol inc
D
m0_prach_start_prbc [9:0] O Start PRB

m0_prach_num_prbc [7:0] O Number of PRBs
AM
D
m0_prach_remask [11:0] O RE mask

m0_prach_num_symbol [3:0] O Number of symbols
m0_prach_beamid [14:0] O Beam ID
m0_prach_freqoffset [23:0] O Frequency offset
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 22: PRACH BID Interface Ports
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
Table 28: Precode Interface

El is o

C
Precode data bus
[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
[113:99] beamID AP1

[128:114] beamID AP2
[143:129] beamID AP3
m_lte_precod_tvalid 1 O Data is valid

m_lte_precod_tlast 1 O Last data for current slot
m_lte_precod_tready 1 I Interface is ready to accept data
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Beam Weight Data Ports
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 29: Beam Weight Data Interface
rib I ma tio
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
6-62 are reserved

5 - Stream is SRS
4 - Stream is LTE
do cl nfi
internal_bus_clk 3 - Stream is PRACH

2 - Stream is SSB
1 - Stream is PUxCH
El is o
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
[0]id_word: Indicates that the

current beamweights_tdata holds
AM
D
the beginning of Word 0.

[1]bw_start: Signals that the current
beamweights_tdata holds the
beginning of Word 1.
[2]bw_position: In correspondence
of the last word in an extension
m<E>_beamweights_tuser [3:0] O indicates that only bytes 0-3 pertain
to that extension. If 0, all bytes
belong. If tuser[0] and tuser[2] are
both 1, then Word 0 for the next
at
extension starts from byte 4; If

tuser[1] and tuser[2] are both 1,
then Word 1 for the next extension
starts from byte 4.
[3] ext_type : 0 = Extension 1, 1 =
Extension 11.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
In case of Extension 1, the body of the extension is untouched in format by the
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
Figure 23: Beam Weight Data Interface

do cl nfi
El is o C
D
AM
D
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 24: Beam Weight Data Interface with Staggered View
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
[7:0] 1'b0, BeamID[14:8]

[15:8] BeamID[ 7: 0]
[23:16] bfwCompHdr
do cl nfi
[31:24] bfwCompParam/bfwXX bfwCompParam presence depends on the chosen

compression method.
[39:32] bfwXX
El is o
[47:40] bfwXX
C
[55:48] bfwXX
[63:56] bfwXX
D
Table 31: Ext 11, Word 1

AM
D
Position ORAN Field Additional Notes

[29:0] Reserved
[30] RAD
[31] disableBFWs
[39:32] numBundPrbs
[47:40] bfwCompHdr
at
[55:48] bfwCompParam/1'b0, BeamID[14:8] bfwCompParam presence depends on the chosen

compression method.
[63:56] 1'b0, BeamID[14:8]/BeamID[ 7: 0] If bfwCompParam is required, BeamID[ 7: 0]
occupies the less significant byte in Word 2.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Bypass/Raw Section Message Ports
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
-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
Figure 25: Unsupported Section Message Signaling

do cl nfi
El is o C
D
AM
D
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
Bypass/Raw Section Extension Message Ports

C-Plane messages that are processed by the core can contain multiple extension messages, some
that are not consumed by the core. In this case these extension messages will appear on this
interface where an external block must be able to accept data as it arrives.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 33: Unsupported Extension Interface
rib I ma tio
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.
The following timing diagram shows the signaling on this bus.

t f do ed nt
Figure 26: Unsupported Extension Message Signaling
No ra os de
do cl nfi
El is o C
D
AM
D
Uplink Early Beam ID Ports

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.
at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 34: Uplink Early BID Interface
rib I ma tio
[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
Downlink Early Beam ID Ports

AM
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.
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 35: Downlink Early BID Interface
rib I ma tio
[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
-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.
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
Uplink Beam ID Forward Ports

AM
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
Component carrier for this ID. Not all

m<S>_fram_bid_cc_id [7:0] O
bits are required.
Frequency offset, valid if a section
m<S>_fram_bid_frequency_offset [23:0] O
type 3 message was sent to this port.
El is o
Time offset, valid if a section type 3

m<S>_fram_bid_time_offset [15:0] O
C
message was sent to this port.

Frame structure, valid if a section
m<S>_fram_bid_frame_structure [7:0] O
type 3 message was sent to this port.
D
CP Length, valid if a section type 3

m<S>_fram_bid_cp_length [15:0] O
AM
m<S>_fram_bid_debug [107:0] O Factory debug port. Do not use.

D
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 29: Uplink Beam ID Forward Interface Timing
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
Assign to cc_ul_bidf_c_abs_symbol the smallest integer greater than (desired advance

time / symbol period).
Assign to cc_ul_bidf_c_cycles the difference (cc_ul_bidf_c_abs_symbol × symbol

do cl nfi
period – desired advance time).
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
the settings must also satisfy the two following conditions:
• 2 ≤ cc_ul_bidf_c_abs_symbol ≤ cc_ul_setup_c_abs_symbol
D
• If (cc_ul_bidf_c_abs_symbol = cc_ul_setup_c_abs_symbol), then cc_ul_bidf_c_cycles

AM
> cc_ul_setup_c_cycles
D
Downlink Beam ID Forward Ports

the beam former downlink U-plane data. The number of spatial streams is determined in the
signal name (<S>). The symbol is implied from the system timing. The O-RAN Radio IF core
at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 37: Downlink (PDxCH) Beam ID Forward Interface
rib I ma tio
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
Number of symbols to apply beamID15

m<S>_defm_bid_num_symbol [3:0] O
to.
m<S>_defm_bid_cc_id [7:0] O
do cl nfi
bits are required.

Frequency offset, valid if a type 3
m<S>_defm_bid_frequency_offset [23:0] O
El is o
Time offset, valid if a type 3 message was

m<S>_defm_bid_time_offset [15:0] O
sent to this port.
C
Frame structure, valid if a type 3

m<S>_defm_bid_frame_structure [7:0] O
CP Length, valid if a type 3 message was
D
m<S>_defm_bid_cp_length [15:0] O
sent to this port.
AM
D
Uplink U-Plane Data Ports

Table 38: PUxCH Request Output Interface

s<S>_fram_data_req[32:25] O udCompHdr for this section.
at
Request is valid. Single cycle pulse,

s<S>_fram_data_req[24] O
must be accepted.
s<S>_fram_data_req[23:15] O internal_bus_clk / Starting RB.
fram_logic_clock
s<S>_fram_data_req[14:7] O Number of RBs requested.
s<S>_fram_data_req[6:4] O Component carrier number.
s<S>_fram_data_req[3:0] O Unused (set to 0).
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
The s<S>_fram_data_req port is used as a request port.
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.
Figure 30: O-RAN Uplink Data Interface Timing

t f do ed nt
No ra os de
do cl nfi
El is o C
D
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 31: Uplink U-Plane Data Bus Signaling Mode
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
Downlink U-Plane Data Ports

Downlink U-Plane data (PDxCH) is passed per section. Additional data is passed out of band, to
route this data to the correct buffers downstream. The spatial stream (SS) is known from the
interface number. In the current release, the compression mode is known from the M-Plane, and
at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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).
or R to ial
[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
2 = Extension Type #5 holding only CSF1, ModComp

m<S>_defm_data_tuser[33:32] 2 O Scaler1 and ReMask1;
3 = both CSFs and ModComp Scalers are valid and
internal_bus_clk coming either from an Extension Type #5 holding 2
do cl nfi
scalers or from 2 different Extensions Type #4

associated to the same resource block (in the latter
case each ReMask holds the content of the
respective section field).
El is o
ModParamValid. When 1 the parameters apply to

m<S>_defm_data_tuser[31] 1 O the current RB. Currently on the second cycle of the
C
RB.
Defines the component carrier that the block of
data pertains to. The usable width depends on
D
m<S>_defm_data_tuser[30:27] 4 O number of component carriers defined in the IP.

Note. This is a major change to v3_0 to make this 4-
bits wide. The SOS Marker is now at bit 90.
AM
D
RB bit. 1 indicates RB data is for every other RB; if

m<S>_defm_data_tuser[26] 1 O set with 3 RBs of data starting at RB 6, the
subsequent 3 RBs are for RB 6, 8, and 10.
Defines the bit width used. These values can be set
using the M-Plane. See Register Space.
Defines the compression type used. These values
can be set using the M-Plane. See Register Space.
at
Defines the number of RBs to which the block of

data pertains.
Defines the starting RB to which the block of data
pertains. Valid values are 0–274.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
the respective section body.
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
to customize sharing of this logic.
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Related Information
n
rib I ma tio
Register Space
SSB Data Ports
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
m_ssb_data_tready I SSB data output ready.

do cl nfi
El is o C
D
AM
D
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
[33:32] == 2'd3).
Modulation Compression RE mask 1 (valid if [33] ==
-D ea iro for
'b1).
ut nst
m_ssb_data_tuser[49] 1 O Constellation Shift Factor 1 (valid if [33:32] != 2'd0).
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
Used as a Start of Symbol marker. Used to indicate

m_ssb_data_tuser[27] 1 O
the start of a symbol of RB sections.
RB bit. 1 indicates RB data is for every other RB; if
m_ssb_data_tuser[26] 1 O set with 3 RBs of data starting at RB 6, the
do cl nfi
subsequent 3 RBs are for RB 6, 8, and 10.

Defines the bit width used. These values can be set
using the M-Plane. See Register Space.
El is o
Defines the compression type used. These values

can be set using the M-Plane. See Register Space.
C
Defines the number of RBs to which the block of

data pertains.
Defines the starting RB to which the block of data
D
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 34: O-RAN SSB Data Interface
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
SSB Early Beam ID Ports

El is o
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
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 42: SSB Early BID Interface
rib I ma tio
[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)
-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.
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
SSB Beam ID Forward Ports

C
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 43: SSB Beam ID Forward Interface
rib I ma tio
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.
m_ssb_bid_cc_id [7:0] O
bits are required.
do cl nfi
m_ssb_bid_frequency_offset [23:0] O Frequency Offset

m_ssb_bid_time_offset [15:0] O Time Offset
m_ssb_bid_frame_structure [7:0] O Frame Structure
El is o
m_ssb_bid_cp_length [15:0] O Length of the cyclic prefix.

C
Figure 36: SSB Beam ID Interface

D
AM
D
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Uplink U-Plane Unsolicited Ports
n
rib I ma tio
Table 44: Uplink U-Plane Unsolicited Interface
n te
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
requested Ethernet port.
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
Figure 37: Uplink U-Plane Unsolicited Interface Timing Diagram

C
D
AM
D
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Uplink U-Plane PRACH Ports
n
rib I ma tio
Table 45: Uplink U-Plane PRACH Interface
n te
ist rch Li ma
s_fram_prach_tdata [63:0] I Data bus.
i o i tu
Bytes valid on this data beat. Only
s_fram_prach_tkeep [7:0] I
evaluated when tlast is set.
-D ea iro for
s_fram_prach_tvalid 1 I Data is valid.
ut nst
s_fram_prach_tlast 1 I Last data beat.
s_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_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
The s_fram_prach port is limited to one channel in this release.
Figure 38: Uplink U-Plane PRACH Interface Timing Diagram

El is o C
D
AM
D
When s_fram_prach_tvalid is asserted, a complete packet of data must be available to

be inserted into the core. When ready, the O-RAN Radio IF asserts
s_fram_prach_tready for one beat and accepts the s_fram_prach_tuser signal.
It then fetches the section data for the message, and internally requests access to the main
framer channels to the Ethernet core. When this access is granted,
s_fram_prach_tready is reasserted and all the data is read in and packetized in the core.
at
If a packet is requested with a non-matching section ID, Ru_Port_Id, and Component Carrier,
s_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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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

or R to ial
fram_radio_start_10ms
defm_radio_start_10ms
I
I
internal_bus_clk
10 ms strobe for fram symbol timer.
10 ms strobe for defm symbol timer.
t f do ed nt
Note: These continuous strobes provide control over the internal symbol timers. They should be aligned
externally to the system time of day.
No ra os de
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 47: Timer Ports
rib I ma tio
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
DL Ctrl Time Advance Current Symbol

m<C>_dl_cta_sym_num [11:0] O
Number. As UL.
m<C>_dl_update 1 O DL Current symbol updated.
do cl nfi
Flips level on DL Current symbol updated.

m<C>_dl_toggle 1 O Use for external scope debug/
measurement.
El is o
DL Increment Current Symbol Number

m<C>_dl_symbol_inc 1 I
(optional).
C
m<C>_cc_enable 1 O Flag indicating CC is enabled.

Strobe indicating CC has just been
m<C>_cc_reload 1 O
reloaded.
D
AM
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
The width of the timing interfaces (ocp_dl_update) and (ocp_ul_update) is dependent on
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
Port Name Width I/O Description
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
Table 49: Downlink U-Plane Interface

do cl nfi
m_dl_ft_tdata NUM_ANTENNA/ O ft_aclk 32-bit samples for (NUM_ANTENNA/

INTERLEAVE INTERLEAVE) antennas aligned on 32-bit
boundaries. The data is valid when
El is o
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
m_dl_ft_tid 8 O ft_aclk Carries information on the identity of the CC

that is currently being output, and which
antennas the data pertains to.
AM
D
• Bits 7:4: CC ID for the current data packet.

• Bits 3:0: Antenna interleave phase.
m_dl_ft_tready 1 I ft_aclk A High indicates to the OCP block that it can
send data.
Uplink U-Plane Interface

at
Table 50: Uplink U-Plane Interface

s_ul_ft_tdata NUM_ANTENNA/ I ft_aclk 32-bit samples for (NUM_ANTENNA/INTERLEAVE)
INTERLEAVE antennas aligned on 32-bit boundaries. The data
is valid when s_ul_ft_tvalid is High.
s_ul_ft_tvalid 1 I ft_aclk The signals are valid when the s_ul_ft_tvalid
output is asserted.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 50: Uplink U-Plane Interface (cont'd)
rib I ma tio
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
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
• Bit 0: DL symbol updated. This can be

driven by the m<C>_dl_update output of the
IP core.
do cl nfi
ocp_ul_update NUM_CC*2 I internal_bus_clk Uplink timing information. This input 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.
El is o
• Bit 0: UL symbol updated. This can be

driven by the m<C>_ul_update output of the
C
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
at
Example System
The O-RAN Radio IF example system, which is generated by block automation, is composed of
the following main blocks:
• O-RAN Radio IF IP core

• One 10G/25G High Speed Ethernet Subsystem instantiated per physical port
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
• 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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 4: Designing with the Core
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.
Recognize Timing Critical Signals

do cl nfi
The constraints provided with the example design identify the critical signals and timing
El is o
constraints that should be applied.

C
Make Only Allowed Modifications

D
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
Table 52: Clocks
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
1588 Timer Synchronization

or R to ial
Throughput
t f do ed nt
Resets
No ra os de
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
Table 53: O-RAN Radio IF Reset Ports

D
Reset Signals Clock Domains

AM
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 39: Internal Reset Distribution
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
De-Framer Ethernet De-Framer Internal

t f do ed nt
Clock Domain Clock Domain
No ra os de
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 40: Top Level Block Diagram
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
• Processor (zynq_ultra_ps_e_0): Arm® processor hard block.

No ra os de
• 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
• 1588 timer 250 MHz clock

• Framer and de-framer antenna clocks
D
• Internal O-RAN Radio IF datapath clock

AM
D
• 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
• LED Driver (led_driver_0): Drives status LEDs for user feedback.
• 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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
TX/RX DMA Logic

do cl nfi
El is o
AXI4-Lite Configuration IF AXI4-Stream Data IF AXI4-Lite FIFO IF

C
X20852-012720
• oran_radio_if: The O-RAN Radio IF IP core under demonstration.

D
• 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
an external I/O connection; in reality, your logic will.
• 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.
• xxv_ethernet_0: 10G/25G High Speed Ethernet Subsystem.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
• 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
1588 Timer Synchronization

AM
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 42: 1588 Timer Synchronization Diagram
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
DIP Clock Select DIP Clock Select

do cl nfi
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
the use of an external VCXO.
Running Block Automation in IP Integrator

The system can only be delivered in IP integrator using Block Automation. See Vivado Design
Suite User Guide: Designing IP Subsystems using IP Integrator (UG994) for more information about
at
using IP integrator.
Block Automation Options

The following options are currently supported by the O-RAN Radio IF core.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
Custom Flows Using Tcl

C
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

AM
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 5: Design Flow Steps
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
Customizing and Generating the Core

do cl nfi
This section includes information about using AMD tools to customize and generate the core in
El is o
the AMD Vivado™ Design Suite.

C
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:
1. Open a block design in IP integrator.

at
2. Add the IP core to the canvas from the IP catalog.

3. Double-click the selected IP core or select the Customize IP command from the toolbar or
right-click menu.
4. Optionally run Block Automation to generate the example system.
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).
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
Ethernet rate Selects the Ethernet serial data rate.

El is o
Mode Settings
C
Table 56: Mode Settings
Option Description
D
When TRUE, the de-framer receives frequency domain

samples, and TLAST must be generated on AXI4-Stream
AM
D
interfaces to mark the end of each symbol. Both the framer

Frame data as Frequency domain symbols
and the de-framer can operate in this mode. The core does
not support the time domain and frequency domain in
opposite directions.
De-Framer - Ethernet to Antenna Datapath (Downlink)
Table 57: De-Framer - Ethernet to Antenna Datapath (Downlink)

at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Framer - Antenna to Ethernet Datapath (Uplink)
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
UL CTRL Delay buffer size in 1K entries

calculation, refer to Control Buffers.
Size of downlink control delay buffer. For buffer size
DL CTRL Delay buffer size in 1K entries
calculation, refer to Control Buffers.
do cl nfi
Size of downlink data delay buffer. For buffer size

DL Data Delay buffer size in 1K entries
calculation, refer to Downlink Buffers.
Maximum number of symbol entries in the buffer pointer
El is o
DL Data Delay buffer pointers table. This is shared among all component carriers and
must be sized for your worst case.
C
Maximum number of symbols to fit into the reception

window for the core, based on the highest numerology
Max number of CTRL Symbols component carrier to be used. For example, if the reception
window is 100 μs and the highest numerology is 2, with a
D
symbol time of 17.84 μs, rnd(100/17.48) = 6 symbols.

Period in PS of internal_bus_clk. Used by the numerology
Timer clock period in PS
AM
timers.
D
Sets the maximum number of sections managed by PRACH

Max Section Messages for all PRACH SS
Section Type #3 C-Plane messages.
SSB CTRL Delay buffer size in 0.5K entries Size of SSB CTRL delay buffer.
SSB Data Delay buffer size in 0.5K entries Size of SSB Data delay buffer.
General Settings Tab

at
Table 60: General Settings Tab
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
11 messages with Beamweights. Supported values are 8, 16,

32, and 64. The default is 64.
Set memory type used by the CIRC XPM Allows you to force Vivado to use block RAM or URAM for
El is o
the CIRC. Auto is the default

Enable a 10ms strobe input per CC Allows you to drive a 10 ms strobe to each CC.
C
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
the Circular buffer used to manage traffic arriving

concurrently for the same spatial stream on different
AM
Ethernet ports. Generally, this should be 256. The low

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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
DL Ctrl Delay buffer size in 1K entries Xran_Max_Dl_Ctrl_1kWords 2

DL Data Delay buffer size in 1K entries Xran_Max_Dl_Data_1kWords 2
do cl nfi
DL Data Delay buffer pointers Xran_Max_Dl_Data_Pointers 5

Max number of CTRL Symbols Xran_Max_Ctrl_Symbols 13
Timer clock period in PS Xran_Timer_Clk_Ps 2500
El is o
Max Section Messages for all PRACH SS Xran_Prach_Sections 16

C
SSB Ctrl Delay buffer size in 0.5K entries Xran_Max_SSB_Ctrl_512Words 1

SSB Data Delay buffer size in 0.5K entries Xran_Max_SSB_Data_512Words 2
Enable internal core decompression logic on PDxCH Defm_Decomp_In_Core 0
D
Enable internal core Compression logic on PUxCH Fram_Comp_In_Core 0

AM
Swap sample order for internal DeCompression Comp_Decomp_Uc_Swap 0

D
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
Set Unsolicited data ports Xran_Unsol_Ports_Fram 1

Default antenna count to use for Ext 11 Ext11_AntCnt_Default 64
Set memory type used by the CIRC XPM Circ_Xpm_Mem_Type auto
Enable a 10 ms strobe input per CC Individual_10ms_Strb_Enable 0
Use Radio Clock in UL datapath Use_Frame_Clock 0
Set the depth of the CIRC Meta Table Circ_Meta_Table_Depth 256
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
This section is not applicable for this IP core.

do cl nfi
Device, Package, and Speed Grade Selections

El is o

C
Clock Frequencies
D

AM
D
Clock Management
Clock Placement

at
Banking
Transceiver Placement
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
I/O Standard and Placement
n
rib I ma tio
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: Example Design
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:
1. No uplink data is sent unless a corresponding Type 1 or 3 message is received.

do cl nfi
2. The Ethernet interface should not be connected in loopback.

3. All O-RAN packets are windowed by the sub-frame, slot, and symbol numbers they carry.
El is o
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix A: Upgrading
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix B: Debugging
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
Finding Help with AMD Adaptive Computing

C
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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.
Master Answer Record for the Core

t f do ed nt
AR 73648.
No ra os de
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
• Customize the solution beyond that allowed in the product documentation.

• Change any section of the design labeled DO NOT MODIFY.
D
To ask questions, navigate to the Community Forums.

AM
D
Debug Tools
There are many tools available to address O-RAN Radio IF design issues. It is important to know
at
which tools are useful for debugging various situations.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Vivado Design Suite Debug Feature
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
• Zynq UltraScale+ MPSoC ZCU102 Evaluation Kit

• Zynq UltraScale+ RFSoC ZCU111 Evaluation Kit
do cl nfi
El is o
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
• FRAM_PROTOCOL_DEFINITION: Specify if O-RAN packets are encapsulated either over
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:
1. Activate the DEFM_SNAP_SHOT, and read the ETH_STATS_TOTAL_RX_GOOD_PKT_CNT,

No ra os de
ORAN_RX_TOTAL counters:
• if only the former is improving, then also the O-RAN packets are not being recognized and
do cl nfi
they are being forwarded to the embedded processor;

• if ETH_STATS_TOTAL_RX_BAD_PKT_CNT improves, then the packets are declared not
acceptable by the MAC;
El is o
• if either ORAN_RX_CORRUPT or ORAN_RX_ERROR_DROP are improving, this means

C
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
either the DMA or the driver itself get overflowed.

3. Finally, by probing the mX_message interface on the core output, the full packets coming out
of the filter can be visualized.
The following step consists in confirming that all incoming O-RAN packets are arriving within the
respective reception windows. Several actions are available:
at
1. Snapshot and read the ORAN_RX_ON_TIME, ORAN_RX_EARLY, ORAN_RX_LATE, as well

the same control specific counters; remember that all packets being counted as either
"too_early" or "too_late" cannot be forwarded and are dropped.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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
4. Moreover, it could also be useful to probe the following signals:

• dl_sym_num: Internal counter for the symbol number. It is used also to address the
segment whose content has to be read out of the SS outputs at any symbol period. It
do cl nfi
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
• dl_cta_sym_num: Counter that is actually used to determine if a C-Plane message is

arriving in its proper Reception Window or if it is late. Then by measuring the time
between the beginning of each value on such a counter with respect to the beginning of
D
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
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_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
design and that all constraints were met during implementation.

AM
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
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix C: Application Software Development
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.
Figure 43: O-RAN Radio IF Software Stack Architecture

or R to ial
External Application/User Interface
t f do ed nt
No ra os de
do cl nfi
Message Parsing Communications

Protocol Module
Module Module
PTP
O-RAN Radio Application
Application
El is o
C Library API
C
D
AM
D
Libmetal
User Space
Kernel Space
at
10/25G
1588 Timer
Ethernet UIO Driver
X20872-111720
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix C: Application Software Development
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
(eCPRI) and command line and socket-based message interfaces.

El is o C
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
• Message Parsing Module: This module demonstrates how a human-readable message

protocol can be used to configure and control the O-RAN Radio IF. It provides interfaces to
the hardware API library and any protocol modules.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix D: O-RAN Support Matrix
Appendix D
n
rib I ma tio
n te
ist rch Li ma
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
arrival advance time for each packet. This period is always a

4.4 Latency Requirements
multiple of the symbol period in the chosen numerology.
Only packets bearing a symbol number included in the
current reception window can be buffered.
El is o
The minimum acceptable TCP_ADV_DL (advance time of

downlink C-Plane packets with regard to U-Plane) and
C
4.4.3 U-Plane / C-Plane Timing

T2A_MIN_CP_UL (advance time of uplink C-Plane packets
with regard to the antenna) are both programmable.
Actual network delay measurement is supported through
D
4.4.4.2 Fronthaul Timing Domain eCPRI Type 5 messages relying on proper timestamping at
Ethernet transceivers.
AM
Supported through uplink unsolicited traffic ports, which

D
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
4.6 Transmission windows Only Normal transmission is currently supported.

5.1.1 Ethernet Encapsulation Supported.
5.1.2 IP/UDP Encapsulation Supported.
5.1.3.2 eCPRI Transport Header Supported.
5.1.3.2.4 ecpriConcatenation Value of 1 is currently not supported.
Supported. Message types 0 and 2 are fully supported in
5.1.3.2.5 ecpriMessage
hardware; type 5 is supported by the processor software.
5.1.3.2.6 ecpriPayload Supported.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 62: O-RAN Support Matrix (cont'd)
rib I ma tio
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
Supported through the programmable filtering of received

5.4 Data Flow ID messages. The merging of packets to be transmitted is
outside of the scope of the core.
do cl nfi
5.5.2 Application Layer Fragmentation Supported on PDxCH/PUxCH channels only.

5.5.3 Radio Transport Layer Fragmentation Not currently supported.
7.1.1 C-Plane Transport Supported.
El is o
Scheduling and beamforming for user traffic and PRACH

7.2.1 Scheduling and beamforming
C
data are supported.

7.2.2 Symbol Numbering and Duration Currently, only 5G-NR is supported.
Mixed numerology is currently not supported in a single CC
D
for OCP. Each CC can be assigned its own numerology and

number of sub-carriers grouped in RBs. In case Section Type
3 messages are used, the Frequency Offset associated to
AM
D
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
block on a dedicated interface.

7.2.5 LAA Commands Not supported.
Supported only through dedicated endpoints, Section
7.2.6 Dynamic Spectrum Sharing
Extension 9 not currently supported.
Channel Information based
7.2.7 Not supported.
beamforming
7.2.8 ACK/NACK Procedure Not supported.
Section Type 4: Slot Configuration
Control
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
rib I ma tio
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.
7.5.2.6 slotId
t f do ed nt
7.5.2.7 startSymbolId
No ra os de
Supported. The user can define the maximum number of

7.5.2.8 numberOfsections
sections per symbol in the register map.
Partially supported; Section Types 0, 1, and 3 are managed
7.5.2.9 sectionType within the core, other section types are transferred to the
do cl nfi
Raw Section message interface

Dynamic definition of user data compression header for UL
sections is supported.
7.5.2.10 udCompHdr
El is o
Note: This is supported as per CUS specification v6.00.

C
7.5.2.11 numberOfUEs Not supported.

Supported: the value carried in the field is presented at UL
7.5.2.12 timeOffset and DL BID forward interfaces for Section Type 0 and 3
D
control messages.
Assignment of numerology through Sub Carrier spacing sub
AM
7.5.2.13 frameStructure
D
field is not supported yet.

Supported: the value carried in the field is presented at UL
7.5.2.14 cpLength and DL BID forward interfaces for Section Type 0 and 3
control messages.
7.5.2.15 ciCompHdr Not supported.
Section Type 4 related parameters are not currently
7.5.2.16-7.5.2.18
supported.
Supported. Uplink sectionIDs carried in the C-Plane packets
at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
rib I ma tio
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
7.7.1 SE 1: Beamforming weights Supported.

Not specifically supported: the content of the extension
7.7.2 SE 2: Beamforming attributes together with the section description fields are available on
El is o
the unsupport_ext interface.

Supported: m_lte_precod interface includes all the
C
7.7.3 SE 3: DL precoding parameters transported parameters to feed a proper used defined

precoding block.
Supported: the CSF and Modulation Compression scaler are
D
presented at the DL U-Plane Data Ports together with the

SE 4: Modulation compression reMask inserted in the section. Also the case of 2 Extensions
7.7.4
parameters Type 4, attached to two different sections holding
AM
D
complimentary reMasks for the same radio resources is

handled.
SE 5: Modulation compression Supported only for one and two scaler values and
7.7.5
additional parameters modulation compression parameters.
7.7.6 SE 6: Non-contiguous PRB allocation Not supported.
7.7.7 SE 7: eAxC mask Not supported.
7.7.8 SE 8: Regularization factor together with the section description fields are available on
at

7.7.9 SE 9: Dynamic Spectrum Sharing together with the section description fields are available on
SE 10: Section description for group
configuration of multiple ports
Fully supported, including the case of numBundPrb =
7.7.11 SE 11: Flexible beamforming weights
numPrb, with and without included beamweights.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
rib I ma tio
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
Support for compression method associated with each

section in DL U-Plane messages is not yet available, but you
can specify compression method per Spatial Stream.
El is o
8.1.3 Digital Power Scaling Out of scope for the fronthaul core.
C
8.2.1 IQ Data Transfer procedure Supported.

IQ Data Transfer Procedure without C- Fully supported in downlink. Applicable in UL through
8.2.2.
Plane unsolicited ports.
D
8.3.2 DL/UL Data Supported.

Supported. 8.3.3.15–8.3.3.19 dynamic definition of the
AM
UL/DL Data Coding of Information

D
8.3.3 compression method and selective RE sending mask are not

Elements
yet supported for DL U-Plane messages.
To ease the implementation of LTE precoding, the core is
able to present in advance with respect to the start of each
slot the information collected from the Extension Type 3,
8.3.4 DL Data Precoding
attached to the C-Plane messages, including the Beam IDs
and to deliver each layer data stream mapping them onto
one or more data stream outputs.
User data channel packet encapsulation available also for
at
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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 63: Mandatory and Optional Features
rib I ma tio
O-RU Category Cat-A RU Supported; up to 20 spatial streams.

Support
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.
Fixed point (no compression) Supported, any bit width.

t f do ed nt
9, 12 & 14 supported in core. The core can be generated
without compression/decompression logic for the user to
No ra os de
add (de)compression logic.

Block floating point 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
Block scaling compression Not supported.

mu-law compression Not supported.
El is o
1/2/4 bit unpacking on PDxCH. Ext4/5 carried information

C
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
Modulation compression + selective RE

Not supported.
sending
AM
D
Presence of udCompLen Not supported.

Real-time variable bit-width Not yet fully supported.
Real-time variable bit-width per
Supported per Spatial Stream, not per data section.
Channel
Static configuration of U-Plane IQ
Supported.
format
Beamspace compression Supported within Extension Type 1 and 11
at
Use of symInc Not supported.

Coupling via Frequency and Time Supported but without priorities.
PRACH data transfer without C-Plane Partially supported (mostly to be designed by the user)
SRS data transfer without C-Plane Supported as unsolicited UL traffic.
Energy Savings Transmission blanking Only Section Type 0 messages per each eAxC are supported.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
Table 63: Mandatory and Optional Features (cont'd)
rib I ma tio
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
Application layer Fragmentation Supported.

Radio Transport fragmentation Not supported.
Section Type 0 Supported in core.
do cl nfi
Section Type 1 Supported in core.

Section Types Section Type 3 Supported in core.
Not supported in core, available on Bypass/Raw Section
El is o
Others
port.
C
Type 1 Supported in core.

D
Extension Types
AM
D
Others Available on Bypass/Raw Section Extension port.

LAA LBT O-DU Congestion Window
Not supported.
mgmt
Other features LAA LBT O-DU Congestion Window
Not supported.
mgmt
Others Not supported.
at
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix E: Additional Resources and Legal Notices
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
Finding Additional Documentation

do cl nfi
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:
• From the AMD Vivado™ IDE, select Help → Documentation and Tutorials.

• On Windows, click the Start button and select Xilinx Design Tools → DocNav.
• At the Linux command prompt, enter docnav.
at
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:
• In DocNav, click the Design Hubs View tab.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
• Go to the Design Hubs webpage.
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
9. Vivado Design Suite User Guide: Getting Started (UG910)

10. 10G/25G High Speed Ethernet Subsystem Product Guide (PG210)
El is o
11. AXI DMA LogiCORE IP Product Guide (PG021)

C
12. AXI Interconnect LogiCORE IP Product Guide (PG059)

13. JTAG to AXI Master LogiCORE IP Product Guide (PG174)
D
AM
D
Revision History
The following table shows the revision history for this document.
Section Revision Summary

at
05/17/2023 Version 3.0

Entire document Updated references to new ORAN v11.0 specification.
Features Added bullet for optional ORAN channel processing block.
Chapter 3: Product Specification Updated figures.
eAxC_ID • Updated title.
• Added Mode 1, 2, and 3 examples.
O-RAN Window – Multi O-DU Ring Buffer Added figure.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
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
Control Buffers Added clarification on numPrb=numBundPrb.

Performance Counters Updated table descriptions.
do cl nfi
Uplink Datapath • Added UL padding note.

• Updated ORAN specification table details.
PRACH Beam ID Ports Added new port.
El is o
Uplink Beam ID Forward Ports Updated ports.

C
Uplink U-Plane Data Ports Updated ORAN specification table details.

Downlink U-Plane Data Ports Improved description of modulation compression scaler
support also to document the new introduced feature of the
D
double Extension type #4 support.

Downlink Beam ID Forward Ports Added type 0 note.
AM
D
Uplink U-Plane PRACH Ports Added clarification on interface data.

Uplink Beam ID Forward Ports Added type 0 note.
General Settings Tab Updated parameter descriptions.
User Parameters Updated parameters.
Hardware Debug Added debug notes and updated links.
Appendix D: O-RAN Support Matrix • Added note on Dynamic Compression support in CUS
version.
at
• 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.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
•
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
Uplink Datapath Updated oRU block description.

Configuring the Core Updated section.
Reconfiguring the Core Updated section.
do cl nfi
Throughput Updated clock note.

Beam Weight Data Ports Added Ext 11 description.
Uplink Beam ID Forward Ports Added m<S>_fram_bid_debug to Uplink (PUxCH) Beam ID
El is o
Forward Ports table and updated cc_ul_bidf_c_cycles.

C
Uplink U-Plane Data Ports Updated timing diagrams.

O-RAN Settings Tab Added Guidance Numerology.
General Settings Tab Updated table.
D
Sample Application Removed eCPRI Protocol Module.

AM
Appendix D: O-RAN Support Matrix Updated IPv4 and Type 11 descriptions.

D
07/15/2021 Version 2.0

Beam Weight Data Ports Updated table.
06/16/2021 Version 2.0
General updates Updated for v2.0.
• Bypass/Raw Section Extension Message Ports Added new topics under Port Descriptions.
• Precode Ports
at
• Uplink U-Plane Data Ports Updated diagrams.

• Downlink U-Plane Data Ports
• Number of Symbols Required
• Chapter 3: Product Specification
• Beam Weight Data Ports
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
n
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
06/03/2020 Version 1.0

Initial Xilinx release. N/A
do cl nfi
Please Read: Important Legal Notices

El is o C
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
CONTENTS HEREOF AND ASSUMES NO RESPONSIBILITY FOR ANY INACCURACIES,

ERRORS, OR OMISSIONS THAT MAY APPEAR IN THIS INFORMATION. AMD SPECIFICALLY
DISCLAIMS ANY IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, OR
FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL AMD BE LIABLE TO ANY
PERSON FOR ANY RELIANCE, DIRECT, INDIRECT, SPECIAL, OR OTHER CONSEQUENTIAL
DAMAGES ARISING FROM THE USE OF ANY INFORMATION CONTAINED HEREIN, EVEN IF
AMD IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
PG370 (v3.0) May 17, 2023

Send Feedback
AMD CONFIDENTIAL
AUTOMOTIVE APPLICATIONS DISCLAIMER
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
may be trademarks of their respective companies.

do cl nfi
El is o C
D
AM
D
at
PG370 (v3.0) May 17, 2023

Send Feedback

Pg370 Oran Radio If WTMKX

Uploaded by

Copyright:

Available Formats

You might also like

Pg370 Oran Radio If WTMKX

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pg370 Oran Radio If WTMKX

Uploaded by

Copyright:

Available Formats

AMD CONFIDENTIAL

O-RAN Radio Interface v3.0

AMD Adaptive Computing is creating an environment where

Chapter 4: Designing with the Core................................................................... 98

Chapter 5: Design Flow Steps...............................................................................107

Customizing and Generating the Core................................................................................. 107

Chapter 6: Example Design................................................................................... 114

PG370 (v3.0) May 17, 2023

Appendix E: Additional Resources and Legal Notices............................131

Finding Additional Documentation.......................................................................................131

Please Read: Important Legal Notices................................................................................. 135

PG370 (v3.0) May 17, 2023

• Provides O-RU (O-RAN radio unit) function only.

PG370 (v3.0) May 17, 2023

O-RAN Support Matrix

PG370 (v3.0) May 17, 2023

Design Entry AMD Vivado™ Design Suite

Synthesis Vivado Synthesis

Release Notes and Known Issues Master Answer Record: 73648

Support web page

1. For a complete list of supported devices, see the Vivado IP catalog.

3. A -2 or faster speed grade is required for 25G operation.

PG370 (v3.0) May 17, 2023

submodule within an implementation of a 5G RRU.

Figure 1: Top Level Overview

O-RAN RADIO UNIT (O-RU)

O-RAN Radio Interface

1588 Timing Synchronization

PG370 (v3.0) May 17, 2023

Control Systems (IEEE 1588), and on Synchronous Ethernet.

PG370 (v3.0) May 17, 2023

• Customizing and Generating the Core

• Chapter 6: Example Design

O-RAN Support Matrix

PG370 (v3.0) May 17, 2023

check IP license level.

Table 1: Ordering Information

Description Part Number License Key

PG370 (v3.0) May 17, 2023

or R to ial 1 dedicated PRACH channel, with O-RAN framing

1– Ethernet Processing Pipelines

Ethernet eCPRI/1914.3 21 to 1 PUxCH Section Request PUxCH Data

Optional fram_logic_clk Domain

2048 FlowId Table

oDU Dest/Vlan lookup

1– Ethernet Processing Pipelines

Ethernet Packet Filter O-RAN Multi O-DU Ring

FIFO Parser Buffer (CIRC) 4 to X Pipelined PDxCH C-Plane PDxCH Control

PDxCH U-Plane PDxCH BFP9/12/14

Multi CC Symbol Buffer DataMgr Mod1/2/4

PUxCH Early BID

Arm Networking Trans/oran/section

PRACH BID List

PG370 (v3.0) May 17, 2023

Figure 4: Core Block Diagram with OCP

1 dedicated PRACH channel, with O-RAN framing

Optional fram_logic_clk Domain

1– Ethernet Processing Pipelines