pg434 Rfsoc Dfe Ofdm - WTMKX

AMD CONFIDENTIAL
RFSoC DFE Orthogonal
ta n o
Frequency Division
a
hi ati
l
Multiplexing v2.0
m
n
-D OT nth for
c
LogiCORE IP Product Guide
Re CD ika In
n
io
or t sr ial
ut
PG434 (v2.0) October 18, 2023
t f a to nt
rib
d ide
ist
se f
lo on
sc C
Di D
AM
No
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
ta n o
a
hi ati
l
Table of Contents
m
n
-D OT nth for
Chapter 1: Introduction.............................................................................................. 4
Features........................................................................................................................................ 4
c
IP Facts..........................................................................................................................................5
Re CD ika In
n
io
Chapter 2: Overview......................................................................................................6
or t sr ial
Core Overview..............................................................................................................................6
ut
Applications..................................................................................................................................8
Unsupported Features................................................................................................................8
t f a to nt
rib
Licensing and Ordering.............................................................................................................. 8
d ide
Chapter 3: Product Specification........................................................................... 9

ist
Standards..................................................................................................................................... 9
Performance................................................................................................................................ 9
se f
lo on
Port Descriptions.......................................................................................................................11
Chapter 4: Designing with the Core................................................................... 17

sc C
General Design Guidelines.......................................................................................................17

Clocking...................................................................................................................................... 18
Di D
Resets..........................................................................................................................................18
Protocol Description................................................................................................................. 18
AM
Chapter 5: Design Flow Steps.................................................................................37

Customizing and Generating the Core................................................................................... 37
No
Constraining the Subsystem....................................................................................................39

Simulation.................................................................................................................................. 40
Synthesis and Implementation................................................................................................40
Chapter 6: C Model....................................................................................................... 41
Features......................................................................................................................................41
Overview.....................................................................................................................................41
Unpacking and Model Contents..............................................................................................41
Installation................................................................................................................................. 42
PG434 (v2.0) October 18, 2023

Send Feedback
RFSoC DFE OFDM IP 2
AMD CONFIDENTIAL
ta n
C Model Interface...................................................................................................................... 43
Compiling and Linking..............................................................................................................50
o
MATLAB Interface......................................................................................................................51
a
hi ati
l
Chapter 7: Example Design..................................................................................... 55
m
Overview.....................................................................................................................................55
n
Running the Example Design.................................................................................................. 56
-D OT nth for
Stimulus Generation and Data Logging................................................................................. 57
Modifying the Example Program............................................................................................ 61
c
Re CD ika In
n
Appendix A: Upgrading............................................................................................. 62
io
Appendix B: Debugging.............................................................................................63
or t sr ial
ut
Finding Help with AMD Adaptive Computing Solutions.......................................................63
Debug Tools............................................................................................................................... 64
t f a to nt
rib
Hardware Debug....................................................................................................................... 65
d ide
Appendix C: Application Software Development....................................... 66
ist
Overview.....................................................................................................................................66
Data Structures..........................................................................................................................90
se f
lo on
Appendix D: Additional Resources and Legal Notices........................... 100

Finding Additional Documentation.......................................................................................100
sc C
Support Resources.................................................................................................................. 101

References................................................................................................................................101
Revision History....................................................................................................................... 101
Di D
Please Read: Important Legal Notices................................................................................. 101

AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
RFSoC DFE OFDM IP 3
AMD CONFIDENTIAL
Chapter 1: Introduction
Chapter 1
ta n o
a
hi ati
l
Introduction
m
n
-D OT nth for
The RFSoC DFE Orthogonal Frequency Division Multiplexing (OFDM) AMD LogiCORE™ IP
performs translations from the frequency domain to the time domain and vice versa using the
c
RFSoC FFT primitive. The IP core is configurable to support up to eight antennas and an antenna
Re CD ika In
n
interleave of one, two, or four. A software API permits up to eight component carriers (CCs) to be
dynamically aggregated on a particular antenna. The IP core performs partial mapping/de-
io
mapping of sub-carriers, FFT/IFFT conversion, scaling, and cyclic prefix insertion/removal. Both
or t sr ial
downlink and uplink modes of operation are supported. In the downlink mode, the RFSoC DFE
ut
OFDM IP core takes OFDM symbols as packets for each antenna and component carrier, and
then outputs them in the time domain, performing an IFFT for each CC and antenna. The reverse
t f a to nt
rib
process occurs on the uplink. An AXI4-Lite interface is provided for configuration and control
through software APIs. The interfaces are compatible with other RFSoC DFE IP cores (for
d ide
example DFE channel filter, DFE DUC-DDC mixer) to allow complete signal chain to be built
ist
directly in AMD Vivado™ IP integrator.
se f
lo on
Features
sc C
The following features are applicable for both uplink and downlink modes.
Di D
• Supports a maximum sampling rate of 491.52 MSPS

• Supports up to eight component carriers (CCs), both LTE and 5G-NR
AM
• Supports subcarrier spacing (SCS) of 15 kHz, 30 kHz and 60 kHz (FR1 in 5G-NR)
• Supports 512, 1K, 2K, and 4K FFT sizes
No
• Supports up to eight downlink or uplink paths (or antennas)

• Uses 16-bit data interfaces for each I or Q sample
• Enables CC programming via a processor (AXI4-Lite) interface
• Provides an indication of overflow of the CC buffer via a status register
• Delay matches the TUSER information accompanying the data through the IP core
PG434 (v2.0) October 18, 2023

Send Feedback
RFSoC DFE OFDM IP 4
AMD CONFIDENTIAL
Chapter 1: Introduction
ta n
IP Facts
o
a
hi ati
AMD LogiCORE™ IP Facts Table
l
Core Specifics
m
Supported Device Family1 AMD Zynq™ UltraScale+™ RFSoC DFE
n
Supported User Interfaces AXI4-Stream, AXI4-Lite
-D OT nth for
Resources Performance
Provided with Core
c
Design Files Encrypted RTL
Re CD ika In
n
Example Design Verilog (simulation only)
io
Test Bench Provided with example design only
Constraints File
or t sr ial Not provided
ut
Simulation Model Encrypted Verilog and C Model
Supported S/W Driver2 Standalone and Linux
t f a to nt
rib
Tested Design Flows3
Design Entry AMD Vivado™ Design Suite
d ide
Simulation For supported simulators, see the Vivado Design Suite User Guide: Release Notes,
ist
Synthesis
Installation, and Licensing (UG973).
Vivado Synthesis
Support
se f
lo on
All Vivado IP Change Logs Master Vivado IP Change Logs: 72775

Support web page
Notes:
sc C
1. For a complete list of supported devices, see the AMD Vivado™ IP catalog.
2. Standalone driver details can be found in <install_directory>/Vitis/<release>/data/embeddedsw/doc/
xilinx_drivers_api_toc.htm.
Di D
Linux: Linux OS and driver support information is available from https://github.com/Xilinx/embeddedsw/tree/

master/XilinxProcessorIPLib/drivers/dfeofdm.
3. For the supported versions of third-party tools, see the Vivado Design Suite User Guide: Release Notes, Installation, and
AM
Licensing (UG973).
No
PG434 (v2.0) October 18, 2023

Send Feedback
RFSoC DFE OFDM IP 5
AMD CONFIDENTIAL
Chapter 2: Overview
Chapter 2
ta n o
a
hi ati
l
Overview
m
n
-D OT nth for
Core Overview
c
Re CD ika In
n
The RFSoC DFE Orthogonal Frequency Division Multiplexing (OFDM) IP core can generate an
io
OFDM baseband signal for up to eight component carriers across up to eight antennas, giving a
or t sr ial
total of 64 component carrier streams. The sample rate of each component carrier can be
ut
configured independently, allowing the aggregate processing resources to be divided between
carriers using time-division sample multiplexing.
t f a to nt
rib
Figure 1: OFDM Core in Downlink Mode
d ide
ist AXI4-LITE CTRL

se f
FT Group delay
lo on
Sequence
AXI4-Lite Register Control Interface
sc C
CC Sequence
CC Sequence
FT Sequence
Scale Factor
Operational
CC Update
Length
Length
Di D
FIFO
AM
CC
FT Buffer/
Buffer/ DOUT
DIN FT Scaling, Group Delay
CC
Sequence Compensation
No
FFT Engine Rounding & Sequence

Gen Saturation Gen
X28344-100423
PG434 (v2.0) October 18, 2023

Send Feedback
RFSoC DFE OFDM IP 6
AMD CONFIDENTIAL
Chapter 2: Overview
Figure 2: OFDM Core in Uplink Mode
ta n o
AXI4-LITE CTRL
a
hi ati
l
FT
Sequence Group delay
AXI4-Lite Register Control Interface
m
n
CC Sequence
CC Sequence
FT Sequence
Scale Factor
Operational
CC Update
-D OT nth for Length

Length
c
Re CD ika In
n
FIFO
io
CC
or t sr ial
DOUT FT Buffer/
Buffer/ DIN
ut
FT Scaling, Group Delay
CC
Sequence Rounding & FFT Engine Compensation
Sequence
Gen Saturation Gen
t f a to nt
rib
d ide
ist
Standard AXI4-Stream interfaces are used for data input and output. The width of the data buses
X28705-100423
se f
are set to be 32 bits with 16 bits for I and 16 for Q samples. The interfaces can generally be
lo on
classified into two categories:
• Fourier transform (FT) interface: The FT interface is the frequency domain interface. DIN
sc C
interface of downlink and DOUT interface of uplink RFSoC DFE OFDM IP carry FT packets.
Each FT sample in a packet is the frequency domain sub-carrier data representing one
resource element (RE). FT packets from multiple component carriers (CCs) and antennas can
Di D
be interleaved on the interface according to a frequency-transform multiplexing sequence.

Successive FT packets are applied back-to-back.
AM
• Component carrier (CC) interface: The CC interface is the time-domain interface. DOUT
interface of downlink and DIN interface of uplink RFSoC DFE OFDM IP core carry CC
No
samples. Each sample consists of I and Q parts. The CC samples from multiple component
carriers and antennas can be interleaved on the interface according to a time-division
multiplexing sequence. Component carrier sample rate of Fc, Fc/2, Fc/4, Fc/8, and Fc/16 can
be supported where Fc is the operating clock frequency. Fc is fixed at 491.52 MHz. The
maximum supported sample rate for a CC is determined by the antenna interleaving selected.
Each AXI4-Stream interface has an associated TUSER signal for user-defined framing/timing
control purposes. The core provides a delay-compensation to preserve and align this out of band
information throughout the signal processing chain.
PG434 (v2.0) October 18, 2023

Send Feedback
RFSoC DFE OFDM IP 7
AMD CONFIDENTIAL
Chapter 2: Overview
The core has a memory-mapped AXI4-Lite interface for configuration, control, and status read
ta n
back. An optional IRQ output is also available to enable interruption of a processor when there
o
are error conditions. A software driver is included with all the API functions required to set up
a
hi ati
and operate this core.
l
The API can instruct changes to the number of component carriers, bandwidth of each
m
component carrier, carrier interleaving sequence, enabling/disabling carriers and antennas, and
n
entry into and exit from the active mode. These configuration updates can all be scheduled to
take place according to a chosen trigger event on all cases where triggering of control changes is
-D OT nth for
possible. The trigger event is based on arbitrary transitions on selected bits of the TBASE_TUSER
in the case of DL or TUSER in case of UL. Further details on the trigger events will be provided in
c
corresponding sections.
Re CD ika In
n
io
or t sr ial
ut
Applications
t f a to nt
rib
The RFSoC DFE OFDM IP core can implement a user-defined OFDM baseband signal processor
for a communication system, including those based on the 3GPP LTE standard and the 3GPP 5G
d ide
NR standard. The core can be used in both downlink and uplink directions. The core is a
ist
component of the AMD RFSoC DFE targeted reference design.
se f
lo on
Unsupported Features
sc C
The following features of the standard are not supported in the core:
• Extended CP (both LTE and 5G-NR) and FR2 (5G-NR)

Di D
AM
Licensing and Ordering

No
This AMD LogiCORE™ IP module is provided at no additional cost in AMD Vivado™ for
customers with a valid license for the RFSoC DFE family of Adaptable SoCs.
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.
PG434 (v2.0) October 18, 2023

Send Feedback
RFSoC DFE OFDM IP 8
AMD CONFIDENTIAL
Chapter 3: Product Specification
Chapter 3
ta n o
a
hi ati
l
Product Specification
m
n
-D OT nth for
Standards
c
Re CD ika In
n
The RFSoC DFE OFDM IP core supports all FR1 transmission bandwidth configurations as
io
specified in 3GPP TS 38.104 for 5G NR. The supported bandwidths are listed in the following
or t sr ial
table. Bandwidth support is the same for UL and DL OFDM configurations. Narrower
ut
bandwidths are supported by padding zeros at appropriate places using configurations of larger
bandwidths. The IP core can also be configured to support any LTE bandwidth configurations as
t f a to nt
rib
long as the FFT size chosen for the bandwidth is greater than or equal to 2048. This is due to the
minimum sample rate (30.72 MSPS) requirement of the IP core. Any rate below 30.72 MSPS is
d ide
not supported.
ist
Table 1: Supported Transmission Bandwidths (FR1)
se f
lo on
SCS 5 10 15 20 25 30 35 40 45 50 60 70 80 90 100
(kHz) MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz
NRB NRB NRB NRB NRB NRB NRB NRB NRB NRB NRB NRB NRB NRB NRB
sc C
15 25 52 79 106 133 160 188 216 242 270 N/A N/A N/A N/A N/A
30 11 24 38 51 65 78 92 106 119 133 162 189 217 245 273
Di D
60 N/A 11 18 24 31 38 44 51 58 65 79 93 107 121 135

Sample 30.72 30.72 30.72 30.72 30.72 61.44 61.44 61.44 61.44 61.44 122.8 122.8 122.8 122.8 122.8
AM
rate 8 8 8 8 8
(MSPS)
No
Performance
Latency
The RFSoC DFE OFDM IP operates in two modes: legacy and low-latency mixed SCS (sub-carrier
spacing). Legacy mode operates in similar way to RFSoC DFE OFDM IP v1.0 and v1.1 with
latency being the same for packets regardless of SCS. In low-latency mixed SCS mode, latency is
reduced for higher SCS packets. Latency figures are provided for FR1 as the IP currently supports
SCS of 15 kHz, 30 kHz, and 60 kHz in normal CP mode.
PG434 (v2.0) October 18, 2023

Send Feedback
RFSoC DFE OFDM IP 9
AMD CONFIDENTIAL
Legacy Mode (FR1)
ta n o
• DL OFDM:
a
hi ati
Latency = 15 kHz SCS OFDM symbol duration including CP (35072 or 35328
l
cycles @491.52 MHz) + 4096 cycles FFT first-in to first-out latency + 20
cycles pipeline latency + programmed TUSER delay
m
n
The latency for a particular CC is measured starting from the CC update trigger or the frame
marker on the s_axis_tbase_tuser to the frame marker on m_axis_dl_dout_tuser.
-D OT nth for
• UL OFDM:
c
Re CD ika In
n
Latency = Programmed TUSER delay + OFDM CC Update delay (170 cycles)
+ 15 kHz SCS OFDM symbol duration including CP (35072 or 35328 cycles
io
@491.52 MHz) + pipeline latency (14 cycles) + 8220
or t sr ial
ut
Measurement points are between the CC and FT frame markers. The measurement points are
similar to DL OFDM. However, the start here is the frame marker on the CC (TUSER IF).
t f a to nt
rib
Low-Latency Mixed SCS Mode (FR1)
d ide
The low-latency mixed SCS mode is specifically included to reduce latency for 30 kHz and 60
ist
kHz SCS carriers.
se f
• DL OFDM:
lo on
• SCS 15 kHz:
Latency = 15 kHz SCS OFDM symbol duration including CP (35072 or

sc C
35328 cycles @491.52 MHz) + 4096 cycles FFT first-in to first-out latency +
20 cycles pipeline latency + programmed TUSER delay
Di D
The latency is measured from the CC update trigger (on s_axis_tbase_tuser) to the
output of (trigger/framing pulse) on m_axis_dl_dout_tuser.
AM
• SCS 30 kHz:

No
17792 cycles @491.52 MHz) + 4096 cycles FFT first-in to first-out latency +
20 cycles pipeline latency + programmed TUSER delay
• SCS 60 kHz:

cycles @491.52 MHz) + 4096 cycles FFT first-in to first-out latency + 14
cycles pipeline latency + programmed TUSER delay
PG434 (v2.0) October 18, 2023

Send Feedback
RFSoC DFE OFDM IP 10
AMD CONFIDENTIAL
ta n
o
a
• UL OFDM:
hi ati
l
• SCS 15 kHz:
m
n
35328 cycles @491.52 MHz) + 8220 cycles FFT latency compensation + 14
cycles pipeline latency + programmed group delay compensation
-D OT nth for
The latency is measured from the s_axis_ul_din_tuser frame marker or trigger to the
c
frame marker on m_axis_tbase [programmed bit].
Re CD ika In
n
• SCS 30 kHz:
io
or t sr ialLatency = 30 kHz SCS OFDM symbol duration including CP (17536 or
ut
17792 cycles @491.52 MHz) + 8220 cycles FFT latency compensation + 14
cycles pipeline latency + programmed group delay compensation
t f a to nt
rib
d ide
ist
• SCS 60 kHz:

se f
cycles @491.52 MHz) + 8220 cycles FFT Latency compensation + 14 cycles

lo on
pipeline latency + programmed group delay compensation

sc C

Di D
AM
Port Descriptions
The widths of the data buses within the DIN and DOUT AXI4-Stream interfaces are determined
No
by the input or output sample width, the number of antennas, and the antenna interleaving
factor that is chosen when the core is customized. These interfaces carry multiplexed data for
multiple component carriers and antennas. The width is given by NL × IW × 2 or NL × OW × 2
where NL is the number of antenna lanes. NL is calculated as the number of antennas NA divided
by the antenna interleaving factor (AILV). For example, with eight antennas and an antenna
interleaving factor of two, the number of antenna lanes NL is equal to four. The core interfaces
are shown in the following figure.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 3: Core Ports
ta n o
a
hi ati
l
s_axis_aclk
m_axis_dl_dout_tdata [NL*OW*2-1:0]
s_axis_aresetn
m_axis_dl_dout_tvalid DL DOUT AXI-
m_axis_dl_dout_tid [7:0] Stream
m
s_axis_tbase_tvalid m_axis_dl_dout_tuser [7:0]
[7:0] s_axis_tbase_tuser
TBASE TUSER IF
n
[32-1:0] s_axis_tbase_tdata
-D OT nth for
m_axis_ul_dout_tdata [NL*OW*2-1:0]
s_axis_dl_din_tvalid m_axis_ul_dout_tvalid UL DOUT AXI-
[NL*IW*2-1:0] s_axis_dl_din_tdata m_axis_ul_dout_tid [7:0] Stream
DL DN AXI-STREAM s_axis_dl_din_tready m_axis_ul_dout_tlast
[7:0] s_axis_dl_din_tid m_axis_ul_dout_tready
c
s_axis_dl_din_tlast
Re CD ika In
n
s_axis_ul_din_tvalid m_axis_ul_tbase_tvalid
[NL*IW*2-1:0] s_axis_ul_din_tdata m_axis_ul_tbase_tuser [7:0]
UL TBASE USER IF
m_axis_ul_tbase_tdata [32-1:0]
io
UL DN AXI-STREAM
[7:0] s_axis_ul_din_tid
[7:0] s_axis_ul_din_tuser DFE OFDM IP
or t sr ial s_axi_aclk
ut
s_axi_aresetn
m_axis_ul_dcout_tdata [NL*OW*2-1:0]
[13:0] s_axi_ctrl_awaddr
m_axis_ul_dcout_tvalid Delay Compensated
s_axi_ctrl_awvalid
m_axis_ul_dcout_tid [7:0] UL DOUT AXI-Stream
s_axi_ctrl_awready
m_axis_ul_dcout_tuser [7:0]
t f a to nt
[31:0] s_axi_ctrl_wdata
rib
s_axi_ctrl_wvalid
s_axi_ctrl_wready
[1:0] s_axi_ctrl_bresp
AXI_MM interface s_axi_ctrl_bvalid
d ide
s_axi_ctrl_bready
irq
[13:0] s_axi_ctrl_araddr
ist
s_axi_ctrl_arvalid
s_axi_ctrl_arready
[31:0] s_axi_ctrl_rdata
[1:0] s_axi_ctrl_rresp
s_axi_ctrl_rvalid
s_axi_ctrl_rready
se f
lo on
X28479-091923
sc C
Data Interface Ports

Di D
Table 2: DL Data Input Interface Ports

AM
Port Name I/O Clock Description

