Pg056-Cpri v87

CPRI v8.
LogiCORE IP Product Guide
Vivado Design Suite

PG056 October 5, 2016
Table of Contents
IP Facts
Chapter 1: Overview
Feature Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Recommended Design Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Licensing and Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 2: Product Specification

Chip Period (TC) in This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Related Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Resource Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Speed Grade Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
CPRI Core Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Management Register Map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 3: Designing with the Core

General Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Clocking and Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Interfacing to the Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Chapter 4: Design Considerations

Reference Clock Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Clock Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Using the PLL to Generate the Core Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Resource Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Line Speed Configuration and Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
RS-FEC Enabled Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Using an External GMII Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Delay Measurement and Requirement 21 (R21) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
CPRI v8.7 Send Feedback

2
PG056 October 5, 2016 www.xilinx.com
Chapter 5: Design Flow Steps
Customizing and Generating the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Constraining the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Synthesis and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Chapter 6: Example Design
Chapter 7: Test Bench
Appendix A: Verification, Compliance, and Interoperability

Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Hardware Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Appendix B: Migrating and Upgrading

Migrating to the Vivado Design Suite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Upgrading in the Vivado Design Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Appendix C: Debugging
Finding Help on Xilinx.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Vivado Design Suite Debug Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Hardware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
AXI4-Lite Interface Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Appendix D: Additional Resources and Legal Notices

Xilinx Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Please Read: Important Legal Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

3
IP Facts
Introduction LogiCORE IP Facts

Core Specifics
The LogiCORE™ IP Common Public Radio
Zynq® UltraScale+™ MPSoC
Interface (CPRI™) core is a high-performance, UltraScale+
low-cost flexible solution for implementation of Supported UltraScale™
Device Family (1) Zynq-7000 All Programmable SoC(2)
the CPRI interface. It uses state-of-the-art
7 Series(3)
transceivers to implement the Physical Layer. A See Speed Grade Support.
compact and customizable Data Link Layer is Generic data, status, configuration and
Supported User
implemented in the FPGA logic. Interfaces
management interfaces,
AXI4-Lite management interface
Features Resources Performance and Resource Utilization web page
Provided with Core

• UltraScale architecture-based device designs Design Files Encrypted register transfer level (RTL)
operate at line rates of 614.4, 1,228.8,
Example Design VHDL
2,457.6, 3,072, 4,915.2, 6,144, 8,110.08,
Test Bench VHDL
9,830.4, 10,137.6 and 12,165.12 Mb/s using
Constraints File Xilinx Design Constraints (XDC)
GTHE3, GTYE3, GTHE4 or GTYE4
transceivers. Simulation
VHDL, Verilog
Models
• Optional RS-FEC supported using GTYE3 Supported
N/A
and GTYE4 transceivers at 24,330.24, S/W Drivers
12,165.12, 10,137.6 and 8,110.08 Mb/s line Tested Design Flows(4)
rates.
Design Entry Vivado® Design Suite
• Zynq-7000, Virtex®-7, and Kintex®-7 For supported simulators, see the
Simulation
device designs operate at line rates of Xilinx Design Tools: Release Notes Guide.
614.4, 1,228.8, 2,457.6, 3,072, 4,915.2, 6,144, Synthesis Vivado Synthesis
9,830.4, and 10,137.6 Mb/s using GTXE2, Support

GTHE2 transceivers. Provided by Xilinx at the Xilinx Support web page
• Artix®-7 devices designs operate at line Notes:
rates of 614.4, 1,228.86 2,457.6, 3,072, 1. For a complete list of supported devices, see the Vivado IP
catalog.
4,915.2, and 6,144 Mb/s using GTPE2 2. Excludes the Zynq-7000 010 and 020 devices.
transceivers. 3. Excludes the Artix-7 100T device in CSG324 and FTG256
packages.
• UTRA-FDD in-phase and quadrature-phase 4. For the supported version of the tool, see the
data (I/Q) module supporting 1 to 48 Xilinx Design Tools: Release Notes Guide.
Antenna-Carriers per core
• Automatic speed negotiation
• Supports both Fast (Ethernet) and Slow
High-Level Data Link Control (HDLC)
Control and Management (C&M) channels
per CPRI Specification v7.0 [Ref 1].
CPRI v8.7 Send Feedback 4

PG056 October 5, 2016 www.xilinx.com Product Specification
Chapter 1
Overview
CPRI™ is a standard for communication between a Radio Equipment Controller (REC) or
Base Station and one or more Radio Equipment (RE) units in a cellular network. By defining
a publicly available specification for the key internal interface between these units, an
independent technology evolution is fostered for cellular equipment products. Figure 1-1
shows the position of the interface within a cellular system. The CPRI v8.7 core has been
designed to the CPRI Specification v7.0 [Ref 1].
X-Ref Target - Figure 1-1
2ADIO 2ADIO
%QUIPMENT %QUIPMENT 2ADIO
#ONTROLLER 2% %QUIPMENT
2%# 2%
#02) #02) #02) #02)
-ASTER 3LAVE -ASTER 3LAVE
"ACKPLANE#ABLEOR&IBER
Figure 1-1: Location of CPRI in a Cellular System

The CPRI core implements Layer 1 and Layer 2 of the CPRI specification in UltraScale™
devices, Zynq®-7000 All Programmable SoCs, and 7 series devices.
Feature Summary
• Designed to CPRI Specification v7.0 [Ref 1]
• Can be configured as a master or slave at generation time. Master core can be switched
to operate as a slave through a configuration port.
• Suitable for use in both Radio Equipment Controllers (RECs) and Radio Equipment (RE),
including multi-hop systems. A multi-hop reference design is available at the CPRI
product page (CPRI product page).
• Easy-to-use I/Q data interface together with optional modules for UMTS terrestrial
radio access - frequency division duplexing (UTRA-FDD) and Evolved UMTS Terrestrial
Radio Access (E-UTRA) data mappings
• Supports both Ethernet and HDLC Control and Management channels

5
Chapter 1: Overview
• Supports vendor-specific data transport including support for the passing of control
AxC information in global system for mobile communications (GSM) systems
• Master core can be switched to operate as a slave through a configuration port
• Core includes the necessary clocking and transceiver logic to enable easy integration
into your design
• Synthesizable example design and simple demonstration test bench provided
• Easy-to-use interface for in-phase (I) and quadrature-phase (Q) data and synchronization
• Supports vendor-specific data transport
• Delay measurement capability meets CPRI Requirement 21 per CPRI Specification v7.0
[Ref 1]
• Reed-Solomon Forward Error Correction (RS-FEC) supported at 8,110.08 Mb/s,
10,137.6 Mb/s, 12,165.12 Mb/s and 24,330.24 Mb/s line rates.
Applications
The goal of the CPRI interface is to use one physical connection for the radio data (I/Q data),
radio unit management (for example, Automatic Gain Control, alarms) and synchronization
(clock frequency control, frame synchronization). Table 1-1 shows the data rates supported
by each Xilinx device. Data is transferred over a single serial link. This link is defined to be
electrically compliant with existing high-speed serial link standards such as the Gigabit
Ethernet and 10 Gigabit eXtended Attachment Unit Interface (XAUI) standards.
Table 1-1: Supported Data Rates

Frequency in Mb/s
Family
614.4 1,228.8 2,457.6 3,072.0 4,915.2 6,144.0 8,110.08 9,830.4 10,137.6 12,165.12 24,330.24
Virtex®-7
-1 speed grade Yes Yes Yes Yes Yes Yes No No No No No
-2 speed grade Yes Yes Yes Yes Yes Yes No Yes Yes No No
-3 speed grade Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No
Kintex®-7 and Zynq®-7000
-1 speed grade Yes Yes Yes Yes Yes Yes No No No No No
-2 speed grade Yes Yes Yes Yes Yes Yes No Yes (1) Yes (1) No No
-3 speed grade Yes Yes Yes Yes Yes Yes No Yes (1) Yes (1) Yes (1) No
Artix®-7
-1 speed grade Yes Yes Yes Yes No No No No No No No
-2/-3 speed
Yes Yes Yes Yes Yes Yes (2) No No No No No
grade
UltraScale™ and UltraScale+™
-2/-3 speed
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
grade

6
Chapter 1: Overview
Table 1-1: Supported Data Rates (Cont’d)

Frequency in Mb/s
Family
614.4 1,228.8 2,457.6 3,072.0 4,915.2 6,144.0 8,110.08 9,830.4 10,137.6 12,165.12 24,330.24
Zynq UltraScale™+ MPSoC
-2/-3 speed
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
grade
Notes:
1. Not supported on non Pb-free flip-chip BGA (FFG) packages.
2. Not supported on wire-bond packages.
System Requirements
For a list of System Requirements, see the Xilinx Design Tools: Release Notes Guide.
Recommended Design Experience

Although the CPRI core is a fully-verified solution, the challenge associated with
implementing a complete design varies depending on the configuration and functionality
of the application. For best results, previous experience building high performance,
pipelined FPGA designs using Xilinx implementation software and the XDC file is
recommended.
Contact your local Xilinx sales representative for a closer review and estimation for your
specific requirements.
Licensing and Ordering Information

License Checkers
If the IP requires a license key, the key must be verified. The Vivado® design tools have
several license check points for gating licensed IP through the flow. If the license check
succeeds, the IP can continue generation. Otherwise, generation halts with error. License
checkpoints are enforced by the following tools: Vivado design tools: Vivado synthesis,
Vivado implementation, write_bitstream (Tcl Command).
IMPORTANT: The IP license level is ignored at checkpoints. The test confirms a valid license exists. It
does not check IP license level.

7
Chapter 1: Overview
License Type
This Xilinx LogiCORE™ IP module is provided under the terms of the Xilinx Core License
Agreement. For full access to all core functionalities in simulation and in hardware, you
must purchase a license for the core. Contact your local Xilinx sales representative for
information about pricing and availability of Xilinx LogiCORE IP.
For more information, visit the CPRI product page.
Information about this and other Xilinx LogiCORE IP modules is available at the Xilinx
Intellectual Property page. For information on pricing and availability of other Xilinx
LogiCORE IP modules and tools, contact your local Xilinx sales representative.

8
Chapter 2
Product Specification
The CPRI™ core implements Layer 1 and Layer 2 of the CPRI specification in UltraScale™
architecture-based, Zynq®-7000 and 7 series devices. The CPRI core provides the following
client-side interfaces.
• I/Q Interface: Consists of a stream of radio data (I/Q samples) that is synchronized to
the Universal Mobile Telecommunications System (UMTS) radio frame pulse.
• Synchronization Interface: Provides the means for the client logic to synchronize to
the network time by transmitting the UMTS radio frame pulse and clock frequency.
• High-Level Data Link Control (HDLC) Interface: Transports management information
between master and slave. The HDLC interface is serialized and synchronous.
• Ethernet Interface: When configured to support speeds of up to 3,072 Mb/s, the
Ethernet interface is presented as a Media Independent Interface (MII); this allows a
100 Mb Ethernet Media Access Controller (MAC) to be attached to the core to provide a
high-speed channel for management information. When speeds over 4,915.2 Mb/s are
supported, a Gigabit Media Independent Interface (GMII) option is available. This
allows a 1 Gb Ethernet MAC to be attached to the core. The core includes an Ethernet
frame buffer in both transmit and receive directions. The frame buffers are derived
from the FIFO Generator and Block Memory Generator IP cores.
• Vendor-Specific Data Interface: Provides client logic access to the vendor-specific
sub-channels in the CPRI stream.
• Management Interface: Provides control and status registers that allow management
of the entire design from a supervisory processor.
The architecture of the core is shown in Figure 2-1. In addition to the interfaces described
previously, the core contains these blocks:
• Status/Alarm Block: Reflects the internal state of the core and the state of the link.
• Start-up Sequencer: Performs line-rate negotiation and Control and Management
(C&M) parameter negotiation at link start-up. This block continuously monitors the
state of the link and sends the status to the alarm block.
• UMTS Terrestrial Radio Access – Frequency Division Duplexing (UTRA FDD) I/Q
Module: A pluggable I/Q module to support multiplexing and demultiplexing of I/Q
samples in UTRA FDD systems (shown in Figure 2-1).

9
• Evolved UMTS Terrestrial Radio Access (E-UTRA) I/Q Module: A pluggable I/Q
module to support multiplexing and demultiplexing of I/Q samples in E-UTRA systems
(not shown in Figure 2-1).
• Legacy raw I/Q Module: A pluggable I/Q Module for backward compatibility with the
raw interfacing timing for CPRI cores (not shown in Figure 2-1).
542!&$$
)1-ODULE #02)CORE
480ATH
#ONTROL
48)1DATA
48)1DATA )1DATA
48
6ENDOR
48)1DATA
3PECIFIC
&)&/
%THERNET
&)&/
'4
($,# TRANSCEIVER
3TARTUP
28)1DATA 3EQUENCING ,3YNCH
AND 28
#$#
28)1DATA )1DATA
28)1DATA -ANAGEMENT 280ATH

#ONTROL
Figure 2-1: CPRI Top-Level Block Diagram

As well as the low-level I/Q Interface of the core, there are additional I/Q modules that ship
with the core to implement mapping and unmapping of I/Q samples, in accordance with the
Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access - Frequency
Division Duplexing (UTRA-FDD) and the Evolved UMTS Terrestrial Radio Access (E-UTRA)
mappings in the CPRI Specification v7.0 [Ref 1].

10
Chip Period (TC) in This Document

CPRI operation is largely defined in units of the “chip period,” defined in the 3GPP
specifications as T C = 1/3.84 MHz; or 260.416667 ns. In particular, the CPRI basic frame
length is defined as 1 TC, so all in-phase and quadrature-phase data (I/Q) data and frame
synchronization depend directly on this time constant.
Related Information
Xilinx products are not intended for use in life-support appliances, devices, or systems. Use
of a Xilinx product in such application without the written consent of the appropriate Xilinx
officer is prohibited.
Performance
The CPRI core is delivered with constraints files to ensure correct operation at line rates up
to 24,330.24 Mb/s.
Maximum Frequencies
Table 2-1 shows the client clock rates at which the CPRI LogiCORE™ IP core operates at all
supported line rates.
Table 2-1: Client Clock Rates
Line Rate Client Clock Rate (MHz)

(Mb/s) 16-bit Datapath 32-bit Datapath 64-bit Datapath
614.4 30.72 15.36 7.68
1,228.8 61.44 30.72 15.36
2,457.6 122.88 61.44 30.72
3,072.0 153.6 76.8 38.4
4,915.2 245.76 122.88 61.44
6,144.0 307.2 153.6 76.8
8,110.08 245.76 122.88
9,830.4 245.76 122.88
10,137.6 307.2 153.6
12,165.12 368.64 184.32
24,330.24 368.64

11
Resource Utilization
For full details about performance and resource utilization, visit the Performance and
Resource Utilization web page.
Speed Grade Support

• 9,830 and 10,137.6 Mb/s are only supported on -2 and -3 speed grades for Virtex-7
devices. These designs are implemented using a 32-bit datapath.
• 12,165.12 Mb/s line rates are only supported on -3 speed grades in FFG packages for
Virtex-7, Kintex-7 and Zynq-7000 devices. These designs are implemented with a 32-bit
datapath.
• 9,830 and 10,137.6 Mb/s are only supported on -2 and -3 speed grades in FFG
packages for Kintex-7 and Zynq-7000 devices. These designs are implemented using a
32-bit datapath.
• CPRI designs supporting maximum line rates of 6,144 Mb/s require the use of a 32-bit
datapath in Virtex-7, Kintex-7 and Zynq-7000 devices with a speed grade of -1 or -2L.
See the Virtex-7 and Kintex-7 FPGA data sheets for more information
• 6,144 Mb/s is only supported on -2 and -3 speed grades in non-wire bond packages for
Artix-7 devices. In wire-bond packages the maximum line rate is 4,915.2 Mb/s on -2
and -3 speed grade devices.
• Line rates up to 12,165.12 Mb/s are supported on UltraScale and UltraScale+ devices
with the exception of GTH transceiver-based cores operating on 0.90V -1LI speed grade
parts. In these parts the maximum line rate is 10,137.6 Mb/s.
• Line rates of up to 24,330.24 Mb/s are supported on -2 and -3 speed grade Virtex
UltraScale devices using the GTYE3 or GTYE4 transceiver.
IMPORTANT: In this product guide where a feature is referred to with the phrase “cores supporting
x Mb/s”, this also implies its sub-line rates. For example, “cores supporting 3,072 Mb/s” also implies
2,457.6, 1,228.8 and 614.4 Mb/s; “cores supporting 6,144 Mb/s” also implies 4,915.2 Mb/s; “cores
supporting 12,165.12 Mb/s” also implies 8,110.08 Mb/s.

12
CPRI Core Structure

The CPRI core is generated as encrypted RTL along with unencrypted block layer and core
support layer wrapper files. The encrypted RTL contains the transmit and receive state
machines, control and management multiplexing and de-multiplexing, L1 synchronization
logic and management registers. The block layer connects the encrypted RTL to an instance
of the transceiver channel. In addition optional interfaces for AXI4-Lite management and
Open Radio Equipment Interface (ORI) support are provided. The core support layer
contains logic to connect the block layer to the transceiver common block and the clocking
and reset logic required to implement a single CPRI link. Figure 2-2 shows a diagram of the
CPRI core.
GT_CHANNEL
Transceiver I/F Serial I/O
RXOUTCLK
Optional TXOUTCLK
Vendor Specific I/F DRP
ORI I/F
<component_name>_v7_gtwizard_gt
IQ I/F
RX Sync
Optional
AXI I/F Management I/F
<component_name>_v7_gtwizard
Ethernet I/F DRP I/F

Speed Change
State Machine
Control & Status <component_name>_gt_and_clocks

Speed clk
Change
State recovered_clk
Machine cpri_v8_7
BUFG
DRP clk_in
MMCM
clk_out txoutclk
BUFG/BUFH/BUFR
recclk_in
rxoutclk
recclk_out
<component_name>_clocking
Quad PLL Ports

GT_COMMON
<component_name>_gt_common_wrapper
Reset Generation
<component_name>_resets
Alignment I/F
TX Sync
<component_name>_tx_alignment <component_name_block>
<component_name>_support
;
Figure 2-2: Block Level of the CPRI Core with Core Support Layer

13
The following blocks are instantiated in the block layer:
• Encrypted RTL. The encrypted RTL of the CPRI IP core.

• Transceiver wrapper files. These files instantiate the transceiver channel primitive
(GT_CHANNEL) along with the RX Sync block. The RX Sync block contains logic to carry
out receive phase and delay alignment. In addition a state machine is included to
program the transceiver channel clock divider settings using the Dynamic
Reconfiguration Port (DRP) bus when the line rate of the link is changed.
• ORI. Optional block to support the ORI standard.
• AXI4-Lite. Optional block to control AXI4-Lite management interface.
The core support layer contains elements that can be shared between multiple CPRI cores.
In this level the following blocks are instantiated:
• Transmit clock logic. In Zynq-7000-based and 7 series-based designs an mixed-mode

clock manager (MMCM) is used to generate the system clock. This is routed to the core
layer through a BUFG. A state machine to change the MMCM clock divider settings on a
speed change is also included. In UltraScale architecture-based designs the clock
divider settings are set by the transceiver rather than by an external MMCM. The
transmitter output clock from the transceiver is routed to the core layer through a
BUFG_GT.
• Receive clock logic. The recovered clock output from the transceiver is routed to the
core layer through a clock buffer. In Zynq-7000-based and 7 series-based designs you
can select a BUFH, BUFG or BUFR to implement the receiver clock buffering. In
UltraScale architecture-based designs a BUFG_GT is used.
• Common Block Wrapper. The transceiver common block GT_COMMON, containing
the quad phase-locked loop (QPLL). In Zynq-7000-based and 7 series-based designs
one common block is required for a group of four cores sharing the same quad in the
device. In UltraScale architecture-based designs the common block wrapper is only
present in cores supporting line speeds over 9,830.4 Mb/s.
• Transmit Alignment. With the exception of 64B66B line rates on UltraScale devices,
the CPRI core bypasses the transmit and receive buffers. This ensures predictable and
measurable latency. In buffer bypass mode, phase and delay alignment must be carried
out after a reset or a change in line rate. If the MMCM is shared between multiple
cores, transmit phase alignment is implemented in multi-lane manual mode. See the
“TX Buffer Bypass” section in the 7 Series FPGAs GTX/GTH Transceivers User Guide
(UG476) [Ref 2], the 7 Series FPGAs GTP Transceivers User Guide (UG482) [Ref 3], the
UltraScale Architecture GTH Transceivers User Guide (UG576) [Ref 4] and the UltraScale
Architecture GTY Transceivers User Guide (UG578) [Ref 5] for more information. The
transmit multi-lane manual mode phase alignment provided by the TX Sync block is
carried out in the core support layer as it performs the alignment for multiple
transceivers. The CPRI core support layer provides I/O for up to three other CPRI cores
to share the transmitter alignment block. When running at 64B66B line rates on
UltraScale devices, instead of bypassing the buffer, the asynchronous gearbox is used.
The latency across the gearboxes is reported in Gearbox Latency Register (0x16).
• Reset Generation. A reset block is used to generate the reset to the transceiver
common block.
14
Optionally the CPRI core can be generated without the core support layer. In this case the
core top level corresponds to the block layer in Figure 2-2. An example design provided
with the core includes the logic provided by the core support layer in Figure 2-2. Figure 2-3
shows a block diagram of the core when it is generated without the core support layer.
GT_CHANNEL
RXOUTCLK
TXOUTCLK
Optional DRP
Vendor Specific I/F
ORI I/F
IQ I/F RX
Sync
Optional
Management I/F
AXI I/F

Speed
Change
HDLC I/F State
Machine

clk
recovered_clk
cpri_v8_7
recclk_in
clk_in
txoutclk
rxoutclk
Quad PLL Ports
Alignment I/F
<component_name>
<component_name>
;
Figure 2-3: Block Level of the CPRI Core without the Core Support Layer
For more information on sharing the resources between multiple cores see Resource
Sharing. The core support layer is discussed in more detail in Output Generation.
Port Descriptions
The interfaces for this core are described in detail in Interfacing to the Core in Chapter 3.

15
Management Register Map

The memory map for the management register block is shown in Table 2-2.
Table 2-2: Management Register Addresses

Address AXI Address Name Mode
0x0 0x0 Status Code and Alarm Register (0x0) Read Only
0x1 0x4 Miscellaneous Status Register (0x1) Read Only
0x2 0x8 Current HDLC Rate Register (0x2) Read Only
0x3 0xC Current Ethernet Pointer Register (0x3) Read Only
0x4 0x10 Received Subchannel 2, Word 0 Register (0x4) Read Only
0x7 0x1C Received Subchannel 2, Word 3 Register (0x7) Read Only
0x8 0x20 Transceiver Loopback and Ethernet Reset Request Register (0x8) Read/Write
0x9 0x24 Transceiver Barrel Shift Position Register(0x9) Read Only
0xA 0x28 Preferred HDLC Rate Register (0xA) Read/Write
0xB 0x2C Preferred Ethernet Pointer Register (0xB) Read/Write
0xC 0x30 Current Line Speed Register (0xC) Read Only
0xD 0x34 Line Speed Capability Register (0xD) Read/Write
0xE 0x38 General Configuration and Transmit CPRI Alarms Register (0xE) Read/Write
0xF 0x3C R21 Timers Register (0xF) Read Only
0x10(1) 0x40 Current Protocol Version Register (0x10) Read Only
0x11 0x44 Preferred Protocol Version Register (0x11) Read/Write
0x12 0x48 Scrambler Seed Register (0x12) Read/Write
0x13 0x4C Descrambler Seed Register (0x13) Read Only
0x14(2) 0x50 Transmit FIFO Transit Time Register (0x14) Read Only
0x15 0x54 Watchdog Timeout Value Register (0x15) Read/Write
0x16(3) 0x58 Gearbox Latency Register (0x16) Read Only
0x17 0x5C FIFO Fill Level Register (0x17) Read/Write
0x18 0x60 General Debug Register (0x18) Read Only
0x19 0x64 High Resolution FIFO Transit Time—Integer Part Register (0x19) Read Only
0x1A 0x68 High Resolution FIFO Transit Time—Fractional Part Register (0x1A) Read Only
0x1B (4) 0x6C FEC Status Register (0x1B) Read Only
0x1C (4) 0x70 FEC CW Count Register (0x1C) Read Only
0x1D(4) 0x74 FEC Corrected CW Count Register (0x1D) Read Only

16
Table 2-2: Management Register Addresses (Cont’d)

Address AXI Address Name Mode
0x1E (4) 0x78 FEC Uncorrected CW Count Register (0x1E) Read Only
Notes:
1. Addresses 0x10 and above (AXI addresses 0x40 and above) are only present in cores that support operation at
4,915.2 Mb/s or higher.
2. Present only in Kintex-7, Virtex-7 and Zynq-7000 based cores supporting 10,137.6 or 12,165.12 Mb/s.
3. Present only in UltraScale-based cores supporting line rates up to 10,137.6, 12,165.12, or 24,330.24 Mb/s.
4. Present only in UltraScale-based cores supporting line rates up to 24,330.24Mb/s with FEC Enabled mode.
Status Code and Alarm Register (0x0)

Table 2-3: Status Code and Alarm Register
Bits Description
31-5 Reserved
Summary Alarm
The summary alarm bit is identical to the stat_alarm bit on the Status and Alarm interface. It
is set whenever any of the following conditions occur:
• If the SDI bit or the Reset bit is set in the Transmit CPRI Alarms register.
• Local Loss Of Frame (LOF), Loss of Signal (LOS) or Remote Alarm Indication (RAI) bits set. A
local LOF or LOS results in the LOF or LOS bit being set in the transmitted Z.130.0 bits
4 respectively. A local LOF or LOS also causes a local RAI which is returned in the transmitted
Z.130.0 RAI bit.
• LOF, LOS or RAI bit set in received Z.130.0. When any of these alarms are seen for the first
time the core returns to carrying out L1 Synchronization and rate negotiation. If the alarm
persists, a slave CPRI core can still become operational albeit with the summary alarm bit
set. A master CPRI core also completes L1 synchronization and rate negotiation regardless
of received alarms.
Status Code
The Status Code indicates the current state of the core. It is identical to the stat_code port on
the Status and Alarm interface. The status code ports are as follows:
0000: Reset
0001: Attempting L1 synchronization
3-0 0010: Protocol version setup
0011: C&M parameter setup
1011: Passive Mode
1110: Interface and vendor-specific negotiation
1111: Operational state: link is up
Note that stat_code keeps its previous value until the deassertion of reset.
Miscellaneous Status Register (0x1)

Bits 31:16 of this register carry read-only information on the version of the core. Bits 15:8
are the latched error register bits and are set High when the relevant error condition is
detected. They are reset when register 0x1 is read through the management interface.

17
Table 2-4: Miscellaneous Status Register

Bits Description
31-24 Major version
23-20 Minor version
19-16 Revision
15 Latched version of local loss of frame synchronization (LOF)
14 Latched version of local loss of signal (LOS)
13 Latched version of local RAI
12 Latched version of remote loss of frame synchronization (LOF)
11 Latched version of remote loss of signal (LOS)
10 Latched version of remote Service Access Point (SAP) Defect Indication
9 Latched version of remote RAI
8 Latched version of remote Reset
7 When 1, core is a master port; when 0, core is a slave port.
6 When 1, core has been generated using a hardware evaluation license
5:2 Reserved
1 Local loss of frame synchronization (1)
0 Local loss of signal (1)
Notes:
1. Bits 0 and 1 are not latched and clear by themselves when LOS and LOF clear.
Current HDLC Rate Register (0x2)

Table 2-5: Current HDLC Rate Register
Bits Description
31-3 Reserved
Current HDLC Rate Encoding
000: No HDLC channel
001: 240 kb/s
010: 480 kb/s
011: 960 kb/s
100: 1,920 kb/s
2-0 101: 2,400 kb/s
110: Highest possible HDLC bit rate for line rates above 3,072.0 Mb/s.
3,840 kb/s when core is operating at 4,915.2 Mb/s
4,800 kb/s when core is operating at 6,144.0 Mb/s
7,680 kb/s when core is operating at 8,110.08, 9,830.4, 10,137.6, 12,165.12, and
24,330.24 Mb/s
111: User defined HDLC rate

18
Current Ethernet Pointer Register (0x3)

Table 2-6: Current Ethernet Pointer Register
Bits Description
31-6 Reserved
Current Ethernet pointer. Value from 20 to 63, where 20 is the highest bandwidth, or 0 if a
5-0
passive link is required, or is in operation.
Received Subchannel 2, Word 0 Register (0x4)

Received value of control word Z.2.0. See CPRI Specification v7.0 [Ref 1], Section 4.2.7.6, “L1
Inband Protocol.”

Received value of control word Z.66.0. See CPRI Specification v7.0 [Ref 1], Section 4.2.7.6,
“L1 Inband Protocol.”


Transceiver Loopback and Ethernet Reset Request Register (0x8)

Table 2-7: Transceiver Loopback and Ethernet Reset Request Register
Bits Description
31-4 Reserved
Loopback (defaults to 00)
3:2 00: Normal Operation

10: Near-end physical medium attachment (PMA) Loopback
01,11: Reserved
Reset the Ethernet receive block. Although this bit is writable, it is always read as 0 as the reset
1
is immediate.
Reset the Ethernet transmit block. Although this bit is writable, it is always read as 0 as the
0
reset is immediate.

19
Transceiver Barrel Shift Position Register(0x9)

Table 2-8: GTP/GTX Transceiver Barrel Shift Position Register
Bits Description
31-7 Reserved
6-0 Current position of the transceiver receive barrel shifter. See R21 Calculation for more details.
Preferred HDLC Rate Register (0xA)

Table 2-9: Preferred HDLC Rate Register
Bits Description
31-13 Reserved
HDLC byte valid vector. These bits provide support for the user-defined HDLC rate, see
12:3
Table 2-5. The vector value indicates which bytes in the HDLC codeword contain valid data.
The preferred HDLC rate for the link. This sets the initial value the core uses in negotiating a
common rate with a peer. To ensure correct operation it should be set before link initialization.
2:0
Typically, this is achieved by disabling the core through the line-speed capability register. For
valid values, see Table 2-5. Defaults to 480 kb/s.
Preferred Ethernet Pointer Register (0xB)

Table 2-10: Preferred Ethernet Pointer Register
Bits Description
31-6 Reserved
The preferred value of the Ethernet pointer.
The preferred value is used by the core in negotiating a common rate with its peer. The value
5:0 must be between 20 and 63 decimal, where 20 is the highest bandwidth, or 0 to indicate no
Ethernet channel. To ensure correct operation it should be set before link initialization.
Typically this is achieved by disabling the core through the line speed capability register.
Defaults to 20 in non-ORI cores and to 53 in cores supporting ORI.
Current Line Speed Register (0xC)

Table 2-11: Current Line Speed Register
Bits Description
31-15 Reserved
14 24,330.24 Mb/s FEC Enabled Mode (GTYE3 or GTYE4 only)
10 24,330.24 Mb/s (GTYE3 or GTYE4 only)
9 12,165.12 Mb/s
8 8,110.08 Mb/s

20
Table 2-11: Current Line Speed Register (Cont’d)

Bits Description
7 10,137.6 Mb/s
6 9,830.4 Mb/s
5 6,144.0 Mb/s
4 4,915.2 Mb/s
3 3,072.0 Mb/s
2 2,457.6 Mb/s
1 1,228.8 Mb/s
0 614.4 Mb/s
Line Speed Capability Register (0xD)

The bits in this register define the line speeds that the core should use.
Table 2-12: Line Speed Capability Register

Bits Description
31-15 Reserved
14 Capable of 24,330.24 Mb/s FEC Enabled Mode
10 Capable of 24,330.24 Mb/s

21
Table 2-12: Line Speed Capability Register (Cont’d)

Bits Description
0 Capable of 614.4 Mb/s
Notes:
1. Setting 000 0000 0000 0000 disables the core.
2. In cores that do not support 6,144.0 Mb/s operation, writes to bits 4 through 14 are ignored. In cores that do not
support 9,830.4 Mb/s operation, writes to bits 6 through 14 are ignored.
In cores that do not support 10,137.6 Mb/s operation, writes to bits 7 through 14 are ignored.
In cores that do not support FEC operation, writes to bits 11 through 14 are ignored.
Table 2-13 shows the defaults for the Line Speed Capability Register, depending on the
speed capability that is selected.
Table 2-13: Line Speed Capability Register Defaults

Core Speed Capability Line Speed Capability Register (0xD) Default
368.64 MHz reference clock: 000 0111 0000 0000
24,330.24 Mb/s
24,330.24 Mb/s with FEC
12,165.12 Mb/s
307.20 and 245.76 MHz reference clock: 000 0011 1111 1111
10,137.6 Mb/s 000 0000 1111 1111
9,830.4 Mb/s 000 0000 0111 1111
6,144.0 Mb/s 000 0000 0011 1111
4,915.2 Mb/s 000 0000 0001 1111
3,072.0 Mb/s 000 0000 0000 1111
General Configuration and Transmit CPRI Alarms Register (0xE)

Table 2-14: General Configuration and Transmit CPRI Alarms Register
Default
Bits Description
Value
Software reset
When set to 1 the core performs a reset. The bit reads back a 1 while reset is in
progress and 0 when complete. The reset is considered complete when clk_ok is
31 0
asserted. The software reset does not affect the other management register settings.
clk_ok remains Low until a valid line rate is selected by the core. Setting the line
speed capability register to 0 does not disable the management interface.
30:29 N/A Reserved

22
Table 2-14: General Configuration and Transmit CPRI Alarms Register (Cont’d)
Bits Default Description

Value
GMII mode
28 1 If the GMII interface is selected and this field is set to 1 then 8-bit GMII data is
transferred over the GMII interface. If this field is set to 0 4-bit MII data is transferred.
Ethernet Jam Byte Count
27:24 5 If Ethernet Receiver Ignores TX_EN is FALSE, this field defines the number of bytes
the core asserts the eth_rx_er signal on the Ethernet interface. Valid values: 1 to 15.
Ethernet Gap Byte Count
23:20 12 If the Ethernet Gap in C&M Channel bit (bit 17) is set to 1, this field defines the
number of bytes of Interframe Gap. The valid range is 3 to 15. This functionality is
not supported when the GMII interface is selected.
Ethernet Transmitter Ignores RX_DV
19 1 When set to 0, the core asserts eth_col if eth_tx_en is asserted at the same time as
eth_rx_dv. When set to 1, eth_col does not depend on the state of eth_rx_dv.
Ethernet Receiver Ignores TX_EN
When set to 0, the core does not attempt to source a frame on the Ethernet receive
18 1 interface if a transmission is in progress (true half-duplex). When set to 1, the
receiver ignores the transmitter and sources a frame on the receive interface if one
is available.
Ethernet Gap in C&M Channel
17 1 When set to 1, the core inserts Ethernet interpacket gaps across the CPRI fast C&M
channel. When set to 0, the core does not insert interpacket gaps on the CPRI Fast
C&M channel but sends frames as fast as they are supplied on the Ethernet interface.
HDLC Rate Adaptation
When set to 1, the enable for the transmit data and the valid signals for the receive
16 1 data are pulsed High at regular intervals. This maintains the average HDLC data rate
negotiated at start-up. When set to 0, the core outputs enable and valid signals that
frame a burst of HDLC data. The length of the burst is dependent on the HDLC rate
negotiated at start-up.
Sync Header Reversal
15 0 When set to 1 the txheader(1:0) and rxheader(1:0) bits are reversed if 64B66B
encoding is enabled.
14:9 N/A Reserved
Slave Transmit Enable
When the Slave Transmit Enable bit is set to 0, the slave does not turn on its
8 0 transmitted output until HFNSYNC is achieved. When set to 1, the slave does turn
on its transmitted output immediately on start-up. This bit is read when the design
enters the L1 synchronization state.
7:3 N/A Reserved
2 0 SAP Defect Indicator (SDI)

23
Table 2-14: General Configuration and Transmit CPRI Alarms Register (Cont’d)
Bits Default Description

Value
1 N/A Reserved
Reset (Downlink—Request, Uplink—Acknowledge)
When this bit is set to 1 on a core configured as a Master, a 1 is transmitted in the
reset bit of control word Z.130.0 of the outbound CPRI frame. When the Reset bit is
then set to 0, the core continues to transmit a 1 for the Z.130.0 reset bit for 10
Hyperframes and then reverts to transmitting 0.
When the core is configured as a slave, setting this bit to 1 causes the Reset bit in
0 Z.130.0 to be asserted as reset acknowledge. After a 0 is written the core transmits a
1 for the Z.130.0 Reset bit for 5 Hyperframes and then reverts to transmitting 0.
Other than obeying the requirements specified previously for performing two writes
on the management interface (that is, wait for mgmnt_ack and then deassert
mgmnt_req signal for at least one clock cycle before starting a subsequent write)
there is no delay requirement between writing 1 and writing 0 to the Reset bit, bit 0.
See section 4.2.7.6.1 of CPRI specification 7.0 [Ref 1] for more information.
R21 Timers Register (0xF)

Table 2-15: R21 Timers Register
Bits Description
31-18 FIFO transit time value
17:0 Coarse timer value
See Delay Measurement and Requirement 21 (R21).
Current Protocol Version Register (0x10)