s_axis_dl_din_tdata (2 × IW × NL – 1:0) I s_axis_aclk Input sample data. Width is determined by the
input sample width (IW) (16 for 16-bit samples )
and the number of antenna lanes (NL).
No
s_axis_dl_din_tvalid I s_axis_aclk Valid handshake signal for the data input

channel. The upstream logic uses this to signal
that it is providing valid data.
s_axis_dl_din_tready O s_axis_aclk Ready handshake signal for the data input
channel. The core uses this to signal that it is
accepting data.
s_axis_dl_din_tlast I s_axis_aclk Last indicates the end of an FT packet. The core
uses tlast to signal the end of a FT packet.
s_axis_dl_din_tid [7:0] I s_axis_aclk Transaction ID associated with the sample(s) on

s_axis_dl_din_tdata. The lower four bits [3:0]
indicate the antenna interleaving phase, and the
upper four bits [7:4] indicate the component
carrier ID.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 3: UL Data Input Interface Ports
o
a
hi ati
s_axis_ul_din_tdata (2 × IW × NL – 1:0) I s_axis_aclk Input sample data. Width is determined by the
input sample width (IW) (16 for 16-bit samples )
l
s_axis_ul_din_tvalid I s_axis_aclk Valid handshake signal for the data input
m
channel. The upstream logic uses this to signal
n
that it is providing valid data.
-D OT nth for
s_axis_ul_din_tid[7:0] I s_axis_aclk Transaction ID associated with the sample(s) on
s_axis_din_tdata. The lower four bits [3:0]
c
carrier ID.
Re CD ika In
n
s_axis_ul_din_tuser[UW - 1:0] I s_axis_aclk User-defined framing information. Define the
width of the field when configuring the core.
io
Used for triggering configuration updates within
or t sr ial the core. Also passed through to the data output
interface after applying latency compensation.
ut
Table 4: DL Data Output Interface Ports
t f a to nt
rib
d ide
ist
m_axis_dl_dout_tdata (2 × OW × NL – O s_axis_aclk Output sample data. Width is determined by the
1:0) output sample width (OW) (16 for 16-bit samples)
m_axis_dl_dout_tvalid O s_axis_aclk Valid handshake signal for the data output
se f
channel.
lo on
m_axis_dl_dout_tid[7:0] O s_axis_aclk Transaction ID associated with the sample(s) on

m_axis_dout_tdata. The lower four bits [3:0]
sc C

carrier ID.
m_axis_dl_dout_tuser[UW – 1:0] O s_axis_aclk User-defined framing information. Define the
width of the field when configuring the core. This
Di D
is a latency-compensated version of
s_axis_tbase_tuser.
AM
Table 5: UL Data Output Interface Ports

No
m_axis_ul_dout_tdata (2 x OW x NL -1:0) O s_axis_aclk Output sample data. Width is determined by the