Table 2-16: Current Protocol Version Register
Bits Description
31-8 Reserved
7:0 Current protocol version

24
Preferred Protocol Version Register (0x11)

Table 2-17: Preferred Protocol Version Register
Bits Description
31-8 Reserved
Preferred Protocol Version
At speeds of 3,072.0 Mb/s and under and at 10,137.6 Mb/s, 12,165.12, and 24,330.24 Mb/s,
protocol version 1 is supported. At other speeds protocol versions 1 and 2 are supported.
Default is protocol version 2.
7:0 At line rates of 4,915.2, 6,144.0 and 9,830.4 Mb/s data scrambling is enabled when the protocol
version on the link has been negotiated to version 2 and there is a non-zero value
programmed into the Scrambler Seed register at address 0x12. To ensure correct operation it
should be set before link initialization. Typically this is achieved by disabling the core through
the line speed capability register.
RECOMMENDED: It is strongly recommended that scrambling is enabled at line rates of 4,915.2 Mb/s
and over. At 8,110.08, 10,137.6, 12,165.12, and 24,330.24 Mb/s, scrambling is always enabled as part
of the 64b/66b protocol.
Scrambler Seed Register (0x12)

Table 2-18: Scrambler Seed Register
Bits Description
31 Reserved
If the protocol on the CPRI link is set to 2, the data is scrambled by a side-stream scrambler
30:0
prior to encoding. This field sets the seed value that the scrambler is initialized to.
Descrambler Seed Register (0x13)

Table 2-19: Descrambler Seed Register
Bits Description
31 Reserved
This field holds the received seed value when the protocol on the CPRI link is set to 2. If the
30:0
protocol version is set to 1 on the link, this field is invalid.
Transmit FIFO Transit Time Register (0x14)

Table 2-20: Transmit FIFO Transit Time Register
Bits Description
31:14 Reserved
13:0 Transmit FIFO transit time.
See Delay Measurement and Requirement 21 (R21).

25
Watchdog Timeout Value Register (0x15)

Table 2-21: Watchdog Timeout Value Register
Bits Description
Watchdog Timeout Value
A timer in the core resets the transceiver after a certain amount of time has passed with no
31:0 valid data received. This register holds the number of management clock cycles for the timer
to wait before resetting the core. With a management clock speed of 125 MHz, the register
times out after around 4 ms by default. Setting the register to all zeros disables the timer.
Gearbox Latency Register (0x16)

Table 2-22: Gearbox Latency Register
Bits Description
31:16 Receiver Gearbox Latency
15:0 Transmitter Gearbox Latency
In UltraScale-based cores operating at line rates of 8,110.08, 10,137.6, 12,165.12, and

24,330.24 Mb/s, the asynchronous gearbox is used to implement 64b66b encoding. The
latency through the transmit and receive gearboxes is reported using this register.
See the UltraScale Architecture GTH Transceivers User Guide (UG576) [Ref 4] and UltraScale
Architecture GTY Transceivers User Guide (UG578) [Ref 5] for more information on the
asynchronous gearbox. The value is reported in units of 1/8 of a UI.
FIFO Fill Level Register (0x17)

Table 2-23: FIFO Fill Level Register
Bits Description
31:7 Reserved
FIFO Fill Level
In master cores the starting level of the clock-domain crossing (CDC) FIFO can be set using
6:0 this register. By default the CDC FIFO fills to half way (fill level = 64) before reading is enabled.
To reduce latency, at the expense of reduced cable length support, the FIFO fill level can be
reduced.

26
General Debug Register (0x18)

This register holds debug information on the state of the received L1 in-band protocol
words. In addition an error in the CDC FIFO is flagged.
Table 2-24: General Debug Register

Bits Description
31:4 Reserved
3 CDC FIFO Error
2 Invalid Ethernet Pointer Received
1 Invalid HDLC Rate Received
0 Invalid Protocol Received
High Resolution FIFO Transit Time—Integer Part Register (0x19)

The integer part of the receiver CDC FIFO transit time. See Delay Measurement and
Requirement 21 (R21).
Table 2-25: High Resolution FIFO Transit Time—Integer Part Register

Bits Description
31:7 Reserved
6:0 FIFO transit time (Integer part)
High Resolution FIFO Transit Time—Fractional Part Register

(0x1A)
The fractional part of the receiver CDC FIFO transit time. See Delay Measurement and
Requirement 21 (R21).
Table 2-26: High Resolution FIFO Transit Time—Fractional Part Register

Bits Description
31:16 Reserved
15:0 FIFO transit time (Fractional part)
FEC Status Register (0x1B)

Table 2-27: FEC Status Register
Bits Description
31:11 Reserved
stat_symbol_errors
10:8
Indicates the number of symbol errors corrected in each codeword.

27
Table 2-27: FEC Status Register (Cont’d)

Bits Description
stat_rx_delay
7:1 Indicates the fraction of a clock cycle delay that is added to the RX datapath latency by the
FEC input gearbox. A value of 0 means no additional delay, a value of 65 means 65/66 of a
clock cycle is being added.
stat_rx_align_status
0 When High this signal indicates that alignment to the incoming codeword boundary position
has been achieved and the receiver is accepting and processing data.
FEC CW Count Register (0x1C)

Table 2-28: FEC CW Count Register
Bits Description
CW Count
31:0
Indicates the number of received RS-FEC codewords.
FEC Corrected CW Count Register (0x1D)

Table 2-29: FEC Corrected CW Count Register
Bits Description
Corrected CW Count
31:0
Indicates the number of corrected RS-FEC codewords.
FEC Uncorrected CW Count Register (0x1E)

Table 2-30: FEC Uncorrected CW Count Register
Bits Description
Uncorrected CW Count
31:0
Indicates the number of uncorrected RS-FEC codewords.

28
Chapter 3
Designing with the Core

This chapter provides a general description of how to use the CPRI™ core in your designs
and also describes specific core interfaces.
General Design Guidelines

This section describes the steps required to turn a CPRI core into a fully-functioning design
with user-application logic. Not all implementations require all the design steps listed in
this chapter. However, it is important to carefully follow the logic design guidelines in this
guide.
Use the Example Design as a Starting Point

Each instance of the CPRI core created by the IP Catalog is delivered with an example design
that can be implemented in an FPGA and simulated. This design can be used as a starting
point for your own design or can be used to debug your application in the event of
difficulty.
See Chapter 6, Example Design for information about using and customizing the example
designs for the CPRI core.
Know the Degree of Difficulty

CPRI designs are challenging to implement in any technology and the degree of difficulty is
further influenced by:
• maximum system clock frequency

• nature of your application
All CPRI implementations need careful attention to system performance requirements.

Pipelining, logic mapping, placement constraints, and logic duplication are all methods that
help boost system performance.

29
Keep It Registered
To simplify timing and increase system performance in an FPGA design, keep all inputs and
outputs registered between your application and the core. This means that all inputs and
outputs from your application should come from or connect to a flip-flop. While registering
signals cannot be possible for all paths, it simplifies timing analysis and makes it easier for
the Xilinx tools to place-and-route the design.
Recognize Timing Critical Signals

The XDC provided with the example design identifies critical signals and timing constraints
that should be used. Constraining the Core contains detailed information about the use of
these signals.
Use Supported Design Flows

The core is delivered to you as encrypted RTL in the Vivado® Design Suite. The Vivado
synthesis tool is supported for the synthesis of the encrypted RTL and the associated
wrapper files. Post-synthesis, only Vivado Design Suite is supported.
Make Only Allowed Modifications

The CPRI core is not user-modifiable. Do not make modifications as they can have adverse
effects on system timing and protocol compliance. Supported configurations of the CPRI
core can only be made by selecting the options from within the IP catalog when the core is
generated. See Chapter 5, Design Flow Steps.
Clocking and Resets

This section lists the clock and reset ports of the CPRI core. Chapter 4, Design
Considerations contains detailed descriptions of the clocking for each device family.
The datapath clocks are generated in the clocking block in the core support layer. This leads
to some differences in the core level clocking ports between designs that are generated
with the core support layer and those that are generated without. For more information on
the core support layer see CPRI Core Structure.
Table 3-1 lists the clock and reset ports that are common to both support layer
configurations of the core.

30
Table 3-1: Clock and Reset Signals (All Cores)

Port Direction Description
Active-High asynchronous reset for the core and the management
interface. This reset is synchronized to each clock domain in the core.
Asserting this input resets both the core and the configuration registers.
reset In
To reset the core without changing the configuration registers a soft reset
can be used (see General Configuration and Transmit CPRI Alarms Register
(0xE)).
Transceiver reference clock input. Generated from the transceiver
refclk In
differential reference clock input by an IBUFDS in the user design.
Transceiver 307.2 MHz reference clock input. In 7 series and GTHE3-based
refclk_307 In cores that support 12,165.12 Mb/s a second reference clock is required in
order to support all the line rates.
Artix®-7 cores supporting a free running receive clock only. Transceiver
tx_refclk In reference clock input from a crystal oscillator by an IBUFDS. Used to drive
PLL1 in the GTPE2_COMMON component.
Management clock in the range 10-125 MHz. When the AXI4-Lite
Management Interface option is selected, the management interface is
clocked by the s_axi_aclk input from the AXI4-Lite bus. When the
generic management interface is used, the aux_clk input is used to clock
the management interface. See Customizing and Generating the Core for
aux_clk/ more information. In addition to the management interface this clock also
In
s_axi_aclk drives the blocks programming the Dynamic Reconfiguration Port (DRP)
ports of the GT transceiver and the internal Phase-Locked Loops (PLLs)
used for clock synthesis. This clock must run continuously without
interruption as the GT transceiver and PLLs are reconfigured during speed
switches. This clock can be shared between multiple instances of the CPRI
core.
Management Interface reset. Asserting this signal resets the management
reset_aux_clk/ sections of the design.
In
s_axi_aresetn reset_aux_clk is for generic management interface, s_axi_aresetn is
generated when the AXI4-Lite Management interface option is selected.
UltraScale™ architecture-based devices only. Clock for the transceiver reset
state machine in the core. This free running clock must have a frequency
gtwiz_reset_clk_
In lower than that of the system clock when running at the lowest supported
freerun_in
line rate, for example 15.36 MHz for 32-bit cores supporting 614.4 Mb/s.
This clock can be shared between multiple cores.
High resolution sampling clock used to measure the transmit time of the
clock-domain crossing FIFO(s). Must be at least
150 MHz when operating at speeds of 2,457.6 Mb/s and under
175 MHz for 3,072 Mb/s operation
275 MHz for 4,915.2 Mb/s operation,
hires_clk In 325 MHz for operation at 6,144 and 9,830.4 Mb/s
380 MHz for operation at 8,110.08, 10,137.6, 12,165.12 and
24,330.24 Mb/s.
The clock should not be derived from the same source as refclk; it must
be unrelated. This clock can be shared between multiple instances of the
CPRI core.

31
Table 3-1: Clock and Reset Signals (All Cores) (Cont’d)

High resolution clock OK. Signal indicating the status of the high resolution
hires_clk_ok In
clock. Set High when the clock is stable.
Ethernet clock running at 25 MHz. When the MII interface is selected, this
eth_ref_clk In clock is used to clock the Ethernet interface. This should also be used to
clock the client logic attached to this interface.
Ethernet transmit clock running at 125 MHz. When the GMII interface is
selected, this clock is used to clock the transmit side of the Ethernet
eth_tx_clk In
interface. This should also be used to clock the client logic attached to the
transmit interface.
Ethernet receive clock running at 125 MHz. When the GMII interface is
selected, this clock is used to clock the receive side of the Ethernet
eth_rx_clk In
interface. This should also be used to clock the client logic attached to the
receive interface.
In UltraScale and UltraScale+ based designs the RXRECCLKOUT port of the
transceiver can be routed out of the device directly. This port can be
rxrecclkout Out connected to an OBUFDS_GTE3 or OBUFDS_GTE4 as shown in the
UltraScale Architecture GTH Transceivers User Guide (UG576) [Ref 4] and
the UltraScale Architecture GTY Transceivers User Guide (UG578) [Ref 5]
Table 3-2 lists the clock and reset ports that are exclusive to designs generated with the
core support layer. These are generated by the clocking circuitry in the support layer and
output for use in the user design. The clocks from the PLL in the common block are also
routed out of the core. These can be shared by other transceivers in the quad. See
Transceiver Interface for a description of these clocks.
Table 3-2: Clock and Reset Signals (Support Layer Generated in the Core)
System clock. Used for all datapath logic in the core and to clock the I/Q,
frame and synchronization, HDLC and vendor-specific interfaces. The
clk_out Out
same clock should be used to clock client logic attached to these
interfaces. See Table 2-1 for the core clock rates.
System clock OK. Signal indicating the status of the system clock. High
clk_ok_out Out
when the clock is stable.
Recovered clock from the GT transceiver. When the design is operating as
recclk Out a slave, a clean-up PLL should be used to generate the transceiver
reference clock from the recclk output.
Recovered clock OK. Signal indicating the status of the recovered clock.
recclk_ok Out
High when the clock is stable.
Present on GTXE2, GTHE2 and GTPE2 implementations. Signal from the
clocking logic in the core support layer that is asserted to reset the
gt_reset_req_out Out transceiver. This is asserted on startup and after a line rate change on the
CPRI link. Used to reset transceivers that share the clocking logic in the
core.
Table 3-3 lists the clock and reset ports that are exclusive to designs generated with the
core support layer in the example design rather than in the core. The clock inputs are

32
generated by the clocking circuitry in the support layer. The core also outputs some clocks
and control signals to the clocking block. The clocks from the PLL in the common block are
also routed in to the core. See Transceiver Interface for a description of these clocks.
Table 3-3: Clock and Reset Signals (Support Layer Generated in the Example Design)
Transmit output clock from the GT transceiver. This is used to generate the
txoutclk Out
system clock.
System clock. Used for all datapath logic in the core and to clock the I/Q,
frame and synchronization, HDLC and vendor-specific interfaces. The
clk_in In
same clock should be used to clock client logic attached to these
interfaces. See Table 2-1 for the core clock rates.
Present on GTXE2 and GTHE2 implementations supporting 10,137.6 or
12,165.12 Mb/s only. This is the transceiver TX user clock. At line rates
using 8B10B encoding it runs at the same frequency as clk_in. When
64B66B encoding is enabled it runs at 66/64th of the clk_in frequency.
clk_316_in In
At 12,165.12 Mb/s the frequency is 380.16 MHz;
at 10,137.6 Mb/s it is 316.8 MHz and
at 8,110.08 Mb/s it is 253.44 MHz.
See Clock Configuration.
Artix-7 and 24,330.24 Mb/s capable UltraScale and UltraScale+ based
txusrclk In cores only. Transceiver TXUSRCLK input. Clock running at double the
speed of clk_in. See Clock Configuration.
System clock OK. Signal indicating the status of the system clock. Drive
clk_ok_in In
High when the clock is stable.
Receive output clock from the GT transceiver. This is used to generate the
rxoutclk Out
recovered clock input.
recclk_in In Recovered clock input for the GT transceiver.
Recovered clock OK. Signal indicating the status of the recovered clock.
recclk_ok Out
High when the transceiver has completed receiver reset and alignment.
Present on GTXE2, GTHE2 and GTPE2 implementations. Signal from the
clocking logic in the core support layer that is asserted to reset the
gt_reset_req In
transceiver. This is asserted on startup and after a line rate change on the
CPRI link.
MMCM Reset. A High on this signal holds the MMCM in the clocking
block in reset until txoutclk is stable.
mmcm_rst Out
mmcm_rst can be used to reset both the core and management interface.
When mmcm_rst is asserted, the stat_code value is 0.
Signal from the core indicating that the transceiver reset sequence is
txresetdone_out Out
complete. The core is held in reset until this signal is asserted.
Present on GTHE2, GTPE2, UltraScale and UltraScale+ implementations.
Signal from the core to indicate that the transceiver reset procedure has
gtreset_sm_done Out
been completed. This is used by the clocking block to prevent a speed
change during a reset cycle.

33
Table 3-3: Clock and Reset Signals (Support Layer Generated in the Example Design) (Cont’d)
Present in GTHE3/GTYE3/GTHE4/GTYE4 implementations only. Reset for
userclk_tx_reset Out
the transmit clock BUFG_GT in the clocking logic.
Present in GTHE3/GTYE3/GTHE4/GTYE4 implementations only. Reset for
userclk_rx_reset Out
the receive clock BUFG_GT in the clocking logic.
Interfacing to the Core

This section provides information about the data, status and transceiver interfaces and
includes instructions for connecting them to the CPRI core. In the following timing
diagrams clk refers to the system clock, as described in Clocking and Resets.
Data Interfaces
I/Q Interface
The I/Q interface of the CPRI core gives direct access to the multiplexed and mapped I/Q
data stream as it appears on the CPRI link. As such, use of this interface requires detailed
knowledge of the CPRI mapping protocol in use by the designer; however, it is an extremely
flexible and powerful interface to use for transporting I/Q data.
Three I/Q data adapter modules are also delivered with the core example design: I/Q
multiplexers that support the UTRA-FDD and E-UTRA sample mappings described in the
CPRI specification and a legacy raw I/Q module to match the raw I/Q interface timing of
v1.2 and earlier of the CPRI core.
The ports shown in Table 3-4 are used to pass I/Q data.
Table 3-4: I/Q Interface Signals

Port Direction Clock Domain Description
Transmit I/Q data. Synchronous to clk. 64 bits
wide when the 64-bit datapath option is selected;
iq_tx In System Clock
32-bits wide when the 32-bit datapath option is
selected; 16-bits wide otherwise.
iq_tx_enable Out System Clock Transmit enable indicating the start of a new T c.
Receive I/Q data. Synchronous to clk. 64 bits
wide when the 64-bit datapath option is selected;
iq_rx Out System Clock
32-bits wide on when the 32-bit datapath option
is selected; 16-bits wide otherwise.
Indicates the start of a new basic frame, asserted
basic_frame_first_word Out System Clock
once every T c.

34
CLK
IQ?TX?ENABLE
IQ?TX;= 88 !! ##"" %%$$
Figure 3-1: 16-Bit Wide I/Q Transmit Interface at 614.4 Mb/s

The signal basic_frame_first_word marks the start of a new basic frame. The signal
iq_rx is sampled on the rising edge of clk. A basic frame at 614.4 Mb/s is 16 bytes in
length, with the first byte being the control word. The control word, denoted as XX in
Figure 3-1 is ignored and can be any value. Bytes are sent out in the basic frame in the
following order:
XX, 00, 11, 22, 33 …
Similarly for the receive interface at 614.4 Mb/s:

CLK
BASIC?FRAME?FIRST?WORD
IQ?RX;= CW !! ##"" %%$$
Figure 3-2: 16-Bit Wide IQ Receive Interface at 614.4 Mb/s

The signal basic_frame_first_word marks the start of a new basic frame. The signal
iq_rx is sampled on the rising edge of clk. The control word data, present in the first
byte at 614.4 Mb/s should be ignored. Bytes are received in the basic frame in the following
order:
cw, 00, 11, 22, 33 …
Other speeds follow a similar format. The length of the basic frame and the control word is
expanded. For 1,228.8 Mb/s, the basic frame is 32 bytes in length, and the first two bytes
are the control word. For 2,457.6 Mb/s, the basic frame is 64 bytes in length, and the first
four bytes are the control word.
For 3,072 Mb/s, the basic frame is 80 bytes in length and the first five bytes are the control
word. At 4,915.2 Mb/s the basic frame is 128 bytes in length and the first 8 bytes are the
control word. At 6,144.0 Mb/s the basic frame is 160 bytes in length and the first 10 bytes
are the control word. Figures 3-2 through 3-12 illustrate the 16-bit wide I/Q Transmit and
Receive Interfaces at a range of speeds.

35
CLK
IQ?TX?ENABLE
IQ?TX;= XXXX ""!! $$##
Figure 3-3: I/Q Transmit Interface at 1,228.8 Mb/s

CLK
IQ?RX;= CWCW ""!! $$##
Figure 3-4: I/Q Receive Interface at 1,228.8 Mb/s

CLK
IQ?TX?ENABLE
IQ?TX;= 8888 8888 ""!!

CLK
IQ?RX;= CWCW CWCW ""!!

CLK
IQ?TX?ENABLE
IQ?TX;= 8888 8888 88 ##"" %%$$ &&

CLK
IQ?RX;= CWCW CWCW CW ##"" %%$$ &&

CLK
IQ?TX?ENABLE
IQ?TX;= 8888 8888 8888 8888

36
CLK
IQ?RX;= CWCW CWCW CWCW CWCW

CLK
IQ?TX?ENABLE
IQ?TX;= 8888 8888 8888 8888 8888 &&%%

CLK
IQ?RX;= CWCW CWCW CWCW CWCW CWCW &&%%

When the 32-bit datapath option is selected, the I/Q data bus is widened to 32 bits. The
data transfers follow a similar format to the 16-bit I/Q interface; however, 4 bytes of data
are input and output on each clock period. The basic frame is 4 clock periods long at
614.4 Mb/s, 8 clock periods at 1,228.8 Mb/s, 16 clock periods at 2,457.6 Mb/s, 20 clock
periods at 3,072.0 Mb/s, 32 clock periods at 4,915.2 Mb/s, 40 clock periods at 6,144.0 Mb/s,
and 64 clock periods at 8,110.08 Mb/s and 9,830.4 Mb/s. The control word is 16 bytes long
at 8,110.08 Mb/s and 9,830.4 Mb/s. Figure 3-13 and Figure 3-14 illustrate the 32-bit wide
I/Q Transmit and Receive Interfaces at 8,110.08 Mb/s and 9,830.4 Mb/s.
CLK
IQ?TX?ENABLE
IQ?TX;= XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ""!! &&%%$$##
Figure 3-13: 32-Bit Wide Transmit Interface at 8,110.08 Mb/s and 9,830.4 Mb/s
CLK
IQ?RX;= CCCC CCCC CCCC CCCC ""!! &&%%$$##
Figure 3-14: 32-Bit Wide Receive Interface at 8,110.08 Mb/s and 9,830.4 Mb/s
When the core is configured to run at 10,137.6 Mb/s, the 32 bit I/Q data bus is used. As with
8,110.08 Mb/s and 9,830.4 Mb/s, the control word is 16 bytes long. The basic frame is
extended to be 80 clock periods long. Figure 3-15 and Figure 3-16 illustrate the I/Q
transmit and receive interfaces at 10,137.6 Mb/s.

37
CLK
IQ?TX?ENABLE
IQ?TX;= XXXXXXXX XXXXXXXX XXXXXXXXX XXXXXXXX ""!! &&%%$$##
Figure 3-15: 32-Bit Transmit Interface at 10,137.6 Mb/s

CLK
IQ?RX;= CCCCCCCC CCCCCCCC CCCCCCCC CCCCCCCC ""!! &&%%$$##
Figure 3-16: 32-Bit Receive Interface at 10,137.6 Mb/s

When the core is configured to run at 12,165.12 Mb/s, the 32-bit I/Q data bus is used. As
with 8,110.08, 9,830.4 and 10,137.6 Mb/s the control word is 16 bytes long. The basic frame
is extended to be 96 clock periods long. Figure 3-17 and Figure 3-18 illustrate the I/Q
transmit and receive interfaces at 12,165.12 Mb/s.
CLK
IQ?TX?ENABLE
IQ?TX;= XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ""!! &&%%$$##

CLK
IQ?RX;= CCCCCCCC CCCCCCCC CCCCCCCC CCCCCCCC ""!! &&%%$$##

When the core is configured to run at 24,330.24 Mb/s a 64-bit I/Q data bus is used. The
basic frame at the highest speed is 96 cycles long. The 24,330.24 Mb/s core can also
operate at 12,165.12 Mb/s and 8,110.08 Mb/s. At these speeds the basic frame is 48 and 32
cycles long respectively. The control word is always 16 bytes long. Figure 3-19 and
Figure 3-20 show the I/Q transmit and receive interfaces at 24,330.24 Mb/s.

38
CLK
IQ?TX?ENABLE
IQ?TX;= 8 8 $ATA $ATA $ATA $ATA $ATA $ATA $ATA

CLK
IQ?RX;= #ONTROL #ONTROL $ATA $ATA $ATA $ATA $ATA $ATA $ATA

UTRA-FDD I/Q Module
This module (contained in iq_module.vhd) allows you to multiplex and interleave I/Q
samples using the UTRA-FDD mapping defined in the CPRI specification. It multiplexes and
de-multiplexes up to 48 channels of I and Q data, one sample per basic frame period. The
existence and width of each channel is configurable at synthesis time.
The generics of the UTRA-FDD I/Q Module are described in Table 3-5.
Table 3-5: UTRA-FDD I/Q Module Generics

Name Type Description
Total width of I/Q channel n (n = 1… 48), transmit side. When set to 0,
C_TX_WIDTH_n Natural channel is disabled.
Legal values are 4–20 for active channels and 0 for inactive channels.
Total width of I/Q channel n (n = 1… 48), receive side. When set to 0, channel
C_RX_WIDTH_n Natural is disabled.
Legal values are 4–20 for active channels and 0 for inactive channels.
Determines the bit position of the nth I/Q channel in each basic frame,
C_TX_START_n Natural transmit side. Bit 0 is the first bit after the control word. Maximum bit
number depends on the I/Q channel widths and line rate.
Determines the bit position of the nth I/Q channel in each basic frame,
C_RX_START_n Natural receive side. Bit 0 is the first bit after the control word. Maximum bit number
depends on the I/Q channel widths and line rate.
Table 3-6: UTRA-FDD I/Q Module Signals - Core Interface

iq_tx_enable In System Clock Transmit enable indicating the start of a new T c
iq_tx Out System Clock IQ Transmit Data
iq_rx In System Clock IQ Receive Data

39
Table 3-6: UTRA-FDD I/Q Module Signals - Core Interface (Cont’d)

basic_frame_first_word In System Clock Start of new basic frame asserted once every T c
Current Line Rate. Connect to stat_speed
speed_select In System Clock
output of CPRI core.
Table 3-7: UTRA-FDD I/Q Module Signals - Transmit Interface

iq_tx_i_n[C_TX_WIDTH_n-1:0] In System Clock I data for transmit direction (n = 1 … 48).
iq_tx_q_n[C_TX_WIDTH_n-1:0] In System Clock Q data for transmit direction (n = 1… 48).
All ports of the transmit interface are synchronous to clk and connected user logic should
also be clocked by clk. The enable signal iq_tx_enable is asserted by the core for
exactly one cycle of clk for every Tc in time. The UTRA-FDD I/Q Module samples all iq_tx
ports following assertion of the iq_tx_enable signal. Figure 3-21 illustrates this timing.
CLK
IQ?TX?ENABLE
IQ?TX?I?N
IQ?TX?Q?N
4CNS
Figure 3-21: UTRA-FDD I/Q Module Transmit Timing - Client Interface
Table 3-8: UTRA-FDD I/Q Module Signals - Receive Interface

iq_rx_data_valid Out System Clock Receive Data Valid asserted once every T c
iq_rx_i_n[C_RX_WIDTH_n-1:0] Out System Clock I data for receive direction (n = 1… 48)
iq_rx_q_n[C_RX_WIDTH_n-1:0] Out System Clock Q data for receive direction (n = 1 … 48)
The de-multiplexer receive interface is similar to the transmit interface described

previously. All ports of the receive interface are also synchronous to clk. The ports are
described in Table 3-8.
The iq_rx_data_valid signal indicates when the I/Q data is valid and is asserted by the
module once every T c, as shown in Figure 3-22.

40
CLK
IQ?RX?DATA?VALID
IQ?RX?I?N
IQ?RX?Q?N
4CNS
Figure 3-22: UTRA-FDD I/Q Module Receive Timing - Client Interface

In this multiplexer I/Q Channel Configuration example the core is configured as follows:
• Transmit:
° I/Q sample width: 16
° Over-sampling ratio: 1
° AxC containers: 3
• Receive:
° I/Q sample width: 5
° Over-sampling ratio: 2
° AxC containers: 3
To set up this configuration, the generics should be set as follows.
C_TX_WIDTH_1 = 16; -- AxC container 1

C_TX_START_1 = 0;
C_TX_START_2 = 32; -- because channel 1 has 16 bits I data and 16
-- bits Q data
C_TX_START_3 = 64;
C_TX_WIDTH_n = 0; -- n = 4..48 all empty
C_RX_WIDTH_1 = 10; -- AxC container 1, 2 samples
C_RX_START_1 = 0;
C_RX_WIDTH_2 = 10; -- AxC container 2, 2 samples
C_RX_START_2 = 20;
C_RX_WIDTH_3 = 10; -- AxC Container 3, 2 samples
C_RX_START_3 = 40;
C_RX_WIDTH_n = 0; -- n = 4..48 all empty
The transmit data sources should then be connected to the correct iq_tx_* ports and the
receive data sinks should be connected to the iq_rx_* ports; in the receive case, the first
sample should be connected to bits 4 down to 0 and the second sample connected to bits
9 down to 5, and so on.

41
Consider the number of data bytes in the basic frame when setting the size and start
positions of the channels. The size of the data section of each basic frame varies from 15
bytes at 614.4 Mb/s to 240 bytes at 9,830.4 Mb/s, 308 bytes at 10,137.6 Mb/s, 368 bytes at
12,165.12 Mb/s and 752 bytes at 24,330.24 Mb/s. You should ensure that the channel start
positions plus two times the channel width (I plus Q data) do not exceed the number of bits
in the basic frame at the operating line speed. If this is not the case for a particular channel,
the data for that channel will not be correctly transmitted or received.
E-UTRA I/Q Module
The E-UTRA IQ module (contained in iq_module_eutra.vhd) provides E-UTRA I/Q

multiplexing and de-multiplexing as defined in the CPRI Specification v7.0 [Ref 1]. The
module is implemented as a wrapper around the UTRA-FDD I/Q Module, enabling the
transmission and reception of multiple samples per channel. It multiplexes and
de-multiplexes up to eight channels each with up to eight samples per basic frame period.
The existence, width, and number of samples in each channel are configurable at synthesis
time. The generics of the E-UTRA I/Q Module are described in Table 3-9.
Table 3-9: E-UTRA I/Q Module Generics

Name Type Description
Number of samples in IQ channel n (n=1 … 8) in the output CPRI stream.
C_TX_S_n Natural
Legal values are 1-8 for active channels and 0 for inactive channels.
Width of transmit IQ channel n (n=1… 8) in the output CPRI stream. Legal
C_TX_WIDTH_n Natural
values are 4-20 for active channels and 0 for inactive channels.
Number of samples in IQ channel n (n=1 … 8) in the input CPRI stream. Legal
C_RX_S_n Natural
Width of receive IQ channel n (n=1 … 8) in the input CPRI stream. Legal
C_RX_WIDTH_n Natural
Table 3-10: E-UTRA I/Q Module Signals - Core Interface

iq_tx Out System Clock IQ Transmit Data
iq_tx_enable In System Clock Transmit enable indicating start of new Tc .
iq_rx In System Clock IQ Receive Data
Start of new basic frame asserted once every
basic_frame_first_word In System Clock
Tc
Currently selected line rate. Connect to
speed_select In System Clock
stat_speed output of CPRI core.
Table 3-11: E-UTRA I/Q Module Signals - Transmit Interface

iq_tx_i_n[C_TX_WIDTH_n-1:0] In System Clock I data for transmit direction (n = 1 to 8)

42
Table 3-11: E-UTRA I/Q Module Signals - Transmit Interface (Cont’d)

iq_tx_q_n[C_TX_WIDTH_n-1:0] System Clock Q data for transmit direction (n = 1 to 8)
Data enable for transmit direction (n = 1 to
iq_tx_data_enable_n Out System Clock
8). Asserted for C_TX_S_n cycles every T c.
All ports of the transmit interface are synchronous to clk. The transmit interface receives
the iq_tx_enable pulse from the core and outputs an iq_tx_data_enable pulse for
each channel. The iq_tx_data_enable pulse is c_tx_s_n samples long. The module
captures the samples sent during the iq_tx_data_enable pulse and routes them to
ports on the internal UTRA-FDD I/Q Module. The assembled data is transmitted on the next
basic frame.
The timing on the I/Q Data Interface is illustrated in Figure 3-23. The number of samples
must be, at most, one cycle less than the length of the basic frame. For example, at
614 Mb/s with a 16-bit IQ interface the basic frame is 8 cycles long. The maximum number
of samples per channel in this case is 7.
CLK
IQ?TX?ENABLE
IQ?TX?DATA?ENABLE?N
#?48?3?N
IQ?TX?I?N ) ) ) )N
IQ?TX?Q?N 1 1 1 1N
4CNS
Figure 3-23: E-UTRA I/Q Module Transmit Timing
Table 3-12: E-UTRA I/Q Module Signals - Receive Interface

iq_rx_i_n[C_RX_WIDTH_n-1:0] Out System Clock I data for receive direction (n = 1 to 8).
iq_rx_q_n[C_RX_WIDTH_n-1:0] Out System Clock Q data for receive direction (n = 1 to 8).
Receive data valid. This signal is asserted
iq_rx_data_valid_n Out System Clock for C_RX_S_n cycles every Tc , framing the
samples from channel n.
The receiver interface receives the data from the internal UTRA-FDD I/Q Module along with
a basic_frame_first_word pulse. It de-multiplexes the data from the internal module
and outputs it along with an iq_rx_data_valid_n signal for each channel.
The timing on the I/Q Data Interface is illustrated in Figure 3-24. As with the transmitter, the
number of samples should be, at most, one cycle less than the length of the basic frame.

43
CLK
#?28?3?N
IQ?RX?DATA?VALID?N
IQ?RX?I?N
IQ?RX?Q?N
4CNS
Figure 3-24: E-UTRA I/Q Module Receive Timing

Figure 3-25 shows an example of the E-UTRA wrapper transmit data mapping. In this
example there are two E-UTRA channels. Channel 1 has three samples of width 14 and
channel 2 has two samples of width 6.
% 542!)1-ODULE 542! &$$)1-ODULE
#HANNEL 3! 3" 3#

#?48?7)$4(? #?48?7)$4(?
#?48?3? #?48?34!24?
IQ?TX?I?
IQ?TX?Q? #?48?7)$4(?
IQ?TX?I? #?48?34!24?
IQ?TX?Q?
#?48?7)$4(?
IQ?TX?I?
#?48?34!24?
IQ?TX?Q?
#HANNEL 3! 3"
#?48?7)$4(?
#?48?3? #?48?7)$4(?
IQ?TX?I?
#?48?34!24?
IQ?TX?Q?
IQ?TX?I? #?48?7)$4(?
IQ?TX?Q? #?48?34!24?
Figure 3-25: E-UTRA I/Q Module Transmit Example

The first sample in channel 1 (S1A) is mapped to the channel 1 IQ inputs of the UTRA-FDD
I/Q Module, the second sample (S1B) to channel 2, and the third (S1C) to channel 3. The
samples from the second E-UTRA channel are mapped to channels 4 and 5 of the UTRA-FDD
module. The sizes and start positions of the data in the UTRA-FDD module are set in the
E-UTRA wrapper.
In this example the first eight 16-bit words of the transmitted CPRI frame appear as shown
in Figure 3-26, when the core is operating at 1,228.8 Mb/s. The samples are transmitted in
order starting with those from channel 1 (S1A, S1B, S1C) followed by the samples from
channel 2 (S2A, S2B).

44
7/2$
BIT

#/.42/,7/2$

3! 3" 3# 3! 3"

4CNS
Figure 3-26: E-UTRA Transmit Frame Example

The receiver performs the inverse operation of the transmitter, taking the data from the
internal UTRA-FDD Module and mapping it to up to eight sample streams. Figure 3-27
shows the first eight 16-bit words of a CPRI frame received at 1,228.8 Mb/s.
7/2$
BIT

3"
#/.42/,7/2$

3! 3" 3! 3" 3! 3#

3"

4CNS
Figure 3-27: E-UTRA Receive Frame Example

The frame contains data from three channels. The first consists of two I/Q samples of 8-bits,
the second two I/Q samples of 12-bits and the third three I/Q samples of 5 bits. Figure 3-28
shows how the E-UTRA module configures the UTRA-FDD module and builds up the three
sample streams.

45
% 542!)1-ODULE 542! &$$)1-ODULE
#?28?7)$4(?
#HANNEL 3! 3" #?28?34!24?
#?28?7)$4(?
IQ?RX?I?
#?28?3? IQ?RX?Q?
#?28?7)$4(?
#?28?34!24?
IQ?RX?I?
IQ?RX?Q?
#HANNEL 3! 3" #?28?7)$4(?
#?28?7)$4(? #?28?34!24?
IQ?RX?I?
#?28?3? IQ?RX?Q?
#?28?7)$4(?
IQ?RX?I? #?28?34!24?
IQ?RX?Q?
#HANNEL 3! 3" 3#
#?28?7)$4(? #?28?7)$4(?
IQ?RX?I?
#?28?3? IQ?RX?Q? #?28?34!24?
IQ?RX?I? #?28?7)$4(?
IQ?RX?Q? #?28?34!24?
IQ?RX?I?
IQ?RX?Q? #?28?7)$4(?
#?28?34!24?
Figure 3-28: E-UTRA I/Q Module Receive Example
IMPORTANT: Ensure that all the samples for each channel can fit into the basic frame. If this is not the
case, the data will not be correctly transmitted or received.
Legacy Raw I/Q Module
This module (contained in file raw_legacy_iq_module.vhd) is intended for users that

wish to maintain the same raw interface as was present on the v1.2 core and earlier. For new
designs, the regular I/Q interface is recommended. This module does not support cores
implemented with the 32-bit or 64-bit datapath.
Table 3-13: Legacy Raw I/Q Module Signals - Core Interface

iq_tx_enable In System Clock Transmit enable indicating the start of a new T c
iq_tx[15:0] Out System Clock IQ Transmit Data
iq_rx[15:0] In System Clock IQ Receive Data
basic_frame_first_word In System Clock Start of new basic frame asserted once every Tc
Current Line Rate. Connect to stat_speed
speed_select[3:0] In System Clock
output of core.
Table 3-14: Legacy Raw I/Q Module Signals - Client Interface

Asserted at the start of the basic frame, when
rx_data_valid Out System Clock
raw_iq_rx_count is zero.
raw_iq_tx[15:0] In System Clock Raw transmit I/Q data. Synchronous to clk.
raw_iq_tx_count[5:0] Out System Clock Indicates position in the frame for raw transmit data.

46
Table 3-14: Legacy Raw I/Q Module Signals - Client Interface (Cont’d)
raw_iq_rx[15:0] Out System Clock Raw receive I/Q data. Synchronous to clk.
raw_iq_rx_count[5:0] Out System Clock Indicates position in the frame for raw receive data.
Operation of the Raw I/Q Module at 614.4 Mb/s
Figure 3-29 illustrates transmission using the legacy raw I/Q Module at 614.4 Mb/s.
• The basic frame is 8 clk periods long.

• raw_iq_tx_count goes from 0 to 7.
• When raw_iq_tx_count is 0, bits [7:0] in raw_iq_tx[15:0] are reserved for the
control word and are ignored.
CLK
IQ?TX?ENABLE
RAW?IQ?TX?COUNT
RAW?IQ?TX;= XX &%$#
CLKCYCLES
Figure 3-29: Legacy Raw I/Q Transmit Interface at 614.4 Mb/s

When a count is presented on raw_iq_tx_count, the data is captured on the next rising
clock edge. For example, in Figure 3-29 0xFEDC is sent on count 1, 0x0000 sent on count 2,
and so on. Bytes are sent out in the basic frame in the following order:
xx, 21, DC, FE, 00, 00, …
Similarly, for the receive interface at 614.4 Mb/s:
• the basic frame is 8 clk periods long.

• raw_iq_rx_count goes from 0 to 7.
• when raw_iq_rx_count is 0, bits [7:0] in raw_iq_rx[15:0] are reserved for the
basic frame control word and can be ignored.

47
This is illustrated in Figure 3-30.

CLK
RX?DATA?VALID
RAW?IQ?RX?COUNT
RAW?IQ?RX;= CW !! &&&&
CLKCYCLES
Figure 3-30: Legacy Raw I/Q Receive Interface at 614.4 Mb/s

When a count is presented on raw_iq_rx_count, the corresponding data is presented at
the same time. For example, in Figure 3-30 0xAA55 has been received on count 1, 0xFFFF
received on count 2 and so on. Bytes are received in the basic frame in the following order:
cw, 21, 55, AA, FF, FF, …
Operation of the Legacy Raw I/Q Module at 1,228.8 Mb/s
Figure 3-31 illustrates transmission using the Legacy Raw I/Q Module at 1,228.8 Mb/s.

• When raw_iq_tx_count is 0, all bits in raw_iq_tx are reserved for the control word
and are ignored.
CLK
IQ?TX?ENABLE
RAW?IQ?TX?COUNT
RAW?IQ?TX;= XXXX "&
CLKCYCLES
Figure 3-31: Legacy Raw I/Q Transmit Interface at 1,228.8 Mb/s

clock edge. For example, in Figure 3-31 0xBF24 is sent on count 1, 0x4199 sent on count 2,
and so on. Bytes in this example are send out in the order:
xx, xx, 24, BF, 99, 41, …

48
Similarly for receive at 1,228.8 Mb/s:

• when raw_iq_rx_count is 0, all bits in raw_iq_rx are reserved for the basic frame
control word and can be ignored.

CLK
RX?DATA?VALID
RAW?IQ?RX?COUNT
RAW?IQ?RX;= CWCW "&
CLKCYCLES
Figure 3-32: Legacy Raw I/Q Receive Interface at 1,228.8 Mb/s

the same time. For example, in Figure 3-32 0xBF24 has been received on count 1, 0x4199
received on count 2, and so on. In this example, bytes are received in the order:
cw, cw, 24, BF, 99, 41, …
For transmitting using the Legacy Raw I/Q Module at 2,457.6 Mb/s:
• the basic frame is 32 clk periods long

• raw_iq_tx_count goes from 0 to 31
• when raw_iq_tx_count is 0 or 1, all bits in raw_iq_tx are reserved for the control
word and are ignored.

49

CLK
IQ?TX?ENABLE
RAW?IQ?TX?COUNT
RAW?IQ?TX;= XXXX XXXX !& "
CLKCYCLES
Figure 3-33: Legacy Raw I/Q Transmit Interface at 2,457.6 Mb/s

clock edge. For example, in Figure 3-33 0xAF54 is sent on count 2, 0x002B sent on count 3,
and so on. In this example, bytes are sent in the order:
xx, xx, xx, xx, 54, AF, 2B, 00, …

• when raw_iq_rx_count is 0 or 1, all bits in raw_iq_rx are reserved for the basic
frame control word and can be ignored.

CLK
RX?DATA?VALID
RAW?IQ?RX?COUNT
RAW?IQ?RX;= CWCW CWCW "$
CLKCYCLES
Figure 3-34: Legacy Raw I/Q Receive Interface at 2,457.6 Mb/s

the same time. For example, in Figure 3-34 0xB12D has been received on count 1, 0x5150
received on count 2, and so on. In this example, bytes are received in the order:
cw, cw, cw, cw, 2D, B1, 50, 51, …

50

• when raw_iq_tx_count is 0 or 1, all bits in raw_iq_tx are reserved for the control
• when raw_iq_tx_count is 2, bits [7:0] in raw_iq_tx are reserved for the control

CLK
IQ?TX?ENABLE
RAW?IQ?TX?COUNT
RAW?IQ?TX;= XXXX XXXX !"XX
CLKCYCLES
Figure 3-35: Legacy RAW I/Q Interface at 3,072.0 Mb/s

clock edge. For example, in Figure 3-35, 0xAB is sent in the second byte of count 2, 0x4412
is sent on count 3 and so on.
In this example, bytes are sent in the order:
xx, xx, xx, xx, xx, AB, 12, 44, …

• when raw_iq_rx_count is 0 or 1, all bits in raw_iq_rx are reserved for the basic
frame control word and can be ignored.
• when raw_iq_rx_count is 2, bits [7:0] in raw_iq_rx are reserved for the basic frame
control word and can be ignored.

51

CLK
RX?DATA?VALID
RAW?IQ?RX?COUNT
RAW?IQ?RX;= CWCW CWCW CW %!
CLKCYCLES

the same time. For example, in Figure 3-36, 0x01 has been received on the upper half of
count 2, and 0x17EA received on count 3 and so on. In this example, bytes are received in
the order:
cw, cw, cw, cw, cw, 01, EA, 17,…

• when raw_iq_tx_count is 0, 1, 2 or 3, all bits in raw_iq_tx are reserved for the

CLK
IQ?TX?ENABLE
RAW?IQ?TX?COUNT
RAW?IQ?TX;= XXXX XXXX XXXX XXXX &
CLKCYCLES

clock edge. For example, in Figure 3-37, 0x76F5 is sent on count 4, 0x5699 sent on count 5,
and so on.

52
In this example, bytes are sent in the order:
xx, xx, xx, xx, xx, xx, xx, xx, F5, 76, 99, …

• when raw_iq_rx_count is 0, 1, 2 or 3 all bits in raw_iq_rx are reserved for the

CLK
RX?DATA?VALID
RAW?IQ?RX?COUNT
RAW?IQ?RX;= CWCW CWCW CWCW CWCW $
CLKCYCLES

the same time. For example, in Figure 3-38, 0x8067 has been received on count 4, and
0x68D7 received on count 5 and so on. In this example, bytes are received in the order:
cw, cw, cw, cw, cw, cw, cw, cw, 67, 80, D7,…

53

• when raw_iq_tx_count is 0, 1, 2, 3 or 4, all bits in raw_iq_tx are reserved for the

CLK
IQ?TX?ENABLE
RAW?IQ?TX?COUNT
RAW?IQ?TX;= XXXX XXXX XXXX XXXX XXXX ! "
CLKCYCLES

clock edge. For example, in Figure 3-39, 0xA161 is sent on count 5, 0xB411 sent on count 6,
and so on. In this example, bytes are sent in the order:
xx, xx, xx, xx, xx, xx, xx, xx, xx, xx, 61, A1, 11, …

• when raw_iq_rx_count is 0, 1, 2, 3 or 4 all bits in raw_iq_rx are reserved for the

54

CLK
RX?DATA?VALID
RAW?IQ?RX?COUNT
RAW?IQ?RX;= CWCW CWCW CWCW CWCW CWCW &#% !%
CLKCYCLES

the same time. For example, in Figure 3-40, 0xFC7E has been received on count 5, and
0x12AE received on count 6 and so on. In this example, bytes are received in the order:
cw, cw, cw, cw, cw, cw, cw, cw, cw, cw, 7E, FC, AE,…
Vendor-Specific Data Interface

The CPRI specification allows for the transport of vendor-specific data in certain sub
channels of the control-word stream. The vendor-specific subchannels begin at subchannel
3 and end at the subchannel before the Ethernet data begins. If an Ethernet channel is not
in use, the subchannels up to 63 can be used for vendor-specific data. In normal CPRI
operation subchannel 3 and subchannels 8 to 15 are reserved. Subchannels 4 to 7 are
reserved for the transport of control AxC information.
Table 3-15: Vendor-Specific Data Interface Signals

Current vendor-specific control word for
transmission. This port is 128-bits wide when
24,330.24, 12,165.12, 10,137.6, or 9,830.4 Mb/s
vendor_tx_data In System Clock operation is supported, 80-bits wide when
6,144.0, 64-bits wide when 4,915.2 Mb/s
operation is supported and 40-bits wide
otherwise.
vendor_tx_xs[1:0] Out System Clock Current Control Word Index (Xs) for transmission
vendor_tx_ns[5:0] Out System Clock Current Subchannel Index (Ns) for transmission
Current received vendor-specific control word.
This port is 128-bits wide when 24,330.24,
12,165.12, 10,137.6, or 9,830.4 Mb/s operation is
vendor_rx_data Out System Clock
supported, 80-bits wide when 6,144.0, 64-bits
wide when 4,915.2 Mb/s operation is supported
and 40-bits wide otherwise.
Control word index (Ns) for received
vendor_rx_xs[1:0] Out System Clock
vendor-specific control word

55
Table 3-15: Vendor-Specific Data Interface Signals (Cont’d)

Subchannel index (Xs) for received
vendor_rx_ns[5:0] Out System Clock
vendor-specific control word
Vendor-specific negotiation complete. This port
should be held Low until vendor-specific
negotiation is complete. This causes the start-up
state machine in the CPRI core to pause in state E,
vs_negotiation_complete In System Clock
“Interface and vendor-specific negotiation” until
vs_negotiation_complete is asserted High.
If no vendor-specific negotiation is required then
this port should be tied High.
The interface for the vendor-specific data is presented to the client logic much like it is on
the I/Q data interface. On transmit, the core presents the current subchannel number Ns
and the control word index Xs on ports vendor_tx_xs and vendor_tx_ns, respectively.
If this subchannel is in the vendor-specific range, the core captures the data on the
vendor_tx_data port on assertion of the iq_tx_enable signal and sends it out in the
correct basic frame. If the subchannel is not in the vendor-specific range, the core ignores
data on the vendor_tx_data port.
TX?CLK
IQ?TX?ENABLE
VENDOR?TX?XS #URRENTINDEX8S
VENDOR?TX?NS #URRENTINDEX.S
VENDOR?TX?DATA $ATAVALUETOBETRANSMITTEDINSUBCHANNEL.S8S
4CNS
Figure 3-41: Vendor-Specific Data Interface - Transmit

On receive, the core presents the last received subchannel number Ns and control word
index Xs on ports vendor_rx_ns and vendor_rx_xs, respectively. If the subchannel is in
the vendor-specific range, the vendor_rx_data port signals the value received in that
subchannel control word. If the subchannel is not in the vendor-specific range, the
vendor_rx_data port will drive all logic 0s. See Figure 3-42.
The vendor-specific data takes several cycles to settle at the vendor_rx_data output. The
number of cycles is dependent on the size of the control word. The data is stable when
basic_frame_first_word is asserted at the end of the frame.

56
RX?CLK
VENDOR?RX?XS #URRENTINDEX8S
VENDOR?RX?NS #URRENTINDEX.S
VENDOR?RX?DATA $ATAVALUERECEIVEDINSUBCHANNEL.S8S
4CNS
Figure 3-42: Vendor-Specific Data Interface – Receive

The valid widths for the vendor_tx_data and vendor_rx_data ports vary according to
line speed. The valid bits are:
• vendor_tx_data[7:0] and vendor_rx_data[7:0] at 614.4 Mb/s

• vendor_tx_data[15:0] and vendor_rx_data[15:0] at 1,228.8 Mb/s
• vendor_tx_data[39:0] and vendor_rx_data[39:0] at 3,072 Mb/s
• vendor_tx_data[127:0] and vendor_rx_data[127:0] at 8,110.08, 9,830.4, 10,137.6,
12,165.12, and 24,330.24 Mb/s.
Invalid bits are ignored on transmit and driven to logic 0s on receive.
In addition to the vendor-specific control words the vendor-specific interface also provides
access to the control words in subchannels 4 to 7. These can be used to convey AxC specific
control information in GSM based systems.
Real Time Vendor-Specific Support

The Real Time Vendor-Specific Support option in the Vivado CPRI core customization
screen can be selected when the 24,339.24, 12,165.12, or 10,137.6 Mb/s line rates are
enabled. This allows the control word to be increased from 128 bits to:
384 bits for 24,330.24 Mb/s,

192 bits for 12,165.12 Mb/s and
160 bits for 10,137.6 Mb/s on every basic frame.
For 10,137.6 Mb/s the extra 32 bits replace the fifth word (bits 159-128) in the basic frame
as shown in Figure 3-43.

57
CLK
IQ?TX?ENABLE
IQ?TX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX2463 )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA
Figure 3-43: 32-Bit Transmit Interface with Real Time Vendor-Specific Support at 10,137.6 Mb/s
For 12,165.12 Mb/s the extra 64 bits replace the fifth and sixth words (bits 191-128) in the
basic frame as shown in Figure 3-44.
CLK
IQ?TX?ENABLE
IQ?TX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX2463 2463 )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA
For 24,330.24 Mb/s, which uses a 64-bit datapath, the extra 256 bits replace the 3rd, 4th, 5th
and 6th words in the basic frame, as shown in Figure 3-45.
CLK
IQ?TX?ENABLE
IQ?TX 8 8 2463 2463 2463 2463 )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA )1$ATA
Real time vendor-specific control data is allocated to the ports in Table 3-16.
Table 3-16: Real Time Vendor-Specific Control Data Interface Signals

Current real-time vendor-specific control data for
transmission. This port is available when 24,330.24,
12,165.12 or 10,137.6 Mb/s operation is selected.
rt_vendor_tx_data In System Clock The port width is:
256 bits when 24,330.24 Mb/s is selected
32 bits when 10,137.6 Mb/s is selected.
Current received real-time vendor-specific control data.
This port is available when 24,330.24, 12,165.12, or
10,137.6 Mb/s operation is selected.
rt_vendor_rx_data Out System Clock The port width is:
32 bits when 10,137.6 Mb/s is selected.
For further info see CPRI specification v7.0 section 3.4.4 [Ref 1].

58
If Real Time Vendor-Specific Support is not selected, bits [383:128] of the control word
can optionally be used to increase the bandwidth of the IQ data block.
Frame and Synchronization Interface

The synchronization interface indicates the current Universal Mobile Telecommunications
System (UMTS) Node B Frame Number (BFN). The signals of this interface are shown in
Table 3-17. The length of a single UMTS frame is 10 ms and is synchronized to the system
clock of the I/Q data interface, clk. Synchronization can be achieved by combining the BFN
and the I/Q data interface clocks.
Table 3-17: Frame Synchronization Interface Port Signals

nodebfn_tx_strobe In System Clock Frame strobe in transmit direction. Synchronous to clk.
Node B Frame Number in transmit direction.
nodebfn_tx_nr[11:0] In System Clock
Synchronous to clk.
nodebfn_rx_strobe Out System Clock Frame strobe in receive direction. Synchronous to clk.
Node B Frame Number in receive direction.
nodebfn_rx_nr[11:0] Out System Clock
Synchronous to clk.
In the transmit direction nodebfn_tx_strobe must be asserted for T c and the BFN value
in signal nodebfn_tx_nr must be maintained through the duration of the Node B Frame,
as shown in Figure 3-46. Asserting nobebfn_tx_strobe forces the next basic frame to be
transmitted to be basic frame 0. It is the responsibility of the user logic to assert the
nodebfn_tx_strobe signal every 10 ms as shown.
CLK
IQ?TX?ENABLE
NODEBFN?TX?STROBE
NODEBFN?TX?NR VALIDPREVIOUSFRAME VALIDTHISFRAME
4CNS
5-43&RAMEMS
Figure 3-46: Frame Synchronization Timing - Transmit

59
To better illustrate the frame-level synchronization, Figure 3-47 shows some of the signals
involved in frame transmission and their relative timing.
CLK
IQ?TX?ENABLE
NODEBFN?TX?STROBE
NODEBFN?TX?NR
VENDOR?TX?XS
VENDOR?TX?NS
VENDOR?TX?NSXSINDICATETHENEXTFRAMEFORTRANSMISSION
IQ?TX;= XXXX XXXX ""!! $$## &&%%
SER?TX?K;=
SER?TXD;= "# ""!! $$## &&%%
4HISFRAMEBASICFRAME CONTAINSTHE#/--!
Figure 3-47: Transmit Interface Timing Relationships

Figure 3-47 shows the end of the assertion of the nodebfn_tx_strobe signal and shows
the /COMMA/ or /S/ character in 64b66b encoded line rates character being transmitted at
the beginning of the first basic frame of the Node B frame. It also illustrates that the
vendor_tx_ns and vendor_tx_xs outputs indicate the basic frame to be transmitted
next, not the basic frame being currently transmitted.
The delay through the transmit path in cores supporting up to 3,072.0Mb/s is one clock
cycle, as shown in Figure 3-47. In cores supporting higher line rates, the delay through the
transmit section of the core is increased to two clock cycles. This is to ensure the higher
clock speed requirements in these cores are met.
On the receive side, the frame strobe nodebfn_rx_strobe is generated at the clk rising
edge for T c and the frame number is presented to the user logic at the same time. Because
the CPRI core cannot completely identify the BFN in progress until it is partially through
receiving the frame, the frame number on nodebfn_rx_nr is the number of the previous
frame at the time the frame strobe is asserted. This is illustrated in Figure 3-48 and
Figure 3-49.
IMPORTANT: The frame number is not valid at start-up until an entire hyperframe has been received
by the core.

60
CLK
NODEBFN?RX?STROBE
NODEBFN?RX?NR VALIDPREVIOUSFRAME
4CNS
5-43&RAMEMS
Figure 3-48: Frame Synchronization Timing - Receive

CLK
NODEBFN?RX?STROBE
NODEBFN?RX?NR
VENDOR?RX?NS
VENDOR?RX?XS
VENDOR?RX?NSXSINDICATESFRAMEJUSTCOMPLETED
IQ?RX;= "# ""!! $$## &&%%
#/--!ATSTARTOFBASICFRAME
Figure 3-49: Receive Interface Timing Relationships

Figure 3-49 shows the reception of the beginning of basic frame 0 at the start of a Node B
frame. It shows that nodebfn_rx_strobe is asserted while basic frame 0 is being
received. It also illustrates that the vendor_tx_ns and vendor_rx_xs outputs indicate
the basic frame just completed, not the basic frame is about to begin.
Both of these frame synchronization interfaces are involved in the round trip delay
measurement feature of the core. If the C_R21_TIMER generic is set to TRUE a timer, the R21
coarse timer, is present in the core. See Delay Measurement and Requirement 21 (R21) for
more details on the round trip delay calculation.
In the master the timer is started when the /COMMA/ synchronization character is
transmitted; this occurs when nodebfn_tx_strobe and iq_tx_enable are asserted. At
this time the nodebfn_tx_nr value is stored. The timer is stopped when the master
detects the start of the 10 ms CPRI frame at the receiver, corresponding to the rising edge
of the nodebfn_rx_strobe, and the received nodebfn_rx_nr matches the stored
nodebfn_tx_nr value.

61
Similarly in the slave the timer is started, and the nodebfn_rx_nr stored, when the slave
receives the synchronization byte at the start of the CPRI 10 ms frame. This corresponds to
the rising edge of nodebfn_rx_strobe. The timer is stopped when nodebfn_tx_strobe
and iq_tx_enable are asserted and the nodebfn_tx_nr frame number matches the
stored nodebfn_rx_nr.
Section 4.2.9 of CPRI specification v7.0 [Ref 1] shows how the delay calibration works in a
CPRI system. The CPRI master core in the REC outputs a synchronization /COMMA/
character when nodebfn_tx_strobe and iq_tx_enable are asserted. This starts the
R21 coarse timer in the master. When the slave core in the RE receives the synchronization
character, it asserts nodebfn_rx_strobe. This starts the R21 coarse timer in the slave.
In the RE the nodebfn_rx_strobe is routed back to the nodebfn_tx_strobe input of

the slave. The received frame number is also looped back to the nodebfn_tx_nr input.
However, the current frame number is not output on nodebfn_rx_nr until some way into
the frame. If the frame number is incrementing by one every 10 ms, then logic in the RE
should increment the nodebfn_rx_nr value by one before it is input to nodebfn_tx_nr
on the falling edge of nodebfn_tx_strobe.
When the CPRI slave in the RE sees nodebfn_tx_strobe and iq_tx_enable asserted,
its R21 coarse timer is stopped and a /COMMA/ synchronization character is transmitted.
When the CPRI master in the REC receives the synchronization character, it stops its R21
coarse timer. From the timer values and the known latencies through the system, the delay
across the CPRI link can be measured.
HDLC Interface
The HDLC interface is also known as the Slow C&M Channel in the CPRI specification. When
the CPRI link starts up, the default behavior is for the master and slave to negotiate a rate
for the HDLC channel based on the highest common rate available to both ends of the link.
The preferred rate for the CPRI core can be set through the management interface before
link start-up. If the preferred rate is changed after the core is in operational mode, then
negotiation restarts based on that new rate.
The ports of the HDLC interface are described in Table 3-18.
Table 3-18: HDLC Interface Port Signals

hdlc_tx_data In System Clock HDLC serial data for transmission. Synchronous to clk.
hdlc_tx_enable Out System Clock HDLC serial data transmit enable. Synchronous to clk.
hdlc_rx_data Out System Clock Received HDLC serial data. Synchronous to clk.
Data valid flag for received HDLC serial data.
hdlc_rx_data_valid Out System Clock
Synchronous to clk.
Figure 3-50 and Figure 3-51 show the HDLC interface timing when the HDLC Adaptation bit
is set to 1 in the General Configuration and Transmit CPRI Alarms Register (0xE)

62
management register. The transmit data port is a serial input synchronous to clk
(Figure 3-50); the receive data port is a serial port also synchronous to clk (Figure 3-51).
The CPRI core generates an enable for the transmit data port and a data valid signal for the
receive data port at regular intervals. This maintains the average HDLC data rate negotiated
at CPRI link start-up.
CLK
HDLC?TX?DATA
HDLC?TX?ENABLE
Figure 3-50: Transmit HDLC Interface Timing with HDLC Adaptation Bit Set to 1
CLK
HDLC?RX?DATA
HDLC?RX?DATA?VALID
Figure 3-51: Receive HDLC Interface Timing with HDLC Adaptation Bit Set to 1
Figure 3-52 and Figure 3-53 illustrate the HDLC interface timing when the HDLC Adaptation
bit is set to zero in the General Configuration and Transmit CPRI Alarms Register (0xE)
register. Here the CPRI core generates an enable that frames a burst of serial HDLC data. The
data burst is the size of the speed related HDLC word. This is 2 bytes when the HDLC
channel is operating at 240 kb/s, 4 bytes at 480 kb/s, 8 bytes at 960 kb/s, 16 bytes at 1,920
kb/s, and 20 bytes at 2,400 kb/s. The bursts are separated by half of a hyperframe at the
lowest HDLC rate and by one quarter of a hyperframe at all other rates. This mode of
operation is not supported in cores using a 32-bit or 64-bit datapath.
CLK
HDLC?TX?DATA
HDLC?TX?ENABLE
Figure 3-52: Transmit HDLC Interface Timing with HDLC Adaptation Bit Set to 0

63
CLK
HDLC?RX?DATA
HDLC?RX?DATA?VALID
Figure 3-53: Receive HDLC Interface Timing with HDLC Adaptation Bit Set to 0
If the current HDLC rate is set to the user-defined rate (111 in the Current HDLC Rate
Register (0x2) management register) then the HDLC rate is negotiated on a higher layer. The
HDLC byte valid vector in the Preferred HDLC Rate Register (0xA) management register can
be used to set an HDLC rate that is not one of the pre-defined values given in Table 3-34. It
should be noted that HDLC rate adaptation is not supported in this mode. In addition this
mode of operation is not supported in devices using the 32-bit or 64-bit datapath.
Each bit in the 10-bit HDLC byte valid vector sets whether a particular byte in each of the
HDLC words (Z.1, Z.65, Z.129 and Z.193) contains valid data. For example, if bit 0 in the
HDLC byte valid vector is set to one, then byte 0 of each HDLC word contains valid data. The
number of bytes in each HDLC word varies with line rate. Only the lowest n bits of the byte
valid vector are valid at a particular speed, where n is the size of the word in bytes at that
speed.
Figure 3-54 and Figure 3-55 illustrate the HDLC interface timing when the line rate is
3,072.0 Mb/s and the current HDLC rate is set to111. Here each HDLC word is 5 bytes wide.
In this example the HDLC byte valid vector is set to 0000010101. The hdlc_tx_enable
and hdlc_rx_data_valid signals are only set High on the first, third and fifth bytes of
the HDLC serial data burst. This gives an HDLC bit rate of 1,440 kb/s.
BITS
CLK
HDLC?TX?DATA
HDLC?TX?ENABLE
Figure 3-54: Transmit HDLC Interface Timing with User Defined HDLC Rate
BITS
CLK
HDLC?RX?DATA
HDLC?RX?DATA?VALID
Figure 3-55: Receive HDLC Interface Timing with User Defined HDLC Rate

64
The CPRI core requires that the HDLC protocol be handled by an external entity, such as the
Xilinx HDLC core or any other controller that complies with the HDLC specification.
Ethernet Interface
The Ethernet interface is known as the Fast C&M Channel in the CPRI specification. When
the CPRI link starts up, the master and slave negotiate a rate for the Ethernet channel, based
on the highest common rate available to both ends of the link. The preferred rate for the
CPRI core can be set by programming the Ethernet pointer through the management
interface before link start-up. If the preferred rate is changed after the core is in operational
mode, then negotiation restarts based on that new rate.
On transmit, the Ethernet interface buffers the incoming data before sending it across the
CPRI link. Similarly on receive, the data from the CPRI link is buffered before being
reassembled and output on the Ethernet interface. The buffers are capable of storing up to
4096 bytes each, providing support for maximum length Ethernet frames.
MII Interface
The MII Ethernet interface on the CPRI core is designed to appear as an MII-compliant
physical-side (PHY) interface; therefore, it can be directly connected to a 100 Mb Ethernet
MAC (such as the Xilinx Ethernet MAC core).
The available Ethernet data rate on the MII interface is dependent on the CPRI link speed.
See Bandwidth Timing on the MII Interface for details on using the Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) half-duplex collision mechanism to provide data
rate control. If the Ethernet MAC does not support half-duplex mode, care must be taken to
avoid exceeding the maximum Ethernet data rate for the selected CPRI line rate. Standard
MII interfacing is used, as shown in Table 3-19 and Figure 3-56 and Figure 3-57.
Figure 3-56 and Figure 3-57 show two frames. The first is transmitted and received without
error. The second is subject to a collision due to the CPRI core transmitting and receiving at
the same time. In this case the Ethernet Transmitter Ignore RX_DV and Ethernet Receiver
Ignore TX_EN control bits are Low. The transmitter asserts the eth_col line to signal the
collision to the client. The receiver asserts the eth_rx_er line and forces a jam pattern
onto the eth_rxd output.
See Bandwidth Timing on the MII Interface for more details. If an error is received during
normal operation, the receiver truncates the frame by deasserting eth_rx_dv. It then
asserts eth_rx_er for one clock cycle after the deassertion of the data valid signal.
Table 3-19: Ethernet Interface Signals, MII Interface

eth_txd[3:0] In Ethernet Clock Ethernet transmit data
eth_tx_en In Ethernet Clock Ethernet transmit enable
eth_tx_er In Ethernet Clock Ethernet transmit error

65
Table 3-19: Ethernet Interface Signals, MII Interface (Cont’d)

eth_rxd[3:0] Out Ethernet Clock Ethernet receive data
eth_rx_dv Out Ethernet Clock Ethernet receive data valid
eth_rx_er Out Ethernet Clock Ethernet receive data error
Signal from the client to the CPRI core indicating
eth_rx_ready In Ethernet Clock that it is ready to receive Ethernet frames. Tie
High if no flow control required.
Signal from the CPRI core indicating that it has at
eth_rx_avail Out Ethernet Clock least one Ethernet frame ready to send to the
client. Leave open if no flow control is required.
rx_fifo_almost_full Out Ethernet Clock CPRI receive Ethernet FIFO is over 62.5% full.
rx_fifo_full Out Ethernet Clock CPRI receive Ethernet FIFO is full.
Ethernet collision detect. Asserted when the TX
FIFO is full or if both the RX and TX interfaces are
eth_col Out Async active and the “Ethernet Transmitter Ignores
RX_DV” bit in the General Configuration and
Transmit CPRI Alarms register is set to zero.
Ethernet carrier sense. Asserted when the TX
interface is active or the Ethernet FIFO is over
62.5% full. In addition this signal is asserted
eth_crs Out Async when the RX interface is active and the “Ethernet
Transmitter Ignores RX_DV” bit in the General
Configuration and Transmit CPRI Alarms register
is set to zero.
ETH?REF?CLK
ETH?TX?EN
ETH?TXD D D DN DN D D DM DM
ETH?TX?ER
ETH?CRS
ETH?COL
Figure 3-56: Transmit MII Ethernet Timing Showing a Collision

66
ETH?REF?CLK
ETH?RX?DV
ETH?RXD D D DN DN D D DM JAM
ETH?RX?ER
Figure 3-57: Receive MII Ethernet Timing Showing an Error due to a Collision
GMII Interface
If the CPRI core supports operation at 4,915.2 Mb/s or over, a GMII interface option is
available. The GMII Ethernet interface on the CPRI core is designed to appear as an
GMII-compliant PHY interface; therefore, it can be directly connected to a 1 Gb or tri-speed
Ethernet MAC (such as the Xilinx Ethernet MAC core).
Standard GMII interfacing is used, as shown in Table 3-20 and Figure 3-58 and Figure 3-59.
Table 3-20: Ethernet Interface Signals, GMII Interface

eth_txd[7:0] In Ethernet Transmit Clock Ethernet transmit data
eth_tx_en In Ethernet Transmit Clock Ethernet transmit enable
eth_tx_er In Ethernet Transmit Clock Ethernet transmit error
eth_rxd[7:0] Out Ethernet Receive Clock Ethernet receive data
eth_rx_dv Out Ethernet Receive Clock Ethernet receive data valid
eth_rx_er Out Ethernet Receive Clock Ethernet receive data error
Signal from the client to the CPRI core
eth_rx_ready In Ethernet Receive Clock indicating that it is ready to receive Ethernet
frames. Tie High if no flow control required.
Signal from the CPRI core indicating that it has
at least one Ethernet frame ready to send to
eth_rx_avail Out Ethernet Receive Clock
the client. Leave open if no flow control is
required.
rx_fifo_almost_full Out Ethernet Receive Clock CPRI receive Ethernet FIFO is over 62.5% full
rx_fifo_full Out Ethernet Receive Clock CPRI receive Ethernet FIFO is full

67
Table 3-20: Ethernet Interface Signals, GMII Interface (Cont’d)

Ethernet collision detect. Asserted when the
TX FIFO is full or if both the RX and TX
interfaces are active and the “Ethernet
eth_col Out Async
Transmitter Ignores RX_DV” bit in the General
Configuration and Transmit CPRI Alarms
register is set to zero.
Ethernet carrier sense. Asserted when the TX
interface is active or the Ethernet FIFO is over
62.5% full. In addition this signal is asserted
eth_crs Out Async when the RX interface is active and the
“Ethernet Transmitter Ignores RX_DV” bit in
the General Configuration and Transmit CPRI
Alarms register is set to zero.
The example design delivered with the core contains a GMII interface to an external
Ethernet MAC. See Using an External GMII Interface. If the core is interfacing to an on-chip
Ethernet MAC, the eth_tx_clk and eth_rx_clk ports can be connected together and
driven from a 125 MHz reference clock.
The CPRI core asserts the eth_rx_avail output when there is a frame present in the
Ethernet receive FIFO. This can be used to enable the client logic. In addition the client can
assert the eth_rx_ready input to the core when it is ready to accept data. When this
signal is not asserted, the Ethernet frames are stored in the FIFO rather than being output
to the client.
If the GMII mode field in the General Configuration and Transmit CPRI Alarms Register (0xE)
management register is set to 0 then 4-bit wide MII data is transmitted over the GMII
interface synchronous to eth_tx_clk. Bits 4 to 7 of gmii_txd are ignored. MII data is
output on the receive ports synchronous to eth_rx_clk. Bits 4 to 7 of gmii_rxd are set
to 0.
ETH?TX?CLK
ETH?TX?EN
ETH?TXD D D DN DN D D DM DM
ETH?TX?ER
ETH?CRS
ETH?COL
Figure 3-58: Transmit GMII Ethernet Timing Showing a Collision

68
ETH?RX?CLK
ETH?RX?DV
ETH?RXD D D DN DN D D DM JAM
ETH?RX?ER
Figure 3-59: Receive GMII Ethernet Timing Showing an Error due to a Collision
Bandwidth Timing on the MII Interface
The Ethernet interface on the CPRI core is fixed at a data rate of 100 Mb/s in MII mode.
However, the actual available bandwidth on the CPRI link varies from 0.384 Mb/s to
270.336 Mb/s, depending on link line rate and the Ethernet pointer configuration (See
Table 2-2 Current Ethernet Pointer row).
To enforce this bandwidth limit at the MII Ethernet interface, the standard CSMA/CD
half-duplex collision mechanism provides rudimentary flow control. Buffering takes place
within the CPRI core in both directions of the Ethernet link. When the transmit buffer is over
half full, the eth_crs signal is asserted. This can be input to the carrier sense input of the
Ethernet MAC to prevent further transmission. When the buffer falls below half full,
eth_crs is deasserted enabling transmission to continue. When the transmission buffer is
nearing the full state, the collision detect signal eth_col is asserted to provide back
pressure on the Ethernet MAC. The Ethernet MAC can then attempt retransmission of the
packet or, in the case of excessive retransmission attempts, drop the packet. Higher layer
protocols such as TCP/IP can then attempt retransmission later.
Because the Fast C&M channel is actually a full-duplex link, the standard half-duplex
collision mechanism can unnecessarily affect the throughput on the receive side of the core,
corrupting a receive frame or holding off the Ethernet MAC receiver from starting a new
frame. To address this, two management registers in the core are provided to allow the
behavior of the collision mechanism to be slightly modified.
• Setting the Ethernet Transmitter Ignore RX_DV management register to 1 means that
the core does not assert the carrier sense signal eth_crs when a receive frame is
being moved over the Ethernet interface. This allows simultaneous transmission of data
if the Ethernet MAC only looks at CRS for transmit hold-off.
• Similarly, setting the Ethernet Receiver Ignore TX_EN management register to 1 means
that the receive interface does not hold off moving a frame out to the Ethernet MAC
while the MAC is transmitting.
Setting both of these registers to 1 is safe in most circumstances; however, some Ethernet
MACs might not behave properly with these settings. Consult your Ethernet MAC
documentation to determine compatibility.