output sample width (OW) (16 for 16-bit samples)
m_axis_ul_dout_tvalid O s_axis_aclk Valid handshake signal for the data output
channel.
m_axis_ul_dout_tlast O s_axis_aclk Indicates the end of a FT packet.
m_axis_ul_dout_tid[7:0] O s_axis_aclk Transaction ID associated with the sample(s) on
carrier ID.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 5: UL Data Output Interface Ports (cont'd)
o
a
hi ati
m_axis_ul_dout_tready I s_axis_aclk Handshake signal currently not used inside the
core as the IF is non-blocking. Used only to
l
monitor overflow.
m
Table 6: Delay Compensated UL Data Output Interface Ports
n
-D OT nth for
m_axis_ul_dcout_tdata (2 × OW × NL – O s_axis_aclk Output sample data. Width is determined by the
c
1:0) output sample width (OW) (16 for 16-bit samples)
Re CD ika In
n
m_axis_ul_dcout_tvalid O s_axis_aclk Valid handshake signal for the data output
io
channel.
or t sr ial
m_axis_ul_dcout_tid[7:0] O s_axis_aclk Transaction ID associated with the sample(s) on
ut
t f a to nt
carrier ID.
rib
m_axis_ul_dcout_tuser[UW – 1:0] O s_axis_aclk User-defined framing information. Define the
width of the field when configuring the core. This
d ide
is a latency-compensated version of
ist
s_axis_din_tuser.
Timebase Interface Ports

se f
lo on
Timebase interface is used to provide framing information to the core for synchronization and
timing alignment.
sc C
Table 7: S_AXIS_TBASE IF
Di D

s_axis_tbase_tvalid I s_axis_aclk Valid handshake signal for
AM
the tbase input channel.

s_axis_tbase_tdata[31:0] I s_axis_aclk Data input channel.
s_axis_tbase_tdata is
included for the AXI4-Stream
No
IF requirement in the IP
integrator. The tdata is not
driven.
s_axis_tbase_tuser[7:0] I s_axis_aclk This is an 8-bit port and used
for triggering configuration
updates within the core. The
port is also used for carrying
framing information.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 8: M_AXIS_TBASE IF
o
a
hi ati
m_axis_tbase_tvalid O s_axis_aclk Valid handshake signal for
the tbase input channel.
l
m_axis_tbase_tdata[31:0] O s_axis_aclk Data input channel.
m_axis_tbase_tdata is
m
included for the AXI4-Stream
n
IF requirement in the IP
integrator. The tdata is not
-D OT nth for
driven.
m_axis_tbase_tuser[7:0] O s_axis_aclk This is an 8-bit port used for
providing framing
c
information to the FT
Re CD ika In
n
domain (for example
OPUXCH).
io
or t sr ial
Control Interface Ports
ut
t f a to nt
rib
s_axi_ctrl_arready O s_axi_aclk Indicates that the core is ready for a read address
d ide
on s_axi_ctrl_araddr.
ist
s_axi_ctrl_arvalid I s_axi_aclk Indicates that the bus logic is providing a read
address on s_axi_ctrl_araddr.
s_axi_ctrl_araddr[3:0] I s_axi_aclk Read address. Accepted when

se f
s_axi_ctrl_arready and s_axi_ctrl_arvalid

lo on
are high on the same clock cycle.

s_axi_ctrl_awready O s_axi_aclk Indicates that the core is ready for a write address
on s_axi_ctrl_awaddr.
sc C
s_axi_ctrl_awvalid I s_axi_aclk Indicates that the bus logic is providing a write

address on s_axi_ctrl_awaddr.
s_axi_ctrl_awaddr[3:0] I s_axi_aclk Write address. Accepted when

s_axi_ctrl_awvalid and s_axi_ctrl_awready
Di D
are asserted on the same clock cycle.

s_axi_ctrl_bready I s_axi_aclk Indicates that the bus logic is ready to receive a
AM
write transaction response.

s_axi_ctrl_bvalid O s_axi_aclk Indicates that the core has completed a write
transaction and the response on
s_axi_ctrl_bresp is valid.
No
s_axi_ctrl_bresp[1:0] O s_axi_aclk Write transaction response.

s_axi_ctrl_rready I s_axi_aclk Indicates that the bus logic is ready to receive read
data.
s_axi_ctrl_rvalid O s_axi_aclk Indicates that the core has completed a read
transaction and that the data on
s_axi_ctrl_rdata and response on
s_axi_ctrl_rresp are valid.
s_axi_ctrl_rresp[1:0] O s_axi_aclk Read transaction response.

s_axi_ctrl_rdata[31:0] O s_axi_aclk Read data.
s_axi_ctrl_wready O s_axi_aclk Indicates that the core is ready to receive write
data on s_axi_ctrl_wdata.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
o
s_axi_ctrl_wvalid I s_axi_aclk Indicates that the bus logic is providing write data
on s_axi_ctrl_wdata.
a
hi ati
s_axi_ctrl_wdata[31:0] I s_axi_aclk Write data.
l
irq O s_axi_aclk Interrupt request to the processor. This is not part
of the AXI4-Lite standard set of signals, and is an
m
optional port.
n
Clock and Reset Ports
-D OT nth for
c
Re CD ika In
n
s_axis_aclk I - Clock for AXI4-Stream interfaces and internal
operation of block.
io
s_axis_aresetn I s_axis_aclk Active-Low synchronous reset for AXI4-Stream
or t sr ial interfaces and internal operation of block.
ut
s_axi_aclk I - Clock for memory mapped AXI interface.
s_axi_aresetn I s_axi_aclk Active-Low synchronous reset for memory
t f a to nt
rib
mapped AXI interface.
d ide
ist
se f
lo on
sc C
Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 4: Designing with the Core
Chapter 4
ta n o
a
hi ati
l
Designing with the Core
m
n
-D OT nth for
This section includes guidelines and additional information to facilitate designing with the core.
c
Re CD ika In
n
io
General Design Guidelines
or t sr ial
ut
Use the Example Design
t f a to nt
rib
Each instance of the RFSoC DFE OFDM IP core created by the Vivado design tool is delivered
d ide
ist
with an example design that can be implemented in a device and then simulated. This design can
be used as a starting point for your own design or can be used to sanity-check your application in
the event of difficulty. See the Example Design content for information about using and
se f
customizing the example designs for the core.

lo on
Registering Signals
sc C
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
Di D
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
AM
easier for the AMD tools to place and route the design.
Recognize Timing Critical Signals

No
The constraints provided with the example design identify the critical signals and timing
constraints that should be applied.
Make Only Allowed Modifications

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
selecting the options in the customization IP dialog box when the core is generated.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Clocking
o
a
hi ati
The RFSoC DFE OFDM IP core has two clocks, s_axis_aclk and s_axi_aclk. The internal
l
datapath logic and the input and output interface all operate synchronously to s_axis_aclk. A
typical frequency for this clock in a 5G wireless system is 491.52 MHz.
m
n
The memory mapped AXI4-Lite interface operates synchronously to s_axi_aclk. No timing
-D OT nth for
relationship between this clock and s_axis_aclk is assumed. This allows the core to be
interfaced to a microprocessor bus which can run at a lower frequency rather than sample-
c
processing frequency (for example, 200 MHz).
Re CD ika In
n
io
or t sr ial
Resets
ut
t f a to nt
rib
The RFSoC DFE OFDM IP core has two resets, s_axis_aresetn and s_axi_aresetn,
corresponding to the two clock domains described above. These signals are active-Low and are
d ide
synchronous to the associated clocks.
ist
The s_axis_aresetn signal resets the core to its default state. To achieve this, assert the reset
signal for at least 60 active clock cycles. After a reset, the core enters its lowest power state in
se f
which the datapath is disabled and no component carriers are configured. All events are cleared
lo on
and all interrupts are disabled.
The s_axi_aresetn signal is part of the AXI4-Lite bus infrastructure and resets the memory
sc C
mapped AXI4-Lite interface and the other peripherals connected to the bus.
The core is ready for operation on the first clock cycle following the deassertion of
Di D
s_axis_aresetn or s_axi_aresetn, whichever comes later.

AM
It is strongly recommended that both reset signals remain asserted at system startup until both
s_axis_aclk and s_axi_aclk are stable. Attempting to operate the AXI4-Lite interface
without the s_axis_aclk present, or to operate the OFDM datapath without the
No
s_axi_aclk present, might lead to unexpected behavior and system instability.
Protocol Description
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Interfacing to the Core
ta n o
a
Packet Format for DL_DIN and UL_DOUT Interfaces
hi ati
l
The data applied at the DL_DIN interface on the downlink is packet based. These packets are
compliant to the AXI4 streaming protocol and have the format as shown in the following figure.
m
The packets follow the frequency transform (FT) sequence. There is a minimum gap of around
n
eight cycles between the CC update trigger and the first valid word of the very first packet in the
-D OT nth for
frame. Each clock cycle carries data for a particular component carrier (CC) and antenna. The
data is validated by the tvalid signal. The end of the packet is indicated by assertion of tlast
c
at the last data word. The tvalid and tready implements the two-way flow control
Re CD ika In
n
mechanism of the AXI4-Stream protocol. The upper four bits of the tid carry the identifier (0 to
io
15) assigned to the component carrier and the lower four bits carry the antenna interleaving
phase.
or t sr ial
ut
Some of the signals in the timing diagram such as OFDM enabled, operational, framePulse,
t f a to nt
subframePulse, subframe No, symbolGroup pulse (15 kHz), and symbolGroupNo (15 kHz) are
rib
internally generated and do not appear on the interface. These are included in the timing diagram
for better understanding of the downlink OFDM (DL_DIN and DL_DOUT) interfaces.
d ide
ist
Though the RFSoC DFE OFDM IP provides complete support for FR1 that includes three
numerology configurations (15, 30, and 60 kHz), only 15 kHz symbol timings are included in the
se f
following timing diagram for ease of understanding.

lo on
The following requirements must be met for FT packets input to downlink OFDM:
• The FT packet for a particular SCS must be applied to OFDM within its corresponding symbol
sc C
boundary. If the packet reaches the IP interface early or late, packet corruption occurs
resulting in incorrect CC samples for the component carrier.
Di D
• The symbol periods for 15, 30, and 60 kHz start six cycles after
s_axis_tbase_tuser[activate].
AM
The CC samples are output on the DL_DOUT interface (m_axis_dl_dout). A frame marker for
other blocks is sent on m_axis_dl_dout_tuser exactly one cycle ahead of the very first CC
No
sample. The CC samples are output according to the CC sequence programmed through the
software APIs. In the following figure, CCIDs 0 to 3 are programmed as active component carriers
with one sample every fourth clock. This is equivalent to an output sample rate of 122.88 MSPS
@491.52 MHz clock. The antenna interleaving assumed in this example case is 1. Each CC
sample must be accompanied by its correct CCID and antenna interleaving phase in order for the
downstream blocks to identify and process the sample correctly.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 4: Downlink DIN Packet Format
ta n o
a
hi ati
l
m
n
-D OT nth for
c
Re CD ika In
n
The data output on the UL_DOUT interface of the uplink OFDM is also in the form of packets
io
and carries the active sub-carrier data. These packets comply with the AXI4-Stream protocol and
or t sr ial
have the format shown in the following figure. The sequence in which these packets are output is
ut
programmed through the software API. The format is the same as used for the DL DIN packets.
UL OFDM assumes the tready is High or the downstream block is ready to accept the data. If
t f a to nt
rib
the downstream block deasserts tready, the OFDM block always ignores the deassertion and
keeps sending data after the reset is released. This is to avoid FT buffer overflow by the FFT
d ide
engine. At the start of each frame, uplink OFDM will assert the frame marker in a bit of
ist
m_axis_ul_tbase_tuser. The bit is user-programmable. The data on the UL_DOUT interface
is always validated by the tvalid signal, therefore, exact determination of the delay between
se f
the framing pulse and the first word of the first packet is not relevant. The downstream block can
lo on
easily determine the first sample of the frame using the tvalid and framing pulse. A single
antenna interleaving phase is assumed in the following figure.
sc C
UL OFDM receives a trigger or frame pulse on s_axis_ul_din_tuser for activation and CC

update. The trigger is placed exactly one cycle ahead of the very first CC sample as shown in the
Di D
following diagram. Each sample is validated by its corresponding CCID. In the timing diagram
below, CCID 0 to 3 are programmed and occupy all CC sample slots.
AM
The trigger or frame marker on m_axis_ul_tbase_tuser is placed after a delay equivalent to

the latency of the RFSoC DFE OFDM IP in the chosen configuration (refer to the Latency section
for delay values). Soon after the marker, FT packets appear in the sequence that you had
No
programmed earlier.
Uplink OFDM ensures that each packet is output within its corresponding symbol boundary.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 5: Uplink DOUT Packets
ta n o
a
hi ati
l
m
n
-D OT nth for
Data Format
c
Re CD ika In
n
The s_axis_dl_din_tdata / s_axis_ul_din_tdata input bus and
io
m_axis_dl_dout_tdata / m_axis_ul_dout_tdata/ m_axis_ul_dcout_tdata output
or t sr ial
bus uses the same format for transferring sample data. The in-phase (I) part of each sample is
ut
placed at the lowest-numbered bit position, followed by the quadrature (Q) part. Each part of the
sample has its least significant bit aligned to an 8-bit boundary, with zero-padding added above
t f a to nt
rib
the most significant bit if the sample width is not a multiple of eight bits.
d ide
The number of antenna lanes is defined as the total number of supported antennas divided by
ist
the antenna interleave factor. These parameters are configurable when the core is generated.
Where the number of antenna lanes is greater than one, samples for multiple antennas are
concatenated from lowest numbered (RHS) to highest numbered (LHS) position within the bus.
se f
lo on
Figure 6: Data Format for the 16-bit Sample Widths
32(N-1) 32(N-1) 63 48 47 32 31 16 15 0
sc C
Di D
Q, Ant N-1 I, Ant N-1 Q, Ant 1 I, Ant 1 Q, Ant 0 I, Ant 0

AM
X27038-090722
The sample data is treated as two's complement fixed-point data. The position of the binary point
is arbitrary.
No
The input to the FFT engine is 16-bit I and 16-bit Q. The FFT computation is carried out in full
precision, with subsequent scaling, saturation and rounding to bring the result into the
appropriate 16-bit I and 16-bit Q format for output. All rounding operations performed by the
core use convergent rounding towards the nearest even number.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Flow Control
ta n o
The RFSoC DFE OFDM IP core supports an arbitrary sample-by-sample flow control handshake
a
hi ati
on the DL DIN input interface. There is no way to stall data on the DL output data interface (DL
l
DOUT). At the DL input (DL DIN), flow control is used to avoid overflow of the FIFO buffer. The
buffer can store up to 4096 samples of FT packets before flow control is used. Successive FT
m
packets should be sent with SC data in each packet.
n
On UL, there is no way to stall data at the input and output interfaces. The TVALID signal of the
-D OT nth for
AXI4-Stream remains High constantly at DL output (DL DOUT) and UL input (UL DIN) when the
core is operational. When operating below the maximum capacity, for example when all
c
component carriers are not active, the TVALID signal is High even on cycles in which no data is
Re CD ika In
n
being transferred for an active component carrier. The TID signal is used to identify cycles
io
carrying data samples belonging to the active component carriers. The behavior is slightly
or t sr ial
different at the DL input (DL DIN) and UL output (UL DOUT). The TVALID is High for each valid
ut
sample and Low otherwise.
t f a to nt
rib
OFDM Sequencing
d ide
Because the RFSoC DFE OFDM IP core is a bridge between frequency and time domains, it
ist
supports two types of sequences: FT Sequence for sequencing frequency domain packets and
CC Sequence for sequencing time domain samples for the configured component carriers. The
RFSoC DFE OFDM IP core provides a high degree of flexibility for defining the two types of
se f
lo on
sequences. The desired sequence can be set up using software API calls, and activated at a
chosen point in time using the TUSER-based triggering mechanism.
sc C
Because the core provides full support for FR1, care must be taken in scheduling packets in the
FT sequence so that each packet lies well within its corresponding symbol boundary. For
example, if CCIDs of 15, 30, and 60 kHz coexist in the FT sequence at any given time, packets for
Di D
these numerologies must be arranged in the sequence so that packets of 15 kHz lie within the
corresponding symbol boundary for 15 kHz, packets of 30 kHz lie within the corresponding
AM
symbol boundary for 30 kHz, and packets of 60 kHz lie within their corresponding 60 kHz
symbol boundary.
No
Fourier Transform (FT) Sequencing

The FT sequence defines the order in which frequency domain packets are input to the DL
OFDM or output by the UL OFDM for the configured component carriers. Each packet
corresponds to one OFDM symbol. The 3GPP specification divides the 10 ms frame into 10
subframes and each subframe into N slots of 14 OFDM symbols, where N=1, 2, and 4 for 15, 30
and 60 kHz SCS, respectively. One symbol group is defined as one symbol for a CC with 15 kHz
SCS, which corresponds to two successive symbols for 30 kHz SCS, and four successive symbols
for 60 kHz SCS.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
The FT sequence is defined for one symbol group. Therefore, a CC with 15 kHz SCS will have
ta n
one entry into the sequence, that is one packet per symbol group, a CC with 30 kHz will have
o
two entries for the two packets and a CC with 60 kHz SCS will have similarly four entries. The
a
hi ati
actual number of packets for a particular CC in a particular symbol is equal to the antenna
l
interleave factor (1, 2, or 4), and those packets are consecutive in time. The core deals with
antenna interleave factor internally; therefore choice of antenna interleave does not change the
m
number of entries for a particular CC in the FT sequence. It does change the number of packets
n
for a particular CC.
-D OT nth for
The CCs in the FT sequence should be scheduled with the following order if at any give time the
sequence contains CCs from all SCS, that is 15, 30, and 60 kHz.
c
Re CD ika In
n
60 30 60 15 60 30 60
io
The order is as follows:
or t sr ial
ut
1. Schedule first packet belonging to 60K symbol 0 for all 60K CCs
t f a to nt
2. Schedule first packet belonging to 30K symbol 0 for all 30K CCs
rib
3. Schedule second packet belonging to 60K symbol 1 for all 60K CCs
d ide
4. Schedule packet belonging to 15K symbol 0 for all 15K CCs
ist
5. Schedule third packet belonging to 60K symbol 2 for all 60K CCs
se f
6. Schedule second packet belonging to 30K symbol 1 for all 30K CCs.
lo on
7. Schedule fourth packet belonging to 60K Symbol 3 for all 60K CCs.
The symbol counter increments by one for 15 kHz, by two for 30 kHz, and by four for the 60 kHz
sc C
CCs. Therefore, in a particular subframe, the symbol number ranges from 0 to 13 for 15 kHz, 0 to
27 for 30 kHz, and 0 to 55 for 60 kHz CCs. This order will be strictly applied. In case of absence
Di D
of any numerology, the corresponding slot should be allocated to packets belonging to the active
numerology or left unscheduled in the case of lightly loaded use cases. For example, if at any
AM
given time CCs belonging to 15 and 60 kHz SCS are configured, the FT scheduling sequence will
take the following form:
60 60 15 60 60
No
The core also requires that each packet must lie within its corresponding symbol boundary. DL-
OFDM generates sequence error if packets are not aligned with their respective symbols. CCs
belonging to a particular numerology should also be configured in descending order of FFT size.
Some example use cases are explained below.
• Case 1: CCID 1 is configured with SCS = 15 kHz: FT Sequence Length = 1. FT Sequence = [1 x

x x x x x x x x x x x x x x]. Here x refers to any value between 0 and 15. Antenna interleave is
assumed to be 2 (ailv=0,1). All packets lie within their respective symbol boundaries.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n o
a
hi ati
l
m
n
• Case 2: CCID 0 and 1 are configured with CCID 0 having SCS = 30 kHz and CCID = 1 SCS =
15 kHz: FT sequence length = 3. FT sequence = [0 1 0 x x x x x x x x x x x x x]. This sequence
-D OT nth for
defines two packets for CCID 0 and one for CCID 1 in the symbol duration for 15 kHz.
Antenna interleave is assumed to be 1 here (ailv=0).
c
Re CD ika In
n
The two packets for CCID0 are output within their respective symbol boundaries with first
packet in symbol 0 and second in symbol 1. The same applies to the only packet for CCID 1
io
which is well within its corresponding 15 kHz symbol boundary.
or t sr ial
ut
t f a to nt
rib
d ide
ist
se f
lo on
• Case 3: CCID 0 is configured with SCS = 60 kHz, CCID 1 is configured with SCS=30 kHz and
CCIDs = 2 and 3 are configured with SCS=15 kHz: FT sequence length = 8 and FT sequence =
[01023010xxxxxxxx]. Antenna interleave is assumed to be 1 with ailv= 0. The timing diagram
is shown below. Each packet lies within its corresponding symbol boundary.
sc C
When all the three numerologies exist, CCIDs are scheduled with [60 30 60 15 60 30 60]
Di D
scheduling. CCIDs are scheduled in the FT sequence with first symbol 60 kHz, first symbol 30
kHz, second symbol 60 kHz, all packets for 15 kHz, third symbol 60 kHz, second symbol 30
AM
kHz and finally the fourth symbol 60 kHz. Each packet lies within its corresponding symbol
boundary.
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Component Carrier (CC) Sequencing
ta n o
The aggregate carrier sample rate Fs, available at the output of DL OFDM and input of UL
a
OFDM, is given by the AXI4-Stream clock frequency Fc (fixed to 491.52 MHz in OFDM v2.0)
hi ati
divided by the antenna interleave factor AILV, which can be 1, 2, or 4. This sample rate can be
l
allocated to a single carrier, or divided up among multiple component carriers as described
m
below.
n
Each component carrier to be processed by the core must have a sample rate Fcc,n that is equal
-D OT nth for
to Fc, Fc/2, Fc/4, Fc/8, or Fc/16. The sum of Fcc,n over all active carriers (n = 0..NAC – 1) must be
less than or equal to Fs, and NAC × AILV must be less than or equal to 16.
c
Re CD ika In
n
The data belonging to each component carrier is identified by a 4-bit value on
s_axis_ul_din_tid[7:4] and m_axis_dl_dout_tid[7:4] known as the component
io
carrier identifier (CCID). The CCID sequence determines the order in which carriers are
or t sr ial
multiplexed on the data bus. The sequence length L can be set to a value of 1, 2, 4, 8, or 16 when
ut
the core is activated via the API, where L×AILV is less than or equal to 16. The number of times
t f a to nt
the CCID for active carrier n appears in the CCID sequence must be equal to Fcc,n×L÷Fs. The
rib
ordering of entries within the CCID sequence is not important.
d ide
In a simple single-carrier configuration where one carrier uses the entire aggregate sample rate,
ist
no TDM is required. The component carrier sequence has a length of 16/AILV. Every element of
the sequence must have the same value, which is the CCID assigned to that carrier.
se f
lo on
When a single component carrier is present but its sample rate is less than the aggregate sample
rate, some of the sample slots on the input and output interfaces will be unused. The CCID field
indicates which cycles contain data for the active component carrier and which are inactive.
sc C
There is no CCID value specifically assigned to stand for an unused slot. Any CCID value that is
not allocated to an active carrier can be used for this purpose. For example, consider a
configuration with 491.52 MSPS aggregate carrier sample rate and a single component carrier
Di D
with a 61.44 MSPS sample rate assigned to CCID 0. If the CCID sequence length has been set to
AM
16, then a valid sequence would be [0,15,15,15,15,15,15,15, 0,15,15,15,15,15,15,15]. The

dummy number 15 has been chosen to represent all the unused slots in the sequence. Other
sequences are possible, provided that the number 0 (the CCID of the active carrier) appears
exactly twice.
No
If two carriers are multiplexed, each carrier having half of the aggregate carrier sample rate, the
TDM sequence alternates between the carriers. For example, if a second 61.44 MSPS carrier
with CCID 1 is added to previous example, then a valid CCID sequence would be
[0,1,15,15,15,15,15,15,0,1,15,15,15,15,15,15]. Another would be
[0,15,1,15,15,15,15,15,0,15,1,15,15,15,15,15]. The core supports an arbitrary interleaving of
active carriers and unused slots with the sequence, although regular patterns with consistent
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
spacing between samples belonging to the same carrier are most likely to be useful in practical
ta n
systems. Extending this multiplexing scheme to carriers with different sample rates is
o
straightforward. For example, if the sample rate of the carrier with CCID 0 in the previous
a
hi ati
example is increased to 122.88 MSPS, then a valid CCID sequence would be
l
[0,1,0,15,15,15,15,15,0,1,0,15,15,15,15,15].
m
When the antenna interleave factor is greater than 1, antenna data interleaving takes place at the
n
level below the component carrier sequencing. All data samples for all antennas are transferred
for the current carrier in the sequence before moving on to the next carrier. The following
-D OT nth for
diagram (Use case 1) shows an example of the component carrier sequencing and how it
interacts with the interleaving of samples for multiple antennas.
c
Re CD ika In
n
Here, the number of antennas is four, the antenna interleave factor is 4, and the sample width is
io
16 bits. Only a single CC with CCID=3 is chosen. The Fcc,n of CCID=3 is chosen to be Fc/16, the
lowest sampling rate.
or t sr ial
ut
On the input CC interface, the sequence of values on TID[7:4] is expected to match the
programmed CC sequence. Where the antenna interleave factor AILV is greater than one, the
t f a to nt
rib
value of TID[3:0] (shown as ailv in the diagram) is expected to count from 0 to AILV – 1 within
each element of the CCID sequence. The core monitors TID and reports a CC sequence error if a
d ide
mismatch is detected on either of these sub-fields.
ist
The clock cycle on which the component carrier interleaving sequence is set when the core is
se f
activated. This sequence start position cannot subsequently be changed unless the core is
lo on
deactivated and reactivated. Activation is performed using one of the triggering mechanisms
described in the following sections. To ensure that the start position can be controlled precisely,
a single-shot TUSER trigger type should be used for the activate process.
sc C
Figure 7: Component Carrier Sequence Example (Use case 1)

Di D
AM
No
Configuring and Controlling the Core

A full software API is provided to facilitate the configuration, control and monitoring of the
RFSoC DFE OFDM IP core’s operation. The API is a set of data structures and functions, defined
in the C programming language, which provide software applications with an abstracted view of
the RFSoC DFE OFDM IP core.
Refer to Appendix C: Application Software Development for more details on the API. API calls
can be used to accomplish the following tasks:
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Triggering Configuration Changes
ta n o
All changes to the configuration of the RFSoC DFE OFDM IP core that affect the processing of
a
hi ati
data are controlled by a triggering mechanism. This includes activating and deactivating the core,
l
adding and removing component carriers, and enabling entry into and exit from low power mode.
m
First, an XDfeOfdm_TriggerCfg structure is used to define the triggers. This is passed to the
n
XDfeOfdm_SetTriggersCfg function to make the new trigger setup current. Then the trigger
is made active through a further software API call, according to the particular configuration
-D OT nth for
change that is being made. When the trigger condition is met, the requested change is put into
effect by the hardware.
c
Re CD ika In
n
A variable TriggerCfg of type XDfeOfdm_TriggerCfg has three fields:
io
• TriggerCfg.Activate: Defines the trigger to be used for activating and deactivating the
or t sr ial
core.
ut
• TriggerCfg.CCUpdate: Defines the trigger to be used for component carrier and antenna.
t f a to nt
rib
• TriggerCfg.LowPower: Defines the trigger to be used for entry into and exit from low
power mode.
d ide
ist
Note: The mode is not supported in RFSoC DFE OFDM IP v2.0.
There are three types of triggers:

se f
lo on
• Immediate Triggers: The simplest type of trigger is the immediate trigger. To define an
immediate trigger, set TriggerCfg.<trigger>.Mode to 0. When an API call that uses the
corresponding trigger is subsequently made, the trigger condition is considered to be met as
sc C
soon as the API performs a write to the hardware register controlling the configuration
parameter in question. The configuration change therefore takes effect immediately.
Di D
Immediate triggers are primarily used for development and debugging. Because the timing of a
register write across the AXI interconnect cannot be guaranteed, and the AXI4-Lite control
AM
interface operates in a different clock domain from the AXI4-Stream data interface, this
mechanism is not suitable for use in situations where sample-accurate alignment of
configuration changes is required.
No
• Single-shot Triggers: For activating and deactivating the core and for updating the component
carrier configuration, a single-shot trigger should be used. To define a single-shot trigger, set
TriggerCfg.<trigger>.Mode to 1. It is also necessary to define the source for the trigger
by setting TriggerCfg.<trigger>.TUSERBit to indicate which bit of
s_axis_tbase_tuser (DL-OFDM) or s_axis_ul_din_tuser (UL-OFDM) should
provide the trigger event. The type of trigger event the hardware should respond to is
determined by TriggerCfg.<trigger>.TuserEdgeLevel. For this field, a value of 0
defines an active-Low trigger, 1 defines an active-High trigger, 2 defines a falling-edge trigger
and 3 defines a rising-edge trigger. When an API call that uses the corresponding trigger is
subsequently made, the trigger condition is considered to be met as soon as the specified
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
event occurs on the chosen bit of s_axis_tbase_tuser for DL operation and
ta n
s_axis_ul_din_tuser for UL operation. The delay between the trigger event and the
o
configuration change taking effect depends on the nature of the configuration change, as
a
described in the following sections. Once the trigger has occurred, it is deactivated until the
hi ati
next API call enables it again.
l
• Continuous Trigger: After activation, a continuous trigger causes the corresponding event to
m
occur repeatedly without further software intervention. To define a continuous trigger, set
n
TriggerCfg.<trigger>.Mode to 2 and define the TUSERBit and TuserEdgeLevel
-D OT nth for
fields as described above for a single-shot trigger. When an API call that uses the
corresponding trigger is subsequently made, the trigger condition is considered to be met as
soon as the specified event occurs on the chosen bit of s_axis_tbase_tuser for DL
c
Re CD ika In
n
operation and s_axis_ul_din_tuser for UL operation. The delay between the trigger
event and the configuration change taking effect depends on the nature of the configuration
io
change, as described in the following sections. The trigger remains enabled so that
or t sr ial
subsequent activity on the same TUSER bit can cause the requested configuration change to
ut
re-occur.
t f a to nt
Continuous triggers are primarily useful for entry into and exit from low power mode, for
rib
example to periodically enable and disable uplink and downlink processing in a TDD system.
d ide
Of the three different types of triggering, the RFSoC DFE OFDM IP uses the Single-shot
ist
Triggering for normal operations. Other triggering types are not recommended in normal
operation.
se f
lo on
Initialization
The RFSoC DFE OFDM IP software API uses the libmetal abstraction layer to provide a
sc C
consistent interface and use model independent of any operating system in use.
Each instance of the RFSoC DFE OFDM IP core in the design requires a corresponding instance
Di D
of an XDfeOfdm API object in the software. The API object is created and bound to the core
using code such as the following.
AM
/* Declare an instance pointer for the API object */

XDfeOfdm *InstancePtr = NULL;
No
/* Initialize an instance of the OFDM driver */

InstancePtr = XDfeOfdm_InstanceInit(XDFEOFDM_NODE1_NAME);
The argument to XDfeOfdm_InstanceInit is the device ID. It controls how the API locates
and binds to the core instance in hardware. The symbol definitions required vary from platform
to platform and will typically be generated as part of the Vitis development platform generation
process. When using embedded Linux, the device ID comes from the device tree. When using a
bare-metal implementation, the device ID comes from the xparameters.h header file.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
After an API object has been created successfully, the RFSoC DFE OFDM core should be put into
ta n
reset to ensure that data processing is halted and the IP is returned to its default state prior to
o
configuration. This can be done by the software API as follows.
a
hi ati
l
/* Reset the OFDM core */
XDfeOfdm_Reset(InstancePtr);
m
In order to ensure that the expected versions of the IP core and software components are in use,
n
the API provides a function to query the version numbers. An example of the usage of these
-D OT nth for
functions is shown below. This also provides a useful initial check that the hardware registers can
be read successfully by the processor.
c
Re CD ika In
n
/* Declare version number objects */
XDfeOfdm_Version SwVersion;
io
XDfeOfdm_Version HwVersion;
or t sr ial
/* Get software and hardware version numbers */
ut
XDfeOfdm_GetVersions(InstancePtr, &SwVersion, &HwVersion);
/* Print the version numbers to the console*/

t f a to nt
rib
printf("SW Version: Major %d, Minor %d\n", SwVersion.Major,
SwVersion.Minor);
printf("HW Version: Major %d, Minor %d, Revision %d, Patch %d\n",
d ide
HwVersion.Major, HwVersion.Minor, HwVersion.Revision,
ist
HwVersion.Patch);
After the core has been put into reset, call the XDfeOfdm_Configure function to complete the
se f
low-level configuration of the core and release the reset. This function checks the configuration
lo on
of the IP core instance against the information in the device tree (when embedded Linux is used)
or xparameters.h file (when a bare metal system is used).
sc C
/* Declare a configuration object */

XDfeOfdm_Cfg Cfg;
Di D
/* Configure the IP instance */

XDfeOfdm_Configure(InstancePtr, &Cfg);
AM
Once the RFSoC DFE OFDM IP core is configured, it must be initialized. The
XDfeOfdm_Initialize function prepares the core for use by setting up the features and
parameters that must remain fixed while the core is operating. For this core, this is the CCID
No
sequence length. The function is used as follows.
/* Declare and populate the initialization parameters object */

XDfeOfdm_Init Init;
Init.CCSequenceLength = 16; // CCID sequence length (must be a power of 2)

/* Initialize the IP core */
XDfeOfdm_Initialize(InstancePtr, &Init);
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
After initialization is complete, the core is ready to be activated. Activation brings the core into
ta n
an operational state in which the core can process data. The start position of the component
o
carrier sequence is set at the point of activation. To ensure that this start position can be
a
hi ati
accurately synchronized with other logic in the system that is providing the TDM data stream to
l
the RFSoC DFE OFDM core, the activation process should use a trigger based on a bit within the
s_axis_tbase_tuser for DL operation and s_axis_ul_din_tuser for UL operation. The
m
core activation function takes a Boolean argument which determines whether the low power
n
mode should be enabled or disabled. An example of the core activation procedure is shown
-D OT nth for
below.
/* Declare and populate a trigger configuration object */
c
XDfeOfdm_TriggerCfg TriggerCfg;
Re CD ika In
n
TriggerCfg.Activate.Mode = 1; // Single-shot trigger
TriggerCfg.Activate.TUSERBit = 0; // on TUSER bit 0
io
TriggerCfg.Activate.TuserEdgeLevel = 1; // when high
or t sr ial
/* Set the trigger configuration */
ut
XDfeOfdm_SetTriggersCfg(InstancePtr, &TriggerCfg);
t f a to nt
/* Activate the IP core (disabling the low power mode) */
rib
XDfeOfdm_Activate(InstancePtr, false);
d ide
The call to XDfeOfdm_Activate will return immediately. The core will be activated when the
ist
trigger condition is met.
Latency Compensation Setup

se f
lo on
The RFSoC DFE OFDM IP core generates the TUSER signal on the output interface by delaying
the signals received on the input interface. The default behavior is to delay TUSER by a number
sc C
of clock cycles equal to the latency of the data processing pipeline. This datapath delay can be
queried from software using the following code.
Di D
u32 dataDelay;
AM
dataDelay = XDfeOfdm_GetTDataDelay(InstancePtr, 0);
The second argument to XDfeOfdm_GetTDataDelay is the number of additional clock cycles

to add to the datapath delay, for example, to include the total delay of a particular component
No
carrier. When a value of 0 is specified, the function returns the number of clock cycles of
datapath delay with no adjustment applied.
The API also provides control over the amount of additional delay applied to the TUSER signal at
the output. This extra delay can be set to any number of clock cycles from 0 to 4095 as required.
The current setting can also be queried. The following code illustrates the required function calls.
XDfeOfdm_SetTUserDelay(InstancePtr, 15); // Additional 15 clock-cycle

delay
currentDelay = XDfeOfdm_GetTUserDelay(InstancePtr);
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Note: The TUSER delay can only be set prior to core activation because changes to the delay while the
ta n
core is active could lead to undefined behavior on m_axis_dl_dout_tuser.
o
a
Component Carrier Setup, FT, and CC Sequencing
hi ati
l
The API provides functions to dynamically add, update, and remove component carriers, and to
m
manage the FT as well as the CC sequence. Updates to the component carrier configuration are
n
typically performed using a trigger based on a bit of the TBASE_TUSER bus for DL and TUSER
bus for UL, similar to that used for the activation process. This allows the timing of the update to
-D OT nth for
be aligned precisely to a particular timing event. One such event is the framing pulse indicating
the beginning of a new frame. Updates to the component carrier configuration take effect 80
c
cycles after the trigger condition occurs, regardless of the FT or CCID sequence length. This is
Re CD ika In
n
the OFDM internal delay and does not impact the timings of the FT packets or CC sequence
io
input to the block. This delay is not normally visible to you.
or t sr ial
ut
Component Carrier Update Sequence
t f a to nt
The functions described in this section operate on one component carrier at a time, requiring a
rib
separate trigger for each update. To add, remove or update multiple component carriers using a
single trigger, see Making Simultaneous Updates.
d ide
ist
After the core has been activated, the XDfeOfdm_AddCC function can be used to start
processing for a new component carrier. This function takes the carrier configuration structure,
se f
CCID value, a bitmap representing the position of this component carrier's samples within the
lo on
CCID sequence, and the FT sequence structure consisting of the FT sequence length and the FT
sequence. It then adds the new component carrier to any existing carriers that are already active,
and writes the new setup into the core's configuration registers. Finally it sets up the CC update
sc C
trigger before returning. The new carrier is activated when the trigger condition occurs as
described above.
Di D
Before calling XDfeOfdm_AddCC, the CC update trigger must be configured using

XDfeOfdm_SetTriggersCfg. The CC update trigger can be configured at the same time as
AM
the Activate trigger during the initialization phase, if desired. If the same trigger configuration is
to be used multiple times by successive component carrier add, update, or remove function calls,
it only needs to be configured once before the first call.
No
It is also necessary to clear the event status before adding, removing, or updating a CC, in order
for the software to be able to detect that the CC update trigger condition was met. This is
achieved by means of the XDfeOfdm_ClearEventStatus function.
The following code sequence illustrates how to set up a new component carrier using the steps
above.
/* Declare and populate trigger configuration, carrier configuration and

CCID bitmap */
XDfeOfdm_TriggerCfg TriggerCfg;
XDfeOfdm_CarrierCfg CarrierCfg;
XDfeOfdm_FTSequence FTSeq;
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
XDfeOfdm_Status status = { 0 };
ta n
u32 BitSequence;
u32 CCID;
o
u32 result;
a
hi ati
CarrierCfg.Numerology = 1; // 1 means SCS 30 KHz, 0 mean s SCS 15 KHz
l
CarrierCfg.NumSubcarriers = 1596; // Number of SubCarriers
CarrierCfg.ScaleFactor = 0xA3; // Scaling used after FFT operation
CarrierCfg.OutputDelay = 0x20;
m
n
BitSequence = 0x0005; // CC will occupy every other timeslot,
starting with the first
-D OT nth for
CCID = 1; // CCID number chosen for this carrier
FTSeq.Length = 2; // For SCS = 30 KHz, two packets are sent in
one symbol group
c
FTSeq.CCID[0] = CCID;
Re CD ika In
n
io
TriggerCfg.CCUpdate.Mode = 1; // Single-shot trigger
TriggerCfg.CCUpdate.TUSERBit = 0; // on bit 0
or t sr ial
TriggerCfg.CCUpdate.TuserEdgeLevel = 1; // when high
ut
/* Set up the CC update trigger */
XDfeOfdm_SetTriggersCfg(InstancePtr, &TriggerCfg);
t f a to nt
rib
/* Clear the event status */
status.CCUpdate = 1;
d ide
XDfeOfdm_ClearEventStatus(InstancePtr, &status);
ist
/* Add the component carrier */
result = XDfeOfdm_AddCC(InstancePtr, CCID, BitSequence, &CarrierCfg,
&FTSeq);
se f
lo on
if (result != XST_SUCCESS)
printf("Add CC #%d failed with error code %d!\n", CCID, result);
else
{
sc C
printf("Successfully scheduled CC #%d for addition.\n", CCID);
status.CCUpdate = 0 ;
Di D
/* (Demonstration only!) Poll for successful CC update trigger */

while (status.CCUpdate == 0)
AM
{
XDfeOfdm_GetEventStatus(InstancePtr, &status);
usleep(10000);
}
printf("Addition of CC #%d was triggered successfully.\n", CCID);
No
The polling loop at the end of this example is not realistic, but illustrates how the API can
determine whether the CC update trigger condition has occurred.
Adding multiple component carriers can be done by following the sequence above several times.
A separate call to XDfeOfdm_AddCC is required for each component carrier and a separate
trigger is required for each update when using this method. See Orthogonal Frequency Division
Multiplexing Reference IP (XAPP1382) (registration required) for an alternative set of API calls
which allow multiple carriers to be added using a single trigger.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
When defining multiple CCs, ensure that the bit sequence values do not overlap. For example, to
ta n
create one 122.88 MSPS CC and three 30.72 MSPS CCs, a valid set of bit sequences could be:
o
a
hi ati
u32 BitSeq0_122p88 = 0x0055;
u32 BitSeq1_30p72 = 0x0002;
l
u32 BitSeq2_30p72 = 0x0008;
u32 BitSeq3_30p72 = 0x0020;
m
assert (BitSeq0_122p88 & BitSeq1_30p72 & BitSeq2_30p72 & BitSeq3_30p72 ==
n
0);
-D OT nth for
The examples in this section assume a CCID sequence length of 16. In the case of UL
operation,the pattern specified by the bitmap must match the pattern supplied to the core on
c
s_axis_ul_din_tid. If it does not match, the core records a CC sequence error. This
Re CD ika In
n
condition can be detected using the following code:
io
or t sr ial
XDfeOfdm_Status status = { 0 };
ut
XDfeOfdm_GetEventStatus(InstancePtr, &status);
if (status.CCSequenceError != 0)
printf("A CC sequence error occured!\n");
t f a to nt
rib
The XDfeOfdm_UpdateCC function is used in a similar way to XDfeOfdm_AddCC. The
d ide
sequence of function calls required, including event clearing and triggering setup, is identical for
ist
both functions. The main difference between the two is that XDfeOfdm_UpdateCC does not
alter the CCID sequence and therefore does not take a bit sequence as an argument. It operates
on an existing active component carrier, overwriting its configuration with the new values
se f
specified in the XDfeOfdm_CarrierCfg structure.

lo on
The function XDfeOfdm_RemoveCC takes only a CCID number as an argument. It deactivates

the specified CC and removes it from the CCID sequence when the trigger condition occurs. As
sc C
for XDfeOfdm_AddCC, the XDfeOfdm_UpdateCC and XDfeOfdm_RemoveCC functions act

only on a single carrier and require one trigger event per function call.
Di D
Making Simultaneous Updates

AM
The API provides additional functions and configuration structures to allow updates for multiple
component carriers to be triggered simultaneously. All details of the trigger setup (including the
No
triggering latency) are the same as when performing individual updates as described in the
previous section.
The overall sequence of events for making multiple simultaneous updates is as follows. First an
XDfeOfdm_CCCfg structure is declared to hold the details of the core's configuration. This can
be populated either with the configuration currently in effect or with an empty configuration
setup. In both cases, the current state of the core is unaffected and all data processing continues
uninterrupted.
The API provides functions to add, remove, or update component carriers within this
configuration. When all changes to the configuration structure are complete, it is scheduled to be
put into effect by a final API call.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
The initial configuration structure is declared and populated with code similar to the following.
ta n o
/* Declare configuration structure */
a
XDfeOfdm_CCCfg CCConfig;
hi ati
XDfeOfdm_FTSequence FTSeq;
l
/* Retrieve the current configuration parameters */
XDfeOfdm_GetCurrentCCCfg(InstancePtr, &CCConfig);
m
FTSeq = CCConfig.FTSequence;
n
To start from a blank configuration instead of the current configuration, use the function
-D OT nth for
XDfeOfdm_GetEmptyCCCfg instead of XDfeOfdm_GetCurrentCCCfg. The arguments and
syntax are identical for the two calls. An empty configuration is initialized to 0, and therefore has
c
no active component carriers.
Re CD ika In
n
io
To add a component carrier to the configuration, use the XDfeOfdm_AddCCtoCCCfg function.
Its arguments and usage are almost identical to XDfeOfdm_AddCC but it operates on an
or t sr ial
ut
XDfeOfdm_CCCfg structure rather than directly on the core itself. To remove a component
carrier from the configuration, use XDfeOfdm_RemoveCCfromCCCfg.
t f a to nt
rib
XDfeOfdm_CarrierCfg CarrierCfg;
u32 BitSequence;
d ide
u32 CCID;
ist
u32 result;
CarrierCfg.Numerology = 1 //1 means SCS 30 KHz, 0 is used for SCS 15 KHz

se f
CarrierCfg.NumSubcarriers = 1596; // Number of active subcarriers.

lo on
CarrierCfg.ScaleFactor = 0xA3;
CarrierCfg.OutputDelay = 0x20;
sc C
BitSequence = 0x0005; // CC will occupy every other timeslot,

starting with the first
CCID = 1; // CCID number chosen for the new carrier
/* Update FT sequence length and FT sequence */
Di D
FTSeq.Length = FTSeq.Length + CarrierCfg.Numerology + 1;

AM
/* Add the component carrier to the configuration */

result = XDfeOfdm_AddCCtoCCCfg(InstancePtr, &CCConfig, CCID, BitSequence,
&CarrierCfg, &FTSeq);
No
/* Remove CCID 7 from the configuration */

XDfeOfdm_RemoveCCfromCCCfg(InstancePtr, &CCConfig, 7, &FTSeq);
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
The parameters for an existing component carrier can be updated within the configuration using
ta n
XDfeOfdm_UpdateCCinCCCfg. It is also possible to retrieve the parameters for an existing
o
component carrier using XDfeOfdm_GetCarrierCfg. The code below shows how the
a
hi ati
parameters for one carrier can be copied from one carrier to another using these functions.
l
/* Retrieve the carrier configuration for CCID 4 */
m
XDfeOfdm_GetCarrierCfg(InstancePtr, &CCConfig, 4, &BitSequence,
&CarrierCfg);
n
/* Apply the same configuration to CCID 5 */
-D OT nth for
XDfeOfdm_UpdateCCinCCCfg(InstancePtr, &CCConfig, 5, &CarrierCfg, &FTSeq);
c
When all the required changes have been made and the configuration structure is ready to be
Re CD ika In
n
applied, call the XDfeOfdm_SetNextCCCfgAndTrigger function to write the new
configuration to the core.
io
or t sr ial
/* Apply the changes */
ut
result = XDfeOfdm_SetNextCCCfgAndTrigger(InstancePtr, &CCConfig);
if (result == XST_SUCCESS)
t f a to nt
rib
printf("CC configuration scheduled for update\n");
else
printf("Set CC configuration failed with error code %d!\n", result);
d ide
ist
The new component carrier and antenna configuration is activated when the specified trigger
condition occurs.
se f
lo on
Status, Events, and Interrupts

The control logic within the RFSoC DFE OFDM IP core performs continuous monitoring for error
sc C
and status events and records them in status registers. The API provides access to the following
information:
Di D
• Arithmetic overflow: The carrier and antenna where an overflow occurred are recorded. The
core also records information about which real and/or imaginary part was affected.
AM
• FT_CC_Sequence_Error: For DL, it checks if the DL DIN TID matches the programmed
FT_SEQUENCE and the packet is in its corresponding symbol boundary. For UL, it checks if
UL DIN TID matches the programmed CC_SEQUENCE.
No
• CC updated triggered: When a component carrier’s configuration is updated based on a user-

defined trigger, this status information confirms whether the trigger condition was met.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
An interrupt masking function is provided to support designs where the optional IRQ signal is
ta n
connected to the control microprocessor, or to other logic, such as an integrated logic analyzer
o
core. The following code demonstrates how to choose which of the events generates an
a
hi ati
interrupt on the IRQ output of the core.
l
/* Declare an interrupt mask structure */
m
XDfeOfdm_InterruptMask IrqMask;
n
/* Populate the structure */
IrqMask.Overflow = 0; // Enable (don't mask) overflow error
-D OT nth for
interrupts
IrqMask.CCUpdate = 1; // Disable (mask) CC update interrupts
IrqMask.CCSequenceError = 0; // Enable (don't mask) CC sequence error
c
interrupts
Re CD ika In
n
/* Set up the interrupt mask */
io
XDfeOfdm_SetInterruptMask(InstancePtr, &IrqMask);
or t sr ial
Whenever an event occurs, the corresponding bit is set in the event status register and an
ut
interrupt is generated by driving IRQ High unless the event has been masked as shown above. If
t f a to nt
the same event then re-occurs before XDfeOfdm_ClearEventStatus has been called, the
rib
status bit and the IRQ state remains High. The IRQ line is not driven Low again until the event
has been cleared.
d ide
ist
se f
lo on
sc C
Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 5: Design Flow Steps
Chapter 5
ta n o
a
hi ati
l
Design Flow Steps
m
n
-D OT nth for
This section describes customizing and generating the core, constraining the core, and the
simulation, synthesis, and implementation steps that are specific to this IP core. More detailed
c
information about the standard AMD Vivado™ design flows and the IP integrator can be found in
Re CD ika In
n
the following Vivado Design Suite user guides:
io
• Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
or t sr ial
• Vivado Design Suite User Guide: Designing with IP (UG896)
ut
• Vivado Design Suite User Guide: Getting Started (UG910)
t f a to nt
rib
• Vivado Design Suite User Guide: Logic Simulation (UG900)
d ide
ist
Customizing and Generating the Core
se f
lo on
This section includes information about using AMD tools to customize and generate the core in
the AMD Vivado™ Design Suite.
sc 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
Di 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
console.
You can customize the IP for use in your design by specifying values for the various parameters
No
associated with the IP core using the following steps:
1. Select the IP from the IP catalog.

2. Double-click the selected IP or select the Customize IP command from the toolbar or right-
click menu.
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) and the Vivado
Design Suite User Guide: Getting Started (UG910).
Figures in this chapter are illustrations of the Vivado IDE. The layout depicted here might vary
from the current version.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Configuration Tab
ta n o
Figure 8: Configuration Parameters Tab
a
hi ati
l
m
n
-D OT nth for
c
Re CD ika In
n
io
or t sr ial
ut
t f a to nt
rib
d ide
ist
se f
lo on
sc C
Di D
AM
No
• Mode (UL=Uplink, DL=Downlink): Defines where OFDM is used. When DL is selected,

OFDM is used in downlink chain and for UL, OFDM is used in uplink chain.
• Number of Antennas: The core can provide processing for one, two, four, or eight antennas in
parallel.
• Antenna Interleave: This factor specifies the number of clock cycles across which the samples
for each antenna are transferred. For example, if the number of antennas is set to eight, an
antenna interleave of 1 will transfer that data for all eight antennas in parallel in a single clock
cycle. At the other extreme, an antenna interleave of 8 will transfer the data for a single
antenna on each clock cycle, and it takes eight cycles in total to transfer the data for all
antennas. The antenna interleave cannot be larger than the number of antennas.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
• Lower Latency for higher SCS (1=ON, 0=OFF): When this mode is activated with a value of 1,
ta n
OFDM processes higher SCS (30 and 60 kHz for FR1) with reduced processing latency.
o
a
hi ati
User Parameters
l
The following table shows the relationship between the fields in the AMD Vivado™ IDE and the
m
user parameters (which can be viewed in the Tcl Console).
n
-D OT nth for
Table 9: User Parameter
Vivado IDE Parameter User Parameter Default Value
c
Re CD ika In
n
Number of Antennas NUM_ANTENNA 1
Antenna Interleave ANTENNA_INTERLEAVE 1
io
Lower Latency for higher SCS (1=ON, 0=OFF) LOW_LATENCY_MIXED_SCS 0
or t sr ial
ut
Output Generation
t f a to nt
rib
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896).
d ide
ist
Constraining the Subsystem
se f
lo on
Required Constraints
sc C
This section is not applicable for this IP core.
Device, Package, and Speed Grade Selections

Di D

AM
Clock Frequencies
No
Clock Management
Clock Placement
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Banking
ta n o
a
hi ati
Transceiver Placement
l
m
n
I/O Standard and Placement
-D OT nth for
c
Re CD ika In
n
io
Simulation
or t sr ial
ut
For comprehensive information about AMD Vivado™ simulation components, as well as
t f a to nt
information about using supported third-party tools, see the Vivado Design Suite User Guide: Logic
rib
Simulation (UG900).
d ide
ist
Synthesis and Implementation
se f
lo on
For details about synthesis and implementation, see the Vivado Design Suite User Guide: Designing
with IP (UG896).
sc C
Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
Chapter 6
ta n o
a
hi ati
l
C Model
m
n
-D OT nth for
The DFE OFDM C Model is a bit-accurate high level representation of the RFSoC DFE OFDM IP
IP. The C Model is a shared library object and can be linked dynamically. It models both UL and
c
DL algorithms of the RFSoC DFE OFDM IP core. It is mainly used in RTL simulation to generate
Re CD ika In
n
reference vectors or prediction for IP verification. It can also be used as part of system level
validation or verification where OFDM operation is involved.
io
or t sr ial
ut
Features
t f a to nt
rib
• Bit-accurate with RFSoC DFE OFDM IP core.
d ide
ist
• Supports both 64-bit Linux and 64-bit Windows platforms.
• Block-based interface where OFDM accepts data for entire symbol and provides
se f
corresponding bit-accurate output for the same symbol.

lo on
sc C
Overview
Di D
The model consists of a set of C functions that reside in a shared library. The set of C functions
models all functionality of the blocks and algorithms used inside the RFSoC DFE OFDM IP core.
AM
Example C code is provided to demonstrate how these functions form the interface to the C
model. Full details of this interface are provided in the C Model Interface section.
The model is bit-accurate but not cycle-accurate; it performs exactly the same operations as the
No
core. However, it does not model the core latency or its interface signals.
Unpacking and Model Contents

Unzip the RFSoC DFE OFDM C model zip file for your platform. This produces the directory
structure and files shown in the following table.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
ta n
Table 10: C Model Zip File Contents: Linux
o
File Description
a
hi ati
xdfe_ofdm_v2_0_bitacc_cmodel.h Header file which defines the C model API
l
xip_common_bitacc_cmodel.h Header file with common definitions
libIp_xdfe_ofdm_v2_0_bitacc_cmodel.so Model shared object library
m
run _bitacc_cmodel.c Example program for calling the C model APIs
n
xdfe_ofdm_v2_0_bitacc_mex.cpp MATLAB MEX function source
-D OT nth for
@xdfe_ofdm_v2_0_bitacc MATLAB MEX function class directory
make_xdfe_ofdm_v2_0_mex.m MATLAB MEX function compilation script
c
run_xdfe_ofdm_v2_0_mex.m MATLAB MEX function example script
Re CD ika In
n
io
Table 11: C Model Zip File Contents: Windows
or t sr ial
ut
File Description
xdfe_ofdm_v2_0_bitacc_cmodel.h Header file which defines the C model API
t f a to nt
rib
xip_common_bitacc_cmodel.h Header file with common definitions
libIp_xdfe_ofdm_v2_0_bitacc_cmodel.dll Model dynamically-linked library
d ide
libIp_xdfe_ofdm_v2_0_bitacc_cmodel.lib Model statically-linked library.
ist
run _bitacc_cmodel.c
xdfe_ofdm_v2_0_bitacc_mex.cpp
Example program for calling the C model APIs
MATLAB MEX function source
se f
@xdfe_ofdm_v2_0_bitacc MATLAB MEX function class directory

lo on
make_xdfe_ofdm_v2_0_mex.m MATLAB MEX function compilation script

run_xdfe_ofdm_v2_0_mex.m MATLAB MEX function example script
sc C
Installation
Di D
AM
Linux
1. Unpack the contents of the ZIP file.

No
2. Ensure that the directory containing the file

libIp_xdfe_ofdm_v2_0_bitacc_cmodel.so is in your $LD_LIBRARY_PATH
environment variable.
Windows
1. Unpack the contents of the ZIP file.

2. Ensure that the directory where the libIp_xdfe_ofdm_v2_0_bitacc_cmodel.dll is:
• Either in your %PATH% environment variable.
• Or the directory from which you run your executable that calls the OFDM C model.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
ta n
C Model Interface
o
a
hi ati
The Application Programming Interface (API) of the C model is defined in the header file
l
xdfe_ofdm_v2_0_bitacc_cmodel.h. This interface consists of data structures and
functions as described in the following sections.
m
n
To use the C model:
-D OT nth for
1. Define a model configuration parameter structure (xdfe_ofdm_v2_0_config) and
initialize its fields as per the application usage requirement.
c
Re CD ika In
n
2. Use this model configuration parameter structure and create an instance of the model by
calling xdfe_ofdm_v2_0_create().
io
3. Create and initialize the composite configuration data structure
or t sr ial
ut
(xdfe_ofdm_v2_0_cc_cfg) for all the component carriers for which OFDM operation is
required.
t f a to nt
rib
4. Allocate and initialize arrays for input and output samples.
5. Call the do-function (xdfe_ofdm_v2_0_do) of the model to perform OFDM baseband
d ide
signal generation for either DL or UL operation.
ist
6. Pass all the required arguments to the do-function for generating the desired reference data.
se f
7. When finished, destroy the model instance (xdfe_ofdm_v2_0_destroy) and deallocate

lo on
the memory as necessary.
It must be noted that the model operates on a symbol-by-symbol basis and the symbol here is
sc C
the symbol used for 15 kHz SCS. Data for all component carriers should be generated prior to
calling the model and input to the model in a two dimensional complex array structure with one
dimension carrying data for a single antenna lane and the other the antenna lanes. There can be
Di D
up to eight antenna lanes. For the DL operation, the input data consist of Frequency Transform
(FT) packets and each packet consists of samples for active sub-carriers. The output is the
AM
corresponding time domain CC samples. For the UL operation, the model takes CC samples as
input, convert these into FT packets and outputs for reference or comparison.
No
The input data must be aligned with the corresponding FT or CC sequence for the DL or UL
operation respectively. The model then outputs reference data with the programmed alignment
in the CC or FT sequence data structures.
The model is called once per 15 kHz symbol. The reference data generated must be stored in a
similar array structure for comparison with the output from the OFDM hardware. Only a single
instance is needed to process all component carriers and/or multiple antennas.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
Constants
ta n o
Table 12: Constants
a
hi ati
l
Name Value
Supported Sample width
m
XDFE_OFDM_V2_0_SAMPLE_WIDTH_16B 16
n
Maximum Number of Antenna supported
-D OT nth for
XDFE_OFDM_V2_0_MAX_NUM_ANTENNA 8
Maximum Number of Antenna Interleave supported
c
XDFE_OFDM_V2_0_MAX_ANTENNA_INTLV 4
Re CD ika In
n
Maximum CC Sequence Number
io
XDFE_OFDM_V2_0_MAX_CC_NUM 16
or t sr ial Maximum FT Sequence Number
ut
XDFE_OFDM_V2_0_MAX_FT_NUM 16
Maximum CC Sequence Length
t f a to nt
rib
XDFE_OFDM_V2_0_MAX_CC_SEQ_LEN 16
Maximum FT Sequence Length
d ide
XDFE_OFDM_V2_0_MAX_FT_SEQ_LEN 16
ist
XDFE_OFDM_V2_0_NUM_ANTENNA_DEFAULT
Default Number of antennas
2
se f
Default Antenna Interleave