69
Connecting the CPRI core to an Ethernet MAC on the FPGA
An example of connecting the CPRI core to the Xilinx Tri-mode Ethernet MAC LogiCORE™ IP
in MII mode is shown in Figure 3-60.
Tri_mode Ethernet MAC core CPRI core
mii_txd eth_txd
mii_tx_en eth_tx_en
mii_tx_er eth_tx_er
mii_crs eth_crs
mii_col eth_col
mii_rxd eth_rxd
mii_rx_dv eth_rx_dv
mii_rx_er eth_rx_er
tx_axi_clk
rx_axi_clk
BUFG
Ethernet clock
generation
Figure 3-60: Interfacing the Tri-mode Ethernet MAC to the CPRI Core in MII Mode
The Tri-mode Ethernet MAC core is generated with an internal physical interface and the
half duplex option selected. This enables the eth_crs and eth_col flow control method
described in the previous section to be used.
The FIFO block level of the Tri-mode Ethernet MAC can also be used in place of the core
support layer to provide buffering and frame retransmission at the client interface of the
TEMAC.
Figure 3-61 shows an example of connecting the CPRI core to the Tri-mode Ethernet MAC in
GMII mode.

70
Tri-mode Ethernet MAC core CPRI core
gmii_txd eth_txd
gmii_tx_en eth_tx_en
gmii_tx_er eth_tx_er
gmii_rxd eth_rxd
gmii_rx_dv eth_rx_dv
gmii_rx_er eth_rx_er
tx_axi_clk eth_tx_clk
rx_axi_clk eth_rx_clk
BUFG
Ethernet clock
generation
Figure 3-61: Interfacing the Tri-mode Ethernet MAC to the CPRI Core in GMII Mode
The Tri-mode Ethernet MAC core is generated with an internal physical interface and the full
duplex option selected. The Ethernet MAC speed is set to 1,000 Mb/s.
The CPRI core does not support GMII half duplex mode as the frame extensions used in the
frame bursting at 1,000 Mb/s are not passed across the CPRI link. Therefore the standard
CSMA/CD half-duplex collision mechanism cannot be used to provide flow control. Care
must be taken to avoid exceeding the maximum Ethernet data rate for the selected CPRI
line rate.
The CPRI core can also be connected to an external Ethernet MAC. For more information on
how to connect using GMII see Using an External GMII Interface.
Interface with Ethernet Frame Buffers Bypassed
You can remove the transmit and receive frame buffers from the CPRI core for
implementation in the user logic. This can be useful if specialized frame buffers are
required. When the Bypass Ethernet Buffers option is selected, the core accepts data on
the TX Ethernet interface in the AXI4-Stream format. Data is output in AXI4-Stream format
on the RX Ethernet interface.
Table 3-21 gives the signals on the TX and RX Ethernet interfaces when the core is
generated with the Bypass Ethernet Buffers option selected.

71
Table 3-21: Ethernet Interface Signals with Frame Buffers Bypassed

tx_axis_eth_tdata[7:0] In System Clock Ethernet Transmit data
Ethernet Transmit data valid. Should be asserted
tx_axis_eth_tvalid In System Clock
when a byte of data is available to be transmitted.
Ethernet Transmit data last byte. Asserted when the
tx_axis_eth_tlast In System Clock last byte of a frame is present on the
tx_axis_eth_tdata input.
Ethernet Transmit data error. Asserted to include an
tx_axis_eth_tuser In System Clock
error code on the current byte.
Ethernet Transmit data ready. Asserted by the CPRI
tx_axis_eth_tready Out System Clock core when it has accepted the current byte of data on
the tx_axis_eth_tdata input.
rx_axis_eth_tdata[7:0] Out System Clock Ethernet Receive data
Ethernet Receive data valid. Asserted by the CPRI
rx_axis_eth_tvalid Out System Clock
core when the data on the RX interface is valid.
Ethernet Receive data last. Asserted by the CPRI core
rx_axis_eth_tlast Out System Clock
when the data output is the last byte of a frame.
Ethernet Receive data error. Asserted by the CPRI
rx_axis_eth_tuser Out System Clock
core when the current byte contains an error code.
Figure 3-62 shows the timing on the Ethernet Transmit interface when the core is generated
with the Bypass Ethernet Buffers option selected.
clk
tx_axis_eth_tdata[7:0] d0 d1 d2 d3 dn-1
tx_axis_eth_tvalid
tx_axis_eth_tlast
tx_axis_eth_tuser
tx_axis_eth_tready
Figure 3-62: Transmit Ethernet Timing with Buffers Bypassed

When a frame of Ethernet data is ready to be sent across the CPRI link
tx_axis_eth_tvalid should be asserted and the first byte of data presented on the
tx_axis_eth_tdata input. When the byte is accepted by the CPRI core it asserts
tx_axis_eth_tready. The next byte of data should then be presented at the
tx_axis_eth_tdata input. In 16-bit and 32-bit cores, the tx_axis_eth_tready
output is asserted once every five system clock cycles when the transmitted subchannel is
in the control and management area defined by the Ethernet pointer. In 64-bit cores the
tx_axis_eth_tready signal is asserted once every two clock cycles. When the last byte
of data is present at the TX interface, tx_axis_eth_tlast should be asserted. The first
byte of a new frame can be transmitted in the next cycle if required, otherwise
tx_axis_tvalid should be deasserted. If it is required to send an error code across the
CPRI link, the tx_axis_eth_tuser input should be asserted.

72
Figure 3-63 shows the timing of the Ethernet data on the Receiver interface.
clk
rx_axis_eth_tdata[7:0] d0 d1 d2 dn-2 dn-1
rx_axis_eth_tvalid
rx_axis_eth_tlast
rx_axis_eth_tuser
Figure 3-63: Receive Ethernet Timing with Buffers Bypassed

When the core receives the first byte of an Ethernet frame it is presented on the
rx_axis_eth_tdata port, along with rx_axis_eth_tvalid. In 16-bit and 32-bit cores,
during frame reception a new byte is presented once every five clock cycles when the
received subchannel is within the control and management area defined by the Ethernet
pointer. In 64-bit cores a new byte is presented once every two clock cycles. When the last
byte of a frame is received, it is presented with the rx_axis_eth_tlast output asserted.
If an error is received the core drives the rx_axis_eth_tuser output High.
ORI Module
The ORI module provides an interface between ORI specific control ports and the
vendor-specific interface. The ORI specific information is carried in the control words of
subchannels 50, 51, and 52 of the CPRI frame.
Table 3-22: ORI Subchannel Allocation

Subchannel Index (Ns) Allocation
52 PORT ID
50 and 51 Received Total Wideband Power (RTWP) measurement report
In the transmit direction the ORI module takes data from ports holding the PORT ID and
RTWP information and maps it into subchannels 50 to 52 of the CPRI frame using the
vendor-specific interface. In the receive direction the data received in subchannels 50 to 52
is extracted and output on the PORT ID and RTWP ports. The ports of the ORI module are
described in Table 3-23 and Table 3-24. All signals are synchronous to clk.
Table 3-23: ORI Module Signals - Core Interface

Transmit enable indicating the start of a new basic
iq_tx_enable In System Clock
frame.
nodebfn_tx_strobe In System Clock UMTS Node B frame strobe in transmit direction
basic_frame_first_word In System Clock Indicates the start of a new basic frame
nodebfn_rx_strobe In System Clock UMTS Node B frame strobe in receive direction
vendor_tx_data Out System Clock Vendor-specific data for transmit direction.
vendor_tx_ns In System Clock Subchannel Index

73
Table 3-23: ORI Module Signals - Core Interface (Cont’d)

vendor_tx_xs In System Clock Control Word Index
vendor_rx_data In System Clock Vendor-specific data for receive direction.
vendor_rx_ns In System Clock Subchannel Index
vendor_rx_xs In System Clock Control Word Index
Table 3-24: ORI Module Signals - ORI Specific Interface

tx_mac_address[47:0] In System Clock Ethernet MAC address of the ORI node
tx _port_number[7:0] In System Clock Port number of the ORI node
Received Ethernet MAC address from the link
rx_mac_address[47:0] Out System Clock
partner
rx_port_number[7:0] Out System Clock Received port number from the link partner
Slave cores only. Up to 20 (3 Gb/s cores), 40 (6 Gb/s
tx_rtwp_group_n[15:0]
In System Clock cores) or 64 (10 Gb/s cores) AxC RTWP groups for
(n = 1 to 20,40 or 64)
transmission from RE
Master cores only. Up to 20 (3 Gb/s cores), 40 (6 Gb/s
rx_rtwp_group_n[15:0]
Out System Clock cores) or 64 (10 Gb/s cores) AxC RTWP groups
(n = 1 to 20,40 or 64)
received from RE
Signal indicating that ORI data is being sent during
ori_tx_en Out System Clock
the current basic frame
Signal indicating that the data on the ORI receiver
ori_rx_valid_strobe Out System Clock
output is valid
The ORI interface transmitter routes the values on the tx_mac_address and
tx_port_number ports to the vendor_tx_data port when the core is transmitting
subchannel 52. This is shown in Figure 3-64. Similarly the RTWP information on the
tx_rtwp_group_n ports is routed through during the transmission of subchannels 50 and
51. The information is mapped to vendor_tx_data for transmission.
CLK
IQ?TX?ENABLE
VENDOR?TX?XS
VENDOR?TX?NS
TX?PORT?NUMBER
TX?MAC?ADDRESS
Figure 3-64: ORI Transmit Timing

The ORI interface receiver samples vendor_rx_data during subchannels 50 to 52 and
outputs the recovered values on the rx_mac_address and rx_port_number ports as

74
shown in Figure 3-65. Similarly the RTWP information is extracted from the incoming data
and output on the rx_rtwp_group_n ports.
CLK
VENDOR?RX?XS
VENDOR?RX?NS
RX?PORT?NUMBER
RX?MAC?ADDRESS
ORI?RX?VALID?STROBE
Figure 3-65: ORI Receive Timing

A nodebfn_rx_strobe from the CPRI core is required before the RTWP information is
output. The RTWP information is only updated in hyperframes 0, 30, 60, 90 and 120. The
strobe is required to collect the data from the correct hyperframe.
Serial Interface
Table 3-25 shows the serial interface of the CPRI core.
Table 3-25: Serial Interface Signals

txp Out TX Serial Clock Positive differential serial output from the transceiver
txn Out TX Serial Clock Negative differential serial output from the transceiver
rxp In RX Serial Clock Positive differential serial input to the transceiver
rxn In RX Serial Clock Negative differential serial input to the transceiver
txinhibit Out Async Transmit inhibit
Loss of Light input. Indicates to the core a lack of illumination
lossoflight In Recovered Clock
of optical receiver. Tie to 0 if not used.
The lossoflight signal is intended to be driven by the Loss Of Light output of an

attached optical module; it signals that the optical receiver is not receiving illumination
from the peer. If an optical module is not in use, this signal should be tied to 0.
The txinhibit signal is wired to the tx_inhibit input of the transceiver but should also
be connected to inhibit the optical transmitter in a connected module. If an optical module
is not in use, this signal can be left as is.

75
Transceiver Interface
Table 3-26 shows the core transceiver interface when the core is generated without the core
support layer.
Table 3-26: Transceiver Interface Signals (Core Generated without Core Support Layer)
Port Direction Clock Description

Domain
Quad PLL Clock Ports
Output clock from the quad PLL QPLLOUTCLK port
qpllclk_in In N/A
(Kintex®-7, Virtex®-7, Zynq®-7000 only)
Output clock from the quad PLL QPLLOUTREFCLK port
qpllrefclk_in In N/A
(Kintex-7, Virtex-7, Zynq-7000 only)
Cores supporting 9,830.4, 10,137.6 or 12,165.12 Mb/s
qplllock_in In N/A only. Lock indication from the quad PLL. (Kintex-7,
Virtex-7, Zynq-7000 only)
Cores supporting 9,830.4, 10,137.6 or 12,165.12 Mb/s
Management
qpll_pd Out only. Asserted to power down the QPLL when it is not
Clock
in use. (Kintex-7, Virtex-7, Zynq-7000 only)
Output clock from the quad PLL QPLL0OUTCLK port
qpll0clk_in In N/A
(UltraScale™ architecture-based devices only)
Output clock from the quad PLL QPLL0OUTREFCLK
qpll0refclk_in In N/A
port (UltraScale architecture-based devices only)
UltraScale architecture-based cores supporting
qpll0lock_in In N/A 9,830.4, 10,137.6, 12,165.12, or 24,330.24 Mb/s only.
Lock indication from QPLL0.
Management
qpll0_pd Out 9,830.4, 10,137.6, 12,165.12, or 24,330.24 Mb/s only.
Clock
Asserted to power down QPLL0 when it is not in use.
Output from the quad PLL QPLL1OUTCLK port
qpll1clk_in In N/A
(UltraScale architecture-based devices only)
Output from the quad PLL QPLL1OUTREFCLK port
qpll1refclk_in In N/A
UltraScale architecture-based devices supporting
qpll1lock_in In N/A 9,830.4, 10,137.6, 12,165.12, or 24,330.24 Mb/s only.
Lock indication from QPLL1.
Management 9,830.4, 10,137.6, 12,165.12, or 24,330.24 Mb/s only.
qpll1_pd Out
Clock
Asserted to power down QPLL1 when not in use.
Output clock from the quad PLL PLL0OUTCLK port
pll0clk_in In N/A
(Artix®-7 only)
Output clock from the quad PLL PLL0OUTREFCLK
pll0refclk_in In N/A
port (Artix-7 only)
Lock indicator from the quad PLL PLL0LOCK_OUT
pll0lock_in In N/A
port (Artix-7 only)

76
Table 3-26: Transceiver Interface Signals (Core Generated without Core Support Layer) (Cont’d)

Domain
Output clock from the quad PLL PLL1OUTCLK port
pll1clk_in In N/A
(Artix-7 only)
Output clock from the quad PLL PLL1OUTREFCLK
pll1refclk_in In N/A
port (Artix-7 only)
Lock indicator from the quad PLL PLL1LOCK_OUT
pll1lock_in In N/A
port (Artix-7 only)
Alignment Interface
phase_alignment_
In Async Asserted High when phase alignment has completed
done_in
txdlysreset_in In Async TX Delay Alignment Soft Reset
Asserted High to indicate that the TX delay alignment
txdlysresetdone_out Out Async
soft reset has completed
txphinit_in In Async TX Phase Alignment initialization
Asserted High to indicate that TX phase alignment
txphinitdone_out Out Async
initialization has completed
txphalign_in In Async Asserted High to set TX phase alignment
The second rising edge of the txphaligndone
txphaligndone_out Out Async signal after txdlysresetdone assertion indicates
that TX phase and delay alignment has completed
txdlyen_in In Async Enables the TX delay alignment in manual mode
When the core is generated with the core support layer option enabled, an illustration of
how to connect the quad PLL and alignment interface signals for a single CPRI link is
present in the <component_name>_support.vhd file. When the core is generated
without the support layer this functionality is implemented in the example design.
Table 3-27 shows the core transceiver interface when the core is generated with the core
support layer option enabled. In this case, the output clocks from the GT common block are
supplied to enable connection to three CPRI cores located in the same quad. The alignment
interface signals are also extended to support sharing with up to three additional CPRI
cores. The additional CPRI cores should be generated without the core support layer.
If the sharing of the GT common block is not required, the Quad PLL ports can be left open.
If alignment block sharing is not required then the alignment interface ports should be
looped back so that txdlysreset_out drives txdlysresetdone_in, txphinit_out
drives txphinitdone_in and txphalign_out drives txphaligndone_in. The
phase_alignment_done_out and txdlyen_out ports can be left open. See Resource
Sharing for more information.

77
Table 3-27: Transceiver Interface Signals (Core Generated with Core Support Layer)
Clock
Port Direction Domain Description
Quad PLL Clock Ports(1)

Clock output from the GT common block in the core
qpllclk_out Out N/A
support layer (Kintex-7, Virtex-7, Zynq-7000 only).
Reference clock output from the GT common block in
qpllrefclk_out Out N/A the core support layer (Kintex-7, Virtex-7, Zynq-7000
only).
Cores supporting 9,830.4, 10,137.6, or 12,165.12 Mb/s
only. Lock output from the GT common block in the
qplllock_out Out N/A core support layer. (Kintex-7, Virtex-7, Zynq-7000
only).
QPLL0 clock output from the GT common block in the
qpll0clk_out Out N/A core support layer (UltraScale architecture-based
devices only).
QPLL0 reference clock output from the GT common
qpll0refclk_out Out N/A block in the core support layer (UltraScale
architecture-based devices only).
9,830.4, 10,137.6, 12,165.12, or 24,330.24 Mb/s only.
qpll0lock_out Out N/A
QPLL0 lock output from the GT common block in the
core support layer
QPLL1 clock output from the GT common block in the
qpll1clk_out Out N/A core support layer (UltraScale architecture-based
devices only)
QPLL1 reference clock output from the GT common
qpll1refclk_out Out N/A block in the core support layer (UltraScale
architecture-based devices only).
9,830.4, 10,137.6, 12,165.12, or 24,330.24 Mb/s only.
qpll1lock_out Out N/A
QPLL1 lock output from the GT common block in the
core support layer.
Clock output from PLL0 of the GT common block in
pll0clk_out Out N/A
the core support layer (Artix-7 only).
Reference clock output from PLL0 of the GT common
pll0refclk_out Out N/A
block in the core support layer (Artix-7 only).
Clock output from PLL1 of the GT common block in
pll1clk_out Out N/A
the core support layer (Artix-7 only).
Reference clock output from PLL1 of the GT common
pll1refclk_out Out N/A
block in the core support layer (Artix-7 only).

78
Table 3-27: Transceiver Interface Signals (Core Generated with Core Support Layer) (Cont’d)

Domain
Alignment Interface(2)
Asserted High when the alignment block in the core
phase_alignment_done_out Out Async
support layer has completed TX phase alignment.
Signal from the alignment block resetting the TX delay
txdlysreset_out[2:0] Out Async
alignment in the additional CPRI cores.
The CPRI cores sharing the alignment block assert this
txdlysresetdone_in[2:0] In Async
signal when soft reset has been completed.
Signal from the alignment block initializing TX phase
txphinit_out[2:0] Out Async
txphinitdone_in[2:0] In Async signal when phase alignment initialization has been
completed.
Signal from the alignment block to set TX phase
txphalign_out[2:0] Out Async
txphaligndone_in[2:0] In Async
signal when TX phase alignment has been completed.
txdlyen_out[2:0] Out Async Enables the TX delay alignment in manual mode.
Notes:
1. These outputs can be shared by CPRI instances without the core support layer.
2. Support provided for up to three additional CPRI instances to share the TX alignment logic in the core support
layer.
For more information on the TX phase alignment process when the TX buffer is bypassed
see the “TX Buffer Bypass” section in the UltraScale Architecture GTY Transceivers User Guide
(UG578) [Ref 5], the UltraScale Architecture GTH Transceivers User Guide (UG576) [Ref 4],
7 Series FPGAs GTX/GTH Transceivers User Guide (UG476) [Ref 2] and the 7 Series FPGAs GTP
Transceivers User Guide (UG482) [Ref 3].
Transceiver Debug Interface

Selecting the Additional Transceiver Control and Status Ports option on the Vivado CPRI
core customization screen enables direct access to selected transceiver control and status
pins. See the UltraScale Architecture GTH Transceivers User Guide (UG576) [Ref 4], UltraScale
Architecture GTY Transceivers User Guide (UG578) [Ref 5], the 7 Series FPGAs GTX/GTH
Transceivers User Guide (UG476) [Ref 2], and the 7 Series FPGAs GTP Transceivers User Guide
(UG482) [Ref 3] for more information on these signals. The transceiver debug pins in
Zynq-7000, Virtex-7, Kintex-7 and Artix-7 cores are described in Table 3-28.
IMPORTANT: The ports in the Transceiver Control And Status Interface must be driven in accordance
with the appropriate GT user guide. Using the input signals listed in Table 3-28 can result in
unpredictable behavior of the IP core.

79
Table 3-28: Transceiver Debug Signals (Zynq-7000 AP SoC, Virtex-7, Kintex-7 and Artix-7)
Port Name(1) Direction Clock Domain Description
gt0_drpdaddr_in[8:0] In Management Clock DRP address
gt0_drpdi_in[15:0] In Management Clock DRP write data
gt0_drpen_in In Management Clock DRP Enable
gt0_drpwe_in In Management Clock DRP write enable
gt0_drpdo_out[15:0] Out Management Clock DRP read data
gt0_drprdy_out Out Management Clock DRP ready
This port is pulsed High to start the TX
gt0_txpmareset_in In Async
PMA reset process.
This port is pulsed High to start the TX
gt0_txpcsreset_in In Async
PCS reset process.
A High on this port indicates that the TX
gt0_txresetdone_out Out Async
reset process has completed.
This port is pulsed High to start the RX
gt0_rxpmareset_in In Async
PMA reset process.
This port is pulsed High to start the RX
gt0_rxpcsreset_in In Async
PCS reset process.
(GTHE2 and GTPE2 transceiver based
cores only.) A High on this port indicates
gt0_rxpmaresetdone_out Out Async
that the RX PMA reset process has
completed.
A High on this port indicates that the RX
gt0_rxresetdone_out Out Async
reset process has completed.
A High on this port indicates that TX
gt0_txphaligndone_out Out Async
phase alignment has completed.
A High on this port indicates that TX
gt0_txphinitdone_out Out Async phase alignment initialization has
completed.
A High on this port indicates that TX delay
gt0_txdlysresetdone_out Out Async
alignment soft reset has completed.
The second rising edge detected on this
port after the assertion of
gt0_rxphaligndone_out Out Async gt0_rxdlysresetdone_out indicates
that RX phase and delay alignment have
completed.
A High on this port indicates that RX
gt0_rxdlysresetdone_out Out Async
delay alignment soft reset has completed.
(GTHE2 and GTPE2 transceiver based
cores only.) Indicates that the RX buffer
gt0_rxsyncdone_out Out Async
bypass alignment procedure has
completed.

80
Active-High signal indicating that the
gt0_cplllock_out Out Async channel PLL has locked to the input
reference clock
Cores supporting 9,830.4, 10,137.6, and
12,165.12 Mb/s only. Active-High signal
gt0_qplllock_out Out Async
indicating that the quad PLL has locked to
the input reference clock.
A High on this port causes an EYESCAN
gt0_eyescantrigger_in In Recovered Clock
trigger event.
This port is pulsed High to initiate the
gt0_eyescanreset_in In Async
EYESCAN reset process.
gt0_eyescandataerror_out Out Async Asserted when an EYESCAN error occurs.
Set High to invert the incoming serial
gt0_rxpolarity_in In Recovered Clock
data.
Set High to invert the outgoing serial
gt0_txpolarity_in In System Clock
data.
(GTXE2 and GTHE2 transceiver based
cores only.) Reset for the low power mode
gt0_rxdfelpmreset_in In Async
(LPM) and decision feedback equalizer
(DFE) datapath.
(GTXE2 and GTHE2 transceiver based
gt0_rxlpmen_in In Async cores only.) Set to 1 to select the LPM
datapath.
(GTPE2 transceiver based cores only.) This
gt0_rxlpmreset_in In Async port is pulsed High to initiate the LPM
reset process.
(GTPE2 transceiver based cores only.)
gt0_rxlpmhfhold_in In Async
High frequency boost control
(GTPE2 transceiver based cores only.)
gt0_rxlpmhfovrden_in In Async
High frequency boost control
(GTPE2 transceiver based cores only.) Low
gt0_rxlpmlfhold_in In Async
frequency boost control
Transmitter pre-cursor pre-emphasis
gt0_txprecursor_in[4:0] In Async
control
Transmitter post-cursor pre-emphasis
gt0_txpostcursor_in[4:0] In Async
control
gt0_txdiffctrl_in[3:0] In Async Driver swing control
Set High to drive errors into the
gt0_txprbsforceerr_in In System Clock pseudo-random binary sequence (PRBS)
transmitter.
Transmitter PRBS generator test pattern
gt0_txprbssel_in[2:0] In System Clock
control

81
Receiver PRBS checker test pattern
gt0_rxprbssel_in[2:0] In Recovered Clock
control
A High on this port indicates that PRBS
gt0_rxprbserr_out Out Recovered Clock
errors have occurred.
gt0_rxprbscntreset_in In Recovered Clock Reset the PRBS error counter
Hold the clock data recovery (CDR)
gt0_rxcdrhold_in In Async
control loop frozen.
Digital Monitor Output Bus. The bus is
15-bits wide in GTHE2 and GTPE2
gt0_dmonitorout_out Out Async
transceiver based cores and 8-bits wide in
GTXE2 transceiver based cores.
Receiver disparity error indicator. The bus
gt0_rxdisperr_out Out Recovered Clock is 2-bits wide in 16-bit datapath cores and
4-bits wide in 32-bit datapath cores.
Receiver not in table error indicator. The
gt0_rxnotintable_out Out Recovered Clock bus is 2-bits wide in 16-bit datapath cores
and 4-bits wide in 32-bit datapath cores.
A High on this port indicates that the
gt0_rxcommadet_out Out Recovered Clock comma alignment block has detected a
valid comma.
(10,137.6 and 12,165.12 Mb/s
gt0_rxheader_out Out Recovered Clock implementations only) Header output
from the transceiver.
(10,137.6 and 12,165.12 Mb/s
gt0_rxheadervalid_out Out Recovered Clock implementations only) Header valid
output from the transceiver.
Notes:
1. If you are migrating from a 7 series to an UltraScale device, the prefixes of the optional transceiver debug ports
are changed from gt0 to gt and the postfix _in and _out are dropped (see Table 3-29).
The transceiver debug pins for cores implemented on UltraScale architecture-based devices
are shown in Table 3-29.
Table 3-29: Transceiver Debug Signals (UltraScale Architecture-Based Devices)

Clock
Port Name Direction Description
Domain
(GTHE3 transceiver based cores) DRP address width is
Management [8:0]
gt_drpdaddr In
Clock (GTHE4, GTYE3 and GTYE4 transceiver-based cores)
DRP address width is [9:0]
Management
gt_drpdi[15:0] In DRP write data
Clock
Management
gt_drpen In DRP Enable
Clock

82
Table 3-29: Transceiver Debug Signals (UltraScale Architecture-Based Devices) (Cont’d)
Port Name Direction Clock Description

Domain
Management
gt_drpwe In DRP write enable
Clock
Management
gt_drpdo[15:0] Out DRP read data
Clock
Management
gt_drprdy Out DRP ready
Clock
This port is pulsed High to start the TX PMA reset
gt_txpmareset In Async
process.
This port is pulsed High to start the TX PCS reset
gt_txpcsreset In Async
process.
A High on this port indicates that the TX reset
gt_txresetdone Out Async
process has completed.
This port is pulsed High to start the RX PMA reset
gt_rxpmareset In Async
process.
This port is pulsed High to start the RX PCS reset
gt_rxpcsreset In Async
process.
A High on this port indicates that the RX PMA reset
gt_rxpmaresetdone Out Async
A High on this port indicates that the RX reset
gt_rxresetdone Out Async
A High on this port indicates that TX phase alignment
gt_txphaligndone Out Async
has completed.
A High on this port indicates that TX phase alignment
gt_txphinitdone Out Async
initialization has completed.
A High on this port indicates that TX delay alignment
gt_txdlysresetdone Out Async
soft reset has completed.
The second rising edge detected on this port after
the assertion of gt_rxdlysresetdone_out
gt_rxphaligndone Out Async
indicates that RX phase and delay alignment have
completed.
A High on this port indicates that RX delay alignment
gt_rxdlysresetdone Out Async
soft reset has completed.
Indicates that the RX buffer bypass alignment
gt_rxsyncdone Out Async
procedure has completed.
Active-High signal indicating that the channel PLL
gt_cplllock Out Async
has locked to the input reference clock.
Cores supporting 9,830.4, 10,137.6, 12,165.12, or
24,330.24 Mb/s with shared logic in the core only.
gt_qplllock Out Async
Active-High signal indicating that the quad PLL has
locked to the input reference clock.
Recovered
gt_rxrate[2:0] In Link signaling rate control
Clock

83

Domain
Recovered
gt_eyescantrigger In A High on this port causes an EYESCAN trigger event.
Clock
This port is pulsed High to initiate the EYESCAN reset
gt_eyescanreset In Async
process.
gt_eyescandataerror Out Async Asserted when an EYESCAN error occurs.
Recovered
gt_rxpolarity In Set High to invert the incoming serial data.
Clock
gt_txpolarity In System Clock Set High to invert the outgoing serial data.
gt_rxdfelpmreset In Async Reset for the LPM and DFE datapath.
gt_rxlpmen In Async Set to 1 to select the LPM datapath.
gt_txprecursor[4:0] In Async Transmitter pre-cursor pre-emphasis control
gt_txpostcursor[4:0] In Async Transmitter post-cursor pre-emphasis control
(GTHE3 transceiver based cores) Driver swing control
width is [3:0].
gt_txdiffctrl In Async
(GTYE3, GTHE4 and GTYE4 transceiver-based cores)
Driver swing control width is [4:0].
System
gt_txprbsforceerr In Set High to drive errors into the PRBS transmitter.
Clock
System
gt_txprbssel[3:0] In Transmitter PRBS generator test pattern control.
Clock
Recovered
gt_rxprbssel[3:0] In Receiver PRBS checker test pattern control
Clock
Recovered A High on this port indicates that PRBS errors have
gt_rxprbserr Out
Clock occurred.
Recovered
gt_rxprbscntreset In Reset the PRBS error counter.
Clock
gt_rxcdrhold In Async Hold the CDR control loop frozen.
gt_dmonitorout[14:0] Out Async Digital Monitor Output Bus.
Receiver disparity error indicator. The bus is 2-bits
Recovered
gt_rxdisperr Out wide in 16-bit datapath cores and 4-bits wide in
Clock
32-bit datapath cores.
Receiver not in table error indicator. The bus is 2-bits
Recovered
gt_rxnotintable Out wide in 16-bit datapath cores and 4-bits wide in
Clock
32-bit datapath cores.
Recovered A High on this port indicates that the comma
gt_rxcommadet Out
Clock alignment block has detected a valid comma.
(10137.6, 12,165.12, and 24,330.24 Mb/s
Recovered
gt_rxheader Out implementations only) Header output from the
Clock
transceiver.

84

Domain
(10137.6, 12,165.12, and 24,330.24 Mb/s
Recovered
gt_rxheadervalid Out implementations only) Header valid output from the
Clock
transceiver.
(GTHE3/GTYE3 transceiver based cores) Set bit 2
gt_pcsrsvdin[15:0] In Async
High to reset the DRP.
Transceiver Data Monitor Interface

The transmit and receive data at the transceiver fabric interface are on this interface. The
signals described in Table 3-30 are used to monitor the transceiver input and output for
debug purposes. These signals are output when the Additional Transceiver Control and
Status Ports option is selected on the Vivado CPRI core customization screen.
Table 3-30: Transceiver Data Monitor Ports

Clock
Domain
In 7 series devices supporting 64B66B encoded line rates this
is the main synchronization clock for all signals into the TX
txusrclk2 Out N/A side of the transceiver. The transmit data and control signals,
txdata, txcharisk, txheader and txsequence are synchronous
to this clock.
Transmit data. 64 bits wide in cores with 64-bit datapath, 32
txdata Out Clock bits wide in cores with 32-bit datapath, 16 bits wide
otherwise.
Transmit control. High when sending an 8B/10B comma
control character. 4 bits wide in cores with a 32-bit datapath,
txcharisk Out Clock
2 bits wide otherwise. Not valid when running at 8,110.08,
10137.6, 12,165.12, or 24,330.24 Mb/s.
Transmit 64B/66B header. Valid only when running at
txheader[1:0] Out Clock
8,110.08, 10137.6, 12,165.12, or 24,330.24 Mb/s.
Transmit 64B/66B sequence. Valid only when running at
txsequence[6:0] Out Clock
8,110.08, 10137.6, 12,165.12, or 24,330.24 Mb/s.
Receive data. 64 bits wide in cores with 64-bit datapath,
Recovered
rxdata Out 32-bits wide in cores with 32-bit datapath, 16-bits wide
Clock
otherwise.
Receive comma. High when an 8B/10B comma control
Recovered character is in the data. 4 bits wide in cores with 32-bit
rxchariscomma Out
Clock datapath, 2 bits wide otherwise. Not valid when running at
8,110.08, 10137.6, 12,165.12, or 24,330.24 Mb/s.
Receive control. High when an 8B/10B control character is in
Recovered the data. 4 bits wide in cores with 32-bit datapath, 2-bits
rxcharisk Out
Clock wide otherwise. Not valid when running at 8,110.08, 10137.6,
12,165.12, or 24,330.24 Mb/s.

85
Table 3-30: Transceiver Data Monitor Ports (Cont’d)

Domain
Receive disparity error. High when an 8B/10B disparity error
Recovered has occurred. 4 bits wide in cores with a 32-bit datapath, 2
rxdisperr Out
Clock bits wide otherwise. Not valid when running at 8,110.08,
10137.6, 12,165.12, or 24,330.24 Mb/s.
Receive not in table error. High when the received data is not
Recovered a valid 8B/10B code word. 4 bits wide in cores with 32-bit
rxnotintable Out
Clock datapath, 2 bits wide otherwise. Not valid when running at
8,110.08, 10137.6, 12,165.12, or 24,330.24 Mb/s.
Recovered Receive 64B/66B header. Valid only when running at 8,110.08,
rxheader[1:0] Out
Clock 10137.6, 12,165.12, or 24,330.24 Mb/s.
Receive 64B/66B data valid. High when 64B/66B data is valid.
Recovered
rxdatavalid Out Valid only when running at 8,110.08, 10137.6, 12,165.12, or
Clock
24,330.24 Mb/s.
Receive 64B/66B header valid. High when the 64B/66B
Recovered
rxheadervalid Out header is valid. Valid only when running at 8,110.08, 10137.6,
Clock
12,165.12, or 24,330.24 Mb/s.
Receive 64B/66B rxgearboxslip. Slips gearbox contents when
High. See the UltraScale Architecture GTY Transceivers User
Guide (UG578) [Ref 5] and the UltraScale Architecture GTH
Recovered Transceivers User Guide (UG576) [Ref 4]. Valid only when
rxgearboxslip Out
Clock running at 8,110.08, 10137.6, 12,165.12, or 24,330.24 Mb/s.
Disabled when running in FEC Enabled mode line rates. The
FEC performs its own alignment.
Management Interface
The management interface is implemented as a generic, processor-friendly,
memory-mapped register block that enables easy connection to either an internal
processor (such as the MicroBlaze™ soft processor) or to an off-chip processor.
The management interface signals are described in Table 3-31, and the timing is illustrated
in Figure 3-66 and Figure 3-67.
Note: The mgmnt_req signal must be deasserted for at least one clock cycle between accesses;
back-to-back transactions are not permitted.

86
Table 3-31: Management Interface Signals

Management Address Bus. See Management
Register Map in Chapter 2 for address
definitions. This port is 8 bits wide when
mgmnt_addr In Management Clock 24,330.24 Mb/s operation is supported,5 bits
wide when 4,915.2, 6,144.0, 9,830.4, 10,137.6 or
12,165.12 Mb/s operation is supported and 4
bits wide otherwise.
mgmnt_req In Management Clock Management Request
Management Read/Not Write
mgmnt_rnw In Management Clock When 1, read from management block
When 0, write to management block
mgmnt_wr_data[31:0] In Management Clock Management Write Data
mgmnt_ack Out Management Clock Management Acknowledge
mgmnt_rd_data[31:0] Out Management Clock Management Read Data
l1_timer_expired In Management Clock L1 Timer Expired flag
AUX?CLK
MGMNT?ADDR
MGMNT?REQ
MGMNT?RNW
MGMNT?WR?DATA
MGMNT?RD?DATA
MGMNT?ACK
Figure 3-66: Management Interface Read Timing

87
AUX?CLK
MGMNT?ADDR
MGMNT?REQ
MGMNT?RNW
MGMNT?WR?DATA;=
MGMNT?RD?DATA;=
MGMNT?ACK
Figure 3-67: Management Interlace Write Timing

The core provides an input port, l1_timer_expired, to allow the connection of a Layer 1
Timer (not supplied with core). According to Clause 4.5.2 of the CPRI specification, this
timer should be started upon entry of the start-up procedure and cleared when the C&M
channel is established (that is, when bit 3 of stat_code is set; see Status and Alarm
Interfaces.)
When the l1_timer_expired input is set to 1, the start-up state machine in the CPRI core
returns to State B, “Attempting L1 Synchronization” (shown as transition 16 in the CPRI
specification) and the stat_code output becomes 0001. The l1_timer_expired input
should then be set to 0 to allow the start-up procedure to restart.
If a level 1 timer is not implemented in the user logic then the l1_timer_expired port
should be tied Low to allow the start-up procedure to complete.
AXI4-Lite Memory Mapped Interface

When the AXI_IPIF generic is set to TRUE, the CPRI core contains a module to convert
between an AXI4-Lite memory mapped interface and the generic memory interface. The
module converts between AXI4-Lite and IP Interface (IPIF) signaling. IPIF is mapped to the
generic memory interface in the core layer. The core functions as an AXI4-Lite slave. The top
level of the AXI interface block is contained in the axi_lite_ipif_wrapper.vhd file.
The AXI4-Lite interface signals are described in Table 3-32, and the timing is illustrated in
Figure 3-68 and Figure 3-69.
Table 3-32: AXI4-Lite Memory Mapped Interface

s_axi_aresetn In Management Clock Global reset source, active-Low
s_axi_awaddr[11:0] In Management Clock Write address

88
Table 3-32: AXI4-Lite Memory Mapped Interface (Cont’d)

Write address valid. This signal indicates that
s_axi_awvalid In Management Clock valid write address and control information are
available.
Write address ready. This signal indicates that the
s_axi_awready Out Management Clock slave is ready to accept an address and associated
control signals.
s_axi_wdata[31:0] In Management Clock Write data.
Write valid. This signal indicates that valid write
s_axi_wvalid In Management Clock
data and strobes are available.
Write ready. This signal indicates that the slave
s_axi_wready Out Management Clock
can accept the write data.
Write response. This signal indicates the status of
the write transaction.
s_axi_bresp[1:0] Out Management Clock
00 - OKAY
10 - SLVERR
Write response valid. This signal indicates that a
s_axi_bvalid Out Management Clock
valid write response is available.
Response ready. This signal indicates that the
s_axi_bready In Management Clock
master can accept the response information.
s_axi_araddr[11:0] In Management Clock Read address
Read address valid. This signal indicates, when
High, that the read address and control
s_axi_arvalid In Management Clock information is valid and remains stable until the
address acknowledgement signal,
s_axi_arready, is High.
Read address ready. This signal indicates that the
s_axi_arready Out Management Clock slave is ready to accept an address and associated
control signals.
s_axi_rdata[31:0] Out Management Clock Read data
Read response. This signal indicates the status of
s_axi_rresp[1:0] Out Management Clock
the read transfer.
Read valid. This signal indicates that the required
s_axi_rvalid Out Management Clock read data is available and the read transfer can
complete.
Read ready. This signal indicates that the master
s_axi_rready In Management Clock can accept the read data and response
information.

89
CLK
S?AXI?ARADDR;=
S?AXI?ARVALID
S?AXI?ARREADY
S?AXI?RDATA;=
S?AXI?RRESP;=
S?AXI?RREADY
S?AXI?RVALID
Figure 3-68: AXI4-Lite Interface Read Timing

CLK
S?AXI?AWADDR;=
S?AXI?AWVALID
S?AXI?AWREADY
S?AXI?WDATA;=
S?AXI?WVALID
S?AXI?WREADY
S?AXI?BRESP;=
S?AXI?BVALID
S?AXI?BREADY
Figure 3-69: AXI4-Lite Interface Write Timing
Status and Alarm Interfaces

The status interface can be connected to LEDs for easy debugging. It can also be connected
to a general purpose Input/Output (I/O) of a management processor or another logic
module, if required. The signals are all synchronous to aux_clk and are described in
Table 3-33.

90
Table 3-33: Status Interface Signals

An alarm has been detected. It is set whenever any
of the following conditions occur:
• If the SDI bit or the Reset bit is set in the
Management Transmit CPRI Alarms register
stat_alarm(1) Out
Clock
• LOF, LOS, SDI, RAI, or Reset bit set in received
Z.130.0
• Local LOF, LOS or RAI bits set
Current state of the core
0000 - Reset
0001 - Attempting L1 synchronization
Management 0010 - Protocol version setup
stat_code[3:0](1) Out 0011 - C&M parameter setup
Clock
1011 - Passive Mode
1110 - Interface and vendor-specific
negotiation
1111 - Operational state; link is up
000 0000 0000 0000 - Core is disabled
000 0000 0000 0001 - 614.4 Mb/s
000 0000 0000 0010 - 1,228.8 Mb/s
000 0000 0000 0100 - 2,457.6 Mb/s
000 0000 0000 1000 - 3,072.0 Mb/s
000 0000 0001 0000 - 4,915.2 Mb/s(3)
000 0000 0010 0000 - 6,144.0 Mb/s(3)
Management 000 0000 0100 0000 - 9,830.4 Mb/s(4)
stat_speed(1)(2) Out
Clock 000 0000 1000 0000 - 10,137.6 Mb/s(5)
000 0001 0000 0000 - 8,110.08 Mb/s(5)
000 0010 0000 0000 - 12,165.12 Mb/s(5)
000 0100 0000 0000 - 24,330.24 Mb/s(6)
000 1000 0000 0000 - 8,110.08 Mb/s with FEC (6)
001 0000 0000 0000 - 10,137.6 Mb/s with FEC (6)
010 0000 0000 0000 - 12,165.12 Mb/s with FEC (6)
100 0000 0000 0000 - 24,330.24 Mb/s with FEC (6)
Master cores only. When set High the core
transmits a 1 in the reset bit of control word
Z.130.0 of the outbound CPRI frame. This is
Management identical to setting the reset bit High in the
reset_request_in In
Clock General Configuration and Transmit CPRI Alarms
Register (0xE) register. When the master core is set
to slave mode (core_is_master is Low) this pin
functions as a reset acknowledge input.
Slave cores only. When set High the core transmits
a 1 in the reset bit of control word Z.130.0 of the
Management
reset_acknowledge_in In outbound CPRI frame. This is identical to setting
Clock
the reset bit High in the General Configuration
and Transmit CPRI Alarms Register (0xE) register.

91
Table 3-33: Status Interface Signals (Cont’d)

When set High the core transmits a 1 in the SDI bit
of control word Z.130.0 of the outbound CPRI
Management
sdi_request_in In frame. This is identical to setting the SDI bit High
Clock
in the General Configuration and Transmit CPRI
Alarms Register (0xE) register.
Management Slave cores only. Holds the received value of the
reset_request_out Out
Clock Reset bit in control word Z.130.0.
Master cores only. Holds the received value of the
Management Reset bit in control word Z.130.0. When the
reset_acknowledge_out Out
Clock master core is set to slave mode (core_is_master is
Low) this pin functions as a reset request output.
Management Holds the received value of the SDI bit in control
sdi_request_out Out
Clock word Z.130.0.
Management
local_los Out Asserted if the core has detected loss of signal.
Clock
Management Asserted if the core has lost frame
local_lof Out
Clock synchronization.
Management
local_rai Out Asserted if the core has detected LOS or LOF.
Clock
Management Asserted if the core is receiving a LOS indication
remote_los Out
Clock from the link partner in control word Z.130.0.
Management Asserted if the core is receiving a LOF indication
remote_lof Out
Management Asserted if the core is receiving a RAI indication
remote_rai Out
FIFO Transit time value. This port mirrors the value
held in the R21 Timers Register (0xF) register. This
Management
fifo_transit_time[13:0] Out can be used to perform the delay measurement
Clock
calculation described in Delay Measurement and
Requirement 21 (R21) in hardware.
Transmit FIFO Transit time value. This port mirrors
the value held in the Transmit FIFO transit time
(0x14) register. This can be used to perform the
Management delay measurement calculation described in Delay
fifo_transit_time_tx[13:0] Out
Clock Measurement and Requirement 21 (R21) in
hardware. Valid only for Zynq-7000, Kintex-7, and
Virtex-7 based cores that support operation at
10,137.6 or 12,165.12 Mb/s.
Transmit gearbox latency. This port mirrors the
value held in the lower 16-bits of the Gearbox
Management
tx_gb_latency_value Out Latency Register (0x16) register. Valid only for
Clock
10,137.6, 12,165.12 or 24,330.24 Mb/s.

92
Table 3-33: Status Interface Signals (Cont’d)

Receive gearbox latency. This port mirrors the
value held in the upper 16-bits of the Gearbox
Management
rx_gb_latency_value Out Latency Register (0x16) register. Valid only for
Clock
10,137.6, 12,165.12 or 24,330.24 Mb/s.
Coarse timer value. This port mirrors the value
held in the R21 Timers Register (0xF) register. This
Management
coarse_timer_value[17:0] Out can be used to perform the delay measurement
Clock
calculation described in Delay Measurement and
Transceiver barrel shift position. This port mirrors
the value held in the Transceiver Barrel Shift
Management Position Register(0x9) register. This can be used to
barrel_shift_value[6:0] Out
Clock perform the delay measurement calculation
described in Delay Measurement and
Notes:
1. When the core is reset these signals do not update until the reset is deasserted.
2. The width of stat_speed differs depending on the supported operating speed of the core as follows:
3,072 M and under - 4 bits
24,330 M and under, FEC Enabled mode - 15 bits
3. Not supported on -1 speed grade Artix-7 devices.
4. Not supported in Artix-7 devices, -1 speed grade in Virtex-7 and Kintex-7 devices and on -2/-3 speed grade
Kintex-7 and Zynq-7000 devices in non FFG packages.
5. This option is available on UltraScale architecture-based devices and on Virtex-7, Kintex-7 and Zynq-7000 devices
of speed grade -2 or -3 in FFG packages.
6. This option is available on UltraScale GTYE3 and UltraScale+ GTYE4 architecture-based devices of speed grade -2
or -3.
Static Configuration Interface

The static configuration interface is made up of a small number of ports that must be
statically wired to indicate to the core how the transceiver that it is connected to is
configured and where it is sited. The core uses this information to determine which DRP
registers need to be manipulated in the transceiver and clock management primitives.
These ports are described in Table 3-34.

93
Table 3-34: Static Configuration Interface Port Description

(Zynq-7000, Virtex-7, Kintex-7 and Artix-7 devices only)
When generating the core clock a PLLE2 can be used as a
replacement for the MMCME2. See Using the PLL to Generate the
Management
use_pll In Core Clock for details of the additional wrapper changes that
Clock
must be applied.
0 - core uses a MMCME2
1 - core uses a PLLE2
(Artix-7 devices only)
Provides support on programming either PLL0 or PLL1 in the
GTPE2_COMMON block.
Management 00 - Reserved
pll_select In
Clock 01 - Core uses PLL0
10 - Core uses PLL1
11 - Core uses PLL0 on the transmit path and PLL1 on the receive
path. See Free Running Receiver Reference Clock (Artix-7 Only).
Specifies which QPLL to use on cores supporting 9,830.4,
Management
qpll_select In 10,137.6, 12,165.12, or 24,330.24 Mb/s.
Clock
0 - QPLL0 is used
1 - QPLL1 is used
These signals should not be dynamically driven but be wired to the appropriate constant
values before implementation.
In most CPRI configurations a speed change does not affect the frequency of the voltage
controlled oscillator in the MMCM. It is therefore possible for the other CLKOUT outputs to
be used by other logic in the FPGA. However, due to the MMCM reset being asserted during
a speed change, the logic must be able to cope with the removal of its clocks during a
speed change.
The following exceptions cause a change in voltage controlled oscillator (VCO) frequency:
• In a CPRI core generated with the 4.915G and under and 307.20 MHz options
selected in the Speed and Reference Clock Selection panel of the Vivado core
customization screen, moving to and from the 3.072 Gb/s line rate.
• A switch between 64B66B and 8B10B encoded line rates.

94
Dynamic Configuration Interface

When the CPRI IP core has been generated as a master, the core_is_master port enables
the core to switch between master and slave modes. A reset is necessary before a change in
mode takes effect.
Table 3-35: Dynamic Configuration Interface Signals

(Master cores only)
Management Defines the mode in which the core is operating.
core_is_master In
Clock 0 - core operates as a slave;
1 - core operates as a master.

95
Chapter 4
Design Considerations
This chapter describes considerations that can apply in common design cases. The figures
in this chapter show the default reference clock frequencies that are supported by the core
for the given devices. Contact your System I/O specialist for guidance on alternative
clocking options.
Reference Clock Selection

Table 4-1 shows the reference clock frequencies that are supported by the IP for each family
of Xilinx devices.
Table 4-1: Reference Clock Frequencies for Device Families

Line Rate Support Reference Clock Options (MHz) Default (MHz)
Up to 3,072.0 Mb/s 122.88, 153.60 153.60
4,915.2 Mb/s on -1 speed 122.88, 245.76 (does not support 3,072.0 Mb/s), 153.60,
307.20
grade devices 307.20
Up to 6,144.0 Mb/s 122.88, 153.60, 245.76, 307.20 307.20
7 series: 122.88, 153.60, 245.76, 307.20
Up to 9,830.4 Mb/s (1) 307.20
UltraScale: 245.76, 307.20
Up to 10,137.6 Mb/s 307.20 307.20
7 series GTXE2:
380.16 MHz for 12,165.12 Mb/s;
307.2 MHz for other line rates
7 series GTHE2:
368.64 MHz for 12,165.12 Mb/s and 8110.08 Mb/s;
Up to 12,165.12 Mb/s 307.2 MHz for other line rates 368.64
UltraScale GTHE3 transceivers:
368.64 MHz for 12,165.12 and 8110.08 Mb/s;
307.2 MHz for other line rates
UltraScale GTYE3 and UltraScale+ GTHE4/GTYE4 transceivers:
245.76 MHz, 307.20 MHz, 368.64 MHz
UltraScale GTYE3 transceivers:
245.76 MHz, 368.64 MHz
Up to 24,330.24 Mb/s 245.76
UltraScale+ GTYE4 transceivers:
245.76 MHz
Notes:
1. For cores generated with 9.830G_and_under line rates, the 8,110.08 Mb/s line rate is not included. Use
12.165G_and under instead.

96
Clock Configuration
This section details the CPRI™ core clocking for correct operation at all supported speeds
for each device family.
The clocks are generated from the GT transceivers in the block level of the CPRI core. When
the design is generated without the core support layer, this corresponds to the top level of
the core. When the support layer is included in the core, the client clock and the recovered
clock (the clk_in and recclk_in inputs to the block level) are output from the core on
the clk_out and recclk ports. See CPRI Core Structure for more information on the core
support and block layers of the design.
Virtex-7, Zynq-7000, and Kintex-7 Devices

Supporting Line Rates up to 3,072.0 Mb/s
Figure 4-1 shows the clock configuration for a CPRI core on Zynq®-7000, Virtex®-7, and
Kintex®-7 devices. In master mode, the reference clock is generated from a crystal
oscillator. In slave mode the reference is generated from the recovered clock by an external
jitter-removal PLL.
IBUFDS_GTE2 GTXE2/GTHE2_CHANNEL
refclk
GTREFCLK0
Reference Clock
122.88 MHz, 153.6 MHz
BUFG(Kintex7)
122.88/153.6 MHz txoutclk
TXOUTCLK
BUFG
30.72/61.44/122.88/153.6 MHz clk_in
MMCM TXUSRCLK
BUFR/BUFH
rxoutclk
RXOUTCLK
recclk
To external jitter
30.72/61.44/122.88/153.6 MHz recclk_in
removal PLL RXUSRCLK
(slave cores only)
Clocking Module
cpri_v8_7 encrypted RTL
clk
recovered_clk
Block Layer
Support Layer
Figure 4-1: Core Clock Configuration at 3,072.0 Mb/s (Virtex-7, Kintex-7, and Zynq-7000 Devices)

97
The recovered clock is routed to the CPRI core through a BUFR in Virtex-7 devices and
through a BUFH in Kintex-7 and Zynq-7000 devices. A BUFG is required on the TXOUTCLK
output of the transceiver on Kintex-7 and Zynq-7000 devices only.
In slave cores, rather than routing the recovered clock directly to the external jitter-removal
PLL as shown in Figure 4-1, the recovered clock can be prescaled within the FPGA to a
constant nominal rate of 30.72 MHz for all line rates. The example design supplied with the
core contains an illustrative implementation of this prescaling technique.
Note: For slave cores the external jitter-removal PLL must free-run in the absence of a reference
signal; a PLL that turns off in the absence of a reference causes the transceiver to fail to start up.
Contact your local System I/O specialist for guidance in selecting a PLL for your application.

Figure 4-2 shows the clock configuration for a CPRI core on a Virtex-7, Zynq-7000, or
Kintex-7 device supporting 6,144.0 Mb/s operation. In master mode, the reference clock is
generated from a crystal oscillator. In slave mode the reference is generated from the
recovered clock by an external jitter-removal PLL.
Figure 4-2 shows the clocking for the 16-bit datapath core. In a 32-bit datapath core the
clock frequencies are halved, running from 15.36 MHz at 614 Mb/s line rate to 153.6 MHz at
6,144.0 Mb/s line rate.
IBUFDS_GTE2 GTXE2/GTHE2_CHANNEL
refclk
GTREFCLK0
Reference Clock
122.88 MHz, 153.6,
245.76, 307.2 MHz
BUFG(Kintex7)
122.88/153.6/245.76/307.2 MHz txoutclk
TXOUTCLK
BUFG
30.72/61.44/122.88/153.6/245.76/307.2 MHz clk_in
MMCM TXUSRCLK
BUFR/BUFH
rxoutclk
RXOUTCLK
recclk
To external jitter
30.72/61.44/122.88/153.6/245.76/307.2 MHz recclk_in
(slave cores only)
Clocking Module

clk
recovered_clk
Block Layer
Support Layer
;

98
The recovered clock is routed to the CPRI core through a BUFR in Virtex-7 devices and
through a BUFH in Kintex-7 and Zynq-7000 devices. A BUFG is required on the TXOUTCLK
output of the transceiver on Kintex-7 and Zynq-7000 devices only.

Figure 4-3 shows the clock configuration for a CPRI core on a Virtex-7, Zynq-7000, and
IBUFDS_GTE2 GTXE2/GTHE2_COMMON
refclk GTREFCLK0
Reference Clock qpllclk_out
4915.2 MHz QPLLOUTCLK
122.88,153.6,
245.76,307.2 MHz qpllrefclk_out QPLLOUTREFCLK
GT Common Wrapper
GTXE2/GTHE2_CHANNEL
GTREFCLK0
qpllclk_in
QPLLCLK
qpllrefclk_in
QPLLREFCLK
BUFG(Kintex7)
122.88/153.6/245.76/307.2 MHz txoutclk
TXOUTCLK
BUFG
15.36/30.72/61.44/76.8/122.88/153.6/245.76 MHz clk_in
MMCM TXUSRCLK
BUFR/BUFH
15.36/30.72/61.44/76.8/122.88/153.6/245.76 MHz rxoutclk
RXOUTCLK
recclk
To external jitter recclk_in
(slave cores only)
Clocking Module
clk
recovered_clk
Block Layer
Support Layer
;
At line rates up to and including 6,144.0 Mb/s, the channel PLL, which is clocked from the
GTREFCLK0 input to the transceiver, is used. The quad PLL is used at 9,830.4 Mb/s. The

99
quad PLL is set up to provide a 4,915.2 MHz PLL clock to the transceiver. This is input to the
transceiver through the QPLLCLK input.
The recovered clock is routed to the CPRI core by a BUFR in Virtex-7 devices and by a BUFH
in Kintex-7 and Zynq-7000 devices. A BUFG is required on the TXOUTCLK output of the
transceiver on Kintex-7 and Zynq-7000 devices only.
Contact your local System I/O specialist for guidance in selecting a PLL for your application.)

Figure 4-4 shows the clock configuration for a CPRI core on a Virtex-7, Zynq-7000, and
IBUFDS_GTE2 GTXE2/GTHE2_COMMON
refclk GTREFCLK0
Reference Clock qpllclk_out QPLLOUTCLK
307.2 MHz 4915.2/5068.8 MHz
qpllrefclk_out QPLLOUTREFCLK
GT Common Wrapper
GTXE2/GTHE2_CHANNEL
GTREFCLK0
qpllclk_in
QPLLCLK
qpllrefclk_in
QPLLREFCLK
BUFG
307.2 MHz txoutclk
TXOUTCLK
BUFR/BUFH
clk_316_in
MMCM TXUSRCLK
15.36/30.72/61.44/76.8122.88/153.6/245.76/316.8 MHz
BUFR/BUFH
rxoutclk
RXOUTCLK
recclk
15.36/30.72/61.44/76.8122.88/153.6/245.76/316.8 MHz
(slave cores only)
BUFGMUX
clk_in cpri_v8_7 encrypted RTL
15.36/30.72/61.44/76.8122.88/153.6/245.76/307.2 MHz clk
Clocking Module clk316
recovered_clk
Block Layer
Support Layer

100
The quad PLL is used at 9,830.4 and 10,137.6 Mb/s. At 9,830.4 Mb/s, the quad PLL provides
a 4,915.2 MHz clock to the transceiver. At 10,137.6 Mb/s, the quad PLL provides a 5,068.8
MHz clock to the transceiver. This is input to the transceiver through the QPLLCLK input. At
line rates of 6144.0 Mb/s and lower the CPLL is used.
The transmitter clock for the transceiver channel block is provided through the
clk_316_in port of the IP core. This runs at 316.8 MHz when operating at 10,137.6 Mb/s.
The clock for the IP core logic, provided to the clk_in input of the core, runs at 307.2 MHz.
The difference in clock frequencies allows for correct operation using the 64B/66B encoding
system.
When running at lower rates with the 8B/10B encoding system, clk_316 and clk_in run
at the same rate, from 245.76 MHz when operating at 9,830.4 Mb/s down to 15.36 MHz
when operating at 614.4 Mb/s.

Figure 4-5 shows a suggested clock configuration for a CPRI core on Virtex-7, Zynq-7000 or
Kintex-7 devices supporting line rates up to 12,165.12 Mb/s. Two reference clocks are
provided to the QPLL in the GTHE2_COMMON block.
The 307.2 MHz reference is used when operating at line rates of 10,137.6 Mb/s and below.
12,165.12 Mb/s operation is supported using an additional 368.64 MHz reference clock
(380.16 MHz for GTXE2 devices).
The GTXE2 transceiver does not support operation at 8,110.08 Mb/s. In master mode the
reference clocks are generated from a crystal oscillator. In slave mode an external jitter
removal PLL should be used to generate the reference clocks from the recovered clock.

101
Reference Clock
GTHE2_COMMON
IBUFDS_GTE3
307.2 MHz refclk_307
GTREFCLK0
Reference Clock refclk GTREFCLK1
368.64 MHz
qpllclk_out
QPLLOUTCLK
4915.2/5068.8/6082.56 MHz
qpllrefclk_out QPLLOUTREFCLK
‘1’ for 64B/66B line rates QPLLREFCLKSEL
GT Common Wrapper
GTHE2_CHANNEL
qpllclk_in GTREFCLK0
qpllrefclk_in QPLLCLK
QPLLREFCLK
BUFG txoutclk
MMCM TXOUTCLK
TXUSRCLK
BUFR/BUFH
rxoutclk
RXOUTCLK
recclk
RXUSRCLK
removal PLL 15.36/30.72/61.44/76.8122.88/153.6/245.76/307.2/368.64 MHz
(slave cores only) CE 32/33 for 64B/66B rates
BUFGCE15.36/30.72/61.44/76.8122.88/153.6/245.76/307.2/368.64 MHz cpri_v8_7 encrypted RTL
clk_in clk
15.36/30.72/61.44/76.8122.88/153.6/245.76/253.44/316.8/380.16 MHz
clk_316
BUFR/BUFH clk_316_in
recovered_clk
Clocking Module Block Layer

Support Layer
;
The quad PLL is used at line rates of 8,110.08 Mb/s and above.
• At 8,110.08 Mb/s, the quad PLL provides a 4,055.04 MHz clock to the transceiver.
• At 12,165.12 Mb/s, the quad PLL provides a 6,082.56 MHz clock to the transceiver. This
is input to the transceiver through the QPLLCLK input.
The transmitter user clock for the transceiver is provided to the core through clk_316_in
port of the IP core. When operating at 64B/66B line rates the frequency of the user clock is
33/32 the frequency of the core clock. The differences in clock frequencies allows for
correct operation using the 64B/66B encoding system. The clocking scheme shown in
Figure 4-5 achieves this by deasserting the clock enable of the global buffer supplying the
core clock for one cycle in every 33 clock cycles.
When operating at 8B/10B line rates the frequency of the core clock and clk_316 are the
same. The clock enable input of the global buffer supplying the core clock is set High at
these line rates.

102
PLL as shown in Figure 4-5, the recovered clock can be prescaled within the device to a
Artix-7 Devices
Figure 4-6 shows the clock configuration for a CPRI core on an Artix®-7 device. In master
mode, the reference clock is generated from a crystal oscillator. In slave mode the reference
is generated from the recovered clock by an external jitter-removal PLL.
IBUFDS_GTE2 GTPE2_COMMON
refclk GTREFCLK0
Reference Clock pll0clk_out PLL0OUTCLK

122.88,153.6 MHz
pll0refclk_out PLL0OUTREFCLK
pll1clk_out PLL1OUTCLK
pll1refclk_out
PLL1OUTREFCLK
GT Common Wrapper
GTPE2_CHANNEL
pll0clk_in
PLL0CLK
pll0refclk_in PLL0REFCLK
pll1clk_in
PLL1CLK
BUFH/BUFG
122.88/153.6MHz txoutclk
TXOUTCLK
BUFG
30.72/61.44/122.88/153.6 MHz txusrclk
TXUSRCLK
MMCM 15.36/30.72/61.44/76.8 MHz clk_in
TXUSRCLK2
BUFH
15.36/30.72/61.44/76.8 MHz rxoutclk
RXOUTCLK
recclk
(slave cores only) Clocking Module
clk
recovered_clk
Block Layer
Support Layer
Figure 4-6: Core Clock Configuration at 3,072.0 Mb/s (Artix-7 Devices)

103
The recovered clock is routed to the CPRI core through a BUFH. The BUFG on the TXOUTCLK
output of the transceiver can be replaced by a BUFH in larger Artix-7 devices. See the
7 Series FPGAs Clocking Resources User Guide (UG472) [Ref 6] for details.
The core can use either PLL0 or PLL1 from the GTPE2_COMMON block. The pll_select
input to the core should be set to 01 when using PLL0 and to 10 when using PLL1.
In slave cores, rather than routing the recovered clock directly to the external jitter removal

Figure 4-7 shows the clock configuration for a CPRI core on an Artix-7 device supporting
6,144.0 Mb/s operation. In master mode, the reference clock is generated from a crystal
oscillator. In slave mode the reference is generated from the recovered clock by an external
jitter-removal PLL.
IBUFDS_GTE2 GTPE2_COMMON
refclk GTREFCLK0
122.88,153.6,
245.76,307.2 MHz pll0refclk_out PLL0OUTREFCLK
pll1refclk_out
PLL1OUTREFCLK
GT Common Wrapper
GTPE2_CHANNEL
pll0clk_in
PLL0CLK
pll1clk_in
PLL1CLK
BUFH/BUFG
122.88/153.6 MHz txoutclk
TXOUTCLK
BUFG
30.72/61.44/122.88/153.6/245.76/307.2 MHz txusrclk
TXUSRCLK
MMCM 15.36/30.72/61.44/76.8/122.88/153.6 MHz clk_in
TXUSRCLK2
BUFH
15.36/30.72/61.44/76.8/122.88/153.6 MHz rxoutclk
RXOUTCLK
recclk
clk
recovered_clk
Block Layer
Support Layer
Figure 4-7: Core Clock Configuration at 6,144.0 Mb/s (Artix-7 Devices)

104
The recovered clock is routed to the CPRI core through a BUFH. The BUFG on the TXOUTCLK
output of the transceiver can be replaced by a BUFH in larger Artix-7 devices. See the
7 Series FPGAs Clocking Resources User Guide (UG472) [Ref 6] for details.
The core can use either PLL0 or PLL1 from the GTPE2_COMMON block. The pll_select
input to the core should be set to 01 when using PLL0 and to 10 when using PLL1.
Rather than routing the recovered clock directly to the external jitter removal PLL as shown
in Figure 4-7, the recovered clock can be prescaled within the FPGA to a constant nominal
rate of 30.72 MHz for all line rates. The example design supplied with the core contains an
illustrative implementation of this prescaling technique.
UltraScale Architecture-Based Devices

This section describes the clocking for UltraScale devices. UltraScale+ devices use the same
clocking schemes with GTHE4 and GTYE4 transceivers taking the place of the GTHE3 and
GTYE3 transceivers shown in the figures.
Supporting Line Rates up to 3,072.0 Mb/s and 6,144 Mb/s

Figure 4-8 shows the clock configuration for a core on an UltraScale™ architecture-based
device. In master mode, the reference clock is generated from a crystal oscillator. In slave mode
the reference clock is generated from the recovered clock using an external jitter removal PLL.
GTHE3/GTYE3_CHANNEL
IBUFDS_GTE3
refclk
GTREFCLK0
Reference Clock
3.072Gb/s capable cores:
122.88 MHz, 153.6 MHz BUFG_GT
txoutclk
TXOUTCLK
6.144Gb/s capable cores:
122.88 MHz, 153.6 MHz,
15.36/30.72/61.44/76.8/122.88/153.6 MHz clk_in
245.76 MHz, 307.2 MHz TXUSRCLK
BUFG_GT
rxoutclk
RXOUTCLK
recclk
15.36/30.72/61.44/76.8/122.88/153.6 MHz
(slave cores only)

clk
recovered_clk
Clocking Module
Block Layer
Support Layer
Figure 4-8: Core Clock Configuration at 3,072.0/6,144.0 Mb/s (UltraScale Architecture-Based Devices)

105
PLL as shown in Figure 4-8, the recovered clock can be prescaled within the device to a
constant nominal rate of 30.72 MHz for all line rates.The example design supplied with the

If the CPLL in the UltraScale device supports line rates over 9,830.4 Mb/s then the CPLL will
be used at this line rate. The clocking for 9,830.4 Mb/s capable cores is the same as that
shown in Figure 4-8.
Figure 4-9 shows the clock configuration for a core on an UltraScale architecture-based
device supporting 9,830.4 Mb/s where the CPLL does not support speeds of 9,830.4 Mb/s.
In master mode, the reference clock is generated from a crystal oscillator. In slave mode the
reference clock is generated from the recovered clock using an external jitter removal PLL.
IBUFDS_GTE3 GTHE3/GTYE3_COMMON
refclk GTREFCLK00
Reference Clock 4915.2 MHz qpll0clk_out
QPLL0OUTCLK
245.76,307.2 MHz qpll0refclk_out
QPLL0OUTREFCLK
qpll1clk_out
QPLL1OUTCLK
qpll1refclk_out QPLL1OUTREFCLK
GT Common Wrapper
GTHE3/GTYE3_CHANNEL
GTREFCLK0
qpll0clk_in
QPLL0CLK
qpll0refclk_in
QPLL0REFCLK
qpll1clk_in
QPLL1CLK
qpll1refclk_in
QPLL1REFCLK
BUFG_GT
txoutclk
TXOUTCLK
15.36/30.72/61.44/76.8/122.88/153.6/245.76 MHz clk_in
TXUSRCLK
BUFG_GT
rxoutclk
RXOUTCLK
recclk
To external jitter 15.36/30.72/61.44/76.8/122.88/153.6/245.76 MHz recclk_in
RXUSRCLK
removal PLL
(slave cores only)
clk
recovered_clk
Clocking Module
Block Layer
Support Layer
Figure 4-9: Core Clock Configuration at 9,830.4 Mb/s (UltraScale Architecture-Based Devices)

106
At line rates up to and including 6,144.0 Mb/s, the channel PLL is used. The quad PLL is used
at 9,830.4 Mb/s. The quad PLL is set up to provide a 4,915.2 MHz PLL clock to the
transceiver. The core can use either QPLL0 or QPLL1 from the GTHE3/GTYE3_COMMON
block. The qpll_select input to the core should be tied Low when using QPLL0 and High
when using QPLL1.
Supporting Line Rates up to 10,137.6 Mb/s and 12,165.12 Mb/s

Figure 4-10 shows the clock configuration for a core on an UltraScale architecture-based
device supporting line rates up to 10,137.6 Mb/s and 12,165.12 Mb/s. In master mode, the
reference clock is generated from a crystal oscillator. In slave mode the reference clock is
generated from the recovered clock using an external jitter removal PLL.
IBUFDS_GTE3 GTHE3/GTYE3_COMMON
refclk 4915.2/5068.8/6082.56 MHz GTREFCLK00
qpll0clk_out
QPLL0OUTCLK
Reference Clock qpll0refclk_out
QPLL0OUTREFCLK
245.76, 307.2, 368.64 MHz qpll1clk_out
QPLL1OUTCLK
qpll1refclk_out
QPLL1OUTREFCLK
GT Common Wrapper
GTHE3/GTYE3_CHANNEL
qpll0clk_in GTREFCLK0
QPLL0CLK
qpll0refclk_in
QPLL0REFCLK
qpll1clk_in
qpll1refclk_in
QPLL1CLK
QPLL1REFCLK
BUFG_GT txoutclk
TXOUTCLK
clk_in
15.36/30.72/61.44/76.8122.88/153.6/245.76/307.2/368.64 MHz TXUSRCLK
BUFG_GT rxoutclk
RXOUTCLK
recclk
15.36/30.72/61.44/76.8122.88/153.6/245.76/307.2/368.64 MHz
RXUSRCLK
removal PLL
clk
recovered_clk
Block Layer
Support Layer
Figure 4-10: Core Clock Configuration at 10,137.6/12,165.12 Mb/s (UltraScale Architecture-Based

Devices)

107
If the CPLL does not support line rates of 9,830.4 Mb/s then the quad PLL is used at speeds
of 8,110.04 Mb/s and above. Otherwise the CPLL is used at 9,830.4 Mb/s and the QPLL at
8,110.08, 10,137.6, and 12,165.12 Mb/s.
• At 9,830.4 Mb/s the quad PLL provides a 4,915.2 MHz clock to the transceiver.
The core can use either QPLL0 or QPLL1 from the GTHE3/GTYE3_COMMON block. The
qpll_select input to the core should be tied Low when using QPLL0 and High when
using QPLL1.
Contact your local SystemIO specialist for guidance in selecting a PLL for your application.

UltraScale GTYE3-based Devices (368.64 MHz Reference Clock)
Figure 4-11 shows the clock configuration for a core on an UltraScale device supporting
line rates of 24,330.24 Mb/s, 12,165.12 Mb/s and 8,110.08 Mb/s. GTHE3, 10,137.6 Mb/s and
the 8B/10B line rates are not supported in this core configuration. In master mode the
368.64 MHz reference clock is generated from a crystal oscillator. In slave mode the
reference clock is generated from the recovered clock using an external jitter removal PLL.

108
IBUFDS_GTE3 GTYE3_COMMON
refclk
GTREFCLK00
qpll0clk_out
Reference Clock 4055.04/6082.56/12165.12 MHz
QPLL0OUTCLK
368.64 MHz qpll0refclk_out
QPLL0OUTREFCLK
qpll1clk_out
QPLL1OUTCLK
qpll1refclk_out
QPLL1OUTREFCLK
GT Common Wrapper
GTYE3_CHANNEL
qpll0clk_in
GTREFCLK0
qpll0refclk_in QPLL0CLK
qpll1clk_in QPLL0REFCLK
QPLL1REFCLK
BUFG_GT txoutclk
TXOUTCLK
clk_in
122.88/184.32/368.64 MHz TXUSRCLK
BUFG_GT
rxoutclk
RXOUTCLK
recclk
RXUSRCLK
removal PLL 122.88/184.32/368.64 MHz
clk
recovered_clk
Block Layer
Support Layer
;
Figure 4-11: Core Clock Configuration at 24,330.24 Mb/s (UltraScale Architecture-Based Devices)
• At 24,330.24 Mb/s the quad PLL provides a 12,165.12 MHz clock to the transceiver.
The core can use either QPLL0 or QPLL1 from the GTYE3_COMMON block. The
qpll_select input to the core should be tied Low when using QPLL0 and High when
using QPLL1.

109
UltraScale GTYE3-based and UltraScale+ GTYE4-based Devices (245.76 MHz Reference Clock)
Figure 4-12 shows the clock configuration for a core on an UltraScale or UltraScale+ device
supporting all line rates from 614.4 Mb/s to 24,33024 Mb/s. GTHE3 and GTHE4 transceivers
are not supported. In master mode the 245.76 MHz reference clock is generated from a
crystal oscillator. In slave mode the reference clock is generated from the recovered clock
using an external jitter removal PLL.
IBUFDS_GTE3 GTYE3_COMMON
refclk
GTREFCLK00
qpll0clk_out
Reference Clock 4055.04/5068.8/6082.56/12165.12 MHz QPLL0OUTCLK
245.76 MHz qpll0refclk_out
QPLL0OUTREFCLK
qpll1clk_out
QPLL1OUTCLK
qpll1refclk_out
QPLL1OUTREFCLK
GT Common Wrapper
GTYE3_CHANNEL
GTREFCLK0
qpll0clk_in QPLL0CLK
qpll0refclk_in
qpll1clk_in
QPLL0REFCLK
QPLL1REFCLK
BUFG_GT txoutclk
TXOUTCLK
7.68/15.36/30.72/38.4/61.44/76.8/122.88/153.6/184.32/ clk_in TXUSRCLK2
368.64 MHz
BUFG_GT
15.36/30.72/61.44/76.8/122.88/153.6/122.88/245.76/ txusrclk
TXUSRCLK
recclk BUFG_GT 153.6/184.32/368.64 MHz
rxoutclk
RXOUTCLK
To external jitter 15.36/30.72/61.44/76.8/122.88/153.6/122.88/245.76/ recclk_in RXUSRCLK
removal PLL 153.6/184.32/368.64 MHz RXUSRCLK2
(slave cores only) Clocking Module cpri_v8_7 encrypted RTL
clk
recovered_clk
Block Layer
Support Layer
;
Figure 4-12: Core Clock Configuration at 24,330.24 Mb/s (245.76 MHz Reference Clock)
When the core is operating at 64b66b encoded line rates the quad PLL is used to provide
the clock to the transceiver.
The transceiver is configured with a 64-bit TX and RX interface and a 64-bit internal data
width.
When the core is operating at 8b10b encoded line rates the transceiver is configured with
a 40-bit internal data width. This is to enable the use of the 8b10b encoding and decoding
logic internal to the transceiver. On the transmit path the TX interface is configured in
80-bit mode. This requires the addition of a TXUSRCLK input running at twice the rate of the