lo on
XDFE_OFDM_V2_0_ANTENNA_INTLV_DEFAULT 1
sc C
Data Types
Table 13: Data Type Definitions
Di D
Field Name Description

AM
Standard types
xdfe_ofdm_v2_0 Model Object type (not visible to the user).
No
xip_uint Unsigned integer type.

xip_int Integer type.
xip_status Result code from API functions; XIP_STATUS_OK, XIP_STATUS_ERROR.
xip_msg_handler Message handler function signature.
Structures
xdfe_ofdm_v2_0_config Model configuration parameters. See xdfe_ofdm_v2_0_config structure section.
xdfe_ofdm_v2_0_cc_sequence Model CC sequence. See xdfe_ofdm_v2_0_cc_sequence structure section.
xdfe_ofdm_v2_0_ft_sequence Model FT sequence. See xdfe_ofdm_v2_0_ft_sequence structure section.
xdfe_ofdm_v2_0_carrier_cfg Carrier configuration for single CC. See xdfe_ofdm_v2_0_carrier_cfg structure
section.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
ta n
Table 13: Data Type Definitions (cont'd)
o
Field Name Description
a
hi ati
xdfe_ofdm_v2_0_cc_cfg Composite configuration structure for OFDM. See xdfe_ofdm_v2_0_cc_cfg
structure section.
l
xdfe_ofdm_v2_0_saturation See xdfe_ofdm_v2_0_saturation structure section.
m
xdfe_ofdm_v2_0_status See xdfe_ofdm_v2_0_status structure section.
n
Dynamic Arrays
-D OT nth for
xip_array_complex Dynamic array of a standard double type.
xip_array_int Dynamic array of integer type.
c
Re CD ika In
n
Functions
io
There are several accessible C model functions.
or t sr ial
ut
xdfe_ofdm_v2_0_get_version
t f a to nt
rib
Gets the version of library.
d ide
Table 14: xdfe_ofdm_v2_0_get_version Returns
ist Type Description

se f
const char* Textual representation of library version

lo on
xdfe_ofdm_v2_0_default_config
sc C
Gets the default configuration structure.

Di D
Table 15: xdfe_ofdm_v2_0_default_config Arguments

AM
Argument Name Type

config xdfe_ofdm_v2_0_config*
No
Table 16: xdfe_ofdm_v2_0_default_config Returns
Type Description
xip_status Exit code
xdfe_ofdm_v2_0_create
Creates a new instance of the model based on specified configuration.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
ta n
Table 17: xdfe_ofdm_v2_0_create Arguments
o
Argument Name Type Description
a
hi ati
config const xdfe_ofdm_v2_0_config* Model configuration structure
l
msg_handler xip_msg_handler Callback function for errors and
warnings
m
msg_handle void* Optional argument to be passed back
to callback function
n
-D OT nth for
Table 18: xdfe_ofdm_v2_0_create Returns
c
Type Description
Re CD ika In
n
xdfe_ofdm_v2_0* Model instance handle
io
xdfe_ofdm_v2_0_reset
or t sr ial
ut
Resets an instance of the core.
t f a to nt
rib
Table 19: xdfe_ofdm_v2_0_reset Arguments
d ide
ist
model xdfe_ofdm_v2_0* Model instance handle
se f
lo on
Table 20: xdfe_ofdm_v2_0_reset Return Value
Type Description
sc C
xdfe_ofdm_v2_0_set_cc_cfg
Di D
Sets the component carrier configuration.

AM
Table 21: xdfe_ofdm_v2_0_set_cc_cfg Arguments

No

cc_cfg const xdfe_ofdm_v2_0_cc_cfg* Component carrier configuration
Table 22: xdfe_ofdm_v2_0_set_cc_cfg Return Value
Type Description
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
xdfe_ofdm_v2_0_get_status
ta n o
Gets status, overflow cleared on read.
a
hi ati
Table 23: xdfe_ofdm_v2_0_get_status Arguments
l
m
n
-D OT nth for
status xdfe_ofdm_v2_0_status* Status output
Table 24: xdfe_ofdm_v2_0_get_status Return Value
c
Re CD ika In
n
Type Description
io
or t sr ial
ut
xdfe_ofdm_v2_0_do
t f a to nt
rib
Filter supplied data using the specified component carrier configuration.
d ide
Table 25: xdfe_ofdm_v2_0_do Arguments
ist Argument Name Type Description

se f

lo on
cc_cfg const xdfe_ofdm_v2_0_cc_cfg* Component carrier configuration.

Optional argument, set to 0 (NULL).
Use current configuration when
undefined.
sc C
data_in const xip_array_complex* Input data

data_out xip_array_complex* Output data
Di D
status xdfe_ofdm_v2_0_status* Overflow, or underflow, status.

Optional argument, set to 0 (NULL).
Not read when undefined.
AM
Table 26: xdfe_ofdm_v2_0_do Return Value

No
Type Description
xdfe_ofdm_v2_0_destroy
Destroys model instance and frees any resources allocated.
Table 27: xdfe_ofdm_v2_0_destroy Arguments

PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
ta n
Table 28: xdfe_ofdm_v2_0_destroy Return Value
o
Type Description
a
hi ati
l
Structures
m
n
There are several C model structures.
-D OT nth for
xdfe_ofdm_v2_0_config
c
Re CD ika In
n
Model configuration parameters.
io
Table 29: xdfe_ofdm_v2_0_config
or t sr ial
ut
Field Name Type Description
t f a to nt
name const char* Instance name
rib
sample_width_in xip_uint Input sample width
d ide
sample_width_out xip_uint Output sample width
ist
num_antenna xip_uint Number of Antennas (2,4,8)
antenna_intlv xip_uint Antenna Interleave
ofdm_type xip_uint OFDM operation type (DL=0, UL=1)
se f
lo on
tuser_width xip_uint TUSER width
xdfe_ofdm_v2_0_cc_sequence
sc C
Defines the CC sequence for sample output.

Di D
Table 30: xdfe_ofdm_v2_0_cc_sequence

AM

length xip_uint Length of the CC sequence
CCID[XDFE_OFDM_V2_0_MAX_CC_NUM] xip_int A fixed size (16) array of integers used
No
to store the CC sequence (-1 means

empty slot)
xdfe_ofdm_v2_0_ft_sequence
Defines the FT sequence for packet input.
Table 31: xdfe_ofdm_v2_0_ft_sequence

length xip_uint Length of the FT sequence
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
ta n
Table 31: xdfe_ofdm_v2_0_ft_sequence (cont'd)
o
a
hi ati
CCID[XDFE_OFDM_V2_0_MAX_CC_NUM] xip_int A fixed size (16) array of integers used
to store the FT sequence.
l
m
xdfe_ofdm_v2_0_carrier_cfg
n
Defines carrier configuration for a single CC.
-D OT nth for
Table 32: xdfe_ofdm_v2_0_carrier_cfg
c
Re CD ika In
n
io
numerology xip_uint Numerology used to show the sub-
carrier spacing (SCS) for the CC (0 = 15
or t sr ial kHz to 4=240 kHz are supported SCS)
ut
num_subcarriers xip_uint Number of sub-carriers used for the CC
fft_size xip_uint FFT size in log2 used for the CC
t f a to nt
rib
comms_standard xip_uint Communication standard. (0 = 5G NR, 1
= LTE)
d ide
scale_factor xip_uint Scale factor to scale the output of the
ist
FFT. Scale factor is in 0Q10 format.
outputdelay xip_uint Delay compensation used for the CC
ccid xip_int CCID of the CC
se f
lo on
xdfe_ofdm_v2_0_cc_cfg
sc C
Defines Carrier configuration, FT and CC sequence for the programmed CCs.
Table 33: xdfe_ofdm_v2_0_cc_cfg

Di D

AM
ccseq xdfe_ofdm_v2_0_cc_sequence CC sequence

ftseq xdfe_ofdm_v2_0_ft_sequence FT sequence
cccfg[XDFE_OFDM_V2_0_MAX_CC_NUM] xdfe_ofdm_v2_0_carrier_cfg A fixed sized array of data structure.
No
xdfe_ofdm_v2_0_saturation
Defines the structure to report saturation in the FFT output.
Table 34: xdfe_ofdm_v2_0_saturation

ccid xip_uint CCID of the CC where saturation occurs
saturation xip_uint Number of times saturation occurs
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
xdfe_ofdm_v2_0_status
ta n o
Defines the status to be reported by OFDM.
a
hi ati
Table 35: xdfe_ofdm_v2_0_status
l
m
n
cc_update_triggered xip_int CC update triggered.
-D OT nth for
ft_cc_sequence_error xip_int Sequence Error in FT or CC domain
saturation xdfe_ofdm_v2_0_saturation Saturation data structure
c
Re CD ika In
n
io
Compiling and Linking
or t sr ial
ut
Place the header files (xdfe_ofdm_v2_0_bitacc_cmodel.h and
t f a to nt
xip_common_bitacc_cmodel.h) with other header files in your project.
rib
Compilation varies from platform to platform but GCC 6.2.0 or later is recommended.
d ide
Linux
ist
To compile the example code, run_bitacc_cmodel.c, follow these steps:
se f
lo on
1. Ensure that the directory containing the file

libIp_xdfe_ofdm_v2_0_bitacc_cmodel.so is present on your $LD_LIBRARY_PATH
environment variable. This shared library is referenced during the compilation and linking
sc C
process.
2. Place the header file and C++ source file in a single directory. Then in that directory, compile
Di D
using the GNU C++ compiler:

AM
gcc -x c++ -I. -L. -lIp_xdfe_ofdm_v2_0_bitacc_cmodel -Wl,-rpath,. -o

run_bitacc_cmodel run_bitacc_cmodel.c
Windows
No
When compiling on Windows, the symbol 'NT' must be defined either by a compiler option or in
the user source code before the xdfe_ofdm_v2_0_bitacc_cmodel.h header file is included.
Link to the import library libIp_xdfe_ofdm_v2_0_bitacc_cmodel.lib. For example, in

Microsoft Visual Studio.NET, in Project Properties, under Linker > Input, for Additional
Dependencies, specify libIp_xdfe_ofdm_v2_0_bitacc_cmodel.lib.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
ta n
MATLAB Interface
o
a
hi ati
A MEX function and MATLAB® software class are provided to simplify the integration with
l
MATLAB®. The MEX function provides a low-level wrapper around the underlying C model,
while the class file provides a convenient interface to the MEX function.
m
n
Compiling
-D OT nth for
Source code for a MATLAB MEX function is provided. This can be compiled within MATLAB with
c
Re CD ika In
the use of a helper script make_xdfe_ofdm_v2_0_mex.m. This script will use the contents of
n
the C model zip file to create a MEX object that can then be used within MATLAB.
io
Compilation varies from platform to platform but GCC 6.2.0 or later is recommended.
or t sr ial
ut
Installation
t f a to nt
rib
To use the MEX function, it must first be compiled and must be present on the MATLAB search
d ide
path. This can be achieved in two ways:
ist
1. Add the directory where the compiled MEX function is located to the MATLAB search path
(see the MATLAB addpath function).
se f
lo on
2. Copy the files to a location already on the MATLAB search path.
As with all uses of the C model, the correct C model libraries also need to be present on the
sc C
platform library search path, either PATH or LD_LIBRARY_PATH.
Running
Di D
AM
Once the MEX object has been compiled it can then be called by a MATLAB script via the
provided MATLAB class. The class provides an equivalent MATLAB function for each C Model
function in the API as well as an model object.
No
Calling these functions automatically translates the MATLAB data-types, passes them to the C
Model, and executes the relevant function. Memory allocation and deallocation within the C
Model is automatically taken care of.
An example script run_xdfe_ofdm_v2_0_mex.m is provided to show how the MEX object is

called via the MATLAB class.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
MATLAB Class
ta n o
The @xdfe_ofdm_v2_0_bitacc class handles the create/destroy semantics on the C model.
a
hi ati
The class provides objects for each of the data, configuration and control structures, defined for
l
the C model and previously described in Structures.
m
The class provides methods equivalent to the C model functions previously described in
n
Functions.
-D OT nth for
All structure elements have MATLAB type double. MATLAB arrays are used with the mapping of
types between MATLAB and the C model.
c
Re CD ika In
n
Table 36: MATLAB to C model Type Mapping
io
or t sr ial C Model Type MATLAB Type
ut
xip_bit uint8
xip_uint uint32
t f a to nt
rib
xip_int int32
xip_real double
d ide
xip_complex complex double
ist
Constructor
se f
lo on
[model]=xdfe_ofdm_v2_0_bitacc
This method constructs a model object using the default configuration.

sc C
[model]=xdfe_ofdm_v2_0_bitacc(config)
Di D
This method constructs a model object using the configuration structure passed in.
AM
Get Version
[version]=get_version(model)
No
This method returns the version string of the C model library used.
Default Configuration
[config]=default_config(model)
This method returns a configuration structure populated with the default values.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
Reset
ta n o
reset(model)
a
hi ati
This method resets the model as per the C model function.
l
m
Set Carrier Configuration
n
-D OT nth for
set_cc_cfg(model,cc_cfg)
This method sets the internal carrier configuration of the model with the given carrier
c
configuration.
Re CD ika In
n
io
Get Status
or t sr ial
ut
[status]=get_status(model)
t f a to nt
rib
This method returns a status structure populated with the current status of the model. This also
clears the internal overflow status of the model.
d ide
Do
ist
[data_out, tid_out, status] = do(model, cc_cfg, data_in, tid_in,
se f
phase_correction)
lo on
The method returns the output data and tid from the DFE OFDM model. The data_in is a two
dimensional MATLAB complex double array.
sc C
The tid_in is used only in the UL mode and is a one dimensional MATLAB integer array that
carries the corresponding TID of the data. The phase_correction is a one-dimensional
Di D
MATLAB complex double array. (Phase_correction is not supported in v2.0; therefore, initialize
the array with 512 complex (complex(0,0)). The data_out output is a two-dimensional MATLAB
AM
complex double array. The tid_out output is a one dimensional MATLAB integer array.
Destroy
No
destroy(model)
This method destroys the model instance and free any resources allocated.
Example
To run the example script:
1. Compile the MEX function with the make_xdfe_ofdm_v2_0_mex.m script (see Compiling).
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 6: C Model
2. Install the MEX function (see Installation).
ta n
3. Execute the run_xdfe_ofdm_v2_0_mex.m script.
o
a
hi ati
l
m
n
-D OT nth for
c
Re CD ika In
n
io
or t sr ial
ut
t f a to nt
rib
d ide
ist
se f
lo on
sc C
Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Chapter 7: Example Design
Chapter 7
ta n o
a
hi ati
l
Example Design
m
n
-D OT nth for
This section contains information about the RFSoC DFE OFDM IP example design provided in
the AMD Vivado™ Design Suite. The example design can configure the IP core for either
c
downlink or uplink operation. In downlink operation, FT packets are input according to the FT
Re CD ika In
n
sequence definition and CC samples are output according to the CC sequence definition. For
uplink operation, CC samples are input as specified by the CC sequence and FT packets are
io
output as described in the FT sequence.
or t sr ial
ut
Note: The example design is provided for simulation purposes only. Synthesis, implementation, and
bitstream generation are not supported. Use of the example design is only supported in Linux.
t f a to nt
rib
d ide
Overview
ist
The following figures show the structure of the example design, as viewed in the Vivado IP
se f
lo on
integrator.
Figure 9: Example Design for DL Configuration

sc C
Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 10: Example Design or UL Configuration
ta n o
a
hi ati
l
m
n
-D OT nth for
c
Re CD ika In
n
io
or t sr ial
Both designs consist of an instance of the RFSoC DFE OFDM IP core, accompanied by a stimulus
ut
generator and output logger. The stimulus generator (<corename>_stimulus_gen_wrapper)
and output logger (<corename>_output_checker_wrapper) modules are provided as
t f a to nt
rib
SystemVerilog source files, contained within Verilog wrappers. There is also an
AMD Zynq™ UltraScale+™ RFSoC processing system and associated AXI infrastructure to run the
d ide
example software application which configures and controls the core.
ist
se f
lo on
Running the Example Design

After the example design project has been created for the specified operation (DL or UL), the
sc C
output products and HDL wrapper are automatically generated. All design parameters are
inherited from the core instance from which the example design was generated and should not
Di D
be modified.
AM
The QEMU emulator software requires an ELF binary executable file to be specified for
operation. The RFSoC DFE OFDM example design includes an example software program which
makes use of the core's software driver and demonstrates the use of the API functions to
No
configure and control the core. This program reads the configuration of the core and adapts its
operation based on the parameters. The example software is provided both as source code and
as a pre-compiled ELF file for use with QEMU. The pre-compiled ELF file can only be used with
DL-OFDM. Use the scripts provided to launch QEMU.
To run the simulation, follow these steps:
1. Ensure the current working directory of the Vivado Tcl Console is the imports directory
within the base project directory using the cd [get_property DIRECTORY
[current_project]]/imports command.
2. To launch QEMU using the default configuration-agnostic ELF file that ships with the
example design, use the source run_qemu_default.tcl command.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
3. To run the simulation, select SIMULATION → Run Simulation → Run Behavioral Simulation
ta n
from the Vivado Flow Navigator panel. A set of waveform signals will be loaded automatically
o
to give visibility of activity on the AXI4-Lite and AXI4-Stream interfaces of the core.
a
hi ati
4. Click Run All to run the simulation. The sequence of events in the example design simulation
l
is described below. The simulation will automatically stop when the TLAST signal reaches the
output logger core.
m
n
Note: To re-run the simulation, the simulation window must be closed to end the current QEMU processes.
QEMU must then be re-started and the simulation run as described above. It is not possible to use the
-D OT nth for
Restart operation within the simulator directly. Should the simulation terminate unnaturally, the QEMU
processes might not automatically terminate. In this case, manually terminate QEMU before attempting to
c
start a new simulation.
Re CD ika In
n
io
or t sr ial
Stimulus Generation and Data Logging
ut
t f a to nt
The stimulus generator drives all signals on the AXI4-Stream data input to the core and monitors
rib
register writes on the AXI4-Lite control interface. The monitoring interface allows the stimulus
generator to update its internal configuration dynamically to match that of the RFSoC DFE
d ide
OFDM IP core. Only the relevant subset of the register map is monitored, including CC sequence
ist
length, trigger, and CC configurations.
se f
The following figure illustrates when a trigger occurs with respect to API calls, in the order they
lo on
appear in the example design default program.

sc C
Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Figure 11: DFE OFDM API Flow Diagram
ta n o
Start
a
hi ati
l
XDfeOfdm_Initialize()
m
n
XDfeOfdm_TriggerCfg()
-D OT nth for
XDfeOfdm_SetTriggersCfg()
c
Re CD ika In
n
io
XDfeOfdm_Activate() Activate Trigger
or t sr ial
ut
XDfeOfdm_ClearEventStatus(0)
t f a to nt
rib
XDfeOfdm_GetEmptyCCCfg()
d ide
ist XDfeOfdm_AddCCtoCCCfg()
se f
lo on
XDfeOfdm_SetNextCCCfgAndTrigger() CC Update Trigger

sc C
XDfeOfdm_GetEventStatus()
Di D
XDfeOfdm_ClearEventStatus() Data
X27046-090922
AM
At the end of the setup phase, the XDfeOfdm_Activate API function is called. The stimulus
generator ensures that the activate trigger event occurs shortly after this function call. By
default, the activate trigger is active-High, single shot and occurs on TBASE_TUSER bit 3 for
No
downlink or UL_DIN_TUSER bit 3 for uplink.
The CCs are then added one by one. The stimulus generator ensures that the CC update trigger
event occurs shortly after each call to XDfeOfdm_AddCC to put the changes into effect. By
default, the CC update trigger is active-High, single shot and occurs on TBASE_TUSER bit 3 for
downlink or UL_DIN_TUSER bit 3 for uplink. Once the last CC has been added, the stimulus
generator will start reading data from the input data files and providing it to the core on
s_axis_dl_din_tdata for DL and s_axis_ul_din_tdata for UL.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
By default, the example design only supports OFDM in DL operation and a single CC with CCID
ta n
= 3, SCS = 15 kHz, and number of active sub-carriers = 1,272. This corresponds to a 20 MHz
o
bandwidth 5G NR CC with 30.72 MSPS baseband rate. The antenna interleave is configurable
a
hi ati
and extracted from the RFSoC DFE OFDM IP core. The FT Sequence being produced by the
l
stimulus generator is shown in the following figures for antenna interleave 1, 2, and 4 cases.
m
The FramePulse indicates the beginning of a 10 ms frame. The sgNo is the symbol group number,
n
and there are a total of 14 such symbol groups per 1 ms duration. Symbol group 0 and 7 consist
of 35,328 cycles at 491.52 MHz, whereas other symbol groups are 35,072 cycles long. sgNo is
-D OT nth for
not an input to the RFSoC DFE OFDM IP core. This is added in the timing diagram to show
relative packet timings in the symbol group. The RFSoC DFE OFDM IP core expects single
c
packets for 15 kHz SCS in a single symbol group, whereas it expects two packets for 30 kHz SCS.
Re CD ika In
n
io
Figure 12: FT Sequence for CCID = 3 and Antenna Interleave (ailv) = 1
or t sr ial
ut
t f a to nt
rib
d ide
ist
se f
Figure 13: FT Sequence for CCID = 3 and Antenna Interleave (ailv) = 2

lo on
sc C
Di D
AM
Figure 14: FT Sequence for CCID=3 and Antenna Interleave (ailv) = 4

No
The corresponding CCID sequence produced by the core for antenna interleave 1, 2, and 4 are
shown in the following figures.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Framing information is sent on dl_dout_tuser. The clock cycle following the
ta n
dl_dout_tuser framing pulse defines the first sample of the configured CCID sequence. The
o
sample rate of CCID = 3 in the example design is 30.72 MSPS. Because the core supports a
a
hi ati
maximum output sampling rate of 491.52 MSPS, CCID = 3 should occupy only one of the 16
l
available slots as shown in the following figure. Figure 12: FT Sequence for CCID = 3 and
Antenna Interleave (ailv) = 1 provides the CC sequence when antenna interleave = 2 is
m
configured. In this case, two of the available 16 slots are allocated to output the two samples of
n
the twos for the CCID. Figure 14: FT Sequence for CCID=3 and Antenna Interleave (ailv) = 4
-D OT nth for
shows the case when antenna interleave = 4.
Figure 15: CC Sequence for CCID = 3 when Antenna Interleave (ailv) = 1
c
Re CD ika In
n
io
or t sr ial
ut
t f a to nt
rib
d ide
ist
se f
lo on

sc C
Di D
AM
The antenna interleave part of the waveform on TID[3:0] is shown for reference only. The
No
antenna interleave is a parameter for core configuration during instantiation and is independent
of the CC sequence and the number of CCs in use.
The stimulus generator sources component carrier time series data from an ASCII file named
dfeofdm_ex_din_ccid_00.txt. For the uplink operation, the stimulus generator uses
$random() function to generate random I and Q samples for the configured CC sequence. The
directory in which the data input files are located is specified by the module parameter
DIN_DIRECTORY. The default path is the imports directory within the Vivado project.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
The data output logger module saves all data seen on the TDATA output from the core to a
ta n
collection of ASCII files, one for each CCID, for offline analysis. The files are named
o
dfeofdm_ex_dout_ccid_<x>.txt, where <x> indicates the CCID as described above. The
a
hi ati
output directory is specified by the module parameter DOUT_DIRECTORY. The output logger will
l
create the necessary file when a new CCID is seen on TID. If output files already exist from
previous runs, they are overwritten.
m
n
-D OT nth for
Modifying the Example Program
c
Re CD ika In
n
The run_vitis.tcl script is provided to create an AMD Vitis™ project and generate an ELF
io
file for use with QEMU. The C source code provided for the Vitis project is the same as that used
to generate the default, configuration-agnostic ELF file that is delivered with the example design.
or t sr ial
ut
The script should be run through the AMD Vivado™ Tcl console using the command
sourcerun_vitis.tcl.
t f a to nt
rib
Vitis console outputs will be displayed in the terminal window from which Vivado was launched.
d ide
The Vitis project will be created in the vitis_workspace directory within the example design
ist
project's root directory. Once this script has run and the Vitis project has been generated, it is
recommended to use the Vitis GUI for subsequent C code updates.
se f
lo on
To launch QEMU using a custom ELF file generated in this way, use the command
sourcerun_qemu_custom.tcl in place of the default Tcl script when preparing to launch a
simulation.
sc C
Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix A: Upgrading
Appendix A
ta n o
a
hi ati
l
Upgrading
m
n
-D OT nth for
This appendix is not applicable for the first release of the core.
c
Re CD ika In
n
io
or t sr ial
ut
t f a to nt
rib
d ide
ist
se f
lo on
sc C
Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix B: Debugging
Appendix B
ta n o
a
hi ati
l
Debugging
m
n
-D OT nth for
This appendix includes details about resources available on the AMD Support website and
debugging tools.
c
If the IP requires a license key, the key must be verified. The AMD Vivado™ design tools have
Re CD ika In
n
several license checkpoints for gating licensed IP through the flow. If the license check succeeds,
io
the IP can continue generation. Otherwise, generation halts with an error. License checkpoints
or t sr ial
are enforced by the following tools:
ut
• Vivado Synthesis
t f a to nt
rib
• Vivado Implementation
• write_bitstream (Tcl command)
d ide
ist
IMPORTANT! IP license level is ignored at checkpoints. The test confirms a valid license exists. It does not
check IP license level.
se f
lo on
Finding Help with AMD Adaptive Computing

sc C
Solutions
Di 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
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.
No
Documentation
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.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Answer Records
ta n o
Answer Records include information about commonly encountered problems, helpful information
a
hi ati
on how to resolve these problems, and any known issues with an AMD Adaptive Computing
l
product. Answer Records are created and maintained daily to ensure that users have access to
the most accurate information available.
m
n
Answer Records for this core can be located by using the Search Support box on the main
-D OT nth for
Support web page. To maximize your search results, use keywords such as:
• Product name
c
Re CD ika In
n
• Tool message(s)
io
• Summary of the issue encountered
or t sr ial
A filter search is available after results are returned to further target the results.
ut
Technical Support
t f a to nt
rib
AMD Adaptive Computing provides technical support on the Community Forums for this AMD
d ide
ist
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:
se f
• Implement the solution in devices that are not defined in the documentation.
lo on
• Customize the solution beyond that allowed in the product documentation.

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

Di D
AM
Debug Tools
There are many tools available to address RFSoC DFE OFDM IP design issues. It is important to
No
know which tools are useful for debugging various situations.
Vivado Design Suite Debug Feature

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
application and integrated block port signals in hardware. Captured signals can then be analyzed.
This feature in the Vivado IDE is used for logic debugging and validation of a design running in
AMD devices.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
The Vivado logic analyzer is used to interact with the logic debug LogiCORE IP cores, including:
ta n o
• ILA 2.0 (and later versions)
a
hi ati
• VIO 2.0 (and later versions)
l
See the Vivado Design Suite User Guide: Programming and Debugging (UG908).
m
n
-D OT nth for
Hardware Debug
c
Re CD ika In
n
Hardware issues can range from link bring-up to problems seen after hours of testing. This
section provides debug steps for common issues. The AMD Vivado™ debug feature is a valuable
io
resource to use in hardware debug. The signal names mentioned in the following individual
or t sr ial
sections can be probed using the debug feature for debugging the specific problems.
ut
General Checks
t f a to nt
rib
Ensure that all the timing constraints for the core were properly incorporated from the example
d ide
ist
design and that all constraints were met during implementation.
• Does it work in post-place and route timing simulation? If problems are seen in hardware but
se f
not in timing simulation, this could indicate a PCB issue. Ensure that all clock sources are
lo on
active and clean.

• If using MMCMs in the design, ensure that all MMCMs have obtained lock by monitoring the
locked port.
sc C
• If your outputs go to 0, check your licensing.

Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix C: Application Software Development
Appendix C
ta n o
a
hi ati
l
Application Software Development
m
n
-D OT nth for
c
Overview
Re CD ika In
n
io
The API is used for the configuration and control of the IP core.
or t sr ial
ut
It is written in C code and compiles and links with the Libmetal library. The API can be built for
Linux or bare-metal.
t f a to nt
rib
Table 37: Quick Function Reference
d ide
istType
XDfeOfdm *
Member
XDfeOfdm_InstanceInit
Arguments
const char * DeviceNodeName

se f
lo on
void XDfeOfdm_InstanceClose
XDfeOfdm * InstancePtr
void XDfeOfdm_Reset
sc C
void XDfeOfdm_Configure
Di D
XDfeOfdm_Cfg * Cfg
AM
void XDfeOfdm_Initialize
XDfeOfdm_Init * Init
No
void XDfeOfdm_Activate
bool EnableLowPower
void XDfeOfdm_Deactivate
XDfeOfdm_StateId XDfeOfdm_GetStateID
void XDfeOfdm_GetCurrentCCCfg
const XDfeOfdm * InstancePtr
XDfeOfdm_CCCfg * CurrCCCfg
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 37: Quick Function Reference (cont'd)
o
Type Member Arguments
a
hi ati
void XDfeOfdm_GetEmptyCCCfg
l
XDfeOfdm_CCCfg * CCCfg
m
u32 XDfeOfdm_AddCCtoCCCfg
n
-D OT nth for
s32 CCID
u32 CCSeqBitmap
c
const XDfeOfdm_CarrierCfg * CarrierCfg
Re CD ika In
n
XDfeOfdm_FTSequence * FTSeq
io
void XDfeOfdm_GetCarrierCfg
or t sr ial const XDfeOfdm * InstancePtr
ut
s32 CCID
u32 * CCSeqBitmap
t f a to nt
rib
XDfeOfdm_CarrierCfg * CarrierCfg
d ide
u32 XDfeOfdm_RemoveCCfromCCCfg
ist XDfeOfdm_CCCfg * CCCfg

s32 CCID
se f
lo on
u32 XDfeOfdm_UpdateCCinCCCfg
s32 CCID
sc C
void XDfeOfdm_SetNextCCCfg
Di D

const XDfeOfdm_CCCfg * NextCCCfg
AM
u32 XDfeOfdm_EnableCCUpdateTrigger
u32 XDfeOfdm_SetNextCCCfgAndTrigger
No

u32 XDfeOfdm_AddCC
s32 CCID
u32 CCSeqBitmap
XDfeOfdm_FTSequence * FTSeq
u32 XDfeOfdm_RemoveCC
s32 CCID
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 37: Quick Function Reference (cont'd)
o
Type Member Arguments
a
hi ati
u32 XDfeOfdm_UpdateCC
l
s32 CCID
m
n
void XDfeOfdm_GetTriggersCfg
-D OT nth for
XDfeOfdm_TriggerCfg * TriggerCfg
c
void XDfeOfdm_SetTriggersCfg
Re CD ika In
n
XDfeOfdm_TriggerCfg * TriggerCfg
io
void XDfeOfdm_SetTuserOutFrameLocation
or t sr ial const XDfeOfdm * InstancePtr
ut
u32 TuserOutFrameLocation
t f a to nt
u32 XDfeOfdm_GetTuserOutFrameLocation
rib
d ide
void XDfeOfdm_SetTUserDelay
u32 ist XDfeOfdm_GetTUserDelay

u32 Delay
se f

lo on
u32 XDfeOfdm_GetDataLatency
sc C
void XDfeOfdm_GetVersions
XDfeOfdm_Version * SwVersion
XDfeOfdm_Version * HwVersion
Di D
void XDfeOfdm_GetEventStatus
AM
XDfeOfdm_Status * Status
void XDfeOfdm_ClearEventStatus
No
const XDfeOfdm_Status * Status
void XDfeOfdm_SetInterruptMask
const XDfeOfdm_InterruptMask * Mask
void XDfeOfdm_GetInterruptMask
XDfeOfdm_InterruptMask * Mask
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Functions
ta n o
a
XDfeOfdm_InstanceInit
hi ati
l
Initializes one instance of the OFDM driver and traverses the "/sys/bus/platform/device"
directory (in Linux) to find the registered OFDM device with the name DeviceNodeName.
m
n
The first available slot in the instances array XDfeOfdm_Ofdm[] will be taken as a
-D OT nth for
DeviceNodeName object. On success, it moves the state machine to a Ready state, while on
failure, it stays in a Not Ready state.
c
Re CD ika In
n
Prototype
io
XDfeOfdm * XDfeOfdm_InstanceInit(const char *DeviceNodeName);
or t sr ial
ut
Parameters
t f a to nt
rib
The following table lists the XDfeOfdm_InstanceInit function arguments.
d ide
Table 38: XDfeOfdm_InstanceInit Arguments
ist Type
const char *
Member
DeviceNodeName Device node name.
Description
se f
lo on
Returns
• Pointer to the instance if successful.

sc C
• NULL on error.
Di D
XDfeOfdm_InstanceClose
AM
Closes the instances of the OFDM driver and moves the state machine to a Not Ready state.
Prototype
No
void XDfeOfdm_InstanceClose(XDfeOfdm *InstancePtr);
Parameters
The following table lists the XDfeOfdm_InstanceClose function arguments.
Table 39: XDfeOfdm_InstanceClose Arguments
Type Member Description

XDfeOfdm * InstancePtr Pointer to the OFDM instance.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
XDfeOfdm_Reset
ta n o
Resets the OFDM instance and puts block into a reset state.
a
hi ati
l
Prototype
m
void XDfeOfdm_Reset(XDfeOfdm *InstancePtr);
n
-D OT nth for
Parameters
The following table lists the XDfeOfdm_Reset function arguments.
c
Re CD ika In
n
Table 40: XDfeOfdm_Reset Arguments
io
or t sr ial
ut
t f a to nt
XDfeOfdm_Configure
rib
d ide
Reads configuration from device tree/xparameters.h and IP registers.
ist
Removes the S/W reset and moves the state machine to a configured state.
se f
Prototype
lo on
void XDfeOfdm_Configure(XDfeOfdm *InstancePtr, XDfeOfdm_Cfg *Cfg);

sc C
Parameters
The following table lists the XDfeOfdm_Configure function arguments.

Di D
Table 41: XDfeOfdm_Configure Arguments

AM

No
XDfeOfdm_Cfg * Cfg Configuration data container.
XDfeOfdm_Initialize
Initializes the OFDM driver and moves the state machine to an initialized state.
Prototype
void XDfeOfdm_Initialize(XDfeOfdm *InstancePtr, XDfeOfdm_Init *Init);
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Parameters
ta n o
The following table lists the XDfeOfdm_Initialize function arguments.
a
hi ati
Table 42: XDfeOfdm_Initialize Arguments
l
m
n
XDfeOfdm_Init * Init Initialization data container.
-D OT nth for
XDfeOfdm_Activate
c
Re CD ika In
n
Activates OFDM and moves the state machine to an activated state.
io
or t sr ial
Prototype
ut
void XDfeOfdm_Activate(XDfeOfdm *InstancePtr, bool EnableLowPower);
t f a to nt
rib
Parameters
d ide
The following table lists the XDfeOfdm_Activate function arguments.
ist
Table 43: XDfeOfdm_Activate Arguments
se f
lo on

bool EnableLowPower Flag indicating low power.

sc C
XDfeOfdm_Deactivate
Di D
Deactivates OFDM and moves the state machine to an initialised state.

AM
Prototype
No
void XDfeOfdm_Deactivate(XDfeOfdm *InstancePtr);
Parameters
The following table lists the XDfeOfdm_Deactivate function arguments.
Table 44: XDfeOfdm_Deactivate Arguments

PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
XDfeOfdm_GetStateID
ta n o
Gets the state machine state ID.
a
hi ati
l
Prototype
m
XDfeOfdm_StateId XDfeOfdm_GetStateID(XDfeOfdm *InstancePtr);
n
-D OT nth for
Parameters
The following table lists the XDfeOfdm_GetStateID function arguments.
c
Re CD ika In
n
Table 45: XDfeOfdm_GetStateID Arguments
io
or t sr ial
ut
t f a to nt
rib
Returns
State machine StateID

d ide
ist
XDfeOfdm_GetCurrentCCCfg
se f
Returns the current CC configuration.

lo on
Not used slot ID in a sequence (Sequence.CCID[Index]) are represented as (-1), not the value in
registers.
sc C
Note: For a sequence conversion, see XDfeOfdm_AddCCtoCCCfg() comment.

Di D
Prototype
AM
void XDfeOfdm_GetCurrentCCCfg(const XDfeOfdm *InstancePtr, XDfeOfdm_CCCfg

*CurrCCCfg);
Parameters
No
The following table lists the XDfeOfdm_GetCurrentCCCfg function arguments.
Table 46: XDfeOfdm_GetCurrentCCCfg Arguments

const XDfeOfdm * InstancePtr Pointer to the OFDM instance.
XDfeOfdm_CCCfg * CurrCCCfg CC configuration container.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
XDfeOfdm_GetEmptyCCCfg
ta n o
Returns configuration structure CCCfg with CCCfg->CCSequence.Length value set in
a
hi ati
XDfeOfdm_Configure() , array CCCfg->CCSequence.CCID[] members are set to not used
l
value (-1) and the other CCCfg members are set to 0.
m
Prototype
n
-D OT nth for
void XDfeOfdm_GetEmptyCCCfg(const XDfeOfdm *InstancePtr, XDfeOfdm_CCCfg
*CCCfg);
c
Parameters
Re CD ika In
n
The following table lists the XDfeOfdm_GetEmptyCCCfg function arguments.
io
or t sr ial
Table 47: XDfeOfdm_GetEmptyCCCfg Arguments
ut
t f a to nt
rib
XDfeOfdm_CCCfg * CCCfg CC configuration container.

d ide
ist
XDfeOfdm_AddCCtoCCCfg
se f
Adds specified CCID, with specified configuration, to a local CC configuration structure.

lo on
If there is insufficient capacity for the new CC the function will return an error. Initiates CC
update (enable CCUpdate trigger TUSER Single Shot).
sc C
The returned CCCfg.CCSequence is translated as there is no explicit indication that

SEQUENCE[i] is not used - 0 can define the slot as either used or not used. Sequence data that is
Di D
returned in the CCIDSequence is not the same as what is written in the registers. The translation
is:
AM
• CCIDSequence.CCID[i] = -1 - if [i] is unused slot

• CCIDSequence.CCID[i] = CCID - if [i] is used slot
No
• A returned CCIDSequence->Length = length in register + 1
Prototype
u32 XDfeOfdm_AddCCtoCCCfg(XDfeOfdm *InstancePtr, XDfeOfdm_CCCfg *CCCfg, s32

CCID, u32 CCSeqBitmap, const XDfeOfdm_CarrierCfg *CarrierCfg,
XDfeOfdm_FTSequence *FTSeq);
Parameters
The following table lists the XDfeOfdm_AddCCtoCCCfg function arguments.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 48: XDfeOfdm_AddCCtoCCCfg Arguments
o
a
hi ati
l
XDfeOfdm_CCCfg * CCCfg Component carrier (CC) configuration container.
s32 CCID CC ID.
m
u32 CCSeqBitmap CC slot position container.
n
const CarrierCfg CC configuration container.
-D OT nth for
XDfeOfdm_CarrierCfg
*
FTSeq Fourier transform sequence container.
c
XDfeOfdm_FTSequence
*
Re CD ika In
n
io
Returns
or t sr ial
• XST_SUCCESS if successful.
ut
• XST_FAILURE if error occurs.
t f a to nt
rib
XDfeOfdm_GetCarrierCfg
d ide
ist
Returns the current CCID carrier configuration.
Prototype
se f
lo on
void XDfeOfdm_GetCarrierCfg(const XDfeOfdm *InstancePtr, XDfeOfdm_CCCfg

*CCCfg, s32 CCID, u32 *CCSeqBitmap, XDfeOfdm_CarrierCfg *CarrierCfg);
sc C
Parameters
The following table lists the XDfeOfdm_GetCarrierCfg function arguments.

Di D
Table 49: XDfeOfdm_GetCarrierCfg Arguments

AM

No
s32 CCID CC ID.

u32 * CCSeqBitmap CC slot position container.
XDfeOfdm_CarrierCfg CarrierCfg CC configuration container.
*
XDfeOfdm_RemoveCCfromCCCfg
Removes specified CCID from a local CC configuration structure.
Note: For a sequence conversion see XDfeOfdm_AddCCtoCCCfg comment.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Prototype
ta n o
u32 XDfeOfdm_RemoveCCfromCCCfg(XDfeOfdm *InstancePtr, XDfeOfdm_CCCfg
a
*CCCfg, s32 CCID, XDfeOfdm_FTSequence *FTSeq);
hi ati
l
Parameters
m
The following table lists the XDfeOfdm_RemoveCCfromCCCfg function arguments.
n
-D OT nth for
Table 50: XDfeOfdm_RemoveCCfromCCCfg Arguments
c
Re CD ika In
n
io
s32 CCID CC ID.
or t sr ial
ut
Returns
t f a to nt
rib
d ide
ist
XDfeOfdm_UpdateCCinCCCfg
se f
Updates a specified CCID with the specified configuration to a local CC configuration structure.
lo on
If there is insufficient capacity for the new CC the function will return an error.
sc C
Prototype
u32 XDfeOfdm_UpdateCCinCCCfg(XDfeOfdm *InstancePtr, XDfeOfdm_CCCfg *CCCfg,

Di D
s32 CCID, const XDfeOfdm_CarrierCfg *CarrierCfg, XDfeOfdm_FTSequence

*FTSeq);
AM
Parameters
The following table lists the XDfeOfdm_UpdateCCinCCCfg function arguments.

No
Table 51: XDfeOfdm_UpdateCCinCCCfg Arguments

s32 CCID CC ID.

XDfeOfdm_CarrierCfg
*
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Returns
ta n o
a
hi ati
l
XDfeOfdm_SetNextCCCfg
m
n
Sets the next CC configuration.
-D OT nth for
Prototype
c
Re CD ika In
n
void XDfeOfdm_SetNextCCCfg(const XDfeOfdm *InstancePtr, const
XDfeOfdm_CCCfg *NextCCCfg);
io
Parameters
or t sr ial
ut
The following table lists the XDfeOfdm_SetNextCCCfg function arguments.
t f a to nt
rib
Table 52: XDfeOfdm_SetNextCCCfg Arguments
d ide
ist
const XDfeOfdm *
const XDfeOfdm_CCCfg
InstancePtr
NextCCCfg
Pointer to the OFDM instance.
Next CC configuration container.

se f
*
lo on
XDfeOfdm_EnableCCUpdateTrigger
sc C
Reads the triggers and sets the enable bit of Update trigger.
If Mode = IMMEDIATE, the trigger will be applied immediately.

Di D
Prototype
AM
u32 XDfeOfdm_EnableCCUpdateTrigger(const XDfeOfdm *InstancePtr);

No
Parameters
The following table lists the XDfeOfdm_EnableCCUpdateTrigger function arguments.
Table 53: XDfeOfdm_EnableCCUpdateTrigger Arguments

Returns
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n o
XDfeOfdm_SetNextCCCfgAndTrigger
a
hi ati
l
Writes local CC configuration to the shadow (NEXT) registers and triggers copying from shadow
to operational registers.
m
n
Prototype
-D OT nth for
u32 XDfeOfdm_SetNextCCCfgAndTrigger(const XDfeOfdm *InstancePtr,
XDfeOfdm_CCCfg *CCCfg);
c
Re CD ika In
n
Parameters
io
The following table lists the XDfeOfdm_SetNextCCCfgAndTrigger function arguments.
or t sr ial
ut
Table 54: XDfeOfdm_SetNextCCCfgAndTrigger Arguments
t f a to nt
rib
d ide
XDfeOfdm_CCCfg * CCCfg CC configuration container.
ist
Returns
se f
lo on
sc C
XDfeOfdm_AddCC
Di D
Adds a specified CCID with specified configuration.

AM
If there is insufficient capacity for the new CC the function will return an error. Initiates CC
update (enable CCUpdate trigger TUSER Single Shot).
Note: Clear the event status with XDfeOfdm_ClearEventStatus() before running this API.
No
CAUTION! This API is deprecated in the release 2023.2. Source code will be removed from in the release
2024.1 release. The functionality of this API can be reproduced with the following API sequence:
XDfeOfdm_GetCurrentCCCfg(InstancePtr, CCCfg); XDfeOfdm_AddCCtoCCCfg(InstancePtr, CCCfg, CCID,
CCSeqBitmap, CarrierCfg, FTseq); XDfeOfdm_SetNextCCCfgAndTrigger(InstancePtr, CCCfg);
Prototype
u32 XDfeOfdm_AddCC(XDfeOfdm *InstancePtr, s32 CCID, u32 CCSeqBitmap, const

XDfeOfdm_CarrierCfg *CarrierCfg, XDfeOfdm_FTSequence *FTSeq);
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Parameters
ta n o
The following table lists the XDfeOfdm_AddCC function arguments.
a
hi ati
Table 55: XDfeOfdm_AddCC Arguments
l
m
n
s32 CCID CC ID.
-D OT nth for
u32 CCSeqBitmap Up to 16 defined slots into which a CC can be allocated. The
number of slots can be from 1 to 16 depending on system
c
initialization. The number of slots is defined by the "sequence
length" parameter which is provided during initialization. The Bit
Re CD ika In
n
offset within the CCSeqBitmap indicates the equivalent slot
number to allocate. For example, 0x0003 means the caller wants
io
the passed component carrier (CC) to be allocated to slots 0 and 1.
or t sr ial
ut
XDfeOfdm_CarrierCfg
*
FTSeq Fourier transform sequence container.
t f a to nt
XDfeOfdm_FTSequence
rib
*
d ide
Returns
ist
se f
lo on
XDfeOfdm_RemoveCC
sc C
Removes the specified CCID.
Initiates CC update (enable CCUpdate trigger TUSER Single Shot).

Di D
AM
XDfeOfdm_GetCurrentCCCfg(InstancePtr, CCCfg); XDfeOfdm_RemoveCCfromCCCfg(InstancePtr, CCCfg,
No
CCID, FTseq); XDfeOfdm_SetNextCCCfgAndTrigger(InstancePtr, CCCfg);
Prototype
u32 XDfeOfdm_RemoveCC(XDfeOfdm *InstancePtr, s32 CCID, XDfeOfdm_FTSequence

*FTSeq);
Parameters
The following table lists the XDfeOfdm_RemoveCC function arguments.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 56: XDfeOfdm_RemoveCC Arguments
o
a
hi ati
l
s32 CCID CC ID.
m
Returns
n
-D OT nth for
c
Re CD ika In
n
XDfeOfdm_UpdateCC
io
Updates a specified CCID carrier configuration and changes the gain or filter coefficients set.
or t sr ial
ut
Initiates CC update (enable CCUpdate trigger TUSER Single Shot).
t f a to nt
rib
d ide
ist
XDfeOfdm_GetCurrentCCCfg(InstancePtr, CCCfg); XDfeOfdm_UpdateCCinCCCfg(InstancePtr, CCCfg,
CCID, CarrierCfg, FTseq); XDfeOfdm_SetNextCCCfgAndTrigger(InstancePtr, CCCfg);
se f
lo on
Prototype
u32 XDfeOfdm_UpdateCC(XDfeOfdm *InstancePtr, s32 CCID, const

sc C
XDfeOfdm_CarrierCfg *CarrierCfg, XDfeOfdm_FTSequence *FTSeq);
Parameters
Di D
The following table lists the XDfeOfdm_UpdateCC function arguments.

AM
Table 57: XDfeOfdm_UpdateCC Arguments

No
s32 CCID CC ID.

XDfeOfdm_CarrierCfg
*
Returns
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
XDfeOfdm_GetTriggersCfg
ta n o
Returns the current trigger configuration.
a
hi ati
l
Prototype
m
void XDfeOfdm_GetTriggersCfg(const XDfeOfdm *InstancePtr,
XDfeOfdm_TriggerCfg *TriggerCfg);
n
-D OT nth for
Parameters
c
The following table lists the XDfeOfdm_GetTriggersCfg function arguments.
Re CD ika In
n
Table 58: XDfeOfdm_GetTriggersCfg Arguments
io
or t sr ialType Member Description
ut
t f a to nt
XDfeOfdm_TriggerCfg TriggerCfg Trigger configuration container.
rib
*
d ide
XDfeOfdm_SetTriggersCfg
ist
Sets the trigger configuration.
se f
lo on
Prototype
void XDfeOfdm_SetTriggersCfg(const XDfeOfdm *InstancePtr,

sc C
XDfeOfdm_TriggerCfg *TriggerCfg);
Parameters
Di D
The following table lists the XDfeOfdm_SetTriggersCfg function arguments.

AM
Table 59: XDfeOfdm_SetTriggersCfg Arguments

No
XDfeOfdm_TriggerCfg TriggerCfg Trigger configuration container.

*
XDfeOfdm_SetTuserOutFrameLocation
Sets the TUSER Framing bit location register where bit location indicates which bit to be used for
sending the framing information on DL_DOUT IF and M_AXIS_TBASE IF.
TUSER bit width is fixed to its default value of 8. Therefore, legal values of FRAME_BIT are 0 to
7.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Prototype
ta n o
void XDfeOfdm_SetTuserOutFrameLocation(const XDfeOfdm *InstancePtr, u32
a
TuserOutFrameLocation);
hi ati
l
Parameters
m
The following table lists the XDfeOfdm_SetTuserOutFrameLocation function arguments.
n
-D OT nth for
Table 60: XDfeOfdm_SetTuserOutFrameLocation Arguments
c
Re CD ika In
n
u32 TuserOutFrameLocation Requested TUSER OutFrame location.
io
or t sr ial
XDfeOfdm_GetTuserOutFrameLocation
ut
Gets the TUSER Framing bit location register where bit location indicates which bit is to be used
t f a to nt
rib
for sending framing information on DL_DOUT IF and M_AXIS_TBASE IF.
d ide
TUSER bit width is fixed to its default value of 8. Therefore, legal values of FRAME_BIT are 0 to
7.
ist
se f
Prototype
lo on
u32 XDfeOfdm_GetTuserOutFrameLocation(const XDfeOfdm *InstancePtr);

sc C
Parameters
The following table lists the XDfeOfdm_GetTuserOutFrameLocation function arguments.

Di D
Table 61: XDfeOfdm_GetTuserOutFrameLocation Arguments

AM

No
Returns
TUSER OutFrame Location.
XDfeOfdm_SetTUserDelay
Sets the delay to be added to TUSER and TLAST (delay matched through the IP).
Prototype
void XDfeOfdm_SetTUserDelay(const XDfeOfdm *InstancePtr, u32 Delay);
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Parameters
ta n o
The following table lists the XDfeOfdm_SetTUserDelay function arguments.
a
hi ati
Table 62: XDfeOfdm_SetTUserDelay Arguments
l
m
n
u32 Delay Requested delay variable.
-D OT nth for
XDfeOfdm_GetTUserDelay
c
Re CD ika In
n
Reads the delay, which will be added to TUSER and TLAST (delay matched through the IP).
io
or t sr ial
Prototype
ut
u32 XDfeOfdm_GetTUserDelay(const XDfeOfdm *InstancePtr);
t f a to nt
rib
Parameters
d ide
The following table lists the XDfeOfdm_GetTUserDelay function arguments.
ist
Table 63: XDfeOfdm_GetTUserDelay Arguments
se f
lo on

sc C
Returns
Delay value.
Di D
XDfeOfdm_GetDataLatency
AM
Returns data latency.

No
Prototype
u32 XDfeOfdm_GetDataLatency(const XDfeOfdm *InstancePtr);
Parameters
The following table lists the XDfeOfdm_GetDataLatency function arguments.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 64: XDfeOfdm_GetDataLatency Arguments
o
a
hi ati
l
Returns
m
n
Returned data latency.
-D OT nth for
XDfeOfdm_GetVersions
c
Gets the driver version.
Re CD ika In
n
io
Prototype
or t sr ial
ut
void XDfeOfdm_GetVersions(const XDfeOfdm *InstancePtr, XDfeOfdm_Version
*SwVersion, XDfeOfdm_Version *HwVersion);
t f a to nt
rib
Parameters
d ide
The following table lists the XDfeOfdm_GetVersions function arguments.
ist
Table 65: XDfeOfdm_GetVersions Arguments
se f
lo on

XDfeOfdm_Version * SwVersion Driver version numbers.
XDfeOfdm_Version * HwVersion HW version numbers.

sc C
XDfeOfdm_GetEventStatus
Di D
Gets event status.

AM
Prototype
void XDfeOfdm_GetEventStatus(const XDfeOfdm *InstancePtr, XDfeOfdm_Status

No
*Status);
Parameters
The following table lists the XDfeOfdm_GetEventStatus function arguments.
Table 66: XDfeOfdm_GetEventStatus Arguments

XDfeOfdm_Status * Status Pointer to a returned event status.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
XDfeOfdm_ClearEventStatus
ta n o
Clears the event status.
a
hi ati
l
Prototype
m
void XDfeOfdm_ClearEventStatus(const XDfeOfdm *InstancePtr, const
XDfeOfdm_Status *Status);
n
-D OT nth for
Parameters
c
The following table lists the XDfeOfdm_ClearEventStatus function arguments.
Re CD ika In
n
Table 67: XDfeOfdm_ClearEventStatus Arguments
io
ut
t f a to nt
const XDfeOfdm_Status Status Clear event status container.
rib
*
• 0 - Does not clear the corresponding event status
d ide
• 1 - Clears the corresponding event status
ist
XDfeOfdm_SetInterruptMask
se f
lo on
Sets interrupt masks.
Prototype
sc C
void XDfeOfdm_SetInterruptMask(const XDfeOfdm *InstancePtr, const

XDfeOfdm_InterruptMask *Mask);
Di D
AM
Parameters
The following table lists the XDfeOfdm_SetInterruptMask function arguments.

No
Table 68: XDfeOfdm_SetInterruptMask Arguments

const Mask Interrupt mask value.

XDfeOfdm_InterruptMa
sk * • 0 - Does not mask the corresponding interrupt
• 1 - Masks the corresponding interrupt
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
XDfeOfdm_GetInterruptMask
ta n o
Gets interrupt masks.
a
hi ati
l
Prototype
m
void XDfeOfdm_GetInterruptMask(const XDfeOfdm *InstancePtr,
XDfeOfdm_InterruptMask *Mask);
n
-D OT nth for
Parameters
c
The following table lists the XDfeOfdm_GetInterruptMask function arguments.
Re CD ika In
n
Table 69: XDfeOfdm_GetInterruptMask Arguments
io
ut
t f a to nt
XDfeOfdm_InterruptMa Mask Interrupt mask value.
rib
sk *
d ide
Enumerations
ist
Enumeration XDfeOfdm_StateId
se f
lo on
Table 70: Enumeration XDfeOfdm_StateId Values

sc C
Value Description
XDFEOFDM_STATE_NOT_READY Not ready state.
XDFEOFDM_STATE_READY Ready state.
Di D
XDFEOFDM_STATE_RESET Reset state.

AM
XDFEOFDM_STATE_CONFIGURED Configured state.

XDFEOFDM_STATE_INITIALISED Initialized state.
XDFEOFDM_STATE_OPERATIONAL Operational state.
No
Definitions
Define XDFEOFDM_DRIVER_VERSION_MINOR
Definition
#define XDFEOFDM_DRIVER_VERSION_MINOR (1U)
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Description
ta n o
Minor version number of driver.
a
hi ati
Define XDFEOFDM_DRIVER_VERSION_MAJOR
l
m
Definition
n
#define XDFEOFDM_DRIVER_VERSION_MAJOR (1U)
-D OT nth for
Description
c
Re CD ika In
n
Major version number of driver.
io
Define XDFEOFDM_PHASE_COMPENSATION_REG_STEP
or t sr ial
ut
Definition
t f a to nt
rib
#define XDFEOFDM_PHASE_COMPENSATION_REG_STEP 8U
d ide
Description
ist
Address space step between space for phase compensation on one carrier.
se f
lo on
Define XDFEOFDM_MAX_NUM_INSTANCES
Definition
sc C
#define XDFEOFDM_MAX_NUM_INSTANCES (10U)

Di D
Description
AM
Maximum number of driver instances running at the same time.
Define XDFEOFDM_INSTANCE_EXISTS
No
Definition
#define XDFEOFDM_INSTANCE_EXISTS (X < XDFEOFDM_MAX_NUM_INSTANCES)
Description
Number of instances that exist at any given time.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Define XST_SUCCESS
ta n o
Definition
a
hi ati
l
#define XST_SUCCESS (0U)
m
Description
n
Success flag.
-D OT nth for
Define XST_FAILURE
c
Re CD ika In
n
Definition
io
or t sr ial
#define XST_FAILURE (1U)
ut
Description
t f a to nt
rib
Failure flag.
d ide
Define XDFEOFDM_NODE_NAME_MAX_LENGTH
ist
Definition
se f
lo on
#define XDFEOFDM_NODE_NAME_MAX_LENGTH (50U)
Description
sc C
Node name maximum length.

Di D
Define XDFEOFDM_CC_NUM
AM
Definition
#define XDFEOFDM_CC_NUM (16)

No
Description
Maximum CC sequence number.
Define XDFEOFDM_FT_NUM
Definition
#define XDFEOFDM_FT_NUM (16)
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Description
ta n o
Maximum FT sequence number.
a
hi ati
Define XDFEOFDM_CC_SEQ_LENGTH_MAX
l
m
Definition
n
#define XDFEOFDM_CC_SEQ_LENGTH_MAX (16U)
-D OT nth for
Description
c
Re CD ika In
n
Maximum sequence length.
io
Define XDFEOFDM_FT_SEQ_LENGTH_MAX
or t sr ial
ut
Definition
t f a to nt
rib
#define XDFEOFDM_FT_SEQ_LENGTH_MAX (16U)
d ide
Description
ist
Maximum Fourier transform sequence length.
se f
lo on
Define XDFEOFDM_PHASE_COMPENSATION_MAX
Definition
sc C
#define XDFEOFDM_PHASE_COMPENSATION_MAX (112U)

Di D
Description
AM
Maximum phase compensation weight.
Define XDFEOFDM_COMPATIBLE_STRING
No
Definition
#define XDFEOFDM_COMPATIBLE_STRING "xlnx,xdfe-ofdm-2.0"
Description
Device name property.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Define XDFEOFDM_PLATFORM_DEVICE_DIR
ta n o
Definition
a
hi ati
l
#define XDFEOFDM_PLATFORM_DEVICE_DIR "/sys/bus/platform/devices/"
m
Description
n
Device location in a file system.
-D OT nth for
Define XDFEOFDM_COMPATIBLE_PROPERTY
c
Re CD ika In
n
Definition
io
or t sr ial
#define XDFEOFDM_COMPATIBLE_PROPERTY "compatible"
ut
Description
t f a to nt
rib
Device tree property.
d ide
Define XDFEOFDM_BUS_NAME
ist
Definition
se f
lo on
#define XDFEOFDM_BUS_NAME "platform"
Description
sc C
System bus name.

Di D
Define XDFEOFDM_BASEADDR_PROPERTY
AM
Definition
#define XDFEOFDM_BASEADDR_PROPERTY "reg"

No
Description
Base address property.
Define XDFEOFDM_BASEADDR_SIZE
Definition
#define XDFEOFDM_BASEADDR_SIZE 8U
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Description
ta n o
Base address bit-size.
a
hi ati
l
Data Structures
m
n
-D OT nth for
XDfeOfdm
c
OFDM Structure.
Re CD ika In
n
Declaration
io
or t sr ial
typedef struct
ut
{
XDfeOfdm_Config Config;
XDfeOfdm_StateId StateId;
t f a to nt
rib
s32 NotUsedCCID;
u32 CCSequenceLength;
char NodeName[XDFEOFDM_NODE_NAME_MAX_LENGTH];
d ide
struct metal_io_region * Io;
ist
struct metal_device * Device;
} XDfeOfdm;
se f
Table 71: Structure XDfeOfdm Member Description

lo on
Member Description
Config Config Structure.
sc C
StateId StateId.
NotUsedCCID Not used CCID.
Di D
CCSequenceLength Exact sequence length.

NodeName Node name.
AM
Io Libmetal I/O structure.

Device Libmetal device structure.
No
XDfeOfdm_CarrierCfg
Configuration for a single CC.
Declaration
typedef struct
{
u32 Numerology;
u32 FftSize;
u32 NumSubcarriers;
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
u32 ScaleFactor;
ta n
u32 CommsStandard;
u32 OutputDelay;
o
u32 PhaseCompensation[XDFEOFDM_PHASE_COMPENSATION_MAX];
a
} XDfeOfdm_CarrierCfg;
hi ati
l
Table 72: Structure XDfeOfdm_CarrierCfg Member Description
m
Member Description
n
Numerology [0-2] Numerology (Mu) value for this CC.
-D OT nth for
• 0 = 15 kHz
• 1 = 30 kHz
c
• 2 = 60 kHz
Re CD ika In
n
Numerology must be 0 for LTE.
io
FftSize [9,10,11,12] FFT size to be used for FFT of the CC.
Valid sizes are:
or t sr ial • 512 = 0x9
ut
• 1024 = 0xA
• 2048 = 0xB
t f a to nt
rib
• 4096 = 0xC
NumSubcarriers [0-32768] Number of non-null subcarriers in this CC.
d ide
ScaleFactor [0-1023] Scaling factor for FFT output for this CC, represented as a fixed-
ist point value in 0.10 fixed-point format.

Scaling factor for FFT output for this CC, represented as a fixed-point
value in 0.10 fixed-point format. For example, to scale by 1/2 = 2-1 , the
se f
scale_factor = (0.1000000000)2 = 0x200 should be written, and to scale by

lo on
1/1024 = 2 -10, scale_factor = (0.0000000001)2 = 0x001 should be written.

A scale_factor of 0x000 is not legal.
CommsStandard [0-1]
• 1 = LTE
sc C
• 0 = 5G NR
OutputDelay [0-4095] Delay required before outputting CC to balance CC Filter group
delay. Delay should be chosen in multiples of 16.
Di D
PhaseCompensation Phase weight is a complex number with 0 to 15 bits providing the I and
16 to 31 bits the Q part of the weight.
AM
XDfeOfdm_CCCfg
No
Full CC configuration.
Declaration
typedef struct
{
XDfeOfdm_CCSequence CCSequence;
XDfeOfdm_FTSequence FTSequence;
XDfeOfdm_InternalCarrierCfg CarrierCfg[XDFEOFDM_CC_NUM];
} XDfeOfdm_CCCfg;
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 73: Structure XDfeOfdm_CCCfg Member Description
o
Member Description
a
hi ati
CCSequence CCID sequence.
l
FTSequence CCID sequence.
CarrierCfg CC configurations.
m
n
XDfeOfdm_CCSequence
-D OT nth for
Defines a CCID sequence.
c
Re CD ika In
n
Declaration
io
typedef struct
or t sr ial
{
ut
u32 Length;
s32 CCID[XDFEOFDM_CC_SEQ_LENGTH_MAX];
} XDfeOfdm_CCSequence;
t f a to nt
rib
Table 74: Structure XDfeOfdm_CCSequence Member Description
d ide
ist
Member Description
Length [1-16] Sequence length.
se f
CCID Array of CCIDs arranged in the order the CC samples are output on CC
interfaces.
lo on
XDfeOfdm_Cfg
sc C
Configuration.
Di D
Declaration
AM
typedef struct
{
XDfeOfdm_Version Version;
XDfeOfdm_ModelParameters ModelParams;
} XDfeOfdm_Cfg;
No
Table 75: Structure XDfeOfdm_Cfg Member Description
Member Description
Version LogiCORE version.
ModelParams LogiCORE parameterization.
XDfeOfdm_Config
OFDM Configuration structure.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Declaration
ta n o
typedef struct
a
{
hi ati
u32 DeviceId;
l
metal_phys_addr_t BaseAddr;
u32 NumAntenna;
u32 AntennaInterleave;
m
u32 PhaseCompensation;
n
} XDfeOfdm_Config;
-D OT nth for
Table 76: Structure XDfeOfdm_Config Member Description
c
Member Description
Re CD ika In
n
DeviceId The component instance ID.
io
BaseAddr Instance base address.
or t sr ial
NumAntenna Number of antennas.
ut
AntennaInterleave Antenna interleave.
PhaseCompensation [0,1] Phase compensation
t f a to nt
rib
• 0: Phase compensation disabled
d ide
• 1: Phase compensation enabled
ist
XDfeOfdm_FTSequence
se f
lo on
Defines an FT sequence.
Declaration
sc C
typedef struct
{
Di D
u32 Length;
s32 CCID[XDFEOFDM_FT_SEQ_LENGTH_MAX];
} XDfeOfdm_FTSequence;
AM
Table 77: Structure XDfeOfdm_FTSequence Member Description

No
Member Description
Length [1-16] Sequence length.
CCID Array of CCIDs arranged in the order of Fourier Transform outputs on FT
interfaces.
XDfeOfdm_Init
Initialization, "one-time" configuration parameters.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Declaration
ta n o
typedef struct
a
{
hi ati
u32 CCSequenceLength;
l
} XDfeOfdm_Init;
m
Table 78: Structure XDfeOfdm_Init Member Description
n
Member Description
-D OT nth for
CCSequenceLength CC Sequence Length.
c
Re CD ika In
n
XDfeOfdm_InternalCarrierCfg
io
Internal configuration for a single CC.
or t sr ial
ut
Declaration
t f a to nt
rib
typedef struct
{
u32 Enable;
d ide
u32 Numerology;
ist
u32 FftSize;
u32 NumSubcarriers;
u32 ScaleFactor;
u32 CommsStandard;
se f
u32 OutputDelay;
lo on
u32 PhaseCompensation[XDFEOFDM_PHASE_COMPENSATION_MAX];
} XDfeOfdm_InternalCarrierCfg;
sc C
Table 79: Structure XDfeOfdm_InternalCarrierCfg Member Description
Member Description
Di D
Enable [0,1] (Private) Enable the CC.

This is distinct from removing from the CC from the sequence. When
AM
enable is not set, the associated CCID will appear in sequence, but its
valid will not propagate.
Numerology [0-2] Numerology (Mu) value for this CC.
• 0 = 15 kHz
No
• 1 = 30 kHz
• 2 = 60 kHz
Numerology must be 0 for LTE. RFSoC DFE OFDM IP v2.0 supports only
0,1, and 2.
FftSize [9, 10,11,12] FFT size to be used for FFT of the CC.
Valid sizes are:
• 512 = 0x9
• 1024 = 0xA
• 2048 = 0xB
• 4096 = 0xC
NumSubcarriers [0-32768] Number of non-null subcarriers in this CC.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 79: Structure XDfeOfdm_InternalCarrierCfg Member Description (cont'd)
o
Member Description
a
hi ati
ScaleFactor [0-1023] Scaling factor for FFT output for this CC, represented as a fixed-
point value in 0.10 fixed-point format.
l
Scaling factor for FFT output for this CC, represented as a fixed-point
value in 0.10 fixed-point format. For example, to scale by 1/2 = 2-1 , the
m
scale_factor = (0.1000000000)2 = 0x200 should be written, and to scale by
1/1024 = 2 -10, scale_factor = (0.0000000001)2 = 0x001 should be written.
n
A scale_factor of 0x000 is not legal.
-D OT nth for
CommsStandard [0-1]
• 1 = LTE
•
c
0 = 5G NR
Re CD ika In
n
OutputDelay [0-4095] Delay required before outputting CC in order to balance CC
Filter group delay.
io
PhaseCompensation Phase weight is a complex number with 0 to 15 bits providing the I and
or t sr ial 16 to 31 bits the Q part of the weight.
ut
XDfeOfdm_InterruptMask
t f a to nt
rib
Interrupt mask.
d ide
ist
Declaration
typedef struct
se f
{
lo on
u32 CCUpdate;
u32 FTCCSequenceError;
u32 Saturation;
u32 Overflow;
sc C
} XDfeOfdm_InterruptMask;
Table 80: Structure XDfeOfdm_InterruptMask Member Description

Di D
Member Description
AM
CCUpdate [0,1] Mask CC update events

FTCCSequenceError [0,1] Mask sequence mismatch events
Saturation [0,1] Mask Saturation events
No
Overflow [0,1] Mask Overflow events
XDfeOfdm_ModelParameters
OFDM model parameters structure.
Data defined in Device tree or xparameters.h for BM.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Declaration
ta n o
typedef struct
a
{
hi ati
u32 NumAntenna;
l
u32 AntennaInterleave;
u32 PhaseCompensation;
} XDfeOfdm_ModelParameters;
m
n
Table 81: Structure XDfeOfdm_ModelParameters Member Description
-D OT nth for
Member Description
c
NumAntenna [1-8] Number of antennas
Re CD ika In
n
AntennaInterleave [1-8] Antenna interleave
io
PhaseCompensation [0,1] Phase compensation
or t sr ial • 0: Phase compensation disabled
ut
• 1: Phase compensation enabled
t f a to nt
rib
XDfeOfdm_Status
d ide
ist
OFDM Status.
Declaration
se f
lo on
typedef struct
{
u32 SaturationCCID;
sc C
u32 SaturationCount;
u32 CCUpdate;
u32 FTCCSequenceError;
u32 Saturation;
Di D
u32 Overflow;
} XDfeOfdm_Status;
AM
Table 82: Structure XDfeOfdm_Status Member Description
Member Description
No
SaturationCCID [0,15] CCID in which saturation event occurred.

SaturationCount [0,2**14-1] Saturation events count across real and imaginary
components.
CCUpdate [0,1] There has been an overflow or underflow in the filter for one or
more of the antennas and CCIDs.
FTCCSequenceError [0,1] TRIGGER.CC_UPDATE has been triggered.
Saturation [0,1] A difference between CC_CONFIGURATION.
SEQUENCE and DIN TID has been detected.
Overflow [0,1] UL OFDM receives tready low during packet transaction
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
XDfeOfdm_Trigger
ta n o
Trigger configuration.
a
hi ati
Declaration
l
m
typedef struct
{
n
u32 TriggerEnable;
-D OT nth for
u32 Mode;
u32 TuserEdgeLevel;
u32 StateOutput;
u32 TUSERBit;
c
} XDfeOfdm_Trigger;
Re CD ika In
n
io
Table 83: Structure XDfeOfdm_Trigger Member Description
or t sr ial Member Description
ut
TriggerEnable [0,1], Enable Trigger:
t f a to nt
rib
• 0 = DISABLED: Trigger Pulse and State outputs are disabled.
• 1 = ENABLED: Trigger Pulse and State outputs are enabled and follow
d ide
the settings described below.
Mode
ist [0-3], Specify Trigger Mode.
In TUSER_Single_Shot mode, as soon as the TUSER_Edge_level condition
is met, the State output will be driven to the value specified in
se f
STATE_OUTPUT. The Pulse output will pulse high at the same time. No
lo on
further change will occur until the trigger register is re-written. In TUSER
Continuous mode, each time a TUSER_Edge_level condition is met the
State output will be driven to the value specified in STATE_OUTPUT This
will happen continuously until the trigger register is re-written. The
sc C
pulse output is disabled in Continuous mode:
• 0 = IMMEDIATE: Applies the value of STATE_OUTPUT immediately

when the register is written.
Di D
• 1 = TUSER_SINGLE_SHOT: Applies the value of STATE_OUTPUT once

when the TUSER_EDGE_LEVEL condition is satisfied.
AM
• 2 = TUSER_CONTINUOUS: Applies the value of STATE_OUTPUT

continually when TUSER_EDGE_LEVEL condition is satisfied.
• 3 = RESERVED: Reserved - will default to 0 behavior.

No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Table 83: Structure XDfeOfdm_Trigger Member Description (cont'd)
o
Member Description
a
hi ati
TuserEdgeLevel [0-3], Specify either Edge or Level of the TUSER input as the source
condition of the trigger.
l
Difference between Level and Edge is Level will generate a trigger
immediately the TUSER level is detected. Edge will ensure a TUSER
m
transition has come first:
n
• 0 = LOW: Trigger occurs immediately after a low-level is seen on
-D OT nth for
TUSER provided tvalid is High.
• 1 = HIGH: Trigger occurs immediately after a high-level is seen on

TUSER provided tvalid is High.
c
Re CD ika In
n
• 2 = FALLING: Trigger occurs immediately after a high to low
transition on TUSER provided tvalid is High.
io
• 3 = RISING: Trigger occurs immediately after a low to high transition
or t sr ial on TUSER provided tvalid is High.
ut
StateOutput [0,1], Specify the State output value:
t f a to nt
rib
• 0 = DISABLED: Place the State output into the Disabled state.
• 1 = ENABLED: Place the State output into the Enabled state.

d ide
ist
TUSERBit [0-255], Specify which DIN TUSER bit to use as the source for the trigger
when MODE = 1 or 2.
se f
XDfeOfdm_TriggerCfg
lo on
All IP triggers.
sc C
Declaration
typedef struct
Di D
{
XDfeOfdm_Trigger Activate;
AM
XDfeOfdm_Trigger LowPower;
XDfeOfdm_Trigger CCUpdate;
} XDfeOfdm_TriggerCfg;
No
Table 84: Structure XDfeOfdm_TriggerCfg Member Description
Member Description
Activate Switch between "Initialized", ultra-low power state, and "Operational".
One-shot trigger, disabled following a single event.
LowPower Switch between "Low-power" and "Operational" state.
CCUpdate Transition to next CC configuration.
Will initiate flush based on CC configuration.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
XDfeOfdm_Version
ta n o
LogiCORE version.
a
hi ati
Declaration
l
m
typedef struct
{
n
u32 Major;
-D OT nth for
u32 Minor;
u32 Revision;
u32 Patch;
} XDfeOfdm_Version;
c
Re CD ika In
n
Table 85: Structure XDfeOfdm_Version Member Description
io
or t sr ial Member Description
ut
Major Major version number.
Minor Minor version number.
t f a to nt
rib
Revision Revision number.
Patch Patch number.
d ide
ist
se f
lo on
sc C
Di D
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
Appendix D: Additional Resources and Legal Notices
Appendix D
ta n o
a
hi ati
l
Additional Resources and Legal
m
n
Notices
-D OT nth for
c
Re CD ika In
n
io
Finding Additional Documentation
or t sr ial
ut
Documentation Portal
t f a to nt
rib
The AMD Adaptive Computing Documentation Portal is an online tool that provides robust
d ide
search and navigation for documentation using your web browser. To access the Documentation
ist
Portal, go to https://docs.xilinx.com.
Documentation Navigator
se f
lo on
Documentation Navigator (DocNav) is an installed tool that provides access to AMD Adaptive
Computing documents, videos, and support resources, which you can filter and search to find
information. To open DocNav:
sc C
• From the AMD Vivado™ IDE, select Help → Documentation and Tutorials.
Di D
• On Windows, click the Start button and select Xilinx Design Tools → DocNav.
• At the Linux command prompt, enter docnav.
AM
Note: For more information on DocNav, refer to the Documentation Navigator User Guide (UG968).
No
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.

• Go to the Design Hubs web page.
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
ta n
Support Resources
o
a
hi ati
For support resources such as Answers, Documentation, Downloads, and Forums, see Support.
l
m
n
References
-D OT nth for
These documents provide supplemental material useful with this guide:
c
Re CD ika In
n
1. Zynq UltraScale+ RFSoC DFE Targeted Reference Design User Guide (UG1530)
io
2. Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
or t sr ial
3. Vivado Design Suite User Guide: Designing with IP (UG896)
ut
4. Vivado Design Suite User Guide: Getting Started (UG910)
t f a to nt
rib
5. Vivado Design Suite User Guide: Logic Simulation (UG900)
d ide
6. Orthogonal Frequency Division Multiplexing Reference IP (XAPP1382) (registration required)
ist
se f
Revision History
lo on
The following table shows the revision history for this document.
sc C
Section Revision Summary

Di D
10/18/2023 Version 2.0

Initial release. N/A
AM
Please Read: Important Legal Notices

No
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
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
product releases, product differences between differing manufacturers, software changes, BIOS
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
PG434 (v2.0) October 18, 2023

Send Feedback
AMD CONFIDENTIAL
AMD to notify any person of such revisions or changes. THIS INFORMATION IS PROVIDED "AS
ta n
IS." AMD MAKES NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE
o
CONTENTS HEREOF AND ASSUMES NO RESPONSIBILITY FOR ANY INACCURACIES,
a
hi ati
ERRORS, OR OMISSIONS THAT MAY APPEAR IN THIS INFORMATION. AMD SPECIFICALLY
l
DISCLAIMS ANY IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, OR
FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL AMD BE LIABLE TO ANY
m
PERSON FOR ANY RELIANCE, DIRECT, INDIRECT, SPECIAL, OR OTHER CONSEQUENTIAL
n
DAMAGES ARISING FROM THE USE OF ANY INFORMATION CONTAINED HEREIN, EVEN IF
-D OT nth for
AMD IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
c
AUTOMOTIVE APPLICATIONS DISCLAIMER
Re CD ika In
n
AUTOMOTIVE PRODUCTS (IDENTIFIED AS "XA" IN THE PART NUMBER) ARE NOT
io
WARRANTED FOR USE IN THE DEPLOYMENT OF AIRBAGS OR FOR USE IN APPLICATIONS
or t sr ial
THAT AFFECT CONTROL OF A VEHICLE ("SAFETY APPLICATION") UNLESS THERE IS A
ut
SAFETY CONCEPT OR REDUNDANCY FEATURE CONSISTENT WITH THE ISO 26262
AUTOMOTIVE SAFETY STANDARD ("SAFETY DESIGN"). CUSTOMER SHALL, PRIOR TO USING
t f a to nt
rib
OR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE PRODUCTS, THOROUGHLY TEST
SUCH SYSTEMS FOR SAFETY PURPOSES. USE OF PRODUCTS IN A SAFETY APPLICATION
d ide
WITHOUT A SAFETY DESIGN IS FULLY AT THE RISK OF CUSTOMER, SUBJECT ONLY TO
ist
APPLICABLE LAWS AND REGULATIONS GOVERNING LIMITATIONS ON PRODUCT
LIABILITY.
se f
lo on
Copyright
© Copyright 2023 Advanced Micro Devices, Inc. AMD, the AMD Arrow logo, UltraScale+, Vitis,
sc C
Vivado, Zynq, and combinations thereof are trademarks of Advanced Micro Devices, Inc. AMBA,
AMBA Designer, Arm, ARM1176JZ-S, CoreSight, Cortex, PrimeCell, Mali, and MPCore are
trademarks of Arm Limited in the US and/or elsewhere. MATLAB and Simulink are registered
Di D
trademarks of The MathWorks, Inc. Other product names used in this publication are for
identification purposes only and may be trademarks of their respective companies.
AM
No
PG434 (v2.0) October 18, 2023

Send Feedback

pg434 Rfsoc Dfe Ofdm - 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

pg434 Rfsoc Dfe Ofdm - WTMKX

Uploaded by

Copyright:

Available Formats

AMD CONFIDENTIAL

RFSoC DFE Orthogonal

AMD Adaptive Computing is creating an environment where

Chapter 3: Product Specification........................................................................... 9

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

General Design Guidelines.......................................................................................................17

Chapter 5: Design Flow Steps.................................................................................37

Constraining the Subsystem....................................................................................................39

PG434 (v2.0) October 18, 2023

Appendix C: Application Software Development....................................... 66

Appendix D: Additional Resources and Legal Notices........................... 100

Support Resources.................................................................................................................. 101

Please Read: Important Legal Notices................................................................................. 101

PG434 (v2.0) October 18, 2023

• Supports a maximum sampling rate of 491.52 MSPS

• Supports up to eight downlink or uplink paths (or antennas)

PG434 (v2.0) October 18, 2023

All Vivado IP Change Logs Master Vivado IP Change Logs: 72775

Linux: Linux OS and driver support information is available from https://github.com/Xilinx/embeddedsw/tree/

PG434 (v2.0) October 18, 2023

ist AXI4-LITE CTRL

FFT Engine Rounding & Sequence

PG434 (v2.0) October 18, 2023

Figure 2: OFDM Core in Uplink Mode

-D OT nth for Length

classified into two categories:

be interleaved on the interface according to a frequency-transform multiplexing sequence.

PG434 (v2.0) October 18, 2023

• Extended CP (both LTE and 5G-NR) and FR2 (5G-NR)

Licensing and Ordering

PG434 (v2.0) October 18, 2023

60 N/A 11 18 24 31 38 44 51 58 65 79 93 107 121 135

PG434 (v2.0) October 18, 2023

Legacy Mode (FR1)

Latency = 15 kHz SCS OFDM symbol duration including CP (35072 or

Latency = 30 kHz SCS OFDM symbol duration including CP (17536 or

Latency = 60 kHz SCS OFDM symbol duration including CP (8768 or 8896

PG434 (v2.0) October 18, 2023

Latency = 60 kHz SCS OFDM symbol duration including CP (8768 or 8896

cycles @491.52 MHz) + 8220 cycles FFT Latency compensation + 14 cycles

pipeline latency + programmed group delay compensation

frame marker on m_axis_tbase [programmed bit].

PG434 (v2.0) October 18, 2023

Figure 3: Core Ports

Data Interface Ports

Table 2: DL Data Input Interface Ports

Port Name I/O Clock Description

s_axis_dl_din_tvalid I s_axis_aclk Valid handshake signal for the data input

s_axis_dl_din_tid [7:0] I s_axis_aclk Transaction ID associated with the sample(s) on

PG434 (v2.0) October 18, 2023

m_axis_dl_dout_tid[7:0] O s_axis_aclk Transaction ID associated with the sample(s) on

upper four bits [7:4] indicate the component

Table 5: UL Data Output Interface Ports

Port Name I/O Clock Description

m_axis_ul_dout_tdata (2 x OW x NL -1:0) O s_axis_aclk Output sample data. Width is determined by the

PG434 (v2.0) October 18, 2023

Timebase Interface Ports

Port Name I/O Clock Description

the tbase input channel.

PG434 (v2.0) October 18, 2023

s_axi_ctrl_araddr[3:0] I s_axi_aclk Read address. Accepted when

s_axi_ctrl_arready and s_axi_ctrl_arvalid

are high on the same clock cycle.