110
core clock. On the receive path the RX interface is configured in 40-bit mode, RXUSRCLK
and RXUSRCLK2 running at the same rate.
Free Running Receiver Reference Clock (Artix-7 Only)

In certain circumstances it might be preferable to use a free running reference clock to clock
the receiver PLL in the GTPE2 transceiver of the CPRI slave core. This removes the need for
the external jitter-removal PLL to be free-running in the absence of a reference signal.
When the free_running_rx_reference generic is set to TRUE, both PLL0 and PLL1 in the
GTPE2 transceiver are used. The receive datapath uses PLL1. This PLL is clocked from a crystal
oscillator. The transmit datapath uses PLL0. This is clocked from the recovered clock through
an external jitter removal PLL. This PLL need not be free running in the absence of the reference
clock from the GTPE2. The pll_select input to the core should be tied to 11 in this mode.
Figure 4-13 shows the clocking for a system supporting 6,144.0 Mb/s.
Reference Clock
From clean-up PLL
IBUFDS_GTE2
refclk
GTPE2_COMMON
IBUFDS_GTE2 GTREFCLK0
tx_refclk
GTREFCLK1
From crystal oscillator
pll0refclk_out PLL0OUTREFCLK
pll1refclk_out
PLL1OUTREFCLK
GT Common Wrapper
GTPE2_CHANNEL
pll0clk_in
PLL0CLK
pll1clk_in
PLL1CLK
BUFR/BUFG
txoutclk
TXOUTCLK
BUFG
30.72/61.44/122.88/153.6/245.76/307.2 MHz txusrclk
TXUSRCLK
MMCM 15.36/30.72/61.44/76.8/122.88/153.6 MHz clk_in
TXUSRCLK2
BUFH
15.36/30.72/61.44/76.8/122.88/153.6 MHz rxoutclk
RXOUTCLK
recclk
RXUSRCLK
removal PLL
Clocking Module
clk
recovered_clk
Block Layer
Support Layer
Figure 4-13: Alternative Clocking Scheme for Artix-7 Slave Core

111
Using the PLL to Generate the Core Clock

In Virtex-7, Artix-7, and Kintex-7 devices the use_pll input to the example design can be
tied to High to enable the core to use a PLLE2 in place of a MMCME2 in the core clock path.
This might help with clocking resource utilization in designs containing multiple CPRI cores.
To use the PLLE2 the following changes should be made to the

<component_name>_tx_clk_gen.vhd file located in the
<project_directory>/example_design/gtx_and_clocks directory.
First, the MMCME2 instance mmcm_adv_inst should be replaced with the following
PLLE2_ADV instance:
mmcm_adv_inst: PLLE2_ADV
generic map
(BANDWIDTH => “HIGH”,
COMPENSATION => “ZHOLD”,
CLKOUT0_PHASE => 0.000,
CLKFBOUT_PHASE => 0.000,
CLKOUT0_DUTY_CYCLE => 0.50,
CLKIN1_PERIOD => 8.138,
REF_JITTER1 => 0.010,
-- See table 5-5 for the following parameter settings
DIVCLK_DIVIDE => 1,
CLKFBOUT_MULT => 10,
CLKOUT0_DIVIDE => 8,
CLKOUT5_DIVIDE => 8)
port map
-- Output clocks
(CLKFBOUT => fb,
CLKOUT0 => clkout0_i,
-- Input clock control
CLKFBIN => fb,
CLKIN1 => refclk,
CLKIN2 => '0',
-- Tied to always select the primary input clock
CLKINSEL => '1',
-- Ports for dynamic reconfiguration
DADDR => daddr_i(6 downto 0),
DCLK => dclk,
DEN => den_i,
DI => di_i,
DO => do,
DRDY => drdy,
DWE => dwe_i,

112
-- Other control and status signals

LOCKED => clk_ok_i,
PWRDWN => '0',
RST => reset);
The settings for the DIVCLK_DIVIDE, CLKFBOUT_MULT and CLKOUT_DIVIDE parameters are
detailed in Table 4-2. The CLKIN1_PERIOD should also be changed to the period of the
reference clock. If the MMCME2 is constrained to a specific location in the XDC constraints
file, a suitable PLL location should be substituted.
Table 4-2: PLLE2 Parameter Settings

Reference Clock DIVCLK_DIVIDE CLKFBOUT_MULT CLKOUT_DIVIDE
3,072.0 Mb/s 122.88 MHz 1 10 8
capable cores 153.60 MHz 2 16 8
122.88 MHz 4 40 4(1)
6,144.0 Mb/s 153.60 MHz 4 32 4(1)

capable cores 245.76 MHz 4 20 4(1)
307.20 MHz 4 16 4(1)
122.88 MHz 1 10 5
9,830.4 Mb/s 153.60 MHz 1 8 5

capable cores 245.76 MHz 2 10 5
307.20 MHz 2 8 5
Notes:
1. Set CLKOUT_DIVIDE to 8 for 32-bit datapath cores.
Resource Sharing
When the CPRI core is generated with the core support layer option enabled, some
components of the design are implemented in the top-level support layer. It is possible to
share these components between two or more instances of the CPRI core.
Figure 4-14 shows an example where two CPRI cores are configured to share the
Transmitter clock and transceiver common block. One instance of the CPRI core (cpri_0) is
generated with the core support layer and the other (cpri_1) without. The clocking
resources in the core support layer of cpri_0 are used to clock cpri_1.

113
Transceiver I/F GT_CHANNEL

Serial IO
RXOUTCLK
TXOUTCLK
Optional DRP
ORI I/F Vendor Specific I/F
cpri_0_v7_gtwizard_gt
Speed IQ I/F
Change
RX Sync
State Optional
Machine AXI I/F Management I/F
cpri_0_v7_gtwizard
DRP BUFG
MMCM
HDLC I/F Speed Change
BUFG/BUFH/BUFR State Machine
Control & Status
cpri_0_gt_and_clocks
clk
recovered_clk
cpri_v8_7
<component_name>_clocking recclk_in
clk_in
txoutclk
rxoutclk
TX Sync Alignment I/F

<component_name>_tx_alignment
Reset Generation
GT_COMMON
Quad PLL Ports
cpri_0
cpri_0_support
Quad PLL Ports Alignment I/F
GT_CHANNEL
Serial IO
Transceiver I/F RXOUTCLK
TXOUTCLK
Optional DRP
Vendor Specific I/F
ORI I/F
IQ I/F
RX Sync
Optional
cpri_1_v7_gtwizard
Speed Change
HDLC I/F State Machine
Control & Status cpri_1_gt_and_clocks

clk
recovered_clk
cpri_v8_7
clk_in
txoutclk
BUFG/BUFH/BUFR
recclk_in
rxoutclk
cpri_1 ;
Figure 4-14: Transmitter Clocking and Common Block Sharing Across Two CPRI Cores

114
Transmitter Clock Sharing

Under certain circumstances it is possible to share the transmit clock logic between several
CPRI cores. To share the transmitter clocking the CPRI cores must all operate at the same
speed. Attention must also be given to the multi-lane manual mode phase alignment
process described in the TX Bypass Buffer section of 7 Series FPGAs GTX/GTH Transceivers
User Guide (UG476) [Ref 2] and 7 Series FPGAs GTP Transceivers User Guide (UG482) [Ref 3].
The transmit phase alignment process will restart when any of the links go down. This resets
all the links that share the transmitter clock. The CPRI links are therefore not independent
from each other and must be brought up and down together.
One of the cores in the system should be chosen as the master CPRI core for clock sharing
and phase alignment (cpri_0 in Figure 4-14). The txoutclk output from this core is used to
generate the overall system clock. This core also initiates TX phase alignment when a reset
is received or when one of the links goes down.
Transceiver Common Block Sharing

Only one transceiver common block is available per quad in an FPGA. In Virtex-7, Kintex-7,
and Zynq-7000 designs the common block contains the quad PLL that is used to clock the
CPRI core and GTXE2/GTHE2 transceiver at the 9,830.4, 10,137.6, and 12165.12 Mb/s line
rates. This block is also instantiated in cores operating at below these rates to correctly set
the BIAS_CFG parameter. In Artix-7 based designs, the common block contains the PLL that
is used to clock the GTPE2 transceiver at all line rates. In UltraScale architecture-based
designs the common block is only instantiated in cores supporting line rates of
10,137.6 Mb/s and over.
When more than one CPRI core is present in the quad region a single common block is
instantiated in the core support layer of one of the CPRI instances. The outputs from the
common block are routed to the quad PLL clock ports of the core layers as described in
Table 3-26 and Table 3-27.
It might be desirable to retain independent transmitter clocks for CPRI cores instantiated in
the same quad and to share only the transceiver common block between them. In this case
the CPRI cores should be generated without the core support layer. The support blocks
provided in the example design can be used to provide the clocking and reset signals for
each instance of the CPRI core. An example with two CPRI cores is shown in Figure 4-15.
The unused ports of the <component_name>_tx_alignment block should be looped back so

that txphalign_vec drives txphaligndone_vec, txdlysreset_vec drives
txdlysresetdone_vec and txphinit_vec drives txphinitdone_vec.

115
Transceiver I/F
GT_CHANNEL
Serial IO
RXOUTCLK
TXOUTCLK
Optional DRP
Vendor Specific I/F
ORI I/F
Speed
Change IQ I/F RX
State Sync
Machine
Optional
Management I/F
BUFG AXI I/F cpri_0_v7_gtwizard
DRP
MMCM Ethernet I/F DRP I/F
Speed
Change
BUFG/BUFH/BUFR HDLC I/F State
Machine
<component_name>_clocking Control & Status cpri_0_gt_and_clocks

clk
recovered_clk
cpri_v8_7
clk_in
txoutclk
recclk_in
rxoutclk
TX Sync
<component_name>_tx_alignment
Alignment I/F
GT_COMMON
<component_name>_gt_common_wrapper Quad PLL Ports
Reset Generation cpri_0
cpri_0_support
Quad PLL Ports Alignment I/F
Transceiver I/F GT_CHANNEL

Serial IO
RXOUTCLK
TXOUTCLK
Optional DRP
Vendor Specific I/F
ORI I/F
IQ I/F RX
Sync
Optional
Management I/F
AXI I/F
cpri_1_v7_gtwizard

TX Sync Speed
<component_name>_tx_alignment HDLC I/F Change
State Machine
Control & Status cpri_1_gt_and_clocks

Speed clk
Change
State recovered_clk
Machine cpri_v8_7
BUFG
DRP clk_in
MMCM
MMCM
txoutclk
BUFG/BUFH/BUFR
recclk_in
rxoutclk
cpri_1
Figure 4-15: Common Block Sharing Across Two CPRI Cores

116
Core Support Layer

The support layer that is delivered with the core contains blocks that can be used to
implement the shared clock and common block logic.
<component_name>_clocking.vhd
This block contains the MMCM and BUFG for the transmitter clock and a state machine to
reprogram the MMCM divider settings after a speed change. In addition the receiver clock
buffer for the CPRI core is instantiated. The default is to use a BUFG for the receiver clocks.
However the buffer can be changed to a BUFH or a BUFR depending on the device.
Table 4-3 shows the ports of the <component_name>_clocking.vhd file and the ports
on the four CPRI cores to which to connect them.
Table 4-3: Signal Connections for TX Clock Sharing

Port Direction Port on CPRI IP core Description
stable_clk In N/A Management clock
txoutclk from the chosen TXOUTCLK from the transceiver
txoutclk_in In
master CPRI core in the master CPRI core
For Kintex-7, Virtex-7 and
Zynq-7000 device designs
supporting 10,137.6 or
clk_out Out 12,165.12 Mb/s clk_316_in The generated system clock
port of all CPRI cores. For
other designs clk_in port of all
CPRI cores.
For Kintex-7, Virtex-7, and
Zynq-7000 designs The generated system clock for
refclkout Out supporting 10,137.6 or 10,137.6 and 12,165.12 Mb/s
12,165.12 Mb/s the clk_in port designs
of all CPRI cores.
rxoutclk port of respective
rxoutclk_in In RXOUTCLK from the transceiver
CPRI core
recclk_in port of respective
recclk_out Out Recovered clock input
CPRI core
Artix-7, UltraScale and
UltraScale+ device
txusrclk Out txusrclk port of all CPRI cores implementations only. Provides
the high frequency TXUSRCLK
input to the transceiver.
Derived from the lock output of
clk_ok Out clk_ok_in of all CPRI cores the MMCM. Used to signal that
the system clock is stable
mmcm_rst from the chosen Signal requesting a reset of the
mmcm_reset In
master CPRI core MMCM in the clocking block.

117
Table 4-3: Signal Connections for TX Clock Sharing (Cont’d)

In 7 series device-based cores
mmcm_locked input of the the TXUSERRDY input of the
mmcm_locked Out
CPRI cores transceiver is held Low until the
MMCM has locked.
Signal indicating that the reset
txresetdone_out from the
txresetdone_in In process in the transceiver has
chosen master CPRI core
completed.
(GTXE2, GTHE2 and GTPE2
gt_reset_req input of all CPRI implementations only.) Asserted
gt_reset_req Out
cores to reset the transceiver in the GT
channel block.
Asserted by the
phase_alignment_done_out
<component_name>_tx_
phase_alignment_done In output of the chosen master
alignment block when
CPRI core.
alignment has completed.
reset_phalignment input of
Asserted to restart phase
reset_phalignment_out Out the <component_name>_tx_
alignment after a speed change.
alignment block
(GTHE2 and GTPE2
gtreset_sm_done of the implementations only.) Asserted
enable In
chosen master CPRI core by the core when the transceiver
reset process is complete.
Signal indicating the speed at
stat_speed from the chosen
speed_select In which the master link is
master CPRI core
operating.
implementations only.) MMCM
output select. You can use a
Tie to value to select MMCM clock output other than
mmcm_output_select[2:0] In
output CLKOUT0 from the MMCM. This
signal should be set to reflect
the MMCM output clock used to
generate the core system clock.
Tie High if using the PLL in implementations only.)
use_pll In
place of the MMCM pll_select as described in Static
Configuration Interface.
(24,330.24, 12,165.12, and
10,137.6 Mb/s capable
userclk_tx_reset output from
userclk_tx_reset In UltraScale architecture-based
the chosen master CPRI core
cores only). Asserted to reset the
transmitter clock buffer.
(24,330.24, 12,165.12, and
10,137.6 Mb/s capable
userclk_rx_reset output from
userclk_rx_reset In UltraScale architecture-based
the chosen master CPRI core
cores only). Asserted to reset the
receiver clock buffer.

118
<component_name>_tx_alignment.vhd
The <component_name>_tx_alignment block performs the transmit phase and delay
alignment process for each of the CPRI cores in the system. Table 4-4 describes the ports of
the <component_name>_tx_alignment block and shows how to connect them to the four
CPRI cores in the system.
Table 4-4: Signal Connections for TX Alignment Sharing

Port Direction Port on CPRI IP Core Description
stable_clock In N/A Management clock
reset_phalignment
Request from the core to start TX
reset_phalignment In output from the chosen
phase alignment
master CPRI core
phase_alignment_done Asserted High when phase alignment
phase_alignment_done Out
input of all CPRI cores has completed.
txdlysreset input of the
txdlyreset_vec[3:0] Out TX Delay Alignment Soft Reset
respective CPRI core
txdlysresetdone output
Asserted High to Indicate that TX delay
txdlysresetdone_vec[3:0] In of the respective CPRI
alignment soft reset has completed.
core
txphinit input of the
txphinit_vec[3:0] Out TX Phase Alignment initialization
respective CPRI core
Asserted High to Indicate that TX
txphinitdone output of
txphinitdone_vec[3:0] In phase alignment initialization has
the respective CPRI core
completed.
txphalign input of the Asserted High to set TX phase
txphalign_vec[3:0] Out
respective CPRI core alignment.
The second rising edge of the
txphaligndone signal after
txphaligndone output of
txphaligndone_vec[3:0] In txdlysresetdone assertion indicates
the respective CPRI core
that TX phase and delay alignment has
completed.
txdlyen input of Enables the TX delay alignment in
txdlyen_vec[3:0] Out
the respective CPRI core manual mode.

119
<component_name>_gt_common.vhd
This file contains an instantiation of the common block for the transceiver. Each of the
outputs is shared by all the CPRI cores in the quad.
Table 4-5: Signal Connections for Transceiver Common Block Sharing

qpllreset_in In N/A PLL reset
UltraScale Architecture-Based, Virtex-7, Kintex-7, and Zynq-7000 devices
qpllclk_out Out qpllclk_in QPLL output clock
qpllrefclk_out Out qpllrefclk_in QPLL output reference clock
QPLL lock indicator (cores supporting
qplllock_out Out qplllock_in
9,830.4 Mb/s and above only)
Signal from the core used to power
qpllpd_in In qpll_pd
down the QPLL when not in use
Artix-7 devices
pll0outclk_out Out pll0clk_in PLL0 output clock
pll0outrefclk_out Out pll0refclk_in PLL0 output reference clock
pll0lock_out Out pll0lock_in PLL0 lock indicator
pll1outclk_out Out pll1clk_in PLL1 output clock
pll1outrefclk_out Out pll1refclk_in PLL1 output reference clock
pll1lock_out Out pll1lock_in PLL1 lock indicator
<component_name>_resets.vhd
This file contains the reset logic for the transceiver common block.
Table 4-6: Signal Connections for Transceiver Common Block Resets

aux_clk In N/A Management Clock
reset In N/A System Reset
qpllreset_in port of the
qpll_reset Out Reset for the quad PLL
<component_name>_gt_common block

120
Line Speed Configuration and Negotiation

Line speed of the core is controlled through the Management Interface. Both the line speed
capability for the core and the current line speed use a 10-bit encoding scheme. A
description of these bits follows.
• Bit 14: 24,330.24 Mb/s FEC Enabled mode

• Bit 10: 24,330.24 Mb/s
• Bit 9: 12,165.12 Mb/s
• Bit 8: 8,110.08 Mb/s
• Bit 7: 10,137.6 Mb/s
• Bit 6: 9,830.4 Mb/s
• Bit 5: 6,144.0 Mb/s
• Bit 4: 4,915.2 Mb/s
• Bit 3: 3,072.0 Mb/s
• Bit 2: 2,457.6 Mb/s
• Bit 1: 1,228.8 Mb/s
• Bit 0: 614.4 Mb/s
Only one of these bits is set by the core in the current line speed register, indicating the
current operating line rate of the core. However, multiple bits of the speed capability
register can be set by the managing entity, as described in the following sections.
Single Speed Operation

To operate the core at a single line speed, set the appropriate bit in the speed capability
register, clearing the other three bits. For example, to set a static line rate of 1,228.8 Mb/s,
set the speed capability register to 000 0000 0000 0010.
Multi-speed Operation with Rate Negotiation

To permit rate negotiation by the core, set each bit to 1 in the speed capability register for
each permitted speed on the link. For example, to negotiate between 2,457.6 Mb/s and
1,228.8 Mb/s, set the speed capability register to 000 0000 0000 0110. In this case, the core

121
attempts to connect at its highest available rate (2,457.6 Mb/s) for the time designated in
the CPRI specification, and then attempts to connect at 1,228.8 Mb/s. If the core is
unsuccessful at this rate, it attempts 2,457.6 Mb/s again, and so on.
IMPORTANT: If the speed capability register is reprogrammed during operation so that the current line
rate is not set to 1 (indicating the current speed is not a permitted speed), the management block
attempts a speed switch to the new highest available rate. This allows the management processor to
force a switch to a different line rate, possibly in reaction to capability information exchanged on the
C&M channel after bringing the link up.
Disabling the Core

Setting the speed capability register to all 0s disables the core and the transceiver tile. This
permits configuration registers such as the Ethernet pointer or HDLC rate values to be
safely set before re-enabling the core.
RS-FEC Enabled Mode

In UltraScale GTYE3 and GTYE4 designs supporting the 24,330.24 Mb/s line rate, an RS-FEC
option can be selected. FEC operation is only available on 64b/66b speeds, that is, 8,110.08,
10,137.6, 12,165.12 and 24,330.24 Mb/s. If the core speed switches down to an 8b/10b line
rate, RS-FEC mode is automatically disabled. RS-FEC enabled line rates are independent
from non-RS-FEC line rates.The RS-FEC is designed in accordance with CPRI Specification
v7.0, October 9, 2015 [Ref 1] section 6.9.
The RS-FEC is instantiated between the core and the GTYE3/GTYE4 transceiver. When in FEC
Enabled mode the RX gearbox block alignment mechanism is disabled because the RS-FEC
performs its own codeword alignment. RS-FEC status information is available on the
management interface and is described in Management Register Map. The additional
latency added by the RS-FEC is described in Additional Pipeline Delays.
When using FEC Enabled mode the codeword alignment process can take much longer than
the normal block alignment process used when in non FEC mode. This can add up to 1.3 ms
to the time taken to complete L1 synchronization.
Using an External GMII Interface

In designs supporting line rates of 4,915.2 Mb/s and higher, a GMII option is available for
the Ethernet interface. If the design is to interface to an off-chip Ethernet MAC then care
must be taken to meet the timing requirements specified in IEEE 802.3-2008.

122
In the example design that is delivered with the core, the transmit GMII interface is driven
by an Ethernet data generator block. The receive interface is routed to a data monitor. The
gmii_if.vhd that is also delivered implements the external GMII interface shown in
Figure 4-16.
"5&' /$$2
ETH?REF?CLK /"5&
$ '-))?28?#,+
1
$
#02),/')#ORE
/&$
/"5&
ETH?RX?CLK ETH?RXD $ 1 '-))?28$
/&$
/"5&
ETH?RX?DV $ 1 '-))?28?$6
/&$
/"5&
ETH?RX?ER $ 1 '-))?28?%2
)&$ )"5&
ETH?TXD 1 $ )$%,!9 '-))?48$
)&$ )"5&
ETH?TX?EN 1 $ )$%,!9 '-))?48?%.
)&$ )"5&
ETH?TX?ER 1 $ )$%,!9 '-))?48?%2
"5&)/
)"5&'
"5&2
ETH?TX?CLK '-))?48?#,+
Figure 4-16: External GMII Interface

The Ethernet reference clock, eth_ref_clk, runs at 125 MHz in GMII mode. This is
forwarded to the Ethernet MAC along with the received GMII data and control signals. An
Input/Output Block (IOB) Double Data Rate (DDR) output register is used giving the clock
the same clock-to-pad delay as the data and control signals. The forwarded clock is inverted
with respect to eth_ref_clk so that its rising edge occurs in the center of the data
window. This gives the best possible setup and hold times for driving the external interface.
The eth_tx_clk input to the CPRI core is provided by the GMII_TX_CLK clock received
from the Ethernet MAC. This clock is also used to clock the received data and control signals
through IOB input buffers. The data and control signals are delayed with respect to the
clock. The delay is provided by IODELAY elements which should be set to sample a 2 ns
setup, 0 ns hold window at the device pins. The trace tool provides information on the setup
and hold window at the device pins.
An IDELAYCTRL primitive should be instantiated to control the IODELAY elements. A

suitable reference clock must also be supplied to the IDELAYCTRL. See the SelectIO™
Resources user guide for the relevant FPGA family.

123
Delay Measurement and Requirement 21 (R21)

Delay Model
Figure 4-17 shows the delay model used for the CPRI core in a master configuration. As
illustrated, there are contributions to the end-to-end delay from the FPGA logic portion of
the core, the clock domain crossing FIFO in the receive path, the transceiver, and the cable
itself. In cores supporting 10,137.6 Mb/s and above on 7 series devices, a clock domain
crossing FIFO is also present in the transmit path. Cable delay can be inferred from the R21
coarse timer measurement, the FIFO transit time measurement and the transceiver delay,
through the use of the T14 delay value shown in the Figure 4-18. The slave configuration is
similar but the T 14 value becomes Toffset, as shown in Figure 4-18.
TCORETX TFIFOTX TGTTX

(10137.6 Mb/s only)
Transmit
Transmit R1
FIFO
I/Q Data (10137.6 Mb/s only)
R21
CPRI T14
Coarse T14 coarse GT Transceiver
core
Timer
Receive
Receive FIFO
R4
I/Q Data
TCORERX TFIFO TGTRX
Figure 4-17: Delay Model for the CPRI Core - Master Configuration
TGTRX TFIFO TCORERX
R2 Receive Receive
FIFO I/Q Data
R21
Toffset CPRI
GT Transceiver Toffset coarse Coarse
core
Timer
Transmit Transmit
FIFO I/Q Data
R3 (10137.6 Mb/s only)
TGTTX TFIFOTX TCORETX

(10137.6 Mb/s only)
Figure 4-18: Delay Model for the CPRI Core - Slave Configuration

124
The next sections expand upon each of the contributions to the delay model and
demonstrate how to determine the cable delay (CPRI Requirement 21) from the R21 coarse
timer measurement, the FIFO transit time measurement, and the transceiver delay.
Note: For the following transceiver delay sections, there is also a variable component to the delay,
the position of the comma alignment barrel shifter.
This value is continuously monitored by the core and is presented through the management
interface, address 0b1001 and on the barrel_shift_value[6:0] port. The barrel shifter delay
value is in units of UI. The barrel shift value is only used when running at line rates using 8B/10B
encoding. At line rates using 64B/66B encoding (24,330.24, 12,165.12, 10,137.6, and 8,110.08 Mb/s),
the barrel shift value should be ignored.
Delay Through the GTXE2 Transceiver

Delay through the GTXE2 transceiver consists of the barrel shifter variable component and
a fixed component. The makeup of the fixed components is shown in Table 4-7.
Table 4-7: Fixed Contribution to Delay - GTXE2 Transceiver

Block Latency
16-bit datapath cores 113.75 UI
TX
RX
Delay Through the GTHE2 Transceiver

Delay through the GTHE2 transceiver consists of the barrel shifter variable component and
Table 4-8: Fixed Contribution to Delay - GTHE2 Transceiver

Block Latency
TX
16-bit datapath cores 223 UI
RX
32-bit datapath cores 421 UI
Delay Through the GTPE2 Transceiver

Delay through the GTPE2 transceiver consists of the barrel shifter variable component and
Table 4-9: Fixed Contribution to Delay - GTPE2 Transceiver

Block Latency
TX 32-bit datapath (8b/10b) 153.73 UI
RX 16-bit datapath (8b/10b) 223 UI

125
Delay Through the GTHE3 Transceiver

Delay through the GTHE3 transceiver consists of the barrel shifter variable component and
Table 4-10: Fixed Contribution to Delay - GTHE3 Transceiver

Block Latency
16-bit datapath cores (8b/10b) 95 UI
TX 32-bit datapath cores (8b/10b) 175 UI
32-bit datapath cores (64b/66b) 144.5 UI
RX 32-bit datapath cores (8b/10b) 248.5 UI
Delay Through the GTYE3 Transceiver

Delay through the GTYE3 transceiver consists of the barrel shifter variable component and
Table 4-11: Fixed Contribution to Delay - GTYE3 Transceiver

Block Latency (UI)
16-bit datapath cores (8b/10b) 99
TX
16-bit datapath cores (8b/10b) 134.5
RX
In addition to the TX and RX latencies in Table 4-11, you should add an additional 0.5 UI of
latency for each 1 Gb/s increment in line rate beyond 4 Gb/s to the total round trip (TX path
+ RX path) latency.
Example: For the 64-bit data path the TX + RX round trip latency is 577.5 UI. If the intended
line rate of operation is 24.3 Gb/s, add 10 UI (0.5 UI * 20) which gives a final latency of 587.5 UI.
Cores supporting 24,330.24, 12,165.12, 10,137.6, and 8,110.08 Mb/s implemented on

UltraScale-based architectures use the transceiver in asynchronous gearbox mode. In these
devices the delay across the transmit and receive gearboxes is presented through the
management interface, address 0b10110 and on the tx_gb_latency_value and
tx_gb_latency_value ports. This value is given in units of 1/8 of a UI.

126
Delay Across the CDC FIFO

The clock-domain crossing (CDC) receive FIFO in the core includes a circuit to measure the
transit time of data across the FIFO. This returns a value in bits 31 to 18 of the R21 Timers
register in the management interface (see Table 2-2.) This value is a fixed-point
representation of the number of datapath clock cycles it takes for data to cross the FIFO. The
upper seven bits represent the integer value; the lower seven bits represent the fractional
part.
In 16-bit datapath cores, this register value can be converted into UI by taking the value
held in bits 31 to 18 of the R21 timer register as an unsigned integer, multiplying by 20, and
dividing by 128. The multiplication by 20 is due to the FIFO being two 8B/10B code words
wide.
For example, a register holds the binary value 10000000000100 (8196 as an unsigned
integer). Multiply this value by 20 and divide by 128 to get a transit time of 1,280.625 UI.
In 32-bit datapath cores, the FIFO is four 8B/10B code words wide. The register value can be
converted into UI by taking the value held in bits 31 to 18 of the R21 timer register as an
unsigned integer, multiplying by 40, and dividing by 128. In cores supporting 64B/66B line
rates the register value is converted to UI by multiplying the value by 33 and dividing by
128.
In 64-bit datapath cores, the FIFO is eight bytes wide. The register value can be converted
into UI by taking the value in bits 31 to 18 of the R21 timer register, multiplying by 66 and
dividing by 128.
The integer and fractional part of the transit time can also be read from the High Resolution
FIFO Transit Time (Integer part) and High Resolution FIFO Transit Time (Fractional part)
registers in the management interface (see Table 2-2). The register values are converted to
UI by first concatenating the integer and fractional parts. The result is then multiplied by 20,
33, 40 or 66, depending on data width and encoding scheme, and divided by 65536.
In cores supporting 12,165.12 and 10,137.6 Mb/s implemented on Zynq-7000, Kintex-7 and
Virtex-7 devices, a clock-domain crossing FIFO is present in the transmit path. The
operation of this FIFO is identical to the receiver FIFO described in this section. This FIFO is
not present in UltraScale architecture-based designs.
The transit time of data across the FIFO is held in bits 13 to 0 of the Transmit FIFO transit
time register (see Table 2-2).
Overall Delay
The delay through the core from the I/Q interface inputs to the transceiver output and from
the transceiver input to the I/Q interface outputs varies, depending on whether the
UTRA-FDD I/Q Module is used with the core. See Table 4-16 for exact timing calculations.

127
Core I/Q Interface

The transmit delay for the I/Q interface is shown in Figure 4-19. A 16-bit data word is
clocked into the CPRI core on the client-side interface, and below that the first encoded
data bit from that word is sent on the output pin of the GTP transceiver. Ttx is the delay
between those two events.
CLK
IQ?TX;=
TXD
4TX
Figure 4-19: Transmit Delay, Raw I/Q Interface

The overall delay T tx is made up of the contributions listed in Table 4-12. Unless stated
these delays are for a GTXE2 transceiver-based implementation.
For other transceiver-based implementations, the calculation is similar but uses the
transceiver latencies for the relevant device.
Table 4-12: Contributions to Transmit Delay, Core I/Q Interface, GTX Transceiver
Contribution Delay
16-bit datapath cores 32-bit datapath 32-bit datapath
Cores supporting
supporting up to cores supporting cores supporting
up to 3,072.0 Mb/s
4,915.2/6,144.0 Mb/s up to 9,830.4 Mb/s 10,137.6 Mb/s
FPGA logic
20 UI 40 UI 80 UI 164 UI
(TCORETX)
Read back from the
CDC FIFO
CPRI core(1) (see
transit time N/A N/A N/A
Delay Across the
(Ttxfifo)
CDC FIFO)
GTX transceiver
113.75 UI 113.75 UI 221.5 UI 221.5 UI
delay (TGTXTX)
Total (Ttx) 133.75 UI 153.75 UI 301.5 UI 385.5 UI + Ttxfifo
Notes:
1. In UltraScale architecture-based designs running at 8,110.08, 10,137.6, 12,165.12 or 24,330.24 Mb/s, the delay
across the transmit gearbox replaces the delay across the CDC FIFO in the calculation.
The receive delay for the raw I/Q interface is shown in Figure 4-20. The figure shows the
first encoded bit of a 16-bit data word being received by the GTX transceiver, and the
corresponding data word being clocked out of the CPRI core on the raw I/Q receive
interface. Trx is the delay between those events.

128
CLK
RXD
IQ?RX;=
4RX
Figure 4-20: Receive Delay, Raw I/Q Interface

Table 4-13 lists the contributions that comprise the overall delay T rx.
Table 4-13: Contributions to Receive Delay, Core I/Q Interface, GTX Transceiver
Contribution Delay
Cores supporting
up to 3,072.0 Mb/s
4,915.2/6,144.0 Mb/s up to 9,830.4 Mb/s 10,137.6 Mb/s
GTX transceiver
210.5 UI 210.5 UI 408.5 UI 408.5 UI
delay (TGTXRX)
Barrel shift Read back from the CPRI core management interface and convert to
N/A(1)
(Tbarrel) absolute time as described in Delay Through the GTXE2 Transceiver.
CDC FIFO
Read back from the CPRI core management interface and convert to absolute
transit time
time as described in Delay Across the CDC FIFO.
(Tfifo)
FPGA logic
20 UI 80 UI 160 UI 129 UI
(TCORERX)
Total (Trx) 230.5 UI + Tbarrel + Tfifo 290.5 UI + T barrel + Tfifo 568.5 UI + T barrel + Tfifo 537.5 UI + Tfifo
Notes:
across the receive gearbox replaces the delay across the barrel shifter in the calculation.
UTRA-FDD I/Q Module

Because the UTRA-FDD I/Q Module accepts a basic frame of I/Q sample data broadside into
the core when tx_iq_enable is asserted and then serializes it according to the configured
I/Q channel count and data widths, it is very difficult to describe the latency from any given
bit in any given I/Q sample for any given configuration of channels in the core, either in the
transmit or receive direction.
Instead, the latency between the tx_iq_enable signal assertion and the first bit of word
0 of the basic frame is given; from this reference, it is possible to work out the delay of any
given bit in the basic frame thereafter.

129
CLK
IQ?TX?ENABLE
IQ?TX?IQ
TXD
4TX
Figure 4-21: Transmit Delay, UTRA-FDD I/Q Interface

The transmit delay for the multiplexed I/Q data interface is shown in Figure 4-21. The figure
shows the I/Q data basic frame being captured into the core by the iq_tx_enable signal
and the first bit of word 0 of the basic frame being transmitted on the output of the GTX
transceiver. Ttx is the delay between those two events.
The overall delay T tx is made up of the contributions listed in Table 4-14. Unless stated
For other transceiver-based implementations, the calculation is similar but uses the
Table 4-14: Contributions to Transmit Delay, Multiplexed I/Q Interface, GTX Transceiver
Contribution Delay
Cores supporting
up to 3,072.0 Mb/s
4,915.2/6,144.0 Mb/s up to 9,830.4 Mb/s 10,137.6 Mb/s
FPGA logic
40 UI 60 UI 120 UI 197 UI
(TCORETX)
Read back
CDC FIFO
from the CPRI core
transit time N/A N/A N/A
(see Delay Across
(Ttxfifo)
the CDC FIFO)(1)
GTX transceiver
113.75 UI 113.75 UI 221.5 UI 221.5 UI
delay (TGTXTX)
Total (Ttx) 153.75 UI 173.75 UI 341.5 UI 418.5 UI + T txfifo
Notes:
across the transmit gearbox replaces the delay across the CDC FIFO in the calculation.
Similarly, the latency between the reception of the first bit of word 0 in the basic frame to
the assertion of iq_rx_data_valid is given; the latency of any given bit in the received
basic frame is offset from this reference value.

130
CLK
RXD
IQ?RX?IQ
IQ?RX?DATA?VALID
4RX
Figure 4-22: Receive Delay, UTRA-FDD I/Q Interface

The receive delay design using the UTRA-FDD I/Q Module is shown in Figure 4-22. The
figure shows the first encoded bit of word 0 of the basic frame being received at the GTP
transceiver pins and the basic frame data being qualified as valid on the iq_rx_i and
iq_rx_q outputs by the iq_rx_data_valid signal. Trx is the delay between those two
events.
The overall delay T rx is made up of the contributions listed in Table 4-15. Unless stated
For other transceiver -based implementations, the calculation is similar but uses the
Table 4-15: Contributions to Receive Delay, Using UTRA-FDD I/Q Module, GTX Transceiver
Contribution Delay
Cores supporting
up to 3,072.0 Mb/s
4,915.2/6,144.0 Mb/s up to 9,830.4 Mb/s 10,137.6 Mb/s
GTX transceiver
210.5 UI 210.5 UI 408.5 UI 408.5 UI
delay (TGTXTX)
Barrel shift Read back from the CPRI core management interface and convert to
N/A (1)
(Tbarrel) absolute time as described in Delay Through the GTXE2 Transceiver.
CDC FIFO
Read back from the CPRI core management interface and convert to absolute
transit time
time as described in Delay Across the CDC FIFO.
(Tfifo)
FPGA logic
T c + 20 UI T c + 80 UI T c + 160 UI Tc + 129 UI
(TCORERX)
Tc + 230.5 UI + Tc + 290.5 UI + Tc + 568.5 UI +
Total (T rx) Tc + 537.5 UI + Tfifo
Tbarrel+ Tfifo Tbarrel+ Tfifo Tbarrel+ Tfifo
Notes:
across the receive gearbox replaces the delay across the barrel shifter in the calculation.

131
R21 Calculation
To calculate the cable delay for a particular link instance, measure or infer the frame timing
at the output and input of the master (in the case of T 14) and at the input and output of the
slave (in the case of T offset). Use the T14 and T offset times to calculate cable delay, as
described in section 4.2.9 of the CPRI Specification v7.0 [Ref 1].
The general procedure for calculating T 14 or T offset is:
1. Measure the coarse value using the R21 Coarse Timer.

2. Correct the coarse value for delays between the timer and the pins of the transceiver.
For 32-bit datapath cores, one datapath clock cycle equates to 40 UI. For all other cores one
datapath clock cycle equates to 20 UI.
Coarse Delay Measurement

If the C_R21_TIMER generic is set to TRUE, there is a counter in the core to assist in
determining the round trip delay of the link. This is shown as the R21 Coarse Timer in
Figure 4-17. It can be read through the management interface (see Table 3-32). This timer
runs at the same rate as datapath clock and the value is given in units of datapath clock
cycles.
Additional Pipeline Delays

The following register-to-register delays must be accounted for in the cable delay
calculation.
• One datapath clock cycle for the cycle that clocks the transmit data into the transceiver
• In cores supporting line rates above 4,915.2 Mb/s and in all Artix-7 FPGA based cores,
one datapath clock cycle to clock the data through the transmit multiplexer. In cores
supporting 10,137.6 Mb/s and higher an extra datapath clock cycle is added for the
delay through the scrambler.
• One recovered clock cycle (Artix-7 devices) or one datapath clock cycle (UltraScale
architecture-based, Virtex-7, and Kintex-7 devices) for the delay from the output of the
transceiver into the CDC FIFO. In cores supporting line rates above 4,915.2 Mb/s, there
is one extra datapath clock cycle, or recovered clock cycle in Artix-7 devices, to clock
the data out of the transceiver
• One datapath clock cycle for clocking the data out of the CDC FIFO
• In cores supporting line rates above 4,915.2 Mb/s, one datapath clock cycle, or
recovered clock cycle in Artix-7 devices, for clocking the data through the descrambler
• Two datapath clock cycles for delay in the control path of the R21 coarse timer

132
• (Artix-7 devices only.) One recovered clock cycle for delay in converting from 2 bytes to
4 bytes.
• (12,165.12 and 10,137.6 Mb/s capable cores implemented on Zynq-7000, Kintex-7 and
Virtex-7 devices only.) Two datapath clock cycles to clock the data in and out of the
transmit CDC FIFO.
This leads to the additional delays described in the following subsections.
Cores Supporting 3,072.0 Mb/s

• UltraScale architecture-based, Virtex-7 and Kintex-7 devices: The additional delay is
five datapath clock cycles, or 100 UI.
• Artix-7 devices: The additional delay is five datapath clock cycles plus two RECCLK
cycles, or 240 UI.
Cores Supporting 4,915.2/6,144.0 Mb/s

eight datapath clock cycles, 160 UI in 16-bit datapath cores and 320 UI in 32-bit
datapath cores.
• Artix-7 devices: The additional delay is five datapath clock cycles plus three RECCLK
cycles, or 260 UI.

eight datapath clock cycles, or 320 UI.

• Virtex-7 and Kintex-7 devices: When running at 8,110.08, 10,137.6 or 12,165.12 Mb/s,
the additional delay equates to 363 UI. When running at lower speeds, the additional
delay is ten clock cycles, or 400 UI.
• UltraScale architecture-based devices: The additional delay is 9 datapath clock cycles
when operating in 64B/66B mode and 8 datapath clock cycles otherwise. This equates
to 297 UI when the core is operating at 8,110.08, 10,137.6, 12,165.12, or 24,330.25 Mb/s
and 320 UI at other speeds.
Cores Supporting 12,165.12 Mb/s and Above
UltraScale architecture-based devices: The additional delay is 12 datapath clock cycles when
operating at 8,110.08, 10,137.6, 12,165.12, and 24,330.24 Mb/s and 10 datapath clock cycles
otherwise. 12 datapath clock cycles equates to 396 UI when the core is operating with a
32-bit datapath and 792 UI with a 64-bit datapath. 10 datapath clock cycles equates to
400 UI at other speeds.

133
Cores supporting FEC Enabled Mode
UltraScale architecture-based devices: For cores running in FEC Enabled mode (8,110.08,
10,137.6, 12,165.12, and 24,330.24 Mb/s) the additional delay is eight datapath clock cycles.
Eight datapath clock cycles equates to 528 UI with a 64-bit datapath.
The additional delay added by the RS-FEC is 214 datapath clock cycles which equates to
14124 UI with a 64-bit datapath.
Performing the Cable Delay Calculation

When all the components of the delay are known, the value for the cable delay can be
calculated. This involves calculating T14 and Toffset for the master and slave, respectively.
These calculations are described in this section.
Calculating T14 (CPRI Master)

1. Take the total fixed latency through the transceiver in UI (A).
2. Read the barrel shift position through the management interface and add it to the fixed
transceiver latency to get the total transceiver latency in UI (B).
3. Read the clock domain crossing FIFO transit time from the management interface.
Convert to UI as described in Delay Across the CDC FIFO, page 127 (C).
4. Add the total transceiver latency (B), the FIFO transit time (C) and the additional pipeline
delay given in the Additional Pipeline Delays section. This sum gives the total delay
correction (D).
5. Get the R21 Coarse Timer value from the management interface.
For 16-bit datapath cores, multiply by 20 to get a R21 Coarse Time in UI (E). For 32-bit
datapath cores, multiply by 40 and for cores running at 10,137.6 or 12,165.12 Mb/s
multiply by 33. For 64-bit datapath cores multiply by 66.
6. Subtract the delay correction (D) from the coarse time value (E) to get T14 in UI.
7. Multiply this by the value shown in Table 4-16 to get T14 in ps.
Calculating Toffset (CPRI Slave)

1. Take the total fixed latency through the transceiver in UI (A).
2. Read the barrel shift position through the management interface and add it to the fixed
transceiver latency to get the total transceiver latency in UI (B).
3. Read the clock domain crossing FIFO transit time from the management interface.
Convert to UI as described in Delay Across the CDC FIFO, page 127 (C).
4. Add the total transceiver latency (B), the FIFO transit time (C), and the additional
pipeline delay given in the Additional Pipeline Delays section. This sum gives the total
delay correction (D).

134
5. Get the R21 Coarse Timer value from the management interface.
For 16-bit datapath, multiply by 20 to get a R21 Coarse Time in UI (E). For 32-bit
datapath, multiply by 40 and for cores supporting 10,137.6 or 12,165.12 Mb/s multiply
by 33. For 64-bit datapath cores multiply by 66.
6. Add the delay correction (D) to the coarse time value (E) to get Toffset in UI.
7. Multiply this by the value shown in Table 4-16 to get Toffset in ps.
Calculating the Cable Delay
The cable delay for a single direction is given by:
Cable Delay = (T 14 - Toffset)/2
Example R21 Delay Calculation
An example of the delay calculation follows, given that:
• Line Rate = 1,228.8 Mb/s

• UI = 813.8 ps
• Transceiver Latency = 150 UI
• Datapath Latency = 100 UI
• Slave CDC FIFO = 160 UI
• Slave Barrel Shift = 16 UI
• Slave Coarse Timer = 340 UI
• Master CDC FIFO = 1,340 UI
• Master Barrel Shift = 13 UI
• Master Coarse Timer = 15,000 UI
Cable Delay = (15000 - (150 + 13 + 100 + 1340) - (340 + 150 + 16 + 100 + 160)) / 2
Cable Delay = 6,315.5 UI = 5,139.55 ns
Table 4-16: Line Speed To UI Conversion Factors

Line Speed (Mb/s) 1 UI (ps)
614.4 1,627.6
1,228.8 813.8
2,457.6 406.9
3,072.0 325.5
4,915.2 203.45
6,144.0 162.76

135
Table 4-16: Line Speed To UI Conversion Factors (Cont’d)

Line Speed (Mb/s) 1 UI (ps)
8,110.08 123.303
9,830.4 101.725
10,137.6 98.643
12,165.12 82.202
24,330.24 41.101
R21A Calculation
The round trip delay through a multi-hop connection can be calculated in a similar manner
to the single hop case. Figure 4-23 shows a block diagram of a two-hop system consisting
of a Radio Equipment Controller (REC), a network Radio Equipment unit (RE) and a node RE.
MASTERPORT
MASTERPORT
SLAVEPORT
SLAVEPORT
2%# 4 NETWORK 4OFFSET NODE2%
2%
8
Figure 4-23: Two-Hop CPRI System

The round trip delay between the REC and the node RE is obtained by first measuring T 14(1)
at the REC and T offset at the node RE. These are measured in the same way as described in
R21 Calculation, T14 at the master port of the REC and T offset at the slave port of the node
RE.
The round trip delay T14(1) is calculated based on the time difference between the
transmission and reception of the synchronization byte at the REC. Section 4.2.9 of the CPRI
Specification v7.0 [Ref 1] describes how the data that arrives at the network RE from the
node RE is sent onto the REC several basic frames (N) after the synchronization byte. To
calculate the round trip delay in the multi-hop system this must be accounted for by adding
N x TC, where T C is the basic frame length, to T14(1).
This gives:
Multi-hop round trip delay = T 14(1) + (N x TC) - Toffset

136
R19 Calculation
The delay figures given earlier in the section can be used to calculate the link delay,
excluding the cable length, from the master synchronization input to the slave
synchronization output. For 32-bit datapath cores, one datapath clock cycle equates to 40
UI. For all other cores one datapath clock cycle equates to 20 UI.
The delay through the transmitter is equal to the delay through the transmit section of the
transceiver plus two datapath clock cycles. The transceiver delays are detailed in Delay
Through the GTXE2 Transceiver, Delay Through the GTHE2 Transceiver, Delay Through the
GTPE2 Transceiver, Delay Through the GTHE3 Transceiver, and Delay Through the GTYE3
Transceiver. The additional two datapath clock cycles represent the latency from the
synchronization port to the transceiver input.
In cores supporting line rates of 4,915.2 Mb/s and above, an extra datapath clock cycle
should be added, this represents the delay through the scrambler block. In cores running at
10,137.6 Mb/s line rate, an extra three 307.6 MHz datapath clock cycles and one 316.8 MHz
datapath clock cycle should be added. These represent the delay through the scrambler
block and the delay in clocking data in and out of the transmit CDC FIFO.
The delay through the receiver is equal to the delay through the receive section of the
transceiver. In addition the following cycles are added:
• One recovered clock cycle (20 UI in Artix-7 devices) or one datapath clock cycle
(UltraScale architecture-based, Virtex-7, and Kintex-7 devices) for the delay from the
output of the transceiver into the CDC FIFO.
• (Artix-7 devices only) One recovered clock cycle for delay in converting from 2 bytes to
4 bytes (20 UI).
• One datapath clock cycle latency through the core to the synchronization interface and
one datapath clock cycle for clocking the data out of the CDC FIFO.
• In cores supporting line rates of 4,915.2 Mb/s and above, an extra two datapath clock
cycles, or recovered clock cycles in Artix-7 devices, should be added. This represents
the extra pipeline delay through the receiver.
Adding the delays through the transmit and receive paths together gives the link delay
between the master and slave service access points (excluding the cable delay).

137
Chapter 5
Design Flow Steps

This chapter 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 information about the standard Vivado® design flows and the IP integrator can be
found in the following Vivado Design Suite user guides:
• Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
[Ref 7]
• Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 8]
• Vivado Design Suite User Guide: Getting Started (UG910) [Ref 9]
• Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 10]]
Customizing and Generating the Core

This section includes information about using Xilinx tools to customize and generate the
core in the Vivado Design Suite.
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) [Ref 7] for
detailed information. IP integrator might auto-compute certain configuration values when
validating or generating the design. To check whether the values do change, see the
description of the parameter in this 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 associated with the IP core using the following steps:
1. Select the IP from the Vivado 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) [Ref 8] and
the Vivado Design Suite User Guide: Getting Started (UG910) [Ref 9].
Note: Figures in this chapter are illustrations of the CPRI configuration screens in the Vivado
Integrated Design Environment (IDE). This layout might vary from the current version.

138
Figure 5-1 shows the Vivado IDE configuration tab for the CPRI™ core.
Figure 5-1: CPRI Main Screen - Configuration Tab
Component Name
The component name is used as the base name of the output files generated for the core.
IMPORTANT: Names must begin with a letter and must be composed from the following characters: a
through z, 0 through 9 and “_” (underscore).
Master/Slave
This radio button controls whether the core is created as a CPRI Master or CPRI slave.

139
Speed and Reference Clock Selection

This radio button and text box control what line rates and reference clock frequencies the
core supports. See the Reference Clock Selection in Chapter 4. For information on the
speed capabilities of the supported devices see Device, Package, and Speed Grade
Selections.
• 24.330G and under—In UltraScale™ device GTYE3 and GTYE4 transceivers if this radio
button is selected, the reference clock can be set to either 368.64 MHz (GTYE3
transceivers only) or 245.76 MHz. If the 368.64 MHz option is selected then the core
supports line rates 8,110.08, 12,165.12 and 24,330.24 Mb/s. If the 245.76 MHz option is
selected then the core supports all line rates from 614.4 Mb/s to 24,330.24 Mb/s.
• 12.165G and under—In UltraScale device GTYE3, GTHE4 or GTYE4 transceivers if this
radio button is selected, the core supports all line rates from 614.4 to 12,165.12 Mb/s
when the reference clock is set to 245.76 MHz or 307.2 MHz. If it is set to 368.64 MHz
then only line rates 8,110.08 and 12,165.12 Mb/s are supported.
In UltraScale device GTHE3 transceivers and Virtex-7 GTHE2 transceivers if this radio
button is selected, the core supports 8,110.08 and 12,165.12 Mb/s using a 368.64 MHz
reference clock and all other rates using a 307.2 MHz reference clock.
In 7 series GTXE2 transceivers if this radio button is selected, the core supports
12,165.12 Mb/s with a 380.16 MHz reference clock and all other rates except
8,110.08 Mb/s using a 307.2 MHz reference clock.
• 10.137G and under—If this radio button is selected, the core supports all line rates
from 614.4 to 10,137.6 Mb/s. In UltraScale device GTHE3 transceivers the reference
clock must be set to 307.2 MHz. In UltraScale GTYE3 and UltraScale+ GTHE4 and GTYE4
device transceivers the reference clock can be set to 245.76 MHz or 307.2 MHz. This
option is not supported in Artix®-7 devices.
• 9.830G and under—If this radio button is selected, the core supports all line rates from
614.4 Mb/s to 9,830.4 Mb/s. In Zynq®-7000, Virtex®-7, Kintex®-7 and Artix-7 based
designs, the reference clock can be set to be 122.88, 153.60, 245.76 or 307.2 MHz.
In UltraScale architecture-based designs the reference clock can be set to be 245.76 or
307.2 MHz.
• 6.144G and under—If this radio button is selected, the core supports all line rates from
614.4 to 6,144.0 Mb/s. The reference clock can be set to be 122.88, 153.60, 245.76 or
307.2 MHz.
• 3.072G and under—If this radio button is selected, the core supports line rates from
614.4 to 3,072.0 Mb/s. The reference clock can be set to be 122.88 or 153.60 MHz.
Use 32-bit Datapath

This check box controls the width of the core datapath. The core supports 16-bit and 32-bit
options. Some line rates are limited to either a 16-bit or a 32-bit datapath depending on the
device and speed grade selected.

140
Use 64-bit Datapath

This check box enables the 64-bit datapath required to operate at the 24,330.24 Mb/s line
rate.
Table 5-1 shows the datapath width options for different implementations of the core.
Table 5-1: Datapath Width Options

Device Line rate (Mb/s) Datapath width
3,072.0 16-bit
Kintex-7L
4,915.2 32-bit
Virtex-7, Kintex-7, Zynq-7000 3,072.0 16-bit

-1/-2L speed grade 6,144.0 32-bit
3,072.0 16-bit
6,144.0 16-bit/32-bit
Virtex-7, Kintex-7, Zynq-7000
-2/-2G/-3 speed architecture-based 9,830.4 32-bit
devices
10,137.6 32-bit
12,165.12 32-bit
3,072.0 16-bit
6,144.0 16-bit/32-bit
9,830.4 32-bit
UltraScale architecture-based
10,137.6 32-bit
devices
8,110.08 32-bit
12,165.12 32-bit
24,330.24 64-bit
Artix-7 3,072.0, 4,915.2, 6,144.0 32-bit
Free Running Receive Clock

This option is available when a slave core is generated on Artix®-7 devices. The parameter
controls whether the core clocks the transceiver receive PLL with a free running or a
recovered reference clock. See Artix-7 Devices.
Management Clock Rate

The core requires information on the frequency of the management clock input. The speed
of the clock should be entered in MHz. This ensures the accurate timing of the transceiver
reset sequence and calibration of the channel phase-locked loop (CPLL). The management
clock can typically run between 10 MHz and 125 MHz. On Artix-7 devices and -2L speed
grade Kintex-7 devices, the maximum frequency is 100 MHz. On UltraScale devices the
maximum frequency is 125 MHz.

141
Transceiver Settings
Transceiver Location
In UltraScale-based devices the transceiver location can be specified with this Vivado IDE
option. Alternatively the location can be specified in the user constraints file.
Reference Clock Location

As with the transceiver location, the reference clock can be selected. Options are refclk0 and
refclk1 along with the refclk0 and refclk1 inputs from the two quads below and above the
selected transceiver location. See the UltraScale Architecture GTH Transceivers User Guide
(UG576) [Ref 4] and the UltraScale Architecture GTY Transceivers User Guide (UG578) [Ref 5]
for more information on reference clock distribution.
GT Type
For UltraScale and UltraScale+ devices where both GTH and GTY transceivers are
supported, this check box selects either the GTY or GTH transceiver. For all other device
types the transceiver type available on that device is displayed.
Additional Transceiver Control and Status Ports

When this option is selected, additional transceiver signals are routed out of the core for
user control. These include polarity and TX driver control. See Transceiver Debug Interface
and Transceiver Data Monitor Interface in Chapter 3.

142
Optional Features
Figure 5-2 shows the Vivado IDE optional features tab of the CPRI core.
Figure 5-2: Optional Features
Include R21 Timers

This check box controls whether the timing logic required for Requirement 21 of the CPRI
specification (R21) is implemented in the core.
AXI4-Lite Management Interface

When this option is selected, the core is generated with an AXI4-Lite memory interface. The
core management signals are converted to AXI4-Lite signaling by an instance of the
AXI4-Lite IPIF core. See Chapter 6, Example Design.

143
ORI Support
This check box allows extra support to be added for the Open Radio Equipment Interface
(ORI) standard. If this option is selected, an ORI interface module is generated in the CPRI
Example Design. See ORI Module in Chapter 3.
Include Ethernet Logic

This check box controls whether the Ethernet C&M capability is implemented in the core.
Use GMII Interface

If the core supports operation at 4,915.2, 6,144.0, 9,830.4, 10,137.6, 12,165.12, or
24,330.24 Mb/s, and the Ethernet C&M capability is included, then a GMII-compliant
interface can be selected as the Ethernet data interface.
Bypass Ethernet FIFOs

When this option is selected the frame buffers in the Ethernet section of the core are
removed. The Ethernet data is input to and output from the core in the AXI4-Stream format.
See Ethernet Interface in Chapter 3.
Real Time Vendor-Specific Support

If the 24,330.24, 12,165.12, or 10,137.6 Mb/s line rates are selected, then Real Time
Vendor-Specific Support can be selected. This allows the control word to be increased on
every basic frame from 128 bits up to 160 bits for 10,137.6 Mb/s, up to 192 bits for
12,165.12 Mb/s and up to 384 bits for 24,330.24 Mb/s.
Line Rate Support

The line rate support radio buttons allow the selection of individual line rates. The radio
buttons default to fully support the line rate selected in the configuration tab. If the design
is to run at only a sub-set of these rates then unused speeds can be turned off by
deselecting the relevant radio buttons.
For example, to generate a core with a maximum line rate of 4915.2 Mb/s, select the 6.144G
and under option in the Configuration pane. The 6144.0 Mb/s support radio button in the
Optional Features pane can then be deselected to change the maximum supported line
rate. Deselecting unused line rates can result in improved logic optimization during the
implementation phase.
FEC Enabled Mode

If the core/device supports the 24,330.24 Mb/s line rate, then the use of Forward Error
Correction can be selected. See RS-FEC Enabled Mode.

144
Shared Logic
Figure 5-3 shows the Vivado IDE Shared Logic tab of the CPRI core.
Figure 5-3: CPRI Main Screen - Shared Logic Tab

If the shared logic is included in the core the common clocking and transceiver logic for the
CPRI core is generated in a support layer around the core. See Chapter 6, Example Design.

145
Advanced
Figure 5-4 shows the Vivado IDE Advanced tab of the CPRI core.
Figure 5-4: CPRI Main Screen - Advanced Tab

In UltraScale and UltraScale+ devices the advanced tab enables the adjustment of the
transceiver equalization mode and insertion loss settings. Three bands are given, low 8b10b
line rate (3,072 Mb/s and lower), high 8b10b line rate (4,915.2 Mb/s to 9,830.4 Mb/s) and
64b66b line rate. The equalization mode for each speed band can be set to LPM, DFE or
Auto. See the following documents for information on setting equalization mode and
insertion loss:
• UltraScale Architecture GTH Transceivers User Guide (UG576) [Ref 4]

• UltraScale Architecture GTY Transceivers User Guide (UG578) [Ref 5]

146
User Parameters
Table 5-2 shows the relationship between the fields in the Vivado IDE and the User
Parameters (which can be viewed in the Tcl Console).
Table 5-2: Vivado IDE Parameter to User Parameter Relationship

Vivado IDE Parameter/Value(1) User Parameter/Value(1) Default Value
Master/Slave Master_Slave Master
Master Master
Slave Slave
Speed Selection Line_Rate 3.072G_and_under
3.072G and under 3.072G_and_under
Use 32-bit Datapath Use_32bit False
Use 64-bit Datapath Use_64bit False
Reference Clock Ref_Clk 122.88 MHz
122.88 MHz 122.88 MHz
153.60 MHz 153.60 MHz
245.76 MHz 245.76 MHz
307.20 MHz 307.20 MHz
368.64 MHz 368.64 MHz
307.20MHz / 368.64MHz 307.20MHz_/_368.64MHz
307.20MHz / 380.16MHz 307.20MHz_/_380.16MHz
Management Clock Rate Aux_Clk_Rate 125.0
Include R-21 Timers Has_R21_Timers True
AXI4-Lite Management Interface AXI_ipif False
Free running receive clock Free_Running_RX_Reference False
ORI Support Use_ORI False
Include Ethernet Logic Has_Ethernet True
Use GMII Interface Use_GMII False
Bypass Ethernet FIFOs Bypass_Buffer False
Shared Logic SupportLevel 0
Include Shared Logic in core 1
Include Shared Logic in example design 0
Additional transceiver control and status ports TransceiverControl False
Real Time Vendor-Specific Support RT_Vendor_Support False

147
Table 5-2: Vivado IDE Parameter to User Parameter Relationship (Cont’d)

Vivado IDE Parameter/Value(1) User Parameter/Value(1) Default Value
FEC Enabled Mode Use_FEC False
GTH / GTX / GTP/
GT Type GT_Type GTHE3 / GTYE3/
GTHE4 / GTYE4
Low Line Rate Equalization Mode Low_Rate_Eq_Mode Auto
Low Line Rate Insertion Loss Low_Rate_Ins_Loss 14
High 8b10b Line Rate Equalization Mode Mid_Rate_Eq_Mode Auto
High 8b10b Line Rate Insertion Loss Mid_Rate_Ins_Loss 20
64b66b Line Rate Equalization Mode High_Rate_Eq_Mode Auto
64b66b Line Rate Insertion Loss High_Rate_Ins_Loss 30
614.4 Mb/s support Line_Rate_0_6144 True
4915.2 Mb/s support Line_Rate_4_9152 False
Notes:
1. Parameter values are listed in the table where the Vivado IDE parameter value differs from the user parameter
value. Such values are shown in this table as indented below the associated parameter.
Output Generation
For output generation file location, see the Vivado Design Suite User Guide: Designing with
IP (UG896) [Ref 8].
When the CPRI IP core is generated, the encrypted RTL of the CPRI IP core is output for
synthesis and simulation. If the Ethernet option is selected in the CPRI Vivado IDE, the RTL
for the FIFO generator and Block Memory Generator are also produced for use in the
Ethernet frame buffers. When the AXI IP interface option is selected, the RTL for the
AXI4-Lite IPIF core and the proc_common helper core are also generated. If required, the
core support level described in CPRI Core Structure is generated. The VHDL core support
files are output to the
<project_name>.srcs/soures_1/ip/<component_name>/synth directory.
Figure 5-5 shows the structure of the CPRI IP core output products.

148
GT_CHANNEL
RXOUTCLK
Optional TXOUTCLK
Vendor Specific I/F DRP
ORI I/F
IQ I/F
RX Sync
Optional

Speed Change
State Machine

Speed clk
Change
State recovered_clk
Machine cpri_v8_7
BUFG
DRP clk_in
MMCM
clk_out txoutclk
BUFG/BUFH/BUFR
recclk_in
rxoutclk
recclk_out
Quad PLL Ports

GT_COMMON
Reset Generation
Alignment I/F
TX Sync
<component_name>_tx_alignment <component_name_block>
;
Figure 5-5: CPRI Core Output Products

The core layer (<component_name>.vhd) consists of the following components.
• cpri_v8_7. This is the top level of the encrypted RTL of the CPRI IP core. The RTL
contains the logic required to implement the transmit and receive state machines,
control and management multiplexing and de-multiplexing, L1 synchronization logic
and management registers.
• <component_name>_v7_gtwizard_gt.vhd. This file instantiates the transceiver
channel primitive. The logic is developed from the output of the serial transceiver
wizard.
• <component_name>_rx_sync.vhd. In 7 series devices, this block contains the state
machine to perform automatic RX phase and delay alignment for 7 series devices as
described in the “RX Buffer Bypass” section of the 7 Series FPGAs GTX/GTH Transceivers
User Guide (UG476) [Ref 2] and 7 Series FPGAs GTP Transceivers User Guide (UG482)
[Ref 3].
• <component_name>_v7_gtwizard.vhd. This file, derived from the serial transceiver
wizard output, instantiates <component_name>_v7_gtwizard_gt together with the
receive alignment block.

149
• <component_name>_gt_and_clocks.vhd. The serial transceiver and clocks block

instantiate the transceiver wrappers. Reset handling is also included. A state machine is
instantiated that detects a change in line rate by monitoring the status outputs from
the encrypted RTL block. When a change in line rate is detected, it reprograms the
transceiver clock dividers through the DRP bus. The settings are dependent on the new
line rate.
• <component_name>_ori_if.vhd. This file takes the ORI MAC address, port number
and, if a slave configuration, the RTWP groups and maps them onto the vendor-specific
interface for transmission. In the receive direction the MAC address, port number and,
if a master configuration, the RTWP groups are extracted from the vendor-specific data
stream and output to the client. See ORI Module for more information.
• <component_name>_axi_lite_ipif_wrapper.vhd. When the AXI interface is selected,
this file maps between the generic management interface and the AXI4-Lite interface.
See Management Interface and AXI4-Lite Memory Mapped Interface for more
information.
The core support level (<component_name>_support.vhd) consists of the following

components.
• <component_name>_clocking.vhd. This file contains the clock logic for the CPRI
core. In Zynq-7000, Virtex-7, Kintex-7 and Artix-7 based designs, an MMCM is used to
generate the system clock from the TXOUTCLK output of the transceiver. The MMCM
output is routed to the core layer and the user logic through a BUFG. A state machine is
included to modify the MMCM clock divider settings using the DRP bus when the line
rate of the CPRI link is changed. In UltraScale architecture-based designs the
TXOUTCLK output of the transceiver is routed to the core layer and the user logic
through a BUFG_GT. In addition, this file routes the RXOUTCLK output from the
transceiver through a clock buffer. The output is used to generate the recovered clock
input to the core layer. See the Clock Configuration sections in Chapter 4, Design
Considerations for more information.
• <component_name>_gt_common.vhd. This file instantiates the transceiver common
block. If the core is configured to run at a line rate of 9,830.4 Mb/s, the common block
provides the 4,915.2 MHz reference clock for running at 9.8304 Gb/s. When
10,137.6 Mb/s operation is supported the common block provides a 5,068.8 MHz
reference clock to the transceiver. When 12,165.12 Mb/s operation is supported the
common block provides a 6,082.56 MHz reference clock to the transceiver. When
24,330.24 Mb/s operation is supported the common block provides a 12,165.12 MHz
reference clock to the transceiver. In Artix-7 FPGA-based designs the common block
contains the PLLs for the transceiver. In other cases the common block is instantiated to
correctly set the BIAS_CFG parameter.
• <component_name>_tx_alignment.vhd. This block contains the state machine to
perform manual TX phase and delay alignment as described in the “TX Buffer Bypass”
section in the UltraScale Architecture GTY Transceivers User Guide (UG578) [Ref 5], the
UltraScale Architecture GTH Transceivers User Guide (UG576) [Ref 4], 7 Series FPGAs

150
GTX/GTH Transceivers User Guide (UG476) [Ref 2] and the 7 Series FPGAs GTP
Transceivers User Guide (UG482) [Ref 3].
• <component_name>_resets.vhd. This block contains logic to generate the reset to
the transceiver common block.
An example design is provided that shows an example of how to instantiate the CPRI IP
core. This is generated when Open IP Example Design is selected. The example design files
are generated to the example_project/<component_name>_ex/imports/ directory.
See Chapter 6, Example Design for more information.
Constraining the Core

This section describes how to constrain a design that contains the CPRI core. This is
illustrated by the constraints files (XDC) that are delivered with the core when it is
generated.
Two XDC files are delivered. The <component_name>.xdc file contains the core specific
constraints. These include the period requirements for the clocks that are generated in the
core support layer and the clock crossing delays between the different core clock domains.
The <component_name>_example_design.xdc file contains constraints that are
specific to the example design described in Chapter 6, Example Design. These include
placement constraints for specific devices and constraints on the device input and output
signals.
In UltraScale architecture-based designs the transceiver clock outputs are constrained in an

XDC file provided by the UltraScale architecture-based FPGAs transceivers wizard. This is
output in the <component_name>_gt/synth directory.
Required Constraints
This section is not applicable for this IP core.
Device, Package, and Speed Grade Selections

The CPRI core supporting operation at line rates up to 3,072.0 Mb/s can be implemented in
these Xilinx devices:
• Zynq-7000 devices, XC7Z030 and larger, with speed grade of -1 or higher

• Virtex-7 devices with a speed grade of -1 or higher
• Kintex-7 devices with a speed grade of -1 or higher.
• Kintex-7 Low Voltage devices with a speed grade of -2L
• Artix-7 devices with a speed grade of -1 or higher

151
• UltraScale architecture-based devices with a speed grade of -1 or higher
The CPRI core supporting operation at line rates of up to 4,915.2 Mb/s can be implemented
in Artix-7 devices with a speed grade of -2 or -3 in wire bond packages.
The CPRI core supporting operation at line rates up to 6,144.0 Mb/s can be implemented in
these Xilinx devices:
• Zynq-7000 (XC7Z030 and larger), Virtex-7, and Kintex-7 devices with a speed grade of
-1, -2 or -3
• Kintex-7 Low Voltage devices with a speed grade of -2L
• Artix-7 devices with a speed grade of -2 or -3 in non wire-bond packages
• UltraScale architecture-based devices with a speed grade of -1 or higher
The CPRI core supporting operation at line rates up to 9,830.4 Mb/s or 10,137.6 Mb/s can
be implemented in Virtex-7, Zynq-7000 (XC7Z030 and larger), and Kintex-7 devices with a
speed grade of -2 or -3 in FFG packages and in UltraScale architecture-based devices with
a speed grade of -1 or higher.
The CPRI core supporting operation at line rates up to 12,165.12 Mb/s can be implemented
in Virtex-7, Zynq-7000 (XC7Z030 and larger), and Kintex-7 devices with a speed grade of -3
in FFG packages and in UltraScale architecture-based devices with a speed grade of -1 or
higher.
The CPRI core supporting operation at line rates up to 24,330.24 Mb/s can be implemented
in -2 and -3 speed grade UltraScale architecture-based devices that use the GTYE3 or GTYE4
transceiver.
Clock Frequencies and Clock Management

The CPRI core has multiple clock domains:
• The refclk domain. This is the transceiver reference clock at 122.88, 153.6, 245.76, 307.2,
368.64, or 380.16 MHz.
• The auxiliary domain. This is a clock in the range 10 MHz to 125.00 MHz. The
management interface runs on this clock as do the blocks programming the DRP ports
of the transceiver and the internal PLL used for clock synthesis. This clock must run
continuously without interruption as the transceiver and PLL are reconfigured during
speed switches.
• The datapath clock domain. In Virtex-7, Kintex-7, Artix-7 and Zynq-7000 devices this is
the output from the PLL or MMCM.
• The transceiver clock domain (12,165.12 and 10,137.6 Mb/s cores only). On cores
implemented on Kintex-7, Virtex-7 and Zynq-7000 devices, the 316.8 MHz clock is used
by the transceiver when running at 10,137.6 Mb/s. This clock runs at 380.16 MHz when

152
operating at 12,165.12 Mb/s. When running at lower speeds, the frequency of the
transceiver clock is the same as that of the datapath clock.
• The recovered clock domain. This is the recovered clock from the transceiver, driven
from a BUFR or a BUFH.
• The Ethernet clock domain. This is the clock used for the Ethernet C&M channel (if
present). If an off-chip GMII interface is used then the transmitter circuitry is in a
separate clock domain.
• Hi-speed clock domain. This must be greater than both the maximum transmit and
receive clock frequencies and must be unrelated to the reference, datapath or
recovered clock.
The following subsections describe how the different clock domains are constrained in the
XDC files provided with the example design.
System Clock Domain

For a GTXE2 based design:
create_clock -name refclkout -period <period> [get_pins

gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtxe2_i/TXOUTCLK]
For a GTHE2 based design:

gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gthe2_i/TXOUTCLK]
For a GTPE2 based design:

gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtpe2_i/TXOUTCLK]
The period specified in the preceding constraint depends on the reference clock that is
selected. In the case of a 122.88 MHz reference the period is 8.138 ns, for a 153.6 MHz
reference it is 6.510 ns, for a 245.76 MHz reference it is 4.069 ns, for a 307.2 MHz reference
it is 3.255 ns, for a 368.64 MHz reference it is 2.713 ns and for a 380.16 MHz reference it is
2.630 ns.
This clock constraint is propagated through the core MMCM to constrain the core clock
domain to the relevant speed. This constraint is present in the core XDC file.
In GTHE3/GTYE3-based designs the system clock is constrained by the reference clock

constraint in the user XDC file. An example is provided in the example design XDC file
provided by the core.

153
Recovered Clock Domain

For a GTXE2 based design:
create_clock -name recclk -period <period> [get_pins

gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtxe2_i/RXOUTCLK]
For a GTHE2 based design:

gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gthe2_i/RXOUTCLK]
For a GTPE2 design

gt_and_clocks_i/gtwizard_i/gt0_gtwizard_i/gtpe2_i/RXOUTCLK]
The period specified depends on the line rate selected. If the recovered clock is to operate
at a maximum of 153.6 MHz, the period is 6.510 ns. If the recovered clock is to operate at a
maximum of 245.76 MHz, the period is 4.096 ns. If the recovered clock is to operate at a
maximum of 307.2 MHz, the period is 3.255 ns. If the recovered clock is required to operate
at 368.64 MHz, the period is 2.713 ns and for a 380.16 MHz recovered clock it is 2.630 ns.
See the clock configuration sections in Chapter 4, Design Considerations for the recovered
clock speed for the chosen configuration. This constraint in present in the core XDC file.
In GTHE3 and GTYE3 based designs the recovered clock is constrained by the reference
clock constraint in the user XDC file. An example is provided in the example design XDC file
provided by the core.
In addition to constraining the clock domains the core XDC file contains constraints on the
signals that cross between clock domains.
Management Clock Domain

When the generic management interface is selected:
create_clock -name aux_clk -period 8.000 [get_ports aux_clk]
When the AXI4-Lite management interface is selected:
create_clock -name aux_clk -period 8.000 [get_ports s_axi_aclk]
The example design constrains the management clock to 125 MHz.
Reset Block Clock Domain

When the design is implemented on UltraScale architecture-based devices a free running
clock is required to drive the transceiver reset circuitry. This clock should run at a slower
speed than the system clock at the lowest supported line rate. In the example design XDC
file this clock is constrained to the speed of the system clock at 614.4 Mb/s.

154
When a 32-bit datapath is selected:
create_clock -name reset_block_clk -period 65.104 [get_ports gtwiz_reset_clk_freerun_in]
When 16-bit datapath is selected:
create_clock -name reset_block_clk -period 32.552 [get_ports gtwiz_reset_clk_freerun_in]
Ethernet Clock Domain

When the bypass Ethernet Buffers option is not selected, the Ethernet clock domain is
present. In the example design XDC the Ethernet clock is constrained to be 125 MHz in GMII
mode and 25 MHz in MII mode.
When the MII interface option is selected:
create_clock -name eth_ref_clk -period 40.000 [get_ports eth_ref_clk]
When the GMII interface option is selected:
create_clock -name eth_ref_clk -period 8.000 [get_ports eth_ref_clk]
Hi-Speed Clock Domain

When the R-21 timers are included the hi-speed clock domain is present. In the example
design XDC, this clock is constrained to run at 250 MHz for cores supporting up to
3,072 Mb/s, at 333 MHz for cores supporting up to 9,830.4 Mb/s and at 380 MHz for cores
supporting 10,137.6, 12,165.12 and 24,330.24 Mb/s.
create_clock -name hires_clk -period 4.000 [get_ports hires_clk]
Clock Placement
Banking
Transceiver Placement
In Artix-7 based designs the example design XDC file contains placement information for
the GTPE2 instances in the design. These are tailored towards specific devices and should
be altered for the chosen device and placement.
I/O Standard and Placement


155
Simulation
For comprehensive information about Vivado simulation components, as well as
information about using supported third-party tools, see the Vivado Design Suite User
Guide: Logic Simulation (UG900) [Ref 10].
IMPORTANT: For cores targeting 7 series or Zynq-7000 devices, UNIFAST libraries are not supported.
Xilinx IP is tested and qualified with UNISIM libraries only.
Synthesis and Implementation

For details about synthesis and implementation, see the Vivado Design Suite User Guide:
Designing with IP (UG896) [Ref 8].

156
Chapter 6
Example Design
This chapter contains information about the example design provided in the Vivado®
Design Suite.
Figure 6-1 illustrates the example design that is generated when the core support layer
option is enabled.
IOBs refclk
BUFG
IOBs aux_clk
BUFG
IOBs hires_clk
BUFG
Serial I/O
IOBs eth_ref_clk
Vendor Vendor Specific I/F
Stim
IQ TX
Gen IQ I/F
stat_speed
IQ RX Clock recclk to PLL at
Check recclk_out Divide 30.72 MHz
IOBs Management I/F
MII Ethernet I/F

Stim
HDLC HDLC I/F

Stim
ORI
Stim ORI I/F
IOBs Control & Status
Clock for stimulus and clk_out

monitor blocks
Figure 6-1: Example Design

157
The complete example design can be opened as a separate project by right-clicking the
core in the project hierarchy after it has been customized using the IP catalog. Right-click
the <component_name>.xci in the Design Sources hierarchy in the Sources window and
select Open IP Example Design. This opens a new Vivado project in a new window with a
complete CPRI™ example design.
The CPRI example design consists of the following:
• An instance of the CPRI core

• An example VHDL wrapper containing data generators and monitors
The example VHDL wrapper connects the core I/O to the top-level FPGA I/O so that the core
can be implemented as an FPGA design. Additional logic is included within the example
design for the following functions:
• Constant Rate Clock Division. The received recovered clock output by the transceiver
varies in frequency depending on the line rate set (manually or by auto-negotiation).
This logic ensures that a constant clock rate is output to the external jitter-removal PLL.
• Reset Logic for Slave. A top-level input, ext_clk_ok, is provided to allow the state of
the external jitter-removal PLL to have influence on the design; specifically, this signal
inhibits the hires_clock_ok flag until the external PLL is in LOCKED state.
• Data Generation and Monitoring. Data generators are provided to stimulate the
transmit IQ, Ethernet, HDLC, ORI and vendor-specific data interfaces. The data arriving
at the receive interfaces is checked against the transmitted data in monitor blocks.
Error counters are incremented when mismatches are detected. The operation of the
CPRI link can be tested by looping the serial output of the core back to the input and
querying the status counters in the data monitors. Data generation and monitoring is
enabled when the core is in the operational state.
• Management Register Multiplexing. The monitor blocks provide counters for the
number of frames or words received and for the number of errors detected.
Multiplexing is included in the example design to enable these counters to be read
through the management interface. The top-level example design is intended as a
template for you to use in creating your own top-level FPGA design.
The example design consists of the following VHDL source files:
• <component_name>_example_design.vhd. Top-level example design

encapsulating a CPRI core together with the data generator and monitor blocks. The
example design instantiates the <component_name>_support.vhd file. This
includes the CPRI encrypted RTL block along with the core and core support layers. It is
expected that <component_name>.vhd is the block that designers instantiate in their
design.
• iq_tx_gen.vhd. IQ data generator. This block outputs a simple incrementing data
pattern to the core transmit I/Q (Data) interface.

158
• iq_rx_chk.vhd. IQ data monitor. This blocks checks the receive I/Q (Data) interface
for the incrementing pattern output by the IQ data generator. Error and basic frame
counters are provided.
• mii_stim.vhd/gmii_stim.vhd. Ethernet data generator and monitor block.
Dummy Ethernet frames are transmitted to the CPRI MII/GMII interface and the frames
received are monitored. Transmit and receive frame counters are provided. An error
counter is incremented when mismatches between the transmitted and received frames
are detected.
• hdlc_stim.vhd. The HDLC block sends a serial bit pattern generated by a
pseudo-random binary sequence counter. The received pattern is checked for errors
and a counter is incremented if any are detected.
• vendor_stim.vhd. The vendor-specific block outputs words to the vendor-specific
interface in sub channels 16 to 19. The words are generated by a pseudo-random
binary sequence counter. The received pattern is checked for errors and a counter is
incremented if any are detected.
• ori_stim.vhd. An ORI stimulus block outputs and checks the port number and
Ethernet MAC address of the core. In slave cores RTWP information is generated and in
master cores the RTWP ports are monitored.

159
Figure 6-2 illustrates the example design that is generated when the core support layer
option is not selected.
IOBs refclk
BUFG
IOBs aux_clk
BUFG
IOBs hires_clk
BUFG
Serial IO
IOBs eth_ref_clk
Vendor Vendor Specific I/F
Stim
IQ TX
Gen IQ I/F
stat_speed
IQ RX Clock
Check recclk to PLL
Divide
IOBs Management I/F
recclk_in
MII BUFG
Ethernet I/F
Stim rxoutclk
BUFG
HDLC HDLC I/F txoutclk MMCM
Stim DRP
ORI Speed
Stim ORI I/F Change State

Machine
IOBs Control & Status

GT Quad I/F GT_COMMON
clk_in Alignment I/F TX Alignment
<component_name>
Clock for stimulus and
monitor blocks
;
Figure 6-2: Example Design without Core Support Layer

In addition to the blocks described previously, the example design includes logic for clock
generation, along with an instance of the transceiver common block and the TX phase and
delay alignment circuitry. These additional blocks enable full functionality for a single CPRI
link. The following extra VHDL files are instantiated by the example design:
• <component_name>_clocking.vhd. In Zynq®-7000, Virtex-7, Kintex®-7, and

Artix®-7 based designs, this block consists of the MMCM and BUFGs required to
generate clocks for the System and Recovered clock domains. A state machine is also
generated to modify the MMCM divider settings using the DRP bus when a speed

160
change occurs. In UltraScale™ architecture-based designs the block routes the

transceiver output clocks to the System and Recovered clock domains through
BUFG_GTs. The transmit clock can be shared between multiple CPRI cores. See
Transmitter Clock Sharing for a two core example.
• <component_name>_gt_common.vhd. One transceiver common block is required per
quad on the FPGA. The clock and reference clock outputs from the block can be shared
between all the cores in the quad.
• <component_name>_tx_alignment.vhd. This block carries out the TX phase and
delay alignment functions. The block interfaces to the alignment interface described in
Transceiver Interface. See Resource Sharing for a two core example.
A user constraints file (<component_name>_example_design.xdc) is included to

support implementation of the example design.

161
Chapter 7
Test Bench
This chapter contains information about the test bench provided in the Vivado® Design
Suite.
For information on setting up and running simulations in the Vivado Design Suite. See
Vivado Design Suite User Guide – Logic Simulation (UG900) [Ref 10]. The CPRI™ LogiCORE™
IP supports behavioral simulation along with post-implementation functional simulation.
Figure 7-1 shows the structure of the CPRI test bench.

DEMO?TB
4"#ONTROL
3TATUS
#LOCKSAND -GMNT RXP

2ESET
TXP
IQ?TX
IQ?TX?GEN
IQ?RX
IQ?RX?CHK
($,#
HDLC?STIM
%THERNET
MII?STIM
6ENDOR3PECIFIC
VENDOR?STIM
CPRI?EXAMPLE
Figure 7-1: CPRI Test Bench Structure

162
The CPRI test bench consists of:
• An instantiation of the CPRI example, wired in serial loopback in the test bench.
Loopback is not representative of a normal CPRI link.
• Clock generation for the reference, management, Ethernet and high-speed clocks.
• Global reset generation for the core.
• A mu-Law encoder and decoder circuit as an example of an IQ compression technique.
The test bench monitors the status of the CPRI link and waits until the core enters the
operational state. It waits until the IQ monitor has received 1,000 basic frames and then
queries the frame and error counters in the data generator and monitor blocks.
A package file is included along with the test bench. This contains useful data types,
constant definitions and functions to access the CPRI control and status registers (shown in
Table 2-2). Table 7-1shows the helper functions available.
Table 7-1: Helper Functions Provided in Test Bench Package File

Function Description
read_rcvd_protocol_version Returns the received protocol version from the Received Subchannel 2,
Word 0 Register (0x4)
read_rcvd_seed Returns the received seed from the Descrambler Seed Register (0x13)
read_rcvd_hdlc_rate Returns the negotiated HDLC rate from the Current HDLC Rate Register
(0x2)
read_status_code Returns the status code from the Status Code and Alarm Register (0x0)
read_status_alarm Returns the summary alarm status from the Status Code and Alarm
Register (0x0)
read_current_speed Returns the negotiated line rate from the Current Line Speed Register
(0xC)
read_tx_cpri_alarms Returns the value of the General Configuration and Transmit CPRI Alarms
Register (0xE)
read_reset Returns the status of the reset bit in the General Configuration and
Transmit CPRI Alarms Register (0xE)
read_sdi Returns the status of the SAP Defect Indicator bit in the General
Configuration and Transmit CPRI Alarms Register (0xE)
read_current_eth_ptr Returns the value of the negotiated Ethernet pointer from the Current
Ethernet Pointer Register (0x3)
write_speed_capability Writes to the Line Speed Capability Register (0xD) to change the line rate
on the link
write_set_sdi Sets the SAP Defect Indicator bit in the General Configuration and
write_clear_sdi Clears the SAP Defect Indicator bit in the General Configuration and

163
Table 7-1: Helper Functions Provided in Test Bench Package File

Function Description
write_clear_hdlc_rate_adapt Sets the HDLC rate adapt bit in the General Configuration and Transmit
CPRI Alarms Register (0xE)
write_set_hdlc_rate_adapt Clears the HDLC rate adapt bit in the General Configuration and Transmit
CPRI Alarms Register (0xE)
write_set_reset_request Sets the reset request or acknowledge bit in the General Configuration
and Transmit CPRI Alarms Register (0xE)
write_clear_reset_request Clears the reset request or acknowledge bit in the General Configuration
and Transmit CPRI Alarms Register (0xE)
write_slave_tx_enable Writes to the slave transmit enable bit in the General Configuration and
write_pref_hdlc Sets the Preferred HDLC Rate Register (0xA)
write_pref_protocol Sets the Preferred Protocol Version Register (0x11)
write_seed Sets the Scrambler Seed Register (0x12)
write_pref_eth_ptr Sets the Preferred Ethernet Pointer Register (0x8)
In addition general purpose write and read functions are provided to access other areas of
the CPRI management register map.

164
Appendix A
Verification, Compliance, and

Interoperability
This appendix includes information about how the IP was tested for compliance with the
protocol to which it was designed. The CPRI™ core has been verified using both simulation
and hardware testing, as described in this appendix.
Simulation
A highly parameterizable, coverage-driven simulation test suite has been used to verify the
core. Tests included:
• I/Q data
• Ethernet data
• HDLC data
• Alarm reception and detection
• Speed negotiation
Hardware Testing
The core has been used in several test platforms within Xilinx to verify both a Master and
Slave CPRI configuration.

165
Appendix B
Migrating and Upgrading

This appendix contains information about migrating a design from the ISE® Design Suite to
the Vivado® Design Suite, and for upgrading to a more recent version of the IP core. For
customers upgrading in the Vivado Design Suite, important details (where applicable)
about any port changes and other impact to user logic are included.
Migrating to the Vivado Design Suite

For information on migrating from Xilinx ISE Design Suite tools to the Vivado Design Suite,
see the ISE to Vivado Design Suite Migration Guide (UG911) [Ref 11].
Upgrading in the Vivado Design Suite

This section provides information about any changes to the user logic or port designations
that take place when you upgrade to a more current version of this IP core in the Vivado
Design Suite.
When upgrading from version 7.0 of the CPRI™ core the option to include the shared logic
in the core should be selected on the Vivado Integrated Design Environment (IDE). This
gives the easiest upgrade path because the shared logic is included in the core in version
7.0.
Device Migration
If you are migrating from a GTX or GTH transceiver for a 7 series device to a GTH or GTY
transceiver for an UltraScale™ device, the prefixes of the optional transceiver debug ports
for single-lane cores are changed from gt0 to gt, and the postfix _in and _out are
dropped.
IMPORTANT: Update your design to use the new transceiver debug port names. For more information
about migration to UltraScale architecture-based devices, see the UltraScale Architecture Migration
Methodology Guide (UG1026) [Ref 12].

166
Port Changes in Version 8.7

The following ports have been added in version 8.7 of the core. The rxrecclkout port is
present on UltraScale and UltraScale+ device based cores. This port gives access to the
RXRECCLKOUT port of the transceiver.
Table B-1: Ports Added in Version 8.7

Port Direction Upgrade Action
rxrecclkout Out Leave open

The following ports have been added in version 8.6 of the core. The refclk_307 port is
only present on 7 series cores that support 12,165.12 Mb/s and have the shared logic in the
core.

refclk_307 In Tie to 0

The following ports have been added in version 8.5 of the core.

reset_aux_clk In Tie to 0
mmcm_locked In Tie to the LOCKED output of the MMCM.

The following port has been added in version 8.4 of the core.
Table B-4: Port Added in Version 8.4

gt_pcsrsvdin In Tie to 0 unless using the DRP for debug purposes
Notes:
1. UltraScale architecture-based devices only

167
The following ports have been removed in version 8.4 of the core.
Table B-5: Ports Removed in Version 8.4

refclk2 In N/A
clk_316_in In N/A
Notes:
1. UltraScale architecture-based devices with 10,137.6 Mb/s support only
Ports Added in Version 8.3

The following ports have been added in version 8.3 of the core.
Table B-6: Transceiver Data Monitor Ports

txdata Out Leave open
txcharisk Out Leave open
rxdata Out Leave open
rxchariscomma Out Leave open
rxcharisk Out Leave open
rxdisperr Out Leave open
rxnotintable Out Leave open
Cores supporting 10,137.6 Mb/s only
txheader Out Leave open
txsequence Out Leave open
rxheader Out Leave open
rxdatavalid Out Leave open
rxheadervalid Out Leave open

The ports in Table B-7 were added in version 8.2 of the core. The qpll_select input is
only present for designs implemented in UltraScale architecture-based devices. The
clk_316_in port is only present on Kintex®-7, Virtex®-7 and Zynq®-7000-based designs
supporting the 10,137.6 Mb/s line rate.

UltraScale Architecture-Based Devices Only
Drive with free running clock at less than the speed
gtwiz_reset_clk_freerun_in In
of the system clock at the lowest supported line rate.

168

Cores With Core Support Layer Only
gt_reset_req_out Out Leave open
UltraScale Architecture-Based Devices With Core Support Layer
qpll_select In Tie to 0
qpll1clk_out Out Leave open
qpll1refclk_out Out Leave open
qpll1lock_out Out Leave open
UltraScale Architecture-Based Devices Without Core Support Layer
qpll_select In Tie to 0
qpll1clk_in In Tie to 0
qpll1refclk_in In Tie to 0
qpll1lock_in In Tie to 0
qpll1_pd Out Leave open
Cores Without Core Support Layer Supporting 10,137.6 Mb/s Only
clk_316_in In Tie to 0
userclk_tx_reset Out Leave open
userclk_rx_reset Out Leave open
Transceiver Debug Ports (Kintex-7, Virtex-7, Artix®-7, Zynq-7000)
gt0_drpdaddr_in[8:0] In Tie to 0
gt0_drpdi_in[15:0] In Tie to 0
gt0_drpen_in In Tie to 0
gt0_drpwe_in In Tie to 0
gt0_drpdo_out[15:0] Out Leave open
gt0_drprdy_out Out Leave open
Transceiver Debug Ports (UltraScale Architecture-Based)
gt_drpdaddr[8:0] In Tie to 0
gt_drpdi[15:0] In Tie to 0
gt_drpen In Tie to 0
gt_drpwe In Tie to 0
gt_drpdo[15:0] Out Leave open
gt_drprdy Out Leave open

169

In version 8.1 of the core additional transceiver debug ports were added. These are only
present when the Additional Transceiver Control and Status Ports option is selected. The
new ports are shown in Table B-8.
Table B-8: Transceiver Debug Interface

gt0_txpmareset_in In Tie Low
gt0_txpcsreset_in In Tie Low
gt0_rxpmareset_in In Tie Low
gt0_rxpcsreset_in In Tie Low
gt0_rxpmaresetdone_out Out Leave open
gt0_txphaligndone_out Out Leave open
gt0_txphinitdone_out Out Leave open
gt0_txdlysresetdone_out Out Leave open
gt0_rxphaligndone_out Out Leave open
gt0_rxdlysresetdone_out Out Leave open
gt0_rxsyncdone_out Out (GTHE2 and GTPE2 based cores only) Leave open
gt0_cplllock_out Out Leave open
gt0_qplllock_out Out Leave open
gt0_txprbsforceerr_in In Tie Low
gt0_txprbssel_in[2:0] In Tie to 000
gt0_rxprbssel_in[2:0] In Tie to 000
gt0_rxprbserr_out Out Leave open
gt0_rxprbscntreset_in In Tie Low
gt0_rxcdrhold_in In Tie Low
gt0_dmonitorout_out Out Leave open
gt0_rxcommadet_out Out Leave open

170

The ports in Table B-9, Table B-10, and Table B-11 were added to version 8.0 of the core.
Table B-9: Quad PLL Clock Ports

Virtex-7, Kintex-7 and Zynq-7000 Implementations
qpllclk_out Out Leave open
qpllrefclk_out Out Leave open
qplllock_out Out Leave open
Artix-7 implementations
pll0clk_out Out Leave open
pll0refclk_out Out Leave open
pll1clk_out Out Leave open
pll1refclk_out Out Leave open
Table B-10: Alignment Interface

phase_alignment_done_out Out Leave open
txdlysreset_out[2:0] Out Tie to txdlysresetdone_in[2:0]
txdlysresetdone_in[2:0] In Tie to txdlysreset_out[2:0]
txphinit_out[2:0] Out Tie to txphinitdone_in[2:0]
txphinitdone_in[2:0] In Tie to txphinit_out[2:0]
txphalign_out[2:0] Out Tie to txphaligndone_in[2:0]
txphaligndone_in[2:0] In Tie to txphalign_out[2:0]
txdlyen_out[2:0] Out Leave open
Table B-11: Transceiver Debug Interface (1)

gt0_eyescantrigger_in In Tie Low
gt0_eyescanreset_in In Tie Low
gt0_eyescandataerror_out Out Leave open
gt0_txdiffctrl_in In Tie to 1010
gt0_txpostcursor_in In Tie to 00000
gt0_txprecursor_in In Tie to 00000
gt0_txpolarity_in In Tie Low
gt0_rxpolarity_in In Tie Low
gt0_rxdfelpmreset_in In (GTXE2 and GTHE2 based cores only) Tie Low

171
Table B-11: Transceiver Debug Interface (1) (Cont’d)

gt0_rxlpmen_in In (GTXE2 and GTHE2 based cores only) Tie Low
gt0_rxlpmreset_in In (GTPE2 based cores only) Tie Low
gt0_rxlpmhfhold_in In (GTPE2 based cores only) Tie Low
gt0_rxlpmhfovrden_in In (GTPE2 based cores only) Tie Low
gt0_rxlpmlfhold_in In (GTPE2 based cores only) Tie Low
gt0_rxdisperr_out Out Leave open
gt0_rxnotintable_out Out Leave open
gt0_rxresetdone_out Out Leave open
gt0_txresetdone_out Out Leave open
Notes:
1. Ports only present when the Additional Transceiver Control and Status Ports option is selected
Changed Ports in Version 8.0

The ports in Table B-12 were re-named or re-sized in version 8.0 of the CPRI core. Their
functionality remains the same.
Table B-12: Renamed Ports

Port Description Version 7.0 Version 8.0
System clock output core_clk clk_out
System clock OK clk_ok clk_ok_out
AXI Write Address s_axi_awaddr[31:0] s_axi_awaddr[11:0]
AXI Read Address s_axi_araddr[31:0] s_axi_araddr[11:0]

172
Appendix C
Debugging
This appendix includes details about resources available on the Xilinx Support website and
debugging tools.
TIP: If the IP generation halts with an error, there might be a license issue. See License Checkers in
Chapter 1 for more details.
Finding Help on Xilinx.com

To help in the design and debug process when using the CPRI™ core, the Xilinx Support web
page contains key resources such as product documentation, release notes, answer records,
information about known issues, and links for obtaining further product support.
Documentation
This product guide is the main document associated with the CPRI core. This guide, along
with documentation related to all products that aid in the design process, can be found on
the Xilinx Support web page or by using the Xilinx Documentation Navigator.
Download the Xilinx Documentation Navigator from the Downloads page. For more
information about this tool and the features available, open the online help after
installation.
Answer Records
Answer Records include information about commonly encountered problems, helpful
information on how to resolve these problems, and any known issues with a Xilinx product.
Answer Records are created and maintained daily ensuring that users have access to the
most accurate information available.

173
Answer Records for this core can be located by using the Search Support box on the main
Xilinx support web page. To maximize your search results, use proper keywords such as
• Product name
• Tool message(s)
• Summary of the issue encountered.
A filter search is available after results are returned to further target the results.
Master Answer Record for the CPRI Core
AR: 54473
Technical Support
Xilinx provides technical support at the Xilinx Support web page for this LogiCORE™ IP
product when used as described in the product documentation. Xilinx cannot guarantee
timing, functionality, or support if you do any of the following:
• Implement the solution in devices that are not defined in the documentation.
• Customize the solution beyond that allowed in the product documentation.
• Change any section of the design labeled DO NOT MODIFY.
To contact Xilinx Technical Support, navigate to the Xilinx Support web page.
Vivado Design Suite Debug Feature

The 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 Xilinx devices.
The Vivado logic analyzer is used with the logic debug IP cores, including:
• ILA 2.0 (and later versions)

• VIO 2.0 (and later versions)
Several internal signal are marked as debug signals. These can be easily added to the logic
analyzer.
See the Vivado Design Suite User Guide: Programming and Debugging (UG908) [Ref 13].

174
Hardware Debug
Hardware issues can range from link bring-up to problems seen after hours of testing. This
section provides debug steps for common issues. The debug feature is a valuable resource
to use in hardware debug. The signal names mentioned in the following individual sections
can be probed using the debugging tool for debugging specific problems.
Hardware Demonstration Design

A hardware demonstration design is available in the CPRI IP lounge (registration required).
This provides a self-contained CPRI loopback demo. The design is available for a variety of
Xilinx evaluation boards.
General Checks
Ensure that all the timing constraints for the core were properly incorporated from the
example 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 not in timing simulation, this might indicate a PCB issue. Ensure that all
clock sources are active and clean.
• If using MMCMs in the design, ensure that all MMCMs have obtained lock by
monitoring the locked port.
• Disabling the watchdog timer by writing zeros to address 0x15 (AXI 0x54) gives the
core the maximum length of time to achieve link-up.
CPRI Specific Checks

The following section lists some tips for debugging common problems with the CPRI link.
• Confirming the link stays up and there are no alarms. Do this by looking at the
stat_code and stat_speed signals. Ensure that stat_alarm is not active.
• Confirm that the transceiver settings are correct for the design. Check all errata and
answer records for the transceiver and ensure all patches are applied.
• Confirm that MMCM/PLL settings are correct for the design. Check all errata and
answer records for the MMCM/PLL and ensure all patches are applied.
• Check which silicon is being used, for example is it ES silicon or production? Check all
errata and answer records for the silicon.
• Look at the clk_ok_out and recclk_ok outputs from the core. Are these steady at
logic High? The clocks can be unreliable until this is the case.

175
• Using the debug feature, view the received data and control signals at the output of the
transceiver. If errors are present in the received data, it could indicate an issue with the
link. For 8B/10B line rates the signals of note are rxdata, rxcharisk,
rxchariscomma and rxcharerr in the core suppport layer. For 64B/66B line rates,
along with rxdata, the rxheader and rxheadervalid signals are also of note.
These signals are synchronous to the recovered clock.
• Check the settings for “static configuration interface” inputs to the core and ensure
they meet your design requirements. See Static Configuration Interface.
• Ensure the hfnsync signal is High to confirm hyperframe synchronization has been
achieved
• Confirm that the transmit and receive strobes are exactly 10 ms apart. The strobes at
the slave end of the link should be connected as described in Frame and
Synchronization Interface.
• Set the core into PMA loopback (Write 0x8 to register 0x8 (AXI register 0x20)) and
ensure the core can reach the operational state and data can be sent and received.
AXI4-Lite Interface Debug

Read from a register that does not have all 0s as a default to verify that the interface is
functional.
See Figure 3-68 for a read timing diagram. Output s_axi_arready asserts when the read
address is valid and output s_axi_rvalid asserts when the read data/response is valid. If
the interface is unresponsive ensure that the following conditions are met.
• The s_axi_aclk and aclk inputs are connected and toggling.

• The interface is not being held in reset, and s_axi_areset is an active-Low reset.
• Ensure that the main core clocks are toggling and that the enables are also asserted.
• Has a simulation been run? Verify in simulation and/or a debugging tool to capture that
the waveform is correct for accessing the AXI4-Lite interface.

176
Appendix D
Additional Resources and Legal Notices
Xilinx Resources
For support resources such as Answers, Documentation, Downloads, and Forums, see Xilinx
Support.
References
These documents provide supplemental material useful with this product guide:
1. CPRI Specification v7.0, October 9, 2015

2. 7 Series FPGAs GTX Transceivers User Guide (UG476)
3. 7 Series FPGAs GTP Transceivers User Guide (UG482)
4. UltraScale Architecture GTH Transceivers User Guide (UG576)
5. UltraScale Architecture GTY Transceivers User Guide (UG578)
6. 7 Series FPGAs Clocking Resources User Guide (UG472)
7. Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
8. Vivado Design Suite User Guide: Designing with IP (UG896)
9. Vivado Design Suite User Guide: Getting Started (UG910)
10. Vivado Design Suite User Guide - Logic Simulation (UG900)
11. ISE to Vivado Design Suite Migration Guide (UG911)
12. UltraScale Architecture Migration Methodology Guide (UG1026)
13. Vivado Design Suite User Guide: Programming and Debugging (UG908)
14. IEEE Std. 802.3-2005 (standards.ieee.org/getieee802/)

177
Revision History
The following table shows the revision history for this document.
Date Version Revision

10/05/2016 8.7 • Added rxrecclkout port
• Extended equalization mode and insertion loss parameters for UltraScale
device based cores
• Extended line rate support in 24,330.24 Mb/s capable cores
• Added RS-FEC support for 64b66b line rates in 24.33024 Gb/s capable cores.
• Added GTYE4 support for Zynq UltraScale+ devices.
04/06/2016 8.6 • Added 24,330.24 Mb/s support with a 64-bit datapath option
• Added 12,165.12 Mb/s to Kintex-7, Zynq-7000 and Virtex-7 devices
• Added debug register and enhanced FIFO transit time registers.
11/18/2015 8.5 • Added support for UltraScale+ families.
• Added rxgearboxslip and txusrclk2 signals to Table 3-30.
09/30/2015 8.5 • Added UltraScale Architecture support for 8,110.08 Mb/s and 12,165.12 Mb/s
line rates.
• Updated to use version 1.6 of the UltraScale™ GT Wizard.
• Added transceiver location selection for UltraScale devices.
• Added DRP state machine sequencer for the 7 series FPGA GTs.
• Added IP revision number to the HDL module, library, and include file names,
to support designs with both locked and upgraded IP instances.
• Added separate management reset to cores using the generic management
interface.
• Routed the locked output of the MMCM to the transceiver TXUSERRDY input
in 7 series devices.
• Added FIFO Fill Level register.
• Added insertion loss setting for UltraScale device based cores.
04/01/2015 8.4 • Changed UltraScale™ device 10,137.6 Mb/s implementation to use the
asynchronous gearbox.
• Added a software reset feature.
• Added optional support for real-time vendor-specific data bits in 10.137G line
rates.
• Provided access to all CPRI™ control channels.
• Added support for GTYE3 transceivers in Virtex® UltraScale devices.
• Added Delay through the GTYE3 Transceiver section.
• Added gt_pcsrsvdin to the transceiver debug ports for the UltraScale
device.
• Removed clk_316_in andrefclk2 ports from the UltraScale 10.1G capable
cores.

178
Date Version Revision

10/01/2014 8.3 • Added speed switching to the 10,137.6 Mb/s capable cores
• Added the watchdog timer register
• Added the transceiver data monitor interface
06/04/2014 8.2 • Updated migration appendix with transceiver debug port information
• Added Table 5-2, Vivado IDE Parameter to User Parameter relationship
04/02/2014 8.2 • Added 10,137.6 Mb/s line rate
• Updated the Clocking and Resets section
• Updated the Clock Configuration section
12/18/2013 8.1 • Added UltraScale™ architecture support
• Updated Table 3-26, Table 3-27
• Added Transceiver Debug Interface section
• Added UltraScale Architecture-Based Devices section
• Added Delay through the GTYE3 Transceiver section
• Added Table B-3 and Table B-5
10/02/2013 8.0 • Revision number advanced to 8.0 to align with core version number.
• Added information on core support layer
• Added option to bypass the Ethernet frame buffers
03/20/2013 3.0 • Updated to core version 7.0 and latest Vivado® design tools.
• Removed all ISE® design tools information and related devices (Virtex®-6,
Virtex-5, Spartan®-6)
• Updated Artix®-7 GTPE2 attributes.
12/18/2012 2.0 • Updated to core version 6.1, ISE Design Suite 14.4, and Vivado Design Suite
2012.4.
• Updated Debugging appendix.
• Added use_pll and pll_select signals
• Replaced Interfacing to the Transceivers section with new Serial Interface
section in Chapter 4.
• Updated the DRP Interface section.
• Updated Figures 5-21, 5-22, and 5-23 in Chapter 5.
• Updated screen captures in Chapter 6 and Chapter 8.
• Updated Output Generation section in Chapter 6.
• Added information about XDC files to Chapter 7.
• Replaced cpri_block.vhd with <component_name>.vhd in Chapter 8.
• Renamed some of the .vhd files
• Added demonstration designs for Artix-7 FPGAs and Zynq-7000 devices.
• Added AC701 and ZC706 boards
• Updated Reference Clock Generation section in Appendix C. Added Tables C-5
and C-6.
• Added information on Use 32-bit datapath option.
• Added new signals to Tables 2-21, 2-22, 4-5, and 4-6.
07/25/2012 1.0 Initial Xilinx product guide release. This new product guide is based on ug447
and ds611.

179
Please Read: Important Legal Notices

The information disclosed to you hereunder (the “Materials”) is provided solely for the selection and use of Xilinx products. To the
maximum extent permitted by applicable law: (1) Materials are made available “AS IS” and with all faults, Xilinx hereby DISCLAIMS
ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether
in contract or tort, including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related
to, arising under, or in connection with, the Materials (including your use of the Materials), including for any direct, indirect,
special, incidental, or consequential loss or damage (including loss of data, profits, goodwill, or any type of loss or damage
suffered as a result of any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had
been advised of the possibility of the same. Xilinx assumes no obligation to correct any errors contained in the Materials or to
notify you of updates to the Materials or to product specifications. You may not reproduce, modify, distribute, or publicly display
the Materials without prior written consent. Certain products are subject to the terms and conditions of Xilinx's limited warranty,
please refer to Xilinx's Terms of Sale which can be viewed at http://www.xilinx.com/legal.htm#tos; IP cores may be subject to
warranty and support terms contained in a license issued to you by Xilinx. Xilinx products are not designed or intended to be
fail-safe or for use in any application requiring fail-safe performance; you assume sole risk and liability for use of Xilinx products
in such critical applications, please refer to Xilinx's Terms of Sale which can be viewed at http://www.xilinx.com/legal.htm#tos.
AUTOMOTIVE APPLICATIONS DISCLAIMER
AUTOMOTIVE PRODUCTS (IDENTIFIED AS “XA” IN THE PART NUMBER) ARE NOT WARRANTED FOR USE IN THE DEPLOYMENT OF
AIRBAGS OR FOR USE IN APPLICATIONS THAT AFFECT CONTROL OF A VEHICLE (“SAFETY APPLICATION”) UNLESS THERE IS A
SAFETY CONCEPT OR REDUNDANCY FEATURE CONSISTENT WITH THE ISO 26262 AUTOMOTIVE SAFETY STANDARD (“SAFETY
DESIGN”). CUSTOMER SHALL, PRIOR TO USING OR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE PRODUCTS, THOROUGHLY
TEST SUCH SYSTEMS FOR SAFETY PURPOSES. USE OF PRODUCTS IN A SAFETY APPLICATION WITHOUT A SAFETY DESIGN IS FULLY
AT THE RISK OF CUSTOMER, SUBJECT ONLY TO APPLICABLE LAWS AND REGULATIONS GOVERNING LIMITATIONS ON PRODUCT
LIABILITY.
© Copyright 2012–2016 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated
brands included herein are trademarks of Xilinx in the United States and other countries. CPRI is a trademark of Siemens AG.
AMBA, AMBA Designer, ARM, ARM1176JZ-S, CoreSight, Cortex, PrimeCell, and MPCore are trademarks of ARM in the EU and other
countries. All other trademarks are the property of their respective owners.

180

Pg056-Cpri v87

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Pg056-Cpri v87

Загружено:

Авторское право:

Доступные форматы

CPRI v8.

LogiCORE IP Product Guide

Vivado Design Suite

Chapter 2: Product Specification

Chapter 3: Designing with the Core

Chapter 4: Design Considerations

CPRI v8.7 Send Feedback

Chapter 6: Example Design

Chapter 7: Test Bench

Appendix A: Verification, Compliance, and Interoperability

Appendix B: Migrating and Upgrading

Appendix D: Additional Resources and Legal Notices

CPRI v8.7 Send Feedback

Introduction LogiCORE IP Facts

Features Resources Performance and Resource Utilization web page

Provided with Core

614.4, 1,228.8, 2,457.6, 3,072, 4,915.2, 6,144, Synthesis Vivado Synthesis

9,830.4, and 10,137.6 Mb/s using GTXE2, Support

CPRI v8.7 Send Feedback 4

Figure 1-1: Location of CPRI in a Cellular System

CPRI v8.7 Send Feedback

Table 1-1: Supported Data Rates

CPRI v8.7 Send Feedback

Table 1-1: Supported Data Rates (Cont’d)

Recommended Design Experience

Licensing and Ordering Information

CPRI v8.7 Send Feedback

For more information, visit the CPRI product page.

CPRI v8.7 Send Feedback

CPRI v8.7 Send Feedback

28)1DATA -ANAGEMENT 280ATH

Figure 2-1: CPRI Top-Level Block Diagram

CPRI v8.7 Send Feedback

Chip Period (TC) in This Document

Table 2-1: Client Clock Rates

Line Rate Client Clock Rate (MHz)

CPRI v8.7 Send Feedback

Speed Grade Support

CPRI v8.7 Send Feedback

CPRI Core Structure

Ethernet I/F DRP I/F

Control & Status <component_name>_gt_and_clocks

Quad PLL Ports

CPRI v8.7 Send Feedback

The following blocks are instantiated in the block layer:

• Encrypted RTL. The encrypted RTL of the CPRI IP core.

• Transmit clock logic. In Zynq-7000-based and 7 series-based designs an mixed-mode

Ethernet I/F DRP I/F

Control & Status <component_name>_gt_and_clocks

CPRI v8.7 Send Feedback

Management Register Map

Table 2-2: Management Register Addresses

CPRI v8.7 Send Feedback

Table 2-2: Management Register Addresses (Cont’d)

Status Code and Alarm Register (0x0)

Miscellaneous Status Register (0x1)

CPRI v8.7 Send Feedback

Table 2-4: Miscellaneous Status Register

Current HDLC Rate Register (0x2)

CPRI v8.7 Send Feedback

Current Ethernet Pointer Register (0x3)

Received Subchannel 2, Word 0 Register (0x4)

Received Subchannel 2, Word 1 Register (0x5)

28)1DATA -ANAGEMENT 280ATH