JESD Specifications

JESD204 v7.
LogiCORE IP Product Guide
Vivado Design Suite

PG066 October 4, 2017
Table of Contents
IP Facts
Chapter 1: Overview
Transmitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Core Level Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Unsupported Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Licensing and Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 2: Product Specification

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Resource Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Register Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapter 3: Designing with the Core

General Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Core Overview and Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Clocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Interfacing to the AXI4-Stream Data Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
AXI4-Lite Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Subclass 1 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Subclass 2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
JESD204B Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
JESD204B Transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Link Test Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Sharing Transceivers between Transmit and Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Chapter 4: Design Flow Steps

Customizing and Generating the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Constraining the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
JESD204 v7.2 www.xilinx.com Send Feedback

2
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Synthesis and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Chapter 5: Example Design

Common Design Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Chapter 6: Test Bench
Appendix A: Verification, Compliance, and Interoperability

Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Hardware Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Appendix B: Hardware Demonstration Design
Appendix C: Migrating and Upgrading

Migrating to the Vivado Design Suite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Upgrading in the Vivado Design Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Appendix D: Debugging
Finding Help on Xilinx.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Debug Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Simulation Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Hardware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Interface Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Appendix E: Additional Resources and Legal Notices

Xilinx Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Please Read: Important Legal Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

3
IP Facts
Introduction LogiCORE IP Facts Table

Core Specifics
The Xilinx® LogiCORE™ IP JESD204 core
UltraScale+™, UltraScale™
implements a JESD204B interface supporting Supported
Zynq®-7000 All Programmable SoC,
Device Family(1)
line rates from 1 Gb/s to 12.5 Gb/s (1). The Artix®-7, Virtex®-7, Kintex®-7
JESD204 core can be configured as a Supported User
AXI4-Stream, AXI4-Lite Control/Status
transmitter or receiver.(2) Interfaces
Resources Performance and Resource Utilization web page
Provided with Core

Features Design Files Encrypted RTL
Example Design Verilog

• Designed to JEDEC® JESD204B [Ref 1] Test Bench Verilog
• Supports up to 8 lanes per core and up to Constraints File XDC

32 lanes using multiple cores Simulation
Verilog
Model
• Supports Initial Lane Alignment
Supported
N/A
S/W Driver
• Supports scrambling
Tested Design Flows(2)
• Supports 1–256 octets per frame (3)
Design Entry Vivado® Design Suite
• Supports 1–32 frames per multiframe (3) For supported simulators, see the
Simulation
Xilinx Design Tools: Release Notes Guide.
• Supports Subclass 0, 1, and 2
Synthesis Vivado Synthesis
• Physical and Data Link Layer functions
Support
provided
Provided by Xilinx at the Xilinx Support web page
• AXI4-Lite configuration interface [Ref 2]
Notes:
• AXI4-Stream data interface [Ref 3] 1. For a complete listing of supported devices, see the Vivado IP
catalog.
• Supports transceiver sharing between TX 2. For the supported versions of the tools, see the
Xilinx Design Tools: Release Notes Guide.
and RX cores using the JESD204_PHY core
1. Non-standard line rates up to 16.375 Gb/s are supported.
2. The maximum line rate supported is dependent on the
transceiver type and speed grade of the selected device.
For UltraScale+ devices with GTHE4/GTYE4 transceivers,
the line rate is also limited by the maximum frequency
specified for TXUSRCLK/RXUSERCLK (core clock) with
40-bit Interconnect Logic Data width. For these devices the
maximum line rate is TX/RXusrclk * 40.
Please see the relevant Device Data sheet.
3. The maximum supported multiframe size is 1000 octets
and the minimum is 20 octets.
JESD204 v7.2 www.xilinx.com Send Feedback 4

PG066 October 4, 2017 Product Specification
Chapter 1
Overview
The LogiCORE™ IP JESD204 core implements a JESD204B interface supporting line rates
between 1 and 12.5 Gb/s(1) on 1 to 8 lanes using GTX, GTH, GTP or GTY (UltraScale and
UltraScale+ only) transceivers. See the device data sheets for maximum line rates supported
by each device and family. The JESD204 core can be configured as transmit or receive and
multiple cores can be used to realize links requiring greater than 8 lanes.
The JESD204 core is a fully-verified solution design delivered by using the Xilinx® Vivado®
Design Suite. In addition, an example design is provided in Verilog.
Transmitter
Figure 1-1 shows an overview block diagram for the transmitter of the JESD204 core.
X-Ref Target - Figure 1-1
JESD204 Transmitter Core
TX Lane(s)
Alignment
Character JESD204_PHY
Generator
AXI4-Stream Scrambler JESD204
Text
Lane Serial Data
Text
Alignment
Sequence
RPAT
Generator
Sync/SYSREF TX Counters
JSPAT
Generator
AXI4-Lite AXI4-Lite/IPIF
Control Registers
Figure 1‐1: Transmitter Core Overview
1. Non-standard line rates up to 16.375 Gb/s are supported.

5
Chapter 1: Overview
The main blocks are:
• Single AXI4-Stream interface for all lanes

• TX lane logic, per lane, contains:
° Scrambling
° Alignment character insertion logic
° Initial Lane Alignment (ILA) sequence generation
• TX Counters – control, state machine and SYNC/SYSREF interface
• JESD204_PHY containing the transceivers
• RPAT generator
• JSPAT generator
• AXI4-Lite Management interface and control/status registers
Receiver
Figure 1-2 shows an overview block diagram for the receiver of the JESD204 core.
-(6'5HFHLYH&RUH
5;/DQH V
JESD204_PHY
7H[W
7H[W 5HSODFH
JESD204 'HVFUDPEOHU $OLJQPHQW
'DWD
Serial Data $;,6WUHDP
'HFRGH/DQH
$OLJQPHQW
6HTXHQFH
/LQN
(UURU
&RXQWHU
/0)&DQG
6<65() 6\QF
6WDWXV
$;,/LWH $;,/LWH,3,)
&RQWURO 5HJLVWHUV
Figure 1‐2: Receiver Core Overview
The main blocks are:
• Single AXI4-Stream interface for all lanes

• RX lane logic, per lane, contains:
° ILA capture
° Descrambling
° Alignment character detection and replacement logic

6
Chapter 1: Overview
• Local Multiframe Clock (LMFC) state machine and SYNC/SYSREF interface

• JESD204_PHY containing the transceivers
• Error counters for each lane
• AXI4-Lite Management interface and control/status registers
Core Level Architecture

The JESD204 core is delivered by the Vivado Design Suite with supporting wrapper files.
Either a JESD204B transmitter core or a JESD204B receiver core can be selected for
generation using the Vivado IDE.
Core-level Verilog wrappers are provided to instantiate the JESD204 IP, the clock/reset logic,
Management block, the JESD204_PHY transceiver, the JSPAT and RPAT pattern generator
blocks, and the Error Counting blocks depending on whether the core is a transmitter or a
receiver. The core support layer, delivered with the example design, is intended for
instantiation in simple unidirectional designs.
The Management block provides core Control and Status registers with a standard AXI4-Lite
interface. The RPAT and JSPAT blocks are optional test pattern generators which can be
included in a TX core. Link Error counter blocks are included in a receiver core to support
data link layer test modes and link status monitoring.
A Verilog example design is provided which instantiates the core-level wrapper, together
with example interface modules. This is a device-level design and can be used to run the
core through the Xilinx tool flow, but is not intended to be used directly in customer
designs.
The transmit and receive logic is completely independent; a core can be generated as a
transmitter or a receiver. The core can be generated with the JESD204 PHY, instantiated
either:
• Inside the core for basic simplex applications
or
• Inside the example design for applications that require sharing the transceivers with
other JESD204 cores (e.g., TX and RX sharing transceivers) or access to the extended
features available using JESD204 PHY AXI-lite register interface (see Shared Logic Tab).

7
Chapter 1: Overview
Applications
JESD204 is a high-speed serial interface designed to connect Analog-to-Digital Converter
(ADCs) and Digital-to-Analog Converter (DACs) to logic devices. The JESD204 interface is
specified in the JEDEC® JESD204B Specification [Ref 1]. Figure 1-3 and Figure 1-4 show how
the JESD204 provides the interface between an ADC/DAC and user logic over an example
four lane interface.
ADC Device FPGA

4 Lanes
JESD204B RX
JESD204B TX
ADC
User
Logic
ADC
x12138
Figure 1‐3: Example ADC Application

FPGA DAC Device

4 Lanes
JESD204B RX
JESD204B TX
DAC
User
Logic
DAC
x12139
Figure 1‐4: Example DAC Application
Unsupported Features
Sample data mapping/demapping is not provided by the core, because of the requirement
that it be customized for different converter devices. For more information, see Interfacing
to the AXI4-Stream Data Interface.

8
Chapter 1: Overview
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 checkpoints 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 synthesis
• Vivado implementation
• write_bitstream (Tcl command)
IMPORTANT: IP license level is ignored at checkpoints. The test confirms a valid license exists. It does
not check IP license level.
License Type
This Xilinx LogiCORE IP module is provided under the terms of the Xilinx Core License
Agreement. The module is shipped as part of the Vivado Design Suite. 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.
For more information, visit the JESD204 product web page.
Information about 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.
A free evaluation version of the core is provided with the Xilinx Vivado Design Suite which
lets you assess the core functionality and demonstrates the various interfaces of the core in
simulation. To access the evaluation version visit the JESD204 IP Evaluation page.

9
Chapter 1: Overview
License Options
The JESD204 core provides three licensing options. After installing the Vivado Design Suite
and the required IP Service Packs, choose a license option.
Simulation Only
The Simulation Only Evaluation license key is provided with the Xilinx Vivado Design Suite.
This key lets you assess core functionality with either the example design provided with the
JESD204 core, or alongside your own design and demonstrates the various interfaces to the
core in simulation. (Functional simulation is supported by a dynamically generated HDL
structural model.)
Full System Hardware Evaluation

The Full System Hardware Evaluation license is available at no cost and lets you fully
integrate the core into an FPGA design, place-and-route the design, evaluate timing, and
perform functional simulation of the JESD204 core using the example design and
demonstration test bench provided with the core.
In addition, the license key lets you generate a bitstream from the placed and routed
design, which can then be downloaded to a supported device and tested in hardware. The
core can be tested in the target device for a limited time before timing out (ceasing to
function), at which time it can be reactivated by reconfiguring the device.
Full
The Full license key is available when you purchase the core and provides full access to all
core functionality both in simulation and in hardware, including:
• Gate-level functional simulation support

• Back annotated gate-level simulation support
• Functional simulation support
• Full-implementation support including place and route and bitstream generation
• Full functionality in the programmed device with no time-outs

10
Chapter 1: Overview
Obtaining Your License Key

This section contains information about obtaining a simulation, full system hardware, and
full license keys.
Simulation License
No action is required to obtain the Simulation Only Evaluation license key; it is provided by
default with the Xilinx Vivado Design Suite.
Full System Hardware Evaluation License

To obtain a Full System Hardware Evaluation license, perform these steps:
1. Navigate to the JESD204 product page for this core.

2. Click Evaluate.
3. Follow the instructions on the page.
Obtaining a Full License

To obtain a Full license key, you must purchase a license for the core. After doing so, click
the “Access Core” link on the xilinx.com IP core product page for further instructions.
Installing Your License File

The Simulation only Evaluation license key is provided with the Vivado Design Suite and
does not require installation of an additional license file. For the Full System Hardware
Evaluation license and the Full license, an email will be sent to you containing instructions
for installing your license file. Additional details about IP license key installation can be
found in the Vivado Design Suite Installation, Licensing and Release Notes document.

11
Chapter 2
Product Specification
The JESD204 core supports JESD204B. The original JESD204 specification defined a serial
link between one data converter and a logic device. The link was made up of one lane.
Revisions A and B extend this to cover multiple converters, each linked to the logic device
using multiple lanes. See Figure 2-1.
*%3$ VERSION *%3$ REVISION ! AND "

/NE MULTIPOINT LINK
!LL LANES ALIGNED
3IMILAR
CONVERTERS LINK
, LANES
-
,OGIC CONVERTERS ,OGIC
$EVICE $EVICE
&0'! OR LINK &0'! OR
LANE
!3)# , LANES !3)#
- LINK -
CONVERTERS CONVERTERS
8
Figure 2‐1: System Overview
Standards
JEDEC® Serial Interface for Data Converters (JESD204B) available from www.jedec.org.
Performance
For details about performance, visit the Performance and Resource Utilization web page.
Resource Utilization
For details about resource utilization, visit the Performance and Resource Utilization web
page.

12
Port Descriptions
The port descriptions for the JESD204 core are described in the following sections.
Clock and Reset Ports – TX Core

The clock and reset ports available on the delivered core component depend on the Shared
Logic selection when customizing the core; see Table 2-1 or Table 2-2.
Table 2‐1: TX Core: Clock and Reset Ports – Shared Logic in Example Design
Signal Name Direction Description
Core logic clock input.
tx_core_clk In
Frequency = serial line rate/40.
tx_reset In Core asynchronous logic reset.
JESD204_PHY TX datapath reset output. Core output to reset the
tx_reset_gt Out
transmit datapath in a connected JESD204B_PHY.
JESD204_PHY reset done input. Indicates the JESD204B_PHY has
tx_reset_done In
completed the transmit reset process.
AXI4-Stream reset. Active-Low. Associated with the transmit data
tx_aresetn Out
interface.
s_axi_aclk In AXI4-Lite clock. Associated with the management interface.
AXI4-Lite reset. Active-Low. Associated with the management
s_axi_aresetn In
interface.
Table 2‐2: TX Core: Clock and Reset Ports – Shared Logic in Core
Differential transceiver reference clock input.
refclk_p/refclk_n In
Reference clock for the transceiver(s) and Quad Common PLL(s)
Differential core logic clock input. Additional global logic clock
required for Subclass 1 or Subclass 2 operation where the
glblclk_p/glblclk_n In reference clock cannot be used for the synchronous capture of
SYSREF or SYNC.
Frequency = serial line rate/40. (See Clocking)(1)
Core logic clock input.
tx_core_clk In
Frequency = serial line rate/40(2)
Dynamic Reconfiguration Port (DRP) clock. A free-running DRP
drpclk In
clock is required for UltraScale architecture-based devices.
Clock output from the QPLL (Quad 0) associated with serial lanes
common0_pll_clk_out Out
0–3. This port is only present when using QPLL.
Reference Clock output from the QPLL (Quad 0) associated with
common0_pll_refclk_out Out
serial lanes 0–3. This port is only present when using QPLL.

13
Table 2‐2: TX Core: Clock and Reset Ports – Shared Logic in Core (Cont’d)
Clock Lock output from the QPLL (Quad 0) associated with serial
common0_pll_lock_out Out lanes 0–3. This port is only present when using QPLL.
• 1 = Indicates that the QPLL is locked
common1_pll_clk_out Out 4–7. This port is only present for configurations with 5 to 8 lanes
and QPLL is selected.
common1_pll_refclk_out Out serial lanes 4–7. This port is only present for configurations with 5
to 8 lanes.
lanes 4–7. This port is only present for configurations with 5 to 8
common1_pll_lock_out Out
lanes and QPLL is selected.
• 1 = Indicates that the QPLL is locked.
Core logic clock output.
tx_core_clk_out Out
Frequency = serial line rate/40
AXI4-Stream reset. Active-Low. Associated with the transmit data
tx_aresetn Out
interface.
s_axi_aresetn In
interface.
1. Port available on 7 Series devices only.
2. Port available on UltraScale devices only.

14
Clock and Reset Ports – RX Core

The clock and reset ports available on the delivered core component depend on the Shared
Logic selection when customizing the core; see Table 2-3 or Table 2-4.
Table 2‐3: RX Core: Clock and Reset Ports – Shared Logic in Example Design
Core logic clock.
rx_core_clk In
rx_reset In Core asynchronous logic reset.
JESD204_PHY RX datapath reset output. Core output to reset the
rx_reset_gt Out
receive datapath in a connected JESD204B_PHY.
JESD204_PHY reset done input. Indicates the JESD204B_PHY has
rx_reset_done In
completed the receive reset process.
AXI4-Stream reset. Active-Low. Associated with the receive data
rx_aresetn Out
interface.
s_axi_aresetn In
interface.
Table 2‐4: RX Core: Clock and Reset Ports – Shared Logic in Core
Differential transceiver reference clock input. Reference clock for
refclk_p/refclk_n In
the transceiver(s) and Quad Common PLL(s).
Differential core logic clock input. Additional global logic clock
required for Subclass 1 or Subclass 2 operation where the
glblclk_p/glblclk_n In reference clock cannot be used for the Synchronous capture of
SYSREF or SYNC.
Frequency = serial line rate/40. (See Clocking).(1)
Core logic clock.
rx_core_clk In
Frequency = serial line rate/40(2)
DRP clock. A free-running DRP clock is required for UltraScale
drpclk In
architecture-based devices.
common0_pll_clk_out Out
0–3. This port is present only when QPLL is selected.
common0_pll_refclk_out Out
serial lanes 0–3. This port is present only when QPLL is selected.
Clock lock output from the QPLL (Quad 0) associated with serial
common0_pll_lock_out Out lanes 0–3. This port is present only when QPLL is selected.
• 1 = Indicates that the QPLL is locked
common1_pll_clk_out Out 4–7. This port is only present for configurations with 5 to 8 lanes
and QPLL is selected.
common1_pll_refclk_out Out serial lanes 4–7. This port is only present for configurations with 5
to 8 lanes and QPLL is selected.

15
Table 2‐4: RX Core: Clock and Reset Ports – Shared Logic in Core (Cont’d)
common1_pll_lock_out Out lanes 4–7. 1 = Indicates that the QPLL is locked. This port is only
present for configurations with 5 to 8 lanes and QPLL is selected.
Core logic clock output.
rx_core_clk_out Out
AXI4-Stream reset. Active-Low. Associated with the RX data
rx_aresetn Out
interface.
s_axi_aresetn In
interface.
1. Port available on 7 Series devices only.
2. Port available on UltraScale devices only.
JESD204 PHY and Transceiver Interface Ports – TX Core

The JESD204 PHY and transceiver ports available on the delivered core component depend
on the Shared Logic selection when customizing the core; see Table 2-5 or Table 2-6.
Table 2‐5: TX Core: JESD204 PHY Interface Ports – Shared Logic in Example Design
gtN_txdata[31:0] Out TX data to JESD204 PHY. N = Lanes - 1
gtN_txcharisk[3:0] Out TX Char is K to JESD204 PHY. N = Lanes - 1
TX PRBS generator test pattern control to transceivers. Number of
gt_prbssel_out[X:0] Out bits (X) varies by transceiver type. Refer to the relevant transceiver
documentation for further details.
Table 2‐6: TX Core: Transceiver Interface Ports – Shared Logic in Core

Positive differential serial data output
txp[N:0] Out
N = (Lanes - 1)
Negative differential serial data output
txn[N:0] Out
N = (Lanes - 1)
JESD204 PHY and Transceiver Interface Ports – RX Core

The JESD204 PHY and transceiver ports available on the delivered core component depend
on the Shared Logic selection when customizing the core; see Table 2-7 or Table 2-8.
Table 2‐7: RX Core: JESD204 PHY Interface Ports – Shared Logic in Example Design
gtN_rxdata[31:0] In RX data from JESD204 PHY. N = 0 to (Lanes - 1)
gtN_rxcharisk[3:0] In RX Char is K from JESD204 PHY. N = Lanes - 1

16
Table 2‐7: RX Core: JESD204 PHY Interface Ports – Shared Logic in Example Design (Cont’d)
gtN_rxdisperr[3:0] In RX disparity error from JESD204 PHY. N = Lanes - 1
gtN_rxnotintable[3:0] In RX Not In Table from JESD204 PHY. N = Lanes - 1
rxencommalign_out Out RX enable comma alignment to JESD204 PHY
Table 2‐8: RX Core: Transceiver Interface Ports – Shared Logic in Core

Positive differential serial data input
rxp[N:0] In
N = (Lanes - 1)
Negative differential serial data input
rxn[N:0] In
N = (Lanes - 1)
Transmit Data Interface – TX Core

Note: This interface is clocked by the port tx_core_clock.
Table 2‐9: Transmit Data Interface
AXI4-Stream Interface Signals (Transmit Only)
tx_aresetn Out Active-Low reset (shared by all lanes)
AXI transmit data (samples and control words); transmitted least
significant byte first.
tx_tdata[(32*N)-1:0] In Data for Serial Lane 0 on tx_tdata[31:0]
Data for Serial Lane 1 on tx_tdata[63:32]
...
Data for Serial Lane N on tx_tdata[((N + 1) × 32) - 1:(N × 32))]
tx_tready Out AXI slave ready for data
Non-AXI Data Interface Signals (Transmit Only)
Frame boundary indication. The signal is 4 bits to indicate the byte
position of the first byte of a frame in tdata in the following clock
cycle.
• When start_of_frame = 0001, the first byte of a frame is in bits
[7:0] of the tdata word with the next 3 bytes in bits[31:8].
• When start_of_frame = 0010, the first byte is in bits [15:8] of the
tdata word with the next 2 bytes in bits[31:16]; bits [7:0] contain
the end of the previous frame.
tx_start_of_frame[3:0] Out • When start_of_frame = 0100, the first byte is in bits [23:16] of
the tdata word with the next byte in bits[31:24]; bits [15:0]
contain the end of the previous frame.
• When start_of_frame = 1000, tdata contains the last 3 bytes of
the previous frame in bits [23:0] and the first byte of a new frame
in bits [31:24].
Note: Multiple bits of tx_start_of_frame can be asserted in the
same cycle, depending on the number of octets per frame (for
example, for F = 1, tx_start_of_frame = 1111)

17
Table 2‐9: Transmit Data Interface (Cont’d)

tx_start_of_multiframe Multi-frame boundary indication. The position of the first byte of
Out
[3:0] each multiframe is encoded in the same way as start_of_frame.
SYSREF input. When Subclass 1 mode is selected, this signal is
required and used by the core. JESD204B specifies a SYSREF signal
tx_sysref In must be generated synchronous to the core clock (see Clocking for
details). This input should be driven from an external device
generating SYSREF for both TX and RX.
Sync signal. The sync signal is defined as an active-Low sync
tx_sync (1) In request signal by JESD204 so this signal is Low until comma
alignment is completed and High to request ILA and normal data.
Notes:
1. See the JEDEC JESD204 specifications [Ref 1] for details of this signal.

18
Figure 2-2 shows the timing of tx_start_of_frame and tx_start_of_multiframe

relative to the AXI data. tx_start_of_frame and tx_start_of_multiframe are fixed
at four bits wide because the internal data width of each lane is 32 bits and the start of
frame (or multiframe) can occur in any of the 4-byte positions of the 32-bit word. For
multi-lane configurations, the start of frame (or multiframe) signal indicates the byte
position of the first byte of a frame in tx_tdata[31:0], tx_tdata[63:32],
tx_tdata[95:64], etc.
Note: tx_tdata transfers the JESD204B transport layer - not raw converter samples. Refer to the
appropriate converter datasheet for information on correctly mapping samples into the transport
layer.
For example, in a four lane configuration when tx_start_of_frame = 0001 the first byte
of four new frames appears in tx_tdata in a single cycle, tx_tdata[7:0],
tx_tdata[39:32], tx_tdata[71:64], and tx_tdata[103:96].
TX?CORE?CLK
TX?TREADY
TX?TDATA;= $$$$ $$$$ $$$$ $$$$ $$$$ $$$$ $$$$ $$$$ $$$$ $$$$
TX?START?OF?FRAME;=
TX?START?OF?MULTIFRAME;=
Figure 2‐2: Transmit Data Interface Timing for F = 8 and K = 4
Receive Data Interface – RX Core

Note: This interface is clocked by the port rx_core_clock.
Table 2‐10: Receive Data Interface
AXI4-Stream Interface Signals (RX Only)
rx_aresetn Out Active-Low reset (shared by all lanes)
AXI receive data (samples and control words). Data in least
significant byte was received first.
Data from Serial Lane 0 on rx_tdata[31:0]
rx_tdata[(32*N)-1:0] Out Data from Serial Lane 1 on rx_tdata[63:32]
...
Data from Serial Lane N on rx_tdata[((N + 1) × 32) - 1:(N ×
32))]
rx_tvalid Out AXI receive data valid
Non-AXI Data Interface Signals (RX Only)

19
Table 2‐10: Receive Data Interface (Cont’d)

Frame boundary indication. The position of the first byte in a
frame is encoded in the same way as tx_start_of_frame[3:0].
This signal is asserted one cycle before the AXI4-Stream data.
rx_start_of_frame[3:0] Out
The alignment of the very first valid byte is always in byte 0 if
the multiframe size is a multiple of 4 and rx_buffer_delay is a
multiple of 4.
Frame boundary indication. The position of the last byte in a
rx_end_of_frame[3:0] Out
frame is encoded in the same way as start_of_frame.
Multi-frame boundary indication. The position of the first byte
rx_start_of_multiframe[3:0] Out of each multiframe is encoded in the same way as
start_of_frame.
Multi-frame boundary indication. The position of the last byte
rx_end_of_multiframe[3:0] Out of each multiframe is encoded in the same way as
start_of_frame.
Error in byte. JESD204 specifies that data must be replicated
from the previous frame if certain errors occur. The core does
not buffer the previous frame. You can choose to implement a
frame buffer or use a buffer elsewhere in the system to
perform this function if required. The rx_frame_error signal
indicates that a single byte error exists in the data stream.
rx_frame_error There is one bit for each byte of each AXI stream. For example,
Out
[(LANES*4)-1:0] a four lane interface has four 32-bit AXI streams, the error
signal is 16 bits wide with bit 15 of the error signal
corresponding to the most significant byte of lane 4 and bit 0
of the error signal corresponding to the least significant byte
of lane 1. This signal is synchronous to rx_core_clk and output
in the cycle before the data in the same way as
rx_start_of_frame.
Sync signal. The sync signal is defined as an active-Low sync
request signal by JESD204 so this signal is Low until comma
rx_sync Out
alignment is completed and High to indicate the receiver is
ready for ILA and normal data.
SYSREF Input. When Subclass 1 mode is selected, this signal is
required and used by the core. JESD204B specifies that a
SYSREF signal must be generated synchronous to the core
rx_sysref In
clock (see Clocking for details). This input should be driven
from an external device generating SYSREF for both TX and
RX.
Figure 2-3 and Figure 2-4 show the timing of rx_start_of_frame and rx_end_of_frame
relative to the AXI data. rx_start_of_frame and rx_start_of_frame are fixed at 4
bits wide because the internal data width of each lane is 32 bits and the start (or end) of
frame can occur in any of the 4-byte positions of the 32-bit word. For multi-lane
configurations the start (or end) of frame signal indicates the byte position of the first byte
of a frame in rx_tdata[31:0], rx_tdata[63:32], rx_tdata[95:64], etc.

20
For example, in a four lane configuration when rx_start_of_frame = 0001 the first byte
of four new frames appears in rx_tdata in a single cycle, rx_tdata[7:0],
rx_tdata[39:32], rx_tdata[71:64], and rx_tdata[103:96].
Note: rx_tdata transfers the JESD204B transport layer - not raw converter samples. Refer to the
appropriate converter datasheet for information on correctly mapping samples from the transport
layer.
RX?CORE?CLK
RX?TVALID
RX?TDATA;= $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $
RX?START?OF?FRAME;=
RX?END?OF?FRAME;=
&RAME 3IZE
Figure 2‐3: Receive Data Interface Timing for F = 8

RX?CORE?CLK
RX?TVALID
RX?TDATA;= $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $
RX?START?OF?FRAME;=
RX?END?OF?FRAME;=
&RAME 3IZE
Figure 2‐4: Receive Data Interface Timing for F = 7

21
Management Interface (AXI4-Lite)

Also, see the Xilinx Vivado AXI Reference Guide (UG1037) [Ref 16] for AXI4-Lite interface
information.
Table 2‐11: Management Interface (AXI4-Lite)

s_axi_aclk In Clock
s_axi_aresetn In Active-Low reset
s_axi_awaddr[11:0] In Write Address
s_axi_awvalid In Write Address Valid
s_axi_awready Out Write Address Ready
s_axi_wdata[31:0] In Write Data
s_axi_wstrb[3:0] In Write Data Byte Strobe
s_axi_wvalid In Write Data Valid
s_axi_wready Out Write Data Ready
s_axi_bresp[1:0] Out Write Response (Always = 00 = OK)
s_axi_bvalid Out Write Response Valid
s_axi_bready In Write Response Ready
s_axi_araddr[11:0] In Read Address
s_axi_arvalid In Read Address Valid
s_axi_arready Out Read Address Ready
s_axi_rdata[31:0] Out Read Data
s_axi_rresp[1:0] Out Read Response (Always = 00 = OK)
s_axi_rvalid Out Read Data Valid
s_axi_rready In Read Data Ready
Transceiver Debug Interface

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 2-12 and Table 2-13 might
result in unpredictable behavior of the IP core.
The transceiver debug interface (when present) provides access to transceiver control and
status pins for debug purposes. See the appropriate transceiver user guide (UltraScale
Architecture GTH Transceivers User Guide (UG576) [Ref 6], UltraScale Architecture GTY
Transceivers User Guide (UG578) [Ref 7], 7 Series FPGAs GTX/GTH Transceivers User Guide
(UG476) [Ref 8], or 7 Series FPGAs GTP Transceivers User Guide (UG482) [Ref 9]) for a
detailed description of these pins. This interface is only present on the core when Include

22
Shared Logic in core and Additional transceiver control and status ports options are
selected when generating the core.
Table 2‐12: Optional Transceiver Debug Ports (7 Series Devices)

Signal Name(1)(2) Direction Clock Domain Description
gtN_drpaddr [8:0] In drp_clk DRP Address Bus
Data bus for writing configuration data from the FPGA
gtN_drpdi [15:0] In drp_clk
logic resources to the transceiver
DRP Enable Signal
gtN_drpen In drp_clk 0: No read or write operation performed
1: Enables a read or write operation
DRP Write Enable
gtN_drpwe In drp_clk 0: Read operation when DEN is 1
1: Write operation when DEN is 1
Data bus for reading configuration data from the GTX/
gtN_drpdo [15:0] Out drp_clk
GTH transceiver to the FPGA logic resources
Indicates operation is complete for write operations and
gtN_drprdy Out drp_clk
data is valid for read operations
Transceiver Loopback:
• 000: No loopback
• 001: Near-End PCS Loopback
loopback[2:0] In Async
• 010: Near-End PMA Loopback
• 100: Far-End PMA Loopback
• 110: Far-End PCS Loopback
gtN_txpostcursor[4:0] In tx_core_clock Transmit Differential Driver control. (TX only)
gtN_txpresursor[4:0] In tx_core_clock Transmit Differential Driver control. (TX only)
gtN_txdiffctrl[3:0] In Async Transmit Differential Driver control. (TX only)
gtN_txpolarity In tx_core_clock Transmit polarity control. (TX only)
Copy of raw transceiver data bus between core and
gt_txdata[X:0] Out tx_core_clock
transceiver, width depends on number of lanes. (TX only)
Copy of raw transceiver charisk bus between core and
gt_txcharisk[Y:0] Out tx_core_clock
transceiver, width depends on number of lanes. (TX only)
gtN_rxpolarity In rx_core_clock Receive polarity control. (RX only)
Copy of raw transceiver data bus between core and
gt_rxdata[X:0] Out rx_core_clock
transceiver, width depends on number of lanes. (RX only)
Copy of raw transceiver charisk bus between core and
gt_rxcharisk[Y:0] Out rx_core_clock
transceiver, width depends on number of lanes. (RX only)
Copy of raw transceiver disparity error bus between core
gt_rxdisperr[Y:0] Out rx_core_clock and transceiver, width depends on number of lanes. (RX
only)
Copy of raw transceiver not-in-table error bus between
gt_rxnotintable[Y:0] Out rx_core_clock core and transceiver, width depends on number of lanes.
(RX only)

23
Table 2‐12: Optional Transceiver Debug Ports (7 Series Devices) (Cont’d)

Active-High signal indicating that the channel PLL has
gtN_cplllock_out Out Async
locked to the input reference clock
gtN_eyescandataerror_out Out Async Asserted when an EYESCAN error occurs
This port is pulsed High to initiate the EYESCAN reset
gtN_eyescanreset_in In Async
process
gtN_eyescantrigger_in In rx_core_clock A High on this port causes an EYESCAN trigger event
This port is driven High and then deasserted to start the
gtN_rxbufreset_in In Async
RX elastic buffer reset process.
gtN_rxbufstatus_out[2:0] Out rx_core_clock RX Elastic Buffer Status
gtN_rxbyteisaligned_out Out rx_core_clock RX Byte Alignment Status
gtN_rxbyterealign_out Out rx_core_clock RX Byte Alignment has changed
gtN_rxcdrhold_in In Async Hold the CDR control loop frozen
gtN_rxcommadet_out Out rx_core_clock RX Comma Detect Out
gtN_rxdfelpmreset_in In Async DFE Reset
gtN_rxlpmen_in In Async LPM Mode Enable
gtN_rxmonitorout_out Out Async RX Monitor Out
gtN_rxmonitorsel_in In Async RX Monitor Out Mode Select
gtN_rxpcsreset_in In Async PCS Reset
gtN_rxpd_in[1:0] In Async RX Power Down
gtN_rxpmareset_in In Async PMA Reset
gtN_rxprbscntreset_in In rx_core_clock RX PRBS Counter Reset
gtN_rxprbserr_out Out rx_core_clock RX PRBS Error Detect
gtN_rxprbssel_in In rx_core_clock RX PRBS Select
gtN_rxresetdone_out Out rx_core_clock RX Reset Done
gtN_rxstatus_out[2:0] Out rx_core_clock Encodes RX Status and Error Codes
gtN_txbufstatus_out[1:0] Out tx_core_clock TX Elastic Buffer Status
gtN_txpcsreset_in In Async TX PCS Reset
gtN_txinhibit In tx_core_clock TX Inhibit
gtN_txpd_in In tx_core_clock TX Power Down
gtN_txpmareset_in In Async TX PMA Reset
gtN_txprbsforceerr_in In tx_core_clock TX PRBS Force Error
gtN_txresetdone_out Out tx_core_clock TX Reset Done
gtN_rxlpmhfhold_in In rx_core_clock (GTP Only) LPM Mode Control
gtN_rxlpmhfoverden_in In rx_core_clock (GTP Only) LPM Mode Control

24
Table 2‐12: Optional Transceiver Debug Ports (7 Series Devices) (Cont’d)

gtN_rxlpmlfhold_in In rx_core_clock (GTP Only) LPM Mode Control
Notes:
1. N is the number of the transceiver channel.
2. If you are migrating from a 7 series to an UltraScale architecture-based device, the prefixes of the optional transceiver debug
ports for single-lane cores are changed from gt0, gt1 to gt, and the postfix _in and _out are dropped. For multi-lane
cores, the prefixes of the optional transceiver debug ports gt(n) are aggregated into a single port (see Table 2-13).
Table 2‐13: Optional Transceiver Debug Ports (UltraScale Architecture-Based Devices)

Signal Name(1) Direction Clock Domain Description
DRP Address Bus
gtN_drpaddr [8:0] In drp_clk
Note: GTH=[8:0], GTY=[9:0]
Data bus for writing configuration data from the FPGA logic
gtN_drpdi [15:0] In drp_clk
resources to the transceiver
DRP Enable Signal
gtN_drpen In drp_clk 0: No read or write operation performed
1: Enables a read or write operation
DRP Write Enable
gtN_drpwe In drp_clk 0: Read operation when DEN is 1
1: Write operation when DEN is 1
Data bus for reading configuration data from the GTX/GTH
gtN_drpdo [15:0] Out drp_clk
transceiver to the FPGA logic resources
Indicates operation is complete for write operations and
gtN_drprdy Out drp_clk
data is valid for read operations
gt_txpmareset
In Async Port is pulsed High to start the TX PMA reset process
[(LANES-1):0]
gt_txpcsreset
In Async Port is pulsed High to start the TX PCS reset process
[(LANES-1):0]
gt_txresetdone A High on this port indicates that the TX reset process has
Out tx_core_clock
[(LANES-1):0] completed
gt_rxpmareset
In Async Port is pulsed High to start the RX PMA reset process
[(LANES-1):0]
gt_rxpcsreset
In Async Port is pulsed High to start the RX PCS reset process
[(LANES-1):0]
gt_rxbufreset Port is driven High and then deasserted to start the RX
In Async
[(LANES-1):0] elastic buffer reset process
gt_rxpmaresetdone A High on this port indicates that the RX PMA reset process
Out Async
[(LANES-1):0] has completed
gt_rxresetdone A High on this port indicates that the RX reset process has
Out rx_core_clock
[(LANES-1):0] completed
gt_txbufstatus
Out tx_core_clock Elastic Buffer Status
[(LANES*2)-1:0]

25
Table 2‐13: Optional Transceiver Debug Ports (UltraScale Architecture-Based Devices) (Cont’d)
gt_rxbufstatus
Out rx_core_clock RX Elastic Buffer Status
[(LANES*3)-1:0]
gt_cplllock Active-High signal indicating that the channel PLL has
Out refclk
[(LANES-1):0] locked to the input reference clock
gt_rxrate
In rx_core_clock Link signaling rate control
[(LANES*3)-1:0]
gt_eyescantrigger
In rx_core_clock A High on this port causes an EYESCAN trigger event
[(LANES-1):0]
gt_eyescanreset
In Async Port is pulsed High to initiate the EYESCAN reset process
[(LANES-1):0]
gt_eyescandataerror
Out Async Asserted when an EYESCAN error occurs
[(LANES-1):0]
Transceiver Loopback:
• 000: No loopback
gt_loopback • 001: Near-End PCS Loopback
In Async
[(LANES*3)-1:0] • 010: Near-End PMA Loopback
• 100: Far-End PMA Loopback
• 110: Far-End PCS Loopback
gt_rxpolarity
In rx_core_clock Set High to invert the incoming serial data
[(LANES-1):0]
gt_txpolarity
In tx_core_clock Set High to invert the outgoing serial data
[(LANES-1):0]
gt_rxdfelpmreset
In Async Reset for the LPM and DFE datapath
[(LANES-1):0]
gt_rxlpmen
In Async Set to 1 to select the LPM datapath
[(LANES-1):0]
gt_txprecursor
In tx_core_clock Transmitter pre-cursor pre-emphasis control
[(LANES*5)-1:0]
gt_txpostcursor
In tx_core_clock Transmitter post-cursor pre-emphasis control
[(LANES*5)-1:0]
gt_txdiffctrl
In Async Driver swing control
[(LANES*4)-1:0]
gt_txprbsforceerr
In tx_core_clock Set High to drive errors into the PRBS transmitter
[(LANES-1):0]
gtN_txinhibit In tx_core_clock TX Inhibit
gt_pcsrsvdin
In Async DRP Reset (Bits 2, 18, 34,....)
[(LANES*16)-1:0]
gt_txprbssel
In tx_core_clock Transmitter PRBS generator test pattern control
[(LANES*4)-1:0]
gt_rxprbssel
In rx_core_clock Receiver PRBS checker test pattern control
[(LANES*4)-1:0]

26
Table 2‐13: Optional Transceiver Debug Ports (UltraScale Architecture-Based Devices) (Cont’d)
gt_rxprbserr
In rx_core_clock A High on this port indicates that PRBS errors have occurred
[(LANES-1):0]
gt_rxprbscntreset
In rx_core_clock Reset the PRBS error counter
[(LANES-1):0]
gt_rxcdrhold
In Async Hold the CDR control loop frozen
[(LANES-1):0]
gt_dmonitorout
Out Async Digital Monitor Output Bus
[(LANES*15-1):0]
gt_rxdisperr
Out rx_core_clock Receiver disparity error indicator
[(LANES*4-1):0]
gt_rxnotintable
Out rx_core_clock Receiver not in table error indicator
[(LANES*4-1):0]
gt_rxcommadet A High on this port indicates that the comma alignment
Out rx_core_clock
[(LANES-1):0] block has detected a valid comma
RX Power Down
gt_rxpd [(LANES*2-1):0] In Async 00=Normal Operation
11=Lowest power mode
TX Power Down
gt_txpd [(LANES*2-1):0] In tx_core_clock 00=Normal Operation
11=Lowest power mode
Notes:
1. N is the number of the transceiver channel.
Register Space
The JESD204 core is configured using an AXI4-Lite Register Interface. The register map is
shown in Table 2-14.
The RX and TX cores share a common address map and register definitions where possible,
exceptions are highlighted.
RECOMMENDED: Xilinx recommends that if significant configuration changes are made using the
control registers (in particular, changes to framing parameters), the core should be reset to ensure that
the link is resynchronized using the updated parameters.
Table 2‐14: Register Address Map

RX Core Registers TX Core Registers
Address Offset Description R/W Description R/W
0x000 Version R Version R
0x004 Reset R/W Reset R/W

27
Table 2‐14: Register Address Map (Cont’d)

0x008 ILA Support R/W ILA Support R/W
0x00C Scrambling R/W Scrambling R/W
0x010 SYSREF Handling R/W SYSREF Handling R/W
0x014 – – ILA Multiframes R/W
0x018 Test Modes R/W Test Modes R/W
0x01C Link Error Status (Lanes 0 to 7) – – –
0x020 Octets per Frame R/W Octets per Frame R/W
0x024 Frames per Multiframe R/W Frames per Multiframe R/W
0x028 Lanes in Use R/W Lanes in Use R/W
0x02C Subclass Mode R/W Subclass Mode R/W
0x030 RX Buffer Delay (RX Only) R/W – –
0x034 Error Reporting (RX Only) R/W – –
0x038 Sync Status R Sync Status R
0x03C Debug Status R – –
0x040–0x7FC Reserved – Reserved –
0x400 Reserved R/W Lane ID Lane0 R/W

0x404 Reserved R/W Lane ID lane 1 R/W
0x40C Reserved R/W Lane ID lane 3 R/W
0x41C Reserved R/W Lane ID lane 7 R/W
0x800 lane 0 ILA Config Data 0 R – –

0x80C lane 0 ILA Config Data 3 R ILA Config Data 3 R/W
0x810 lane 0 ILA Config Data 4 R ILA Config Data 4 R/W
0x81C lane 0 ILA Config Data 7 R ILA Config Data 7 R/W
0x820 lane 0 Test Mode Error Count R – –

28
Table 2‐14: Register Address Map (Cont’d)

0x824 lane 0 Link Error Count R – –
0x828 lane 0 Test Mode ILA Count R – –
0x82C lane 0 Test Mode Multiframe Count R – –
0x830 lane 0 Buffer Adjust R – –
0x834–0x83C lane 0 Reserved – – –
0x840–0x87C Same as 0x800–0x83C for Lane 1 R – –
0x880–0x8BC Same as 0x800–0x83C for Lane 2 R – –
0x8C0–0x8FC Same as 0x800–0x83C for Lane 3 R – –
0x980–0x9BC Same as 0x800–0x83C for Lane 6 R – –
0x9C0–0x9FC Same as 0x800–0x83C for Lane 7 R – –
Table 2‐15: Version

Default
Bits Value Description
31:24 – Version: Major

23:16 – Version: Minor
15:8 – Version: Revision
7:0 – Reserved (read 0x00)
Register Address Map
Table 2‐16: Reset

Default
Bits Description
Value
31:17 – Reserved
16 1 Watchdog Timer Disable (1): 1 = Disable GT watchdog timer
15:2 – Reserved
Reset (fixed).
Write 1 to hold the core in the reset state.
1 0 Write 0 to release the core from reset.
After writing 0 to this bit. Bit 0 of this register should be polled to confirm completion
of the reset process.

29
Table 2‐16: Reset (Cont’d)
Bits Default Description

Value
Reset (self clearing)
Write 1 to reset core
Read: 1 = reset in progress; 0 = reset complete
0 1
A reset must be performed as a final step after any changes to the configuration
registers. This reset does not clear the configuration register values. It forces a restart
and resync of the link using the newly programmed values.
Notes:
1. Applicable to GTXE2 transceivers only.
Table 2‐17: ILA Support

Default
Bits Description
Value
31:1 – Reserved
0 1 1 = Enable ILA Support (1); 0 = Disable ILA Support
Notes:
1. When Enable ILA Support is 1, a TX core transmits an Inter Lane Alignment (ILA) sequence; an RX core expects to
receive an ILA sequence. Should always be enabled for Subclass 1 or 2 operation and any multi-lane configuration.
Table 2‐18: Scrambling

Default
31:1 – Reserved
0 0 1 = Enable Scrambling; 0 = Disable Scrambling
Table 2‐19: SYSREF Handling

Default
31:17 – Reserved
SYSREF Required on Re-Sync
1 = A SYSREF event is required following a Link Re-Sync event:
TX core transmits K28.5 until a SYSREF re-aligns the LMFC;
16 0 RX core does not deassert SYNC until a SYSREF event re-aligns the LMFC.
0 = No SYSREF event is required on a Link Re-Sync event:
TX core transmits ILA sequence on the next LMFC.
RX core deasserts SYNC on the next LMFC.
15:12 – Reserved

30
Table 2‐19: SYSREF Handling (Cont’d)

Value
SYSREF delay: add additional delay to SYSREF re-alignment of LMFC counter
1111 = 15 core_clk cycles delay
11:8 0000
....
0000 = 0 core_clk cycles delay
7:1 – Reserved
SYSREF Always
0 0 1 = Core re-aligns LMFC counter on all SYSREF events
0 = Core only aligns LMFC counter on the first SYSREF event detected following reset,
and ignores subsequent SYSREF events
Table 2‐20: ILA Multiframes

Default
Bits Description
Value
31:8 – Reserved
Multiframes in the Transmitted Initial Lane Alignment Sequence
7:0 0x03
Parameter Range: 4–256; program the register with required value minus 1
Table 2‐21: Test Modes

Default
Bits Description
Value
31:5 – Reserved
Test Mode Select
00000 = Normal operation
00001 = Transmit/Receive /K28.5/ indefinitely
00010 = Synchronize as normal then transmit/receive repeated ILA sequences
00011 = Transmit/receive /D21.5/ indefinitely [TX Only] (2)
4:0 (1) 00101 = Transmit Modified Random Pattern (RPAT) [TX ONLY](2)
00000
00111 = Transmit Scrambled Jitter Pattern (JSPAT) [TX ONLY] (2)
1xxxx = Enable Transceiver’s PRBS test patterns. For correct bit values see relevant
Transceiver User Guide (UltraScale) [TX Only](2)
10xxx = Enable Transceiver’s PRBS test patterns. For correct bit values see relevant
Transceiver User Guide (7-Series) [TX Only](2)
See Link Test Modes.
1. When bit [4] is set, enabling the transceiver PRBS test patterns, the JESD204 data output is disabled.
2. These test modes are only applicable to the JESD204 transmitter IP. They are used to set the transceiver to output
specific patterns that may be used to evaluate the electrical characteristics of a link using tools such as IBERT. A
JESD204 receiver core will not synchronize or function if these test patterns are received.

31
Table 2‐22: Link Error Status (Lanes 0 to 7)

Default
Lane Alignment Error Detected Alarm

1 = A Received Multiframe Framing character was detected in a mis-aligned location
31 – relative to the LMFC.
Alignment error is asserted if any lane sees seven consecutive misaligned alignment
characters.
SYSREF LMFC Alarm (Subclass 1 Only)
30 –
1 = A SYSREF event was detected, misaligned to current LMFC counter
RX Buffer Overflow Alarm
29 –
1 = RX Lane Alignment Buffer Overflow has occurred
28:24 – Reserved (Read 00000)
23:21 – Link Error Status, Lane 7
5:3 – Link Error Status, Lane 1; format as per lane 0
Link Error Status, Lane 0
bit 2: 1 = Unexpected K-character(s) received
bit 1: 1 = Disparity Error(s) received
2:0 – bit 0: 1 = Not in Table Error(s) received
Each bit indicates that 1 or more errors of that type have been received in Lane 0
because the register was last read.
All status bits are auto-cleared on read of the register.
Notes:
1. The status bits can only be set when the core has completed initial lane synchronization, errors during
synchronization and comma alignment are ignored. This register is cleared on read or when the core is reset. The
contents might be cleared if the watchdog timer is enabled.
Table 2‐23: Octets per Frame

Default
Bits Description
Value
31:8 – Reserved
Octets per Frame (F)
Parameter range 1–256;
7: 0 0x01
Program register with required value minus 1
(for example, for F = 4, 0x03 should be programmed)

32
Table 2‐24: Frames per Multiframe

Default
31:5 – Reserved
Frames per Multiframe (K)
Parameter range 1–32;
4:0 0x1F
Program register with required value minus 1
(for example, for K = 16, 0x0F should be programmed)
Table 2‐25: Lanes in Use

Default
31:12 – Reserved
Lanes in Use: Allows the number of active lanes to be set.
Each bit corresponds to a single lane, when set to “1” lane is
active.
Varies depending on Number Lanes 0 to X are active if bits 0 to X are set to 1.
7:0 of Lanes which the core was For example, for three active lanes (lanes 0 to 2 active), 0x07 is
generated for programmed. But if you wanted lane 2 and 0 active, program
0x05.
Note: You cannot activate any lane > X which is set during
customization.
Table 2‐26: Subclass Mode

Value
31:3 – Reserved
Subclass Mode
11: Reserved
1:0 01 10: Subclass 2
01: Subclass 1
00: Subclass 0

33
Table 2‐27: RX Buffer Delay (RX Only)

Default
31:10 – Reserved
RX Buffer Delay
RX Buffer Delay can be programmed, in conjunction with the RX Buffer Adjust values
read from the lanes, to minimize the overall RX Latency. See Minimum Deterministic
Latency Support.
An indication of the maximum allowable reduction of the latency is output on the
9:0 0
rx_buffer_adjust register. This provides an indication of the difference between the
write and read pointers of the receiver elastic buffer in each lane. The number of
octets output in each 10-bit value give an indication of the buffer fill level in each lane.
The lowest number given can be programmed to the rx_buffer_delay register to
reduce the overall latency by that number of octets.
Table 2‐28: Error Reporting (RX Only)

Default
Bits Description
Value
31:9 – Reserved
Disable Error Reporting Using SYNC Interface
8 0 1 = Error reporting using SYNC interface Disabled
0 = Error reporting using SYNC interface Enabled
7:1 0 Reserved
Link Error Counters Enable
1 = Enable Link Error counters (Link errors are counted and reported using Link Error
0 0
Count registers per lane)
0 = Disable Link Error counters
Table 2‐29: Sync Status

Value
31:17 – Reserved
SYSREF Captured (Subclass 1 Only)
16 0 1 = A SYSREF event has been captured
0 = No SYSREF event has been captured
15:1 – Reserved
SYNC Status
0 0 1 = Link SYNC achieved
0 = Link SYNC not achieved

34
Table 2‐30: Debug Status

Default
31:28 – Link Debug status Lane 7 as per lane 0

Link Debug status Lane 0
Bit 3: 1 = Start of Data was Detected (1)
3:0 – Bit 2: 1 = Start of ILA was Detected (1)
Bit 1: 1 = Lane has Code Group Sync (2)
Bit 0: 1 = Lane is currently receiving K28.5's (BC alignment characters) (2)
Notes:
1. The status bits 3:2 latch when set and are cleared on read or when the core is reset. If the core is streaming data
when these bits are cleared, they are instantly set again. The purpose of these bits is to detect whether these
conditions have occurred since SYNC was asserted.
2. The status bits 1:0 show instantaneous status.
Table 2‐31: Lane ID

Note: This is a “Per Lane” Register
Default
31:5 – Reserved
ID of lane N. Value can be anywhere between 0 and 31. The default value N is set to
the lane number. For interfaces using more than 8 lanes and hence multiple JESD204
4:0 N
cores. This register should be programmed to ensure each lane has the correct
identifier.
Table 2‐32: ILA Config Data 0

Bits Default Description(1)

Value
31:11 – Reserved
JESDV (JESD204 version):
10:8 – 000=JESD204A
001=JESD204B
7:3 – Reserved

35
Table 2‐32: ILA Config Data 0 (Cont’d)

Default
Bits Description(1)
Value
SUBCLASS:
000=Subclass0
2:0 –
001=Subclass1
010=Subclass2
Notes:
1. RX only: captured configuration data from the ILA sequence (per lane);
TX: Not applicable, the values transmitted in the ILA sequence are generated automatically by the core based on
the configuration.

Default
Bits Description(1)
Value
31:8 – Reserved
7:0 – F (Octets per Frame). Binary value minus 1.
Notes:
1. RX only: captured configuration data from the ILA sequence (per lane);
TX: Not applicable, the values transmitted in the ILA sequence are generated automatically by the core based on
the configuration.

Default
Bits Description(1)
Value
31:5 – Reserved
4:0 – K (Frames per Multiframe). Binary value minus 1.
Notes:
1. RX only: captured Configuration data from the ILA sequence (per lane);
TX: Not Applicable, the values transmitted in the ILA sequence are generated automatically by the core based on
the configuration.

36

Bits Default Description(1)

Value
31:29 – Reserved
28:24 – L (Lanes per Link) [RX only, not writeable for TX]. Binary value minus 1.
23:21 – Reserved
20:16 0x0 LID (Lane ID) [RX only, not writeable for TX]. Binary value.
15:12 – Reserved
11:8 0x0 BID (Bank ID). Binary value.
7:0 0x00 DID (Device ID). Binary value.
Notes:
1. RX: captured configuration data from the ILA sequence (per lane);
TX: Sets the values to be transmitted in the ILA sequence for all lanes. LID and L values cannot be programmed,
they are generated automatically by the core based on the configuration.

Default
Bits Description(1)
Value
31:26 – Reserved
25:24 00 CS (Control bits per Sample). Binary value.
23:21 – Reserved
20:16 00000 N' (Totals bits per Sample). Binary value minus 1.
15:13 – Reserved
12:8 00000 N (Convertor Resolution). Binary value minus 1.
7:0 0x00 M (Convertors per Device). Binary value minus 1.
Notes:
TX: Sets the values to be transmitted in the ILA sequence for all lanes.

Default
Bits Value Description(1)
31:29 – Reserved
28:24 00000 CF (Control Words per Frame). Binary value.
23:17 – Reserved

37

Default
Bits Description(1)
Value
16 0 HD (High Density format)
15:13 – Reserved
12:8 00000 S (Samples per Converter per Frame). Binary value minus 1.
7:1 – Reserved
SCR (Scrambling Enable) [RX only, not writeable for TX]
0 –
1 = enabled
Notes:
TX: Sets the values to be transmitted in the ILA sequence for all lanes. SCR value cannot be programmed, it is
generated automatically by the core based on the configuration.

Default
Bits Value Description(1)
31:24 – Reserved
23:16 0x00 FCHK (Checksum) [RX only, not writeable for TX]. Binary value.
15:8 0x00 RES2 (Reserved Field 2)
7:0 0x00 RES1 (Reserved Field 1)
Notes:
TX: Sets the values to be transmitted in the ILA sequence for all lanes. FCHK value cannot be programmed, it is
calculated automatically by the core for each lane.

Default
Bits Description
Value
31:17 – Reserved
16 0 ADJDIR (Adjust Direction) [Subclass 2 Only]. Binary value.
15:9 – Reserved
8 0 PHADJ (Phase Adjust Request) [Subclass 2 Only]. Binary value.

38

Default
Bits Description
Value
7:4 – Reserved
ADJCNT (Phase Adjust Request) [Subclass 2 Only]. Binary value.
3:0 0x0 RX: captured configuration data from the ILA sequence (per lane).
TX: Sets the values to be transmitted in the ILA sequence for all lanes.
Table 2‐40: Test Mode Error Count

Default
Bits Description
Value
Test Mode Error Count
Count of Errors received in Data link Layer test modes.
Test Mode = 001 (Continuous K28.5): counts any non K28.5 characters received
31:0 –
Test Mode = 010 (Continuous ILA): counts any unexpected characters received
This count resets to zero on transition to an active test mode and retains any count
value on transition out of an active test mode.
Table 2‐41: Link Error Count

Default
Link Error Count

Count of total received link errors (per lane) when Link Error Counters is Enabled.
31:0 – Errors counted are Disparity or Not In Table errors indicated by the lane.
The error counter can be reset by disabling and re-enabling using the control bit in
the Error Reporting register.
Table 2‐42: Test Mode ILA Count

Default
Test Mode ILA Count

Count of total ILA Sequences received when Test Mode = 010 (Continuous ILA)
31:0 –
This count resets to zero on transition to Test Mode = 010, and retains any count value
on transition out of test mode.

39
Table 2‐43: Test Mode Multiframe Count


Value
Test Mode Multiframe Count
Count of total ILA Multiframes received when Test Mode = 010 (Continuous ILA)
31:0 –
This count resets to zero on transition to Test Mode = 010 and retains any count value
on transition out of test mode.
Table 2‐44: Buffer Adjust

Default
Bits Description
Value
31:10 – Reserved
RX Buffer Adjust. Indicates the RX Buffer fill level (per lane).
9:0 – This can be used to minimize overall latency. See Minimum Deterministic Latency
Support.

40
Chapter 3
Designing with the Core

This chapter provides a general description of how to use the JESD204 core in your designs
and should be used in conjunction with Chapter 2, Product Specification, which describes
specific core interfaces.
General Design Guidelines

This section describes the steps required to turn a JESD204 core into a fully-functioning
design with user-application logic. It is important to know that not all implementations
require all of the design steps listed in this chapter. Follow the logic design guidelines in
this manual carefully.
Use the Example Design as a Starting Point

Each instance of the JESD204 core created by the Vivado® Design Suite 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 troubleshoot your
application, if necessary.
See Chapter 5, Example Design for information about using and customizing the example
designs for the JESD204 core.
Know the Degree of Difficulty

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

• Targeted device architecture
• Nature of your application
All JESD204 implementations require careful attention to system performance

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

41
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 might not 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 for the core identifies the critical signals and the
timing constraints that should be applied. See Constraining the Core for further
information.
Use Supported Design Flows

The core is synthesized in the Vivado IDE and is delivered as Verilog. The example
implementation scripts provided currently use Vivado synthesis as the synthesis tool for the
Verilog example design that is delivered with the core. Other synthesis tools can be used.
Make Only Allowed Modifications

The JESD204 core is not user-modifiable. Any modifications can have adverse effects on
system timing and protocol compliance. Supported user configurations of the JESD204 core
can only be made by selecting the options from within the Vivado Customize IP dialog box
and using the top-level parameters described in this document. See Chapter 4, Design Flow
Steps.
Recommended Design Experience

Although the JESD204 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 tools and the XDC is recommended.
Contact your local Xilinx representative for a closer review and estimation for your specific
requirements.

42
Core Overview and Getting Started

This section provides an overview of the core, its deliveries and delivery options, together
with system-level decisions which must be taken account of in generating and using the
core.
Serial Line Rate and Clocking

The JESD204B specification (JEDEC® Serial Interface for Data Converters (JESD204B)
available from www.jedec.org) does not define specific serial line rates for any JESD204B
link, but a valid range of line rates from 312.5 Mb/s to 12.5 Gb/s. The JESD204B core
supports line rates from 1 Gb/s to 12.5 Gb/s, depending on the part and speed grade
selection.
In most instances, the serial line rate selection is governed by the specifications of the ADC/
DAC Converter device(s) to which the core is interfaced. The required operating serial line
rate directly relates to the clock rate at which the core logic operates (core clock); the serial
line rate also governs the selection of the reference clock required by the transceiver(s).
Core Clock
The JESD204 core operates using a 32-bit (4-byte) datapath. The core clock frequency is
always the line rate divided by 40. For example, for a serial line rate of 6.25 Gbs, the core
clock frequency is 156.25 MHz. The AXI-streaming RX and TX data interfaces operate at this
core clock frequency.
Reference Clock
The GTP/GTX/GTH/GTY serial transceivers in the JESD204_PHY require a stable, low-jitter
reference clock which has a device and speed grade-dependent range. In some
circumstances, it can be advantageous to use the same clock frequency or source for both
core clock and reference clock. However this might not always be practical. It is important
to understand the limitations imposed on the reference clock and core clock, together with
system-level implications such as the synchronous capture of SYSREF/SYNC for Subclass 1
or 2 deterministic latency. See Clocking for more information.
AXI4-Lite Interface Clock

The core is configured and monitored through an AXI4-Lite processor interface. The clock
for this interface is a separate clock from either core clock or reference clock. There are no
dependencies between this clock and either core clock or reference clock.

43
Selecting the Operating Line Rate and Reference Clock

The serial line rate and a valid reference clock frequency can be selected when generating
the core in the Vivado IDE, and customized transceiver wrapper files are delivered.
Core Delivery – Shared Logic Example Design

The JESD204B core is delivered through the Vivado IDE, either through the Vivado IP
catalog, or through the Vivado IP integrator block design tool. The core customization
Vivado IDE presents the options available in core generation. See Chapter 4, Design Flow
Steps for more information.
As well as allowing the selection of the main core parameters, the Vivado IDE allows the
selection of how the core and some of its supporting logic is delivered; this is using the
Shared Logic Tab in the Vivado IDE. The default selection is Include Shared Logic in
Example Design where the core is delivered without shared logic. In this case, the JESD204
PHY core is not delivered directly with the core.
To access the JESD204 PHY core and other supporting logic, it is necessary to open the IP
example design (using the right-click menu). This opens a separate Vivado project which
instantiates the IP within the example design. The example design instantiates the core
support layer, which includes the JESD204 PHY core and other supporting logic such as
clock modules. The example design and the support layer delivered in the example design
project are intended to provide a useful example and starting point for you own design.
If Include Shared Logic in Core is selected, the core is delivered complete with a support
layer including the JESD204 PHY core and other supporting logic such as clock buffers. For
simple core implementations where there is no requirement for transceiver sharing, the line
rate is configurable in the Vivado IDE. To perform this, select the Include Shared Logic in
Core option.
For more complex core implementations, for example, transceiver sharing, PLL and/or clock
sharing, select Include Shared Logic in Example Design and use the IP example design as
a starting point for your own design.
Transceiver Sharing
Because JESD204B is defined as a unidirectional protocol, the JESD204 core is customized
and delivered as either a transmitter or as a receiver. The Xilinx GTP/GTX/GTH/GTY
transceivers are duplex, each transceiver supporting both transmit and receive directions. In
a system implementation using both TX and RX JESD204 links, you might want to use both
the TX and RX directions of a transceiver (or group of transceivers), and connect to both TX
and RX JESD204 cores. Such transceiver sharing is supported by the JESD204 core by using
the JESD204_PHY core (within the limitations and constraints imposed by line rates and
clock sources). See Sharing Transceivers between Transmit and Receive.

44
Subclass Mode
The core supports operation in the three JESD204B Subclass modes. This is controlled by a
register setting. By default the core operates in Subclass 1 mode. The core pinout supports
all three subclass modes of operation; however an externally generated SYSREF is required
for Subclass 1 operation. For Subclasses 0 and 2, the SYSREF input signal is not required and
can be tied off.
Subclass 0
Subclass 0 is backwards compatible with JESD204A, with extended line rate range support
up to 12.5 Gb/s. There is no support for Deterministic Latency. SYSREF is not required.
Subclass 1
Subclass 1 supports deterministic latency through the use of a common SYSREF signal. The
SYSREF signal is generated external to the core, and is distributed to all devices in a system.
SYSREF is permitted by the JESD204B standard to be either a “one-shot”, periodic, or
gapped periodic. The core is capable of operating with any of these selections. The timing
and clocking requirements for the reliable capture of SYSREF are key to achieving reliable
deterministic latency (see Clocking).
Subclass 2
Subclass 2 supports deterministic latency using only the SYNC signal. The timing and
clocking requirements for the launch (by an RX core), and capture (by a TX core) of the
SYNC signal are key to achieving reliable deterministic latency (see Clocking).
Programming the Core

Run time operation of the JESD204 core is configured through an AXI4-Lite register
interface. See Register Space for details of the register map.
For correct operation and bring-up of a JESD204 link, it is important that the major framing
and link operation parameters match at both ends of the link:
• Octets per Frame

• Frames per Multiframe
• Scrambling On/Off
• Subclass mode
• SYSREF handling (for Subclass 1 mode)
These parameters are dictated by the configurations available in the ADC/DAC converter
device to which the core is interfacing.

45
For TX cores, in addition to these parameters, some of the additional content of the
configuration data which is transmitted in the ILA sequence at link start-up is also
programmed through the register interface. The data values transmitted in the ILA
configuration data are not normally critical to the operation of the link, but this is
dependent on the behavior of the receiving device.
For RX cores, the configuration data received in the ILA sequence is captured, for each lane,
and can be examined using the register interface.
Clocking
This section describes the options available for clocking the JESD204 core and the
transceiver(s).
IMPORTANT: It is strongly recommended that you use one of the clocking schemes
presented in this section. Use of alternative clocking schemes may lead to design failure.
The following clocks are used in the JESD204 core:
• Device Clock – The JESD204B specification defines a device clock which is distributed
to each device in the system. The device clocks to different devices such as DAC/ADC
converters and FPGAs can run at different rates to suit the individual devices, but must
all be related in frequency and be generated from a common source. See the JESD204B
specification [Ref 1], paragraphs 4.7 and 4.8, for definitions.
• Byte Clock – The frame and multiframe periods in each device are derived from the
device clock. The frame/multiframe periods must match for the transmitting and
receiving devices. From the frame period the octet (byte) clock rate can be directly
inferred (F octets per frame).
• Serial Line Rate – The serial line rate for all lanes is common, and runs at 10 times the
byte clock rate on each lane.
• Core Clock – The JESD204 core operates using a 32-bit (4-byte) datapath. The device
clock for the core logic therefore runs at one quarter of the byte clock rate (1/40th of
the serial line rate). For the JESD204 core, this is referred to as the core clock.
• Reference Clock – The GTP/GTX/GTH/GTY serial transceivers require a stable, low-jitter
reference clock which has a device and speed grade dependent range. In some
circumstances, the same source clock can supply both the reference clock and core
clock.

46
Depending on the Shared Logic selection made when generating the core, a clocking
module is delivered as part of the core (Shared Logic in Core) or as part of the Core
Support Layer delivered with the Example Design project (Shared Logic in Example
Design). This clocking module contains example clocking resources relevant to the selected
device and the core customization choices.
In either case the FPGA level input clocks are:
• refclk (p/n) – transceiver reference clock. This is always present.

• glblclk (p/n) – core clock. This is an optional input which is present if refclk is not
equal to the core clock or refclk is not between the MIN and MAX frequencies for
refclk as coreclk specified in Table 3-1 to Table 3-5.
RECOMMENDED: For the greatest flexibility in implementing system-level clocking, Xilinx recommends
that the FPGA pinout and system-level clocking resources are designed to provide both of these clocks
to the FPGA.
AXI4-Lite Configuration Interface Clock (axi_clk) – This is asynchronous to any other

clock and can be driven by the processor subsystem.
Supporting Subclass 1 and 2 Deterministic Latency

Supporting Subclass 1 or 2 deterministic latency requires careful consideration of the
clocking scheme chosen, to ensure that SYSREF (for Subclass 1) or SYNC (for Subclass 2 TX
cores) can be reliably captured by the core clock.
For Subclass 0, where there are no such constraints, the clocking requirements are
simplified, and alternative clocking arrangements can be used.
Number of lanes per link

The maximum number of lanes per link is 8. For interfaces which require more than 8 lanes,
simply create multiple cores with a maximum of 8 lanes each.
For a transmit interface, the lane ID of each lane of a transmit core can be independently
programmed using the Lane ID registers (see Table 2-31).
For a receive interface, the lane ID of each lane can be read from the LID field of the ILA
Config Data 3 register for each lane (see Table 2-35).
This programmable Lane ID feature can also be utilized to share a single JESD core with
multiple synchronous converters. For example, eight one lane converters may be connected
to a single JESD204 core. If this is a transmitter core, the lanes can all be programmed to be
lane 0.

47
This has the advantage of potentially aligning the data from all the converter as well as
reducing the logic overhead that would be generated if eight individual cores were used.
Note: The system must be designed to support this functionality.
Basic Generic Clocking Schemes

To Converter(s)
Device Clock (800 MHz*)
SYSREF (Subclass 1)
FPGA
JESD204_PHY
(400 MHz*)
Clock Generator REFCLK
Source Clocking
Clock Module
VCO TX/RX_CORE_CLK
refclk (400 MHz*) IBUFDS_GT
glblclk (200 MHz*)

(200 MHz*)
JESD204 CORE
IBUFDS BUFG LOGIC
TX/RXCORE_CLK
SYSREF
Generation SYSREF (Subclass 1) SYSREF
(Subclass 1)
(Subclass 1)
*
example frequencies
Figure 3‐1: Clock Configuration using Separate refclk and Core Clock
Figure 3-1 shows the most generic and flexible clocking scheme, where separate refclk
and glblclk inputs are used to provide the transceiver reference clock and the core clock,
respectively. With this configuration, the reference clock and core clock are physically
separate clocks and can be run at independent frequencies, without additional constraints.
The reference clock can be run at any frequency within the limitations of the transceiver for
the selected line rate. The core clock always runs at the required rate (1/40th of the serial
line rate).
7 Series Devices
This configuration must be used for Artix-7, Kintex-7 and Virtex-7 where the reference
clock frequency is out of the range that can be used for the core clock and supports the
reliable capture of SYSREF/SYNC. This frequency range is governed by the particular device
family and speed grade (see Tables 3-1 to Table 3-3).
UltraScale Devices
This configuration must also be used for Kintex UltraScale and Virtex UltraScale when the
reference clock is not required to run at the same rate as the core clock.

48
To Converter(s)
Device Clock (1228.8 MHz*)
SYSREF (Subclass 1)
FPGA
JESD204_PHY
(153.6 MHz*)
Clock Generator REFCLK
Source Clocking
Clock Module
VCO TX/RX_CORE_CLK
refclk (153.6 MHz*) IBUFDS_GT
JESD204 CORE
LOGIC
BUFG
SYSREF TX/RX_CORE_CLK
Generation
(Subclass 1) SYSREF (Subclass 1)
SYSREF (Subclass 1)
*example frequencies
Figure 3‐2: Artix-7 Kintex-7 and Virtex-7 Clock Configuration using refclk as Core Clock
7 Series Devices
Figure 3-2 shows a clocking scheme that can be used for Artix-7, Kintex-7 and Virtex-7
devices when the reference clock frequency is in the range that can be used for the core
clock and supports the reliable capture of SYSREF/SYNC. This frequency range is governed
by the particular device family and speed grade (see Tables 3-1 to Table 3-3).
UltraScale and UltraScale+ Devices

Figure 3-3 shows a clocking scheme that can be used for all UltraScale and UltraScale+
devices when the reference clock is in the range that can be used for the core clock (see
Table 3-4 to Table 3-7). When the reference clock is outside this range, the clocking scheme
shown in Figure 3-1 must be used.
Note: When using the simple clocking scheme shown in Figure 3-3, the GT_POWERGOOD output
from the JESD204_PHY must be connected to the CE pin on the BUFG_GT.

49
Device Clock (800 MHz*)

SYSREF (Subclass 1)
FPGA
Clock Generator Clocking

Module
JESD204_PHY
VCO refclk
(200 MHz*) IBUFDS_GT
200 MHz*
REFCLK
BUFG_GT
CE TX/RX_CORE_CLK
GT_POWERGOOD
200 MHz*
JESD204 CORE
LOGIC
SYSREF TX/RX_CORE_CLK
Generation
(Subclass 1) SYSREF
(Subclass 1) SYSREF (Subclass 1)
*
Example Frequencies
Figure 3‐3: UltraScale and UltraScale+ - Simple Clock example
Supported Clock Frequency Ranges

The following tables list the relevant parameters for each of the supported device families.
Table 3‐1: Frequency Ranges for Artix-7 Devices

Device Family: Artix-7 and Zynq-7000 (GTP Transceiver)
Speed Grade
Parameter
-3 -2 -1(2)
Line Rate MAX (Gb/s) (1) 6.6 6.6 3.75
Line Rate MIN (Gb/s) (1) 0.5 0.5 0.5
(1)
refclk MAX (MHz) 660 660 660
refclk MIN (MHz) (1) 60 60 60
MAX frequency for refclk as core clock (MHz) (3) 165 165 93.75

50
Table 3‐1: Frequency Ranges for Artix-7 Devices (Cont’d)

Device Family: Artix-7 and Zynq-7000 (GTP Transceiver)
Speed Grade
Parameter
-3 -2 -1(2)
MIN frequency for refclk as core clock (MHz)(3) 60 60 80
Notes:
1. Further limitations might apply: see the Artix-7 FPGAs Data Sheet: DC and AC Switching Characteristics (DS181)
[Ref 10] and the Zynq-7000 All Programmable SoC (Z-7010, Z-7015, and Z-7020): DC and AC Switching
Characteristics (DS187) [Ref 11] for full specifications.
2. For -1 speed grade devices, the line rate is limited to 3.75 Gb/s and the GTP PLL VCO lower limit prevents selecting
a refclk lower than 80 MHz.
3. If these conditions are met, the clocking in Figure 3-2 can be used. Otherwise, the clocking in Figure 3-1 must be
used.
Table 3‐2: Frequency Ranges for Kintex-7, Virtex-7 and Zynq-7000 Devices
Device Family: Kintex-7, Virtex-7 and Zynq-7000 (GTXE2 Transceiver)
Speed Grade
Parameter
-3 -2 -1
(1)
Line Rate MAX (Gb/s) 12.5 10.3 8.0
Line Rate MIN (Gb/s) (1) 0.5 0.5 0.5
refclk MAX (MHz) (1) 700 670 670
(1)
refclk MIN (MHz) 60 60 60
MAX frequency for refclk as core clock (MHz) (3) 165 165 165
MIN frequency for refclk as core clock (MHz) (3) 80 80 80
Notes:
1. Further limitations might apply—see the Kintex-7 FPGAs Data Sheet: DC and AC Switching Characteristics (DS182)
[Ref 12] and Virtex-7 FPGAs Data Sheet: DC and AC Switching Characteristics (DS183) [Ref 13] and Zynq-7000 All
Programmable SoC (Z-7030, Z-7045, and Z-7100): DC and AC Switching Characteristics (DS191) [Ref 14] for full
specifications.
2. The GTXE2 can operate with refclk as low as 60 MHz, but the operating band of the CPLL VCO prevents refclk
and core clock sharing at frequencies less than 80 MHz (CPLL) or 75 MHz (QPLL).
used.
Table 3‐3: Frequency Ranges for Virtex-7 Devices Using GTHE2

Device Family: Virtex-7 (GTHE2 Transceiver)
Speed Grade
Parameter
-3 -2 -1
Line Rate MAX (Gb/s) (1) 12.5 11.3 8.5
(1)
Line Rate MIN (Gb/s) 0.5 0.5 0.5
refclk MAX (MHz) (1) 820 820 820
(1)

51
Table 3‐3: Frequency Ranges for Virtex-7 Devices Using GTHE2 (Cont’d)
Device Family: Virtex-7 (GTHE2 Transceiver)
Speed Grade
Parameter
-3 -2 -1
MAX frequency for refclk as core clock (MHz) (2) 165 165 165
Notes:
1. Further limitations might apply —see the Virtex-7 FPGAs Data Sheet: DC and AC Switching Characteristics (DS183)
[Ref 12] for full specifications.
used.
Table 3‐4: Frequency Ranges for Kintex and Virtex UltraScale Architecture-GTHE3 Based
Devices
Device Family: Kintex UltraScale (GTHE3 Transceiver)
Speed Grade
Parameter
-3 -2 -1
Line Rate MAX (Gb/s) (1) 12.5 12.5 12.5
Line Rate MIN (Gb/s) (1) 0.5 0.5 0.5
(1)
(1)
MAX frequency for refclk as core clock (MHz) (2) 312.5 312.5 312.5
(2)
MIN frequency for refclk as core clock (MHz) 80 80 80
Notes:
1. Further limitations might apply—see the Kintex UltraScale Architecture Data Sheet: DC and AC Switching
Characteristics (DS892) [Ref 15] and Virtex Ultrascale Architecture Data Sheet: DC and AC switching Characteristics
(DS893) [Ref 25] for full specifications.
used.
Table 3‐5: Frequency Ranges for Kintex and Virtex UltraScale Architecture-GTYE3 Based
Devices
Device Family: Kintex and Virtex UltraScale (GTYE3 Transceiver)
Speed Grade
Parameter
-3 -2 -1
Line Rate MAX (Gb/s) (1) 12.5 12.5 12.5
Line Rate MIN (Gb/s) (1) 0.5 0.5 0.5
refclk MAX (MHz) (1) 820 820 820
(1)

52
Notes:
1. Further limitations might apply—See the Kintex UltraScale Architecture Data Sheet: DC and AC Switching
Characteristics (DS892) [Ref 15], and the Virtex Ultrascale Architecture Data Sheet: DC and AC switching
Characteristics (DS893) [Ref 25] for full specifications.
used.
Table 3‐6: Frequency Ranges for Kintex, Virtex and Zynq Ultrascale+ Architecture-GTHE4 Based
devices.
Device Family: Kintex UltraScale (GTHE4 Transceiver)
Speed Grade
Parameter
-3 -2 -1
(1)
Line Rate MAX (Gb/s) 12.5 12.5 12.5
Line Rate MIN (Gb/s) (1) 0.5 0.5 0.5
refclk MAX (MHz) (1) 820 820 820
Notes:
used.
Table 3‐7: Frequency Ranges for Kintex, Virtex and Zynq Ultrascale+ Architecture-GTYE4 Based
devices.
Device Family: Kintex, Virtex and Zynq UltraScale (GTYE4 Transceiver)
Speed Grade
Parameter
-3 -2 -1
Line Rate MAX (Gb/s) (1) 12.5 12.5 12.5
Line Rate MIN (Gb/s) (1) 0.5 0.5 0.5
(1)
(2)
MIN frequency for refclk as core clock (MHz) 80 80 80
Notes:
used.

53
Detailed Clocking
For all device families (GTP, GTXE2, GTHE2, GTHE3, GTYE3, GTHE4 and GTYE4 transceivers),
the clocking schemes described in Basic Generic Clocking Schemes can be used. Depending
on the Shared Logic selection at core generation time, example clocking source code
modules are delivered as part of the core, or as part of the core example design project.
For GTP based devices, the JESD204_PHY core has a 16-bit internal data path rather than
32-bit used by other devices. This imposes an extra requirement that the transceiver be
supplied with another clock running at twice the core clock rate. For JESD204 designs
generated with shared logic in the core or shared logic in the example design, the extra
clock is catered for by the inclusion of an MMCM in the JESD204_PHY core. For designs that
generate the JESD204_PHY core separately with shared logic in the example design
selected. The user must supply this 2x clock to the TX/RXUSERCLK pins on the JESD204_PHY
core. An example of this is shown in Figure 3-4.
Artix-7 FPGA
refclk
JESD204_PHY
153.6 MHz* IBUFDS_GT
153.6 MHz*
REFCLK
glblclk
76.8 MHz* IBUFDS MMCM BUFG 153.6 MHz*
CLKINx2 TX/RXUSRCLK
BUFG BUFG 76.8 MHz*
FBOUT TX/RX_CORE_CLK
FBIN
JESD204 CORE
LOGIC
TX/RX_CORE_CLK
SYSREF SYSREF (Subclass 1)
*
example frequencies
Figure 3‐4: Artix-7 Clock Configuration Using external MMCM to supply JESD204_PHY clocks
Clocking for Subclass 0 Mode

If Subclass 0 operation is required, the timing limitations imposed to support deterministic
latency are removed, and simplified clocking arrangements can be used which require only
a reference clock input.
For Kintex UltraScale and Virtex UltraScale devices, the clocking arrangement in Figure 3-3
can be used. For Artix-7, Kintex-7 and Virtex-7 devices, it is possible to use the TXOUTCLK
from the JESD204_PHY core to generate the core clock. Figure 3-5 shows the generic use

54
case for most devices. However, GTP transceiver devices using a JESD204_PHY core
configured to use shared logic in the example design still require an additional MMCM
(described earlier) for generation of TXUSRCLK/RXUSRCLK at twice the core clock.
Note: No example of this clocking configuration is generated for any Artix-7, Kintex-7 or Virtex-7
configuration of the JESD204 core. The IP is configured to use the Subclass 1 clocking scheme as
seen above. If this clocking scheme is required, it is suggested that the standard clocking module
generated with the core (or example design), is used as a starting point to create the required
clocking configuration.
FPGA
Clocking Module
refclk JESD204_PHY
307.2 MHz IBUFDS_GT
REFCLK
TXOUTCLK
BUFG
153.6 MHz*
TX/RX_CORE_CLK
JESD204
CORE LOGIC
TX/RX_CORE_CLK
*
example frequencies
Figure 3‐5: Artix-7, Kintex-7, Virtex-7 Subclass 0 Clocking
Resets
The JESD204 core uses the following resets.
System Reset
An asynchronous reset is provided to reset the complete system (core logic and
transceiver). On a transmit core this signal is tx_reset and on a receiver the reset signal
is rx_reset. The AXI4-Lite interface and configuration registers are unaffected by these
reset signals. A separate reset signal (s_axi_aresetn) is provided for the AXI4-Lite
interface which resets the configuration registers to the default values.

55
Software Reset
A register is provided through the AXI4-Lite interface which triggers a data path reset
sequence for the transmit or receive logic data path under software control. The
configuration registers are unaffected by this operation.
Note: The use of this reset does not reset the PLLs.
Watchdog Timer Reset

For devices using the GTXE2 transceiver, the core logic includes a Watchdog timer which
automatically provides a reset if SYNC is not achieved, or is lost for a prolonged period. The
Watchdog timer is implemented as a 20-bit counter which increments if SYNC remains
deasserted. The counter is clocked by the AXI4-Lite clock, so the timeout is directly related
to this clock frequency (for example, a 100 MHz clock provides a timeout of approximately
10 ms).
A Watchdog timeout reset acts in the same manner as the Software Reset.
The Watchdog timer can be disabled, if necessary, using a register access (see Reset
register), for example, during system testing where a link can be held out of SYNC for test
purposes. In normal system operation, Xilinx recommends that the Watchdog remain
enabled.
AXI4-Stream Reset
When either a system reset or software reset is performed the rx_aresetn or
tx_aresetn outputs are asserted Low until the reset cycle is completed.
Interfacing to the AXI4-Stream Data Interface

The AXI4-Stream data transmit and receive interfaces are used to pass JESD204 formatted
data to and from the core. The AXI data input and output by the core contains 4-bytes per
clock cycle per lane with the least significant byte position in each 32-bit block holding the
first byte received from the ADC or transmitted to the DAC. Figure 3-6 shows an example of
how the JESD204 data is mapped on to the AXI4-Stream interface.

56
TX?TDATA;= );= );= );= );= );= );= );= );= );= );= );= );=
TX?TDATA;= );= );= );= );= );= );= );= );= );= );= );= );=
TX?TDATA;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;=
TX?TDATA;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;=
,ANE );= );= );= );= );= );= );= );= );= );= );=
,ANE );= );= );= );= );= );= );= );= );= );= );=
,ANE 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;=
,ANE 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;= 1;=
Figure 3‐6: Four Lane DAC, Frame Size (F) = 1, 16 Bit I and Q with I Sample in Lanes 0 & 1
and Q Sample in Lanes 3 & 4
Transport Layer
The following examples show transport layer functions for some common ADC converters.
TI ADS42JB69 ADC 2 Converter, 4 Lane Mode

• 250 MHz sample clock, 4 serial lanes at 2.5 Gb/s
• Four 16 bit samples per converter per 62.5 MHz core clock cycle
adc0_sample0 = {rx_tdata[7:0], rx_tdata[39:32]}; // ADC0 sample N
adc0_sample1 = {rx_tdata[15:8], rx_tdata[47:40]}; // ADC0 sample N+1
ADI AD9250 ADC 2 Converter, 2 Lane Mode

• 250 MHz sample clock, 2 serial lanes at 5 Gb/s
• Two 14 bit samples per converter per 125 MHz core clock cycle
IDT ADC1443D ADC 2 Converter, 2 Lane Mode

• 200 MHz sample clock, 2 serial lanes at 4 Gb/s
• Two 14 bit samples per converter per 100 MHz core clock cycle

57

AXI4-Lite Management Interface

For AXI information, go to www.xilinx.com/ipcenter/axi4.htm.
The JESD204 core is configured and monitored using control and status registers accessible
through an AXI4-Lite interface.The AXI4-Lite address map is detailed in Register Space.

58
Subclass 1 Operation
Also to supporting lane operation at up to 12.5 Gb/s, devices of Subclass 1 support
deterministic latency using the SYSREF interface. Figure 3-7 shows the timing relationships
between the signals on a JESD204B link. Subclass 1 is recommended for designs requiring
deterministic latency.
3932%&
4X ),! BEGINS ON FIRST

39.#^ ,-&# CROSSING AFTER 39.#^ DE ASSERTED
48
$EVICE
,-&#
+ + + + + + + + + + + + + + + + + + + +2 $ $ $ $! 21 # #$ $! 2 $ $ $ $!
4RANSMIT ,ANES
3932%&
39.#^ )NTERNAL DELAY

FROM 3932%&
SAMPLED TO ,-&#
,-&#
28
$EVICE %ARLIEST
!RRIVAL + + + + + + + + + + + + + + + + + + + +2 $ $ $ $! 21 # #$ $! 2 $ $
,ANE
,ATEST
!RRIVAL + + + + + + + + + + + + + + + + + + + + + + + +2 $ $ $ $! 21 # #$ $! 2 $ $
,ANE
!LIGNED ,ANE
/UTPUT ON ALL + + + + + + + + + + + + + + + + + + + + + + + + + + + + +2 $ $ $ $! 21 # #$ $! 2 $ $
,ANES
$ETERMINISTIC DELAY
FROM 4X ),! OUTPUT
TO 2X ),! OUTPUT 8
Figure 3‐7: Deterministic Latency across the JESD204B Link
The SYSREF signal is distributed to all devices in a system. On assertion, the JESD204
receiver aligns its internal Local Multiframe Clock (LMFC) to the incoming SYSREF signal
and deasserts SYNC~. The LMFC counts through the octets in a multiframe. A LMFC crossing
occurs at the end of each multiframe. The device clock for the FPGA is the FPGA logic clock
(tx_core_clk or rx_core_clk).

59
When the transmit device detects the SYNC~ signal going High, it waits until the next LMFC
crossing and starts transmitting data. If ILA generation is supported, then this is the ILA
sequence; otherwise it is normal frame data. When the receiver detects that all lanes have
valid data, it buffers the data until the next LMFC crossing. Now the buffers are released and
the data sent to the client interface. In this manner the latency between the data output and
the SYSREF signal can be accurately ascertained and the end-to-end latency of the system
is deterministic and repeatable.
The length of the multiframe is intended by the JESD204B specification to be larger than
the longest possible delay across any lane in the JESD204B link. This might not be
achievable in practice in real systems due to short multiframe sizes dictated by A/D and
D/A devices.
SYSREF Timing
When JESD204B is used in Subclass 1, the SYSREF signal is the master timing reference for
the system. To achieve accurate deterministic latency the SYSREF signal must be captured
synchronously to the core clock. The SYSREF period must also be a multiple of 4-byte clock
periods because the core uses a 4-byte internal datapath. In the example provided with the
core, by default the SYSREF signal is captured on the falling edge of the core clock to allow
the rising edge of the clock and SYSREF to be aligned at the edge of the device; this is the
case typically when a divided device clock is used for SYSREF. See Clocking for details.
SYSREF Handling
The correct handling of SYSREF is critical in Subclass 1 operation. The JESD204B
specification allows SYSREF to be generated in any of the following ways:
• Periodic
• One-Shot
• “Gapped” Periodic
The JESD204 core provides several options for how SYSREF is handled for Subclass 1
operation to support maximum flexibility.
Note: The JESD204 core operates using a 32-bit (4-byte) datapath. If a periodic or gapped periodic
SYSREF is used in the system, the SYSREF period must be an integer multiple of the multiframe
period. But it must also be a multiple of 4-byte clocks if the multiframe period is not itself a multiple
of 4-byte clocks.

60
SYSREF Sampling Clock Edge

The core can be configured to sample SYSREF on either the rising or falling edge of the
core clock. This is a core generation time option on the customization in the Vivado IDE.
This selection controls the clock edge used for the first flip-flop (normally an I/O flip-flop)
in the SYSREF handling logic. Only this first flip-flop is affected by this setting; all other
processing is done on the rising edge of the core clock.
The default setting is for SYSREF to be sampled on the negative edge of core clock. This is
based on the assumption that an externally generated SYSREF is synchronous to the clock
supplied to the core (depending on clocking options, refclk or glblclk—see Clocking),
and thus arrives edge-aligned at the FPGA I/O. This is generally the case when SYSREF is
generated as a divided version of the source clock. Negative edge clocking in this case
provides the best timing margin.
To provide flexibility in the design, however, the core can be generated to use a positive
edge sampling of SYSREF. This should be used where the system-level timing is suitable for
such an approach.
Capturing SYSREF using the Falling Edge of the Clock
Capturing SYSREF using the negative edge of the clock allows SYSREF to be a divided
clock with rising edges aligned to the device clock. In this case, a low skew clock divider
chip is used to generate both the device clock and SYSREF.
Constraints can be applied in the example design to align the clock and SYSREF edges
within 1 ns, for example, as follows.
TIP: Higher line rates reduce the value.
# Set +/- 0.5ns between the rising edges of the clock and sysref
set_input_delay -clock jesd204_0_refclk -max 0.5 [get_ports *x_sysref]
set_input_delay -clock jesd204_0_refclk -min -0.5 [get_ports *x_sysref]
The timing of SYSREF can be confirmed using the report_datasheet command in the
Vivado Design Suite. An example is shown in Figure 3-8. This example uses the following
settings:
• Negative edge clocking of SYSREF using REFCLK as the core clock.

• REFCLK period is 6.4 ns (6.25 Gb/s line rate).
• SYSREF input delay = ±0.5 ns.
The report_datasheet command gives a setup of 1.2 ns and hold of 1.8 ns for the
SYSREF input. Figure 3-8 is a timing diagram based on these values.

61
REFCLK
3932%& )NPUT
NS NS SETUP NS HOLD NS
3932%& 6ALID
Figure 3‐8: SYSREF Timing using Negative Edge Sampling

Capturing SYSREF using the Rising Edge of the Clock
Capturing SYSREF using the positive edge is an option in the core. When this option is
selected, no constraint is applied to the SYSREF input. The timing of the SYSREF input can
be checked using the report_datasheet command in the Vivado Design Suite. An
example is shown in Figure 3-9. This example uses the following settings:
• Positive edge clocking of SYSREF using REFCLK as the core clock.

• REFCLK period is 6.4 ns (6.25 Gb/s line rate).
The report_datasheet command gives a setup of 4.6 ns and hold of -1.5 ns for the
SYSREF input. Figure 3-9 is a timing diagram based on these values.
REFCLK
SETUP NS
HOLD NS
3932%& 6ALID
Figure 3‐9: SYSREF Timing using Positive Edge Sampling
SYSREF Always
The core provides a programmable option allowing the choice of how a periodic SYSREF is
used internally. This is selected using the SYSREF Always control bit in the SYSREF
handling register (See Table 2-19).
When SYSREF Always is set to 0, only an initial SYSREF event seen after reset (or on link
resynchronization) is used to align the internal LMFC counter.
When SYSREF Always is set to 1, all SYSREF events are used to (re)align the LMFC counter.
This setting requires that the SYSREF period be a correct multiple of the multiframe period.
SYSREF on Initial Link Bring-Up

After a reset, the JESD204 core requires at least one SYSREF event to align the internal
LMFC counter, and bring up the link:
• An RX core requires an initial SYSREF event to align the LMFC, and then deasserts
SYNC on the next LMFC boundary when code group sync has been achieved. The core
does not deassert SYNC until an initial SYSREF event is detected.

62
• A TX core requires a SYSREF event to align the LMFC. The core begins ILA transmission
on an LMFC boundary after SYNC is deasserted. The core does not begin ILA
transmission until an initial SYSREF event is detected.
The system must ensure that SYSREF to the JESD204 core is generated after the core has
completed reset. This is of particular importance if the system is operating a One-shot
SYSREF.
SYSREF on Link Resynchronization

When a link has been initially brought up, if a link re-synchronisation is requested (by the
deassertion of SYNC by the receiving device), then the desired core behavior relative to
SYSREF can be controlled using the SYSREF Required on Re-Sync control bit in the
SYSREF Handling register (See Table 2-19).
When SYSREF Required on Re-Sync is set to 0, no SYSREF event is required for the link to
re-synchronize (the assumption is that LMFC counters continue to free-run and remain
valid).
• An RX core deasserts SYNC on the next LMFC boundary after code group sync.
• A TX core transmits ILA sequence on the next LMFC boundary after SYNC is deasserted.
When SYSREF Required on Re-Sync is set to 1, a SYSREF event is required for the link to
re-establish SYNC following a re-sync request.
• An RX core waits for a SYSREF event to realign the LMFC counter, and only deasserts
SYNC on the next LMFC boundary.
• A TX core waits for a SYSREF event to realign the LMFC counter, and only then begins
ILA transmission on an LMFC boundary after SYNC is deasserted.
This setting is particularly important in systems where a One-Shot SYSREF is used, or

where SYSREF is periodic, but SYSREF Always is set to 0.
SYSREF Delay
The deterministic latency mechanism as defined in the JESD204B standard requires that the
multiframe size be larger than the maximum possible delay across the link. In practice, this
is difficult to achieve, particularly with small frame sizes. However, as long as the multiframe
size is greater than the maximum variation in delay across the link, then deterministic
latency can be achieved.

63
A potential issue occurs when the maximum delay variation causes the overall latency to
straddle the boundary between two adjacent LMFC periods. In such a case, latency
variations of exactly one LMFC period can be observed between system restarts. Calculation
of the overall system latency (see RX End to End Latency or TX End to End Latency) should
be carried out to determine if this is a likely scenario.
In cases where this situation arises, the LMFC boundary in TX or RX devices can be moved
relative to each other by adding additional delay to SYSREF in one of the devices. The
JESD204 core supports this shifting of the internal LMFC by allowing an additional delay in
the internal SYSREF handling logic. This is programmed using the SYSREF Delay field in
the SYSREF handling register (see Table 2-19) which allows a delay of 0 to 15 core clock
cycles to be inserted between the SYSREF event detection and LMFC counter reset. A
change in value for SYSREF delay requires a core reset to force the link to realign.
Subclass 2 Operation
The operation of the JESD204B circuit in Subclass 2 mode is similar to a device in Subclass
1 mode. In this case deterministic latency across the link is achieved using the SYNC~
interface. When the receiver has aligned to the incoming idle characters from the
transmitter, it deasserts the SYNC~ signal. The transmitter detects this and waits until the
next LMFC crossing before transmitting data or the ILA sequence (depending on the setting
of the enable link synchronization control bit). The receiver buffers the data at its input until
the next LMFC crossing at its side of the link, before sending the received data to the client.
In Subclass 2 devices the transmitter and receiver latencies are as listed in the previous
Subclass 1 section.
JESD204B Receiver
This section covers implementation and system-level details for a JESD204B receiver core.
Lane Skew
The JESD204B receiver core has been verified to function with a lane to lane skew of up to
8 octets.
Elastic Buffer Implementation

In JESD204B devices, the receiver lane alignment elastic buffer is implemented in
distributed RAM. You can select the size of the buffer by adjusting the LMFC Buffer Size
(Maximum Octets per Multiframe) value in the GUI. This value should be set to a size that
holds a full multiframe of data.

64
Receive Latency
The latency variation is critical for JESD204B systems. The latency through the IP core is
fixed (it can be varied under user control—see Minimum Deterministic Latency Support for
details), but the transceiver introduces some variation as the internal receive elastic buffer
of the transceiver is included in the datapath. The receive datapath latencies are shown in
Table 3-8. The variation in latency is compensated automatically by the core to ensure that
the overall end-to-end latency has no variation. Refer to the Latency calculations checklist
AR#66143.
Table 3‐8: Receive Datapath Latencies

GTPE2 GTXE2 GTHE2 GTHE3 GTHE4 GTYE3 GTYE4
TRXLMFC 16 16 16 16 16 16 16
T RXIN 56±4 76±4 76±4 64±4 64±4 72±4 64±4
TRXOUT 0 0 0 0 0 0 0
Notes:
1. Latency values are given in byte clocks. See RX End to End Latency for
detailed use.
RX End to End Latency

Overall latency in a JESD204 system requires consideration of the various sources of fixed
and variable latencies across the link.
ADC Timing
The key parameters of the ADC required to calculate end to end latency are:
1. The fixed delay from SYSREF to LMFC (TTXLMFC)

2. The fixed delay from analogue input to LMFC (TTXIN)
3. The delay from LMFC to JESD204 serial output (TTXOUT)
The delay from SYSREF to LMFC and analogue data in to LMFC must be fixed for a Subclass
1 device but the delay from LMFC to JESD204 serial data out can vary because it is
compensated for in the receiver during alignment to LMFC. See Figure 3-10.

65
3932%&
,-&#
44X,-&#
!NALOG $ATA )N
44X).
3ERIAL $ATA /UT
44X/54
Figure 3‐10: ADC Timing
Core Timing
The key parameters of the FPGA receiver required to calculate end to end latency are:
1. The fixed delay from SYSREF to LMFC (TRXLMFC)

2. The delay from JESD204 input to LMFC (TRXIN)
3. The fixed delay from LMFC to AXI Data output (T RXOUT)
The delay from SYSREF to LMFC and from LMFC to AXI Data output must be fixed for a
Subclass 1 device but the delay from JESD204 serial data in to LMFC can vary because the
receiver buffer compensates for variations in end to end latency. In the latency calculations
T RXOUT = 0 and all the fixed delays are included in TRXLMFC. See Figure 3-11.
3932%&
,-&#
42X,-&#
*%3$ $ATA )N ! " # $
42X).
!8) $ATA /UT ! "
42X/54
Figure 3‐11: FPGA Receive Timing
Calculating End to End Latency

The end to end latency is always fixed and made up of a multiple number of LMFC periods
plus the fixed TX and RX delays. To calculate the end to end latency, use the following steps,
referring to Figure 3-12.

66
3932%&
44X,-&# 42X,-&#
4X ,-&#
2X ,-&#
4 ,-&#
!NALOG $ATA )N
44X). 44X/54
4X $ATA /UT
47)2%
2X $ATA )N
42X). 42X/54
2X !8) $ATA /UT
4,!4
Figure 3‐12: End to End Latency
Step 1 - Determine how many LMFC periods are required (N)
The delay between LMFC at TX and LMFC at RX (T) is an integer number (N) of LMFC periods
adjusted by the internal delays from SYSREF to LMFC of TX and RX:
T = N*LMFC - TTXLMFC + T RXLMFC
To ensure the overall propagation delay is constant between system restarts, the maximum
propagation delay must be less than T plus one LMFC period:
(TTXOUT + TWIRE(max) + T RXIN(max)) < T + LMFC
The minimum propagation delay must also be greater than T:
(TTXOUT + TWIRE(min) + TRXIN(min)) > T
Substituting (N*LMFC - TTXLMFC + T RXLMFC) for T gives:
(TTXOUT + TWIRE(max) + T RXIN(max)) < ((N+1)*LMFC - TTXLMFC + TRXLMFC )
(TTXOUT + TWIRE(min) + TRXIN(min)) > (N*LMFC - TTXLMFC + TRXLMFC)
It is possible that no valid value for N can be found if the received data arrives close to an
RX LMFC boundary and the variation in the link causes it to fall just before or just after the
boundary after resetting the system. This would be seen as a jump in latency of exactly one
LMFC period between system restarts. If no valid value can be found for N then the SYSREF
signals can be delayed relative to one another to move the RX LMFC boundary relative to
the TX LMFC boundary. For each cycle of delay added to TX SYSREF add 4 to T TXLMFC.
Additional delay can be added to the SYSREF processing in the JESD204 core to accomplish
this; see the SYSREF Handling register.

67
Step 2 - Calculate the end to end latency using N
The data is received after N LMFC periods and before N+1 LMFC periods so the minimum
deterministic latency is T plus one LMFC plus the fixed input delay at the FPGA and the fixed
output delay at the DAC:
T LAT = (T + LMFC) + T TXIN
T LAT = ((N*LMFC - T TXLMFC + T RXLMFC) + LMFC) + TTXIN
= (N+1)*LMFC - TTXLMFC + TRXLMFC + T TXIN
Example
JESD204 v7.1 using GTX Assume an ADC with Parameters) Assume

TRXLMFC = 16 T TXIN = 14 LMFC = 32
TRXIN = 76±4 T TXLMFC = 3 TWIRE = 0
TRXOUT = 0 T TXOUT = 6
(TTXOUT(max) + T WIRE(max) + T RXIN(max)) < ((N+1)*LMFC - T TXLMFC + T RXLMFC)
(6 + 0 + 80) < ((N+1)*32 - 3 + 16)
86< 109 (margin = 23)
(TTXOUT(min) + TWIRE(min) + TRXIN(min)) > (N*LMFC - TTXLMFC + T RXLMFC)
(6 + 0 + 72) > (N*32 - 3 + 16)
78 > 77 (margin = 1)
N=2 is OK, no need to skew SYSREF
The data is received after 2 LMFCs (N) and less than 3 LMFCs (N+1) so the latency is 3*LMFC
plus fixed delays:
T LAT = T + T TXIN
T LAT = (N+1)*LMFC - T TXLMFC + T RXLMFC + TTXIN
= 96 - 3 + 16 + 14 = 123
Note that in this case the margin (how far after the RX LMFC the data arrives) is very small
(1-byte periods) and any variation introduced by the ADC or connection between the ADC
and FPGA could cause the data to be received early causing the data to be received before
the LMFC boundary. There is plenty of margin before the third LMFC so, in this case, it is
advisable to delay the TX LMFC by 1 or 2 to increase the margin and therefore the reliability

68
of the system. If delaying the TX LMFC is not possible then the RX LMFC can be delayed by
5 cycles and N reduced by 1 as follows:
T RXLMFC becomes 16 + 5*4 = 36
(6 + 0 + 80) < ((N+1)*32 - 3 + 36)
86 < 97 (margin 11 byte periods)
(TTXOUT(min) + TWIRE(min) + TRXIN(min)) > (N*LMFC - TTXLMFC + T RXLMFC)
(6 + 0 + 72) > (N*32 - 3 + 36)
78 > 65 (margin 13 byte periods)
The margin numbers at min delay and max delay are closer in value which means the system
is operating with the received multiframe boundary close to the middle of the RX LMFC
period; this reduces the chances of the latency changing due to delay variations in the link.
The data is received after one LMFCs (N) and less than two LMFCs (N+1) so the latency is
2*LMFC plus fixed delays:
T LAT = T + T TXIN
= 64 - 3 + 36 + 14 = 111
Achieving Repeatable Latency

In some cases it is not necessary to know the absolute magnitude of the end to end latency
but it is necessary to ensure this delay is robustly repeatable.
Because high speed transceiver based links, such as those used for the physical layer in
JESD204B do not maintain the same data path latency through a reset or a power cycle,
issues may arise in systems where the start data arrival at the receive core is very close to
the LMFC boundary. Such systems may be unable to manage the small variability in delay
through the link that may occur between restarts.
Figure 3-13 shows the start of sample data arriving ''Just before'' and ''Just after'' the LMFC
boundary, illustrating the effect a restart can have. It can be seen that a very small
difference in data arrival time at the core can cause a change in the timing of the output
data equal to 1 LMFC period.

69
3932%&
,-&#
*UST "EFORE ),! 3AMPLE $ATA
$!4! ). ! " # $
$!4! /54 ! " # $
$!4! 6!,)$
*UST !FTER ),! 3AMPLE $ATA
$!4! ). ! " # $
$!4! /54 ! " # $
$!4! 6!,)$
%FFECT !RRIVAL $IFFERENCE /UTPUT $IFFERENCE ,-&#
Figure 3‐13: Data arrives ''Just before'' vs ''Just after'' the LMFC boundary
To protect against this problem, a margin must be introduced, around the LMFC boundary,
which the start of data must avoid. Figure 3-14 shows this.
,-&#
28 $!4! !RRIVAL
3AFE 5NSAFE 3AFE
Figure 3‐14: LMFC Margin

The LMFC is a periodic signal requiring a target window (TW) within which to aim.
Figure 3-15 shows this. If data can start within this TW, link robustness is ensured.
,-&# PERIOD
,-&#
28 $!4! !RRIVAL
5NSAFE 4ARGET 5NSAFE
Figure 3‐15: Target Window

The TW can generally be set reliably at between 2 CORE_CLK cycles before and 2 CORE_CLK
cycles after an LMFC boundary.
Note: This assumes that any variation in the output timing of the ADC is less than four octets. If the
output variation is greater than four octets, the margin can be increased and the TW decreased
accordingly.
The solution is to adjust the internal LMFC relative to the fixed data arrival such that arriving
data falls within the target window shown in Figure 3-15 (i.e., move the window).

70
This is achieved by starting the link, and using core registers to determine the amount of
data which was buffered, then taking steps to adjust the LMFC boundary until acceptable
values are attained. This process should only be required to be performed once during
development as when the system has been adjusted to ensure the data arrival is within the
target window, it should not require further adjustment.
The registers used during this process are:
BUFFER ADJUST: The JESD204B core contains a readable BUFFER ADJUST register (see
Table 2-44) for every JESD204B lane. This register indicates how much data was in the lane
alignment buffer for each lane at the LMFC boundary when the output data was released.
Note: The value in the BUFFER ADJUST register may be different for each lane due to inter-lane
skew on the link. The value of interest is the smallest value of all the lanes. This marks the starting
point in time when all lanes had valid data. This is the point where the core was actually ready to
release data. The value in this register is a count in octets and there are four octets per CORE CLK
cycle.
SYSREF DELAY: Located in the SYSREF HANDLING register (seeTable 2-19): This register
delays the internal LMFC boundaries relative to SYSREF by an integer number of CORE CLK
cycles. Therefore programming a SYSREF DELAY of 0x1 will cause the LMFC to be delayed by
four octets.
Procedure - Achieving Repeatable Latency

1. Calculate the Multi Frame (MF) size. MF= F * K
(Where F= Frame Size and K= Number of Frames per Multi Frame.)
The larger the value of MF, the greater the target window will be. It is recommended to
pick a value for K that results in a MF of at least 32 octets.
2. Calculate the TW maximum value in octets based on the MF size. This is:
Max = (MF-0x8)
Min= 0x8. (0x8 = 2 CORE_CLK cycles)
3. Configure the system and start the link. At this point all delays can be unknown.
4. Once the link is running, read the JESD204B RX core BUFFER ADJUST register for every
JESD204B lane in use. Select the smallest value read from the BUFFER ADJUST register
and call this value BUF_FILL.
5. If BUF_FILL falls between the Min and Max values (calculated at step 2), the data arrival
is within the safe TW and no further action is required. If however the BUF_FILL does not
fall between the Min and Max values then the following action should be taken.
a. Program the SYSREF DELAY register with a delay value calculated as follows:

71
If the BUF_FILL value is low then the SYSREF DELAY value programmed should be
increased by 1 or 2 as follows:
If BUF_FILL < Min - 4. Then SYSREF DELAY should be increased by 2
If BUF_FILL < Min but > Min - 4. Then SYSREF DELAY should be increased by 1
If the buffer is almost full, then the SYSREF DELAY value programmed should be
increased by 3 or 4 (i.e., 1 or 2 plus the low margin of 2) as follows:
b. Reset the JESD204B receive core and reinitialize the link. This step must be
performed before the modified SYSREF_DELAY value will affect the LMFC.
c. Re-read the BUFFER ADJUST register for every lane to confirm the data arrival is now
within the target window.
The calculated SYSREF DELAY value should be stored for future use when configuring
this link.
Minimum Deterministic Latency Support

When the JESD204B link is first established in Subclass 1 and Subclass 2 devices, the
receiver outputs data as shown in Figure 3-16. Data is output on the LMFC crossing after
valid data is detected in all lanes. It is possible to support minimum latency by adjusting the
number of octets input on the buffer_delay register.
An indication of the maximum allowable reduction of the latency is output on the

buffer_adjust register. This provides an indication of the difference between the write
and read pointers of the receiver elastic buffer in each lane. The number of octets output in
each 10-bit value give an indication of the buffer fill level in each lane. The lowest number
given can be used to calculate a value that can be programmed to the buffer_delay
register to reduce the overall latency by that number of octets. The maximum value
programmed into the buffer delay register must take into account the eight octet margin
described in Achieving Repeatable Latency, and therefore should not be greater than the
lowest buffer_adjust value minus eight.
A reset of the JESD204 receive core and a full link resynchronization cycle must take place
before the modified latency setting is acted upon. A minimum latency example is shown in
Figure 3-16.

72
3932%&
4X ),! BEGINS ON FIRST

39.#^ ,-&# CROSSING AFTER 39.#^ DE ASSERTED
48
$EVICE
,-&#
+ + + + + + + + + + + + + + + + + + + +2 $ $ $ $! 21 # #$ $! 2 $ $ $ $!
4RANSMIT ,ANES
3932%&
39.#^ CYCLES DELAY

FROM 3932%& 28 "UFFER !DJUST
SAMPLED TO ,-&#
,-&#
28
$EVICE %ARLIEST
!RRIVAL + + + + + + + + + + + + + + + + + + + +2 $ $ $ $! 21 # #$ $! 2 $ $
,ANE
,ATEST
!RRIVAL + + + + + + + + + + + + + + + + + + + + + + + +2 $ $ $ $! 21 # #$ $! 2 $ $
,ANE
!LIGNED ,ANE
/UTPUT ON ALL + + + + + + + + + + + + + + + + + + + + + + + + + +2 $ $ $ $! 21 # #$ $! 2 $ $
,ANES
$ETERMINISTIC
DELAY
FROM 4X ),!
OUTPUT
8
TO 2X ),! OUTPUT
Figure 3‐16: Minimum Deterministic Latency
Error Signaling Using the SYNC~ Interface

In the JESD204 RX core, the SYNC~ signal can be deasserted for two frame periods at the
end of each multiframe to indicate an error has occurred which does not require a full
re-initialization of the link. This behavior is enabled by the deassertion of the
disable_error_reporting control bit.
The SYNC~ signal is a 1-bit output; this enables the correct error output for a frame size of
down to two octets. The signal is Low when the receiver has detected an error. An error
occurs when an idle or an unexpected control character is received during normal frame
transmission.
To give a frame-accurate SYNC~ output when the frame size is one octet the SYNC~ signal
should be asserted for only half a cycle of the device clock. This is not implemented in the
core as it would require a dedicated clock (either twice the device clock speed or an inverted
device clock). If accurate timing of SYNC~ assertion for error reporting is required logic

73
must be added externally to generate a half cycle pulse on the external SYNC~ pin if the
core SYNC~ signal is asserted for a single cycle and F = 0.
Link Re-initialization
In the JESD204B RX core. Errors that require a full link re-initialization are signaled by
deasserting SYNC~ for a period sixteen frames. When this occurs, the transmitter should
fall back out of data transmission mode and renegotiate the link as described in the
previous device subclass sections.
The following error conditions require a full link re-initialization:
• 4 consecutive 8b10b decoder errors (disparity or not in table).

• 4 consecutive unexpected Kx.y characters (rxcharisk is expected only at the end of
the frame).
• 8 consecutive alignment errors (multiframes not aligned to LMFC).
A TX may initiate a re-initialization using the data interface by sending 4 consecutive Kx.y
characters. This causes the error condition above to be triggered in the receiver. K28.5
(0xBC) would normally be used for this.
JESD204B Transmitter
This section covers implementation and system-level details for a JESD204B transmitter
core.
Transmit Latency
The latency variation is critical for JESD204B systems. The latency through the IP core is
fixed but the transceiver introduces some variation as the internal transmit elastic buffer of
the transceiver is included in the datapath.
The transmit datapath latencies are shown in Table 3-9. Refer to the Latency calculations
checklist AR#66143.

74
Table 3‐9: Transmit Datapath Latencies

GTPE2 GTXE2 GTHE2 GTHE3 GTHE4 GTYE3 GTYE4
T TXLMFC 36 36 36 36 36 36 36
T TXOUT 41±2 56±2 56±2 52±2 52±2 56±2 52±2
T TXIN 0 0 0 0 0 0 0
Notes:
1. Latency values are given in byte clocks. See TX End to End Latency for detailed use.
TX End to End Latency

Overall latency in a JESD204 system requires consideration of the various sources of fixed
and variable latencies across the link.
Core Timing
The key parameters of the FPGA transmitter required to calculate end to end latency are:
1. The fixed delay from SYSREF to LMFC (TTXLMFC)

2. The fixed delay from AXI input to LMFC (T TXIN)
3. The delay from LMFC to JESD204 serial output (TTXOUT)
The delay from SYSREF to LMFC and AXI data in to LMFC must be fixed for a Subclass 1
device but the delay from LMFC to JESD204 serial data out can vary because it is
compensated for in the receiver during alignment to LMFC. See Figure 3-17.
3932%&
,-&#
44X,-&#
$IGITAL $ATA )N
44X).
3ERIAL $ATA /UT
44X/54
Figure 3‐17: FPGA TX Timing
DAC Timing
The key parameters of the DAC receiver required to calculate end to end latency are:
1. The fixed delay from SYSREF to LMFC (TRXLMFC)

2. The delay from JESD204 input to LMFC (TRXIN)
3. The fixed delay from LMFC to analog output (TRXOUT)

75
The delay from SYSREF to LMFC and from LMFC to output must be fixed for a Subclass 1
device but the delay from JESD204 serial data in to LMFC can vary as the receiver buffer
compensates for variations in end to end latency. See Figure 3-18.
3932%&
,-&#
42X,-&#
*%3$ $ATA )N ! " # $
42X).
!NALOG /UTPUT ! "
42X/54
Figure 3‐18: DAC RX Timing
Calculating End to End Latency

The end to end latency is always fixed and made up of a multiple number of LMFC periods
plus the fixed TX and RX delays. To calculate the end to end latency, use the following steps,
referring to Figure 3-19.
3932%&
44X,-&# 42X,-&#
4X ,-&#
2X ,-&#
4 ,-&#
!8) $ATA )N
44X). 44X/54
4X $ATA /UT
47)2%
2X $ATA )N
42X). 42X/54
!NALOG $ATA /UT
4,!4
Figure 3‐19: End to End Latency
Step 1 – Determine how many LMFC periods are required (N)

The delay between LMFC at TX and LMFC at RX (T) is an integer number (N) of LMFC periods
adjusted by the internal delays from SYSREF to LMFC of TX and RX:
T = N*LMFC - TTXLMFC + T RXLMFC

76
To ensure the overall propagation delay is constant between system restarts, the maximum
propagation delay must be less than T plus one LMFC period:
(TWIRE(max) + T RXIN(max) + T TXOUT(max)) < T + LMFC
The minimum propagation delay must also be > T:
(TWIRE(min) + TRXIN(min) + T TXOUT(min)) > T
(TWIRE(max) + T RXIN(max) + T TXOUT(max)) < ((N+1)*LMFC - T TXLMFC + T RXLMFC)
(TWIRE(min) + TRXIN(min) + T TXOUT(min)) > (N*LMFC - TTXLMFC + T RXLMFC)
It is possible that no valid value for N can be found if the received data arrives close to an
RX LMFC boundary and the variation in the link causes it to fall just before or just after the
boundary after resetting the system. This would be seen as a jump in latency of exactly 1
LMFC period between system restarts. If no valid value can be found for N then the SYSREF
signals can be delayed relative to one another to move the RX LMFC boundary relative to
the TX LMFC boundary. For each cycle of delay added to TX SYSREF add 4 to TTXLMFC.
Additional delay can be added to the SYSREF processing in the JESD204 core to accomplish
this; see the SYSREF Handling register.
Step 2 – Calculate the end to end latency using N

The data is received after N LMFC periods and before N+1 LMFC periods so the min
deterministic latency is T plus one LMFC plus the fixed input delay at the FPGA and the fixed
output delay at the DAC:
T LAT = (T + LMFC) + T TXIN + T RXOUT
TLAT = ((N*LMFC - TTXLMFC + TRXLMFC ) + LMFC) + TRXOUT + T TXIN
= (N+1)*LMFC - TTXLMFC + TRXLMFC + T TXIN + T RXOUT
Example
JESD204 v7.1 using GTX Assume a DAC with Parameters Assume

T TXLMFC = 36 bytes T RXIN = 50±2 bytes T WIRE = 0
T TXOUT = 56±2 bytes T RXLMFC = 4 bytes LMFC = 32 bytes
T TXIN = 0 T RXOUT = 20 bytes

77
(TT XOUT(min) + TWIRE(min) + T RXIN(min)) > (N*LMFC - TTXLMFC + T RXLMFC)
(58 + 0 + 52) < ((N+1)*32 - 36 + 4) and (54 + 0 + 48) > (N*32 - 36 + 4)
Try N = 4
110 < 128 and 102 > 96
N = 4 is OK, no need to skew SYSREF
The data is received after 4 LMFCs (N) and less than 5 LMFCs (N+1) so the latency is 5*LMFC
plus fixed delays:
T LAT = T + T TXIN
= 160 - 36 + 4 + 20 = 156 byte clock periods
Transmitter Phase Adjustment for Subclass 2

The core provides ports to enable the alignment of the frame clock and LMFC internal to the
FPGA to those of the DAC receiver. The required clock and LMFC phase adjustments are
communicated to the DAC using the tx_cfg_adjcnt, tx_cfg_adjdir and
tx_cfg_phadj registers as detailed in Table 2-14.
In Subclass 2 devices, the DAC receiver deasserts the SYNC~ signal on its internal LMFC
boundary. At the FPGA transmitter it is the responsibility of the client logic to detect the
deassertion of the SYNC~ signal and to compare its timing to that of the transmitter LMFC.
If adjustment of the DAC LMFC phase is required, the client inputs the required adjustment
step count to the tx_cfg_adjcnt register. The direction of the phase adjustment is input
on tx_cfg_adjdir and an adjustment request is signaled by the assertion of the
tx_cfg_phadj register.
The values on the phase adjustment ports are embedded in bytes 1 and 2 of the ILA
sequence that is sent to the DAC during link initialization. On the reception of the ILA, the
DAC adjusts its LMFC phase by the step count value and sends back an error report with the
new LMFC phase information. This process can be repeated until the LMFC at the DAC and
the FPGA are aligned.
Link Test Modes

The JESD204 transmitter core supports the following Data link Layer test modes as
described in JESD204B 5.3.3.8.2.
Note: This section does not apply to the JESD204 receiver core.

78
Continuous D21.5 Characters

This mode transmits a continuous sequence of /D21.5/ characters. This pattern is created
within the GTX/GTH/GTY transceivers by setting PRBSSEL to 110. To enable this test mode,
set Test Mode Select in the Configuration register to 011 or if the Additional transceiver
control and status ports box is checked on the JESD204 GUI, set port, txprbssel[2:0], to 110
(see Table 2-12 for the debug port description).
Modified RPAT
This mode transmits a continuous sequence of a modified random pattern. This pattern is
generated by the RPAT block and must be selected in the Vivado IDE. The block generates a
32-bit output containing four RPAT sequences which is then sent to each transmitter. To
transmit this pattern, set Test Mode Select in the Configuration register to 101.
JSPAT
This mode transmits a continuous sequence of a scrambled jitter pattern. This pattern is
generated by the JSPAT block and must be selected in the Vivado IDE. The block generates a
32-bit output containing four JSPAT sequences which is then sent to each transmitter. To
transmit this pattern, set Test Mode Select in the Configuration register to 111.
On the receiver side, an Error Counting block is used to calculate the number of errors in the
received data. The counter has been modified to calculate all the errors in the received data.
To enable this block, signal rx_cfg_link_test_enable must be set High. A block is
created for each transceiver and uses the rx_disperr and rxnotintable signals to
calculate the number of errors. The block produces a 32-bit output which is then written to
a register.
Transceiver PRBS test patterns

The Test Modes register may be used to configure the transceivers to output various PRBS
test patterns.
Link Re-initialization
In the JESD204B TX core. A full link re-initialization will be triggered if the RX deasserts
SYNC~ for a period of 5 tx_core_clk cycles (20 octets).

79
Sharing Transceivers between Transmit and

Receive
RECOMMENDED: Xilinx recommends using Vivado IP integrator to simplify the process of sharing
transceivers using the JESD204_PHY IP.
Sharing Transceivers in IP Integrator

The JESD204_PHY core (see the JESD204 PHY LogiCORE IP Product Guide (PG198) [Ref 4])
provides a simple way to instantiate transceivers for use with the JESD204 cores. Any
number of JESD204_PHY cores can be connected to any number of JESD204 cores to cater
for any combination of ADCs and DACs using different line rates and lane counts.
An example of a two lane TX and two lane RX sharing two transceivers is shown in
Figure 3-20. The transmitter is configured for 3 Gb/s and the receiver configures for 6 Gb/
s. The refclk is 150 MHz and shared between TX and RX. Separate core clocks are
provided for TX and RX to support subclass 1 (see Figure 3-1 in Clocking, page 46).
Figure 3‐20: Two Lane TX and Two Lane RX Sharing Transceivers

80
The connections between the JESD204 cores and the JESD204_PHY can be seen more
clearly in Figure 3-21, which has the external I/O removed.
Figure 3‐21: Connections Required between JESD204 and JESD204_PHY
When sharing transceivers between cores with different lane counts there should be
multiple JESD204_PHY cores instantiated to ensure the JESD204 links can be reset
independently. For an example, see Figure 3-22. In this example, three independent, two
lane transmitters are connected to three JESD204_PHYs and a single six lane receiver shares
the transceivers.
All signals are connected directly between the JESD204 and JESD204_PHY as in the previous
examples, except the rx_reset_done from each JESD204_PHY must be AND’d together to
ensure all six transceivers have completed reset before the six lane receiver is enabled.

81
Figure 3‐22: Multiple JESD204_PHYs Instantiated for Independent Transmitters
Sharing a QPLL
To share the QPLL between two JESD204_PHYs, one JESD204_PHY should be configured
with shared logic in core (jesd204_phy_1 in Figure 3-23) and the other with shared logic
in the example design (jesd204_phy_0 in Figure 3-23). The QPLL outputs are available on
the core containing the shared logic and can be connected to the QPLL inputs on the core
without shared logic as shown in Figure 3-23.

82
Figure 3‐23: Sharing QPLL between Two JESD204_PHYs

83
Sharing Transceivers in RTL Designs

When sharing transceivers in an RTL design, the same JESD204 and JESD204_PHY
combinations shown in the previous section should be used. The JESD204 IP and
JESD204_PHY should be connected together using Verilog or VHDL in exactly the same way
as shown in Figure 3-20 to Figure 3-22. Clock buffers for the refclk (IBUFDS_GTEn) and
(IBUFDS and BUFG) should be added manually. The <component_name>_support.v and
<component_name>_clocking.v files provided with the IP Example Design can be used
as a reference for adding clock buffers to the design. When instantiating the JESD204 IP, the
.xci should be directly used and not the support layer as in previous releases of the IP.
Powering down unused GT channels

For designs that are generated with shared logic in the core and without Transceiver Debug
enabled, the opposite and unused TX or RX GT channels are powered down by default.
For designs that are generated with shared logic in the core with Transceiver Debug
enabled, the user must drive the GT_PD (Power Down) bits of the unused GT channels, if
required.
For designs that are generated with shared logic in the example design, the JESD204 PHY
core controls the power down state of the individual GT channels. Powering down individual
TX and RX lanes can be achieved using either the AXI register interface or the Transceiver
debug pins.

84
Chapter 4
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 Vivado 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 18]
• Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 17]
• Vivado Design Suite User Guide: Getting Started (UG910) [Ref 19]
• Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 21]
Customizing and Generating the Core

This section includes information on using Xilinx tools to customize and generate the core
in the Vivado Design Suite.
If you are customizing and generating the core in the IP integrator, see the Vivado Design
Suite User Guide: Designing IP Subsystems using IP Integrator (UG994) [Ref 18] 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 you can 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 17] and
the Vivado Design Suite User Guide: Getting Started (UG910) [Ref 19].
Note: Figures in this chapter are illustrations of the JESD204 GUI in the Vivado Integrated Design
Environment (IDE). This layout might vary from the current version.

85
Configuration Tab
Figure 4‐1: Configuration Tab
• Component Name – The component name is used as the base name of the output files
generated for the core. Names must begin with a letter and must be composed from
these characters: a through z, 0 through 9 and “_” (underscore).
• Transmit or Receive – The core can be configured as a transmitter, for connection to
DAC devices, or receiver, for connection to ADC devices. Separate Transmit and Receive
cores can optionally share transceivers (see Sharing Transceivers between Transmit and
Receive).
• LMFC Buffer Settings in Receiver – LMFC buffer (buffer for lane alignment and
deterministic latency support). The size of this buffer (per serial lane) can be selected.
IMPORTANT: The LMFC buffer size option is included to allow minimal resource use where appropriate.
The LMFC buffer size should be greater than the MAXIMUM multiframe size which is used in the
implemented design (multiframe size is F*K, where F = octets per frame; K = frames per multiframe)
• Number of Lanes – The core supports 1 to 8 lanes. For interfaces requiring more than
8 lanes, multiple core must be used. The Lane ID registers can then be programmed to
signal the correct number for each lane.

86
• Pattern Generators – Select “Include RPAT” and/or “Include JSPAT” to include the logic
required to generate these test patterns if required. See Link Test Modes for more
information.
• AXI4-Lite Clock Frequency – The frequency of the clock connected to the AXI4-Lite
Management Interface.
For UltraScale™ architecture devices the valid frequency range is from 10 MHz to
200 MHz.
For 7 series devices, the valid frequency range available is dependent on the Shared
Logic Selection:
° When Include Shared Logic in core is selected, the AXI clock is common with the
Transceiver DRP clock. The maximum frequency is limited to the maximum DRP
clock frequency for the selected device.
° When Include Shared Logic in example design is selected, the valid range is from
10 MHz to 200 MHz.
• Clocking Options, SYSREF Sampling Edge – The clock edge which is used to sample
SYSREF can be selected. See SYSREF Handling for more information.
• Drive JESD204 Core Clock using Global Clock – This option is only available under
certain conditions. See Clocking section for details.

87
Link Configuration Tab

Figure 4‐2: Link Configuration Tab
• Default Link Parameters – All of the following parameters set the default (reset) value
stored in the equivalent configuration register, see Register Space in Chapter 2. The
value set during core generation is overwritten if the register is written through the
AXI4-Lite configuration bus. If software is used to configure the converter frame
parameters, there is no need to configure values here. These configuration settings can
be used to use the IP without an AXI4-Lite master connected. Only a small subset of the
registers can be configured this way. To access all configuration settings and monitor
link status, the AXI4-Lite interface should be connected.
° Octets per Frame (F) – Sets the default (reset) value of register 0x020. See
Table 2-23.
° Frames per Multiframe (K) – Sets the default (reset) value of register 0x024. See
Table 2-24.
° Scrambling Enabled – Sets the default (reset) value of register 0x00C. See
Table 2-18.
° SYSREF Always – Sets the default (reset) value of bit 0 of register 0x010. See
Table 2-19.

88
° SYSREF Required on Re-Sync – Sets the default (reset) value of bit 16 of register
0x010. See Table 2-19.
° Subclass – Sets the default (reset) value of register 0x02C. See Table 2-26.
Shared Logic Tab

Figure 4‐3: Shared Logic Tab
The JESD204 IP can be generated with the shared logic included in the core or with the
shared logic included in the example design to enable the sharing of logic between multiple
IP cores as shown in Figure 4-4. Select Include Shared Logic in core to include the JESD204
PHY core and clock buffers, if applicable in the core. Select Include Shared Logic in
example design to instantiate the JESD204 core and clock buffers in the example design so
they can be shared with other IP cores, if desired.

89
<component_name>
No Shared Logic Encrypted RTL
clk clk
rst rst
AXI-S AXI4-Stream
Transceiver
I/F
AXI4-Lite Config
AXI4-Lite Control & Status
IPIF Registers
jesd204_phy_v1_0
<component_name>
Includes Shared Logic
QPLL
Clock Encrypted RTL

clk Buffers clk
rst rst
GT_CHANNEL
AXI-S AXI4-Stream Serial I/O
Transceiver
I/F
AXI4-Lite AXI4-Lite Config

Control & Status Channel Specific Logic
IPIF Registers
Figure 4‐4: Difference Between Cores Including and Excluding Shared Logic
For simple unidirectional lanes, including the shared logic in the core is preferred. The QPLL
output signals are available as top-level ports enabling the QPLL to be shared with other IP
cores using the same transceiver quad. If you need to create a design where the transceiver
is shared between a receive and transmit core, then generate cores with the shared logic in
the example design and see Sharing Transceivers between Transmit and Receive, page 80.

90
JESD204 PHY Configuration Tab

Figure 4‐5: JESD204 PHY Tab
• Transceiver Parameters – The line rate and reference clock frequency can be selected
using the Vivado IDE (see Figure 4-1). For any selected line rate, valid reference clock
frequencies can be selected from a drop-down list.
For UltraScale architecture devices, a free-running DRP clock must be supplied, and the
frequency (within the displayed valid range) must be entered in the DRP Clock
Frequency box.
Devices that support GTYE3 or GTYE4 may also support transceiver type selection (GTH
or GTY).
For 7 series devices, depending on the Shared Logic configuration, a DRP clock can be
provided. When Shared Logic in the core = 1, the DRP clock is tied to the AXI clock.
° Additional Transceiver Control and Status Ports – Select to include additional

transceiver control and status ports for debug purposes. See Transceiver Debug
Interface for more information. This selection is only available if the Shared Logic
selection is set to Shared Logic in Core.

91
User Parameters
Table 4-1 shows the relationship between the GUI fields in the Vivado IDE and the User
Parameters (which can be viewed in the Tcl console).
Table 4‐1: Vivado IDE Parameter to User Parameter Relationship

Vivado IDE Parameter/Value(1) User Parameter/Value(1) Default Value
Transmit or Receive C_NODE_IS_TRANSMIT 0 (= Transmit)
LMFC Buffer Size (2) C_LMFC_BUFFER_SIZE 1024
Lanes per Link (L) C_LANES 2
Include RPAT Generator(3) USE_RPAT FALSE
Include JSPAT Generator (3) USE_JSPAT FALSE
Sample SYSREF on C_SYSREF_SAMPLING_EDGE 0 (= Negative Edge)
AXI4-Lite Clock Frequency AXICLK_FREQ 100.00
Transceiver Parameters
Line Rate(4) GT_Line_Rate 8.0
(4)
Reference Clock GT_REFCLK_FREQ 200.0
DRP Clock Frequency DRPCLK_FREQ 200.0 for UltraScale
100.0 for 7 series
PLL Type C_PLL_SELECTION 0 (=CPLL)
Shared Logic SupportLevel 0
Include Shared Logic in core 1
Include Shared Logic in example design 0
Additional Transceiver Control
TransceiverControl FALSE
and Status ports
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.
2. Receiver only.
3. Transmitter only.
4. Varies depending on device.

92
Output Generation
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 17]. The
final step in generating IP is to select DCP. If you have included the shared logic in the core
and need to change the transceiver configuration then ensure that DCP is not selected.
Constraining the Core

This section describes how to constrain a design containing the JESD204 core. This is
accomplished by using the XDC delivered with the core at generation time. An additional
XDC file is generated with the IP example design; only the core XDC file should be used in
user designs.
Required Constraints
This section defines the constraint requirements for the core. Constraints are provided in
several XDC files which are delivered with the core and the example design to give a
starting point for constraints for the user design.
There are four XDC constraint files associated with this core:
• <corename>_example_design.xdc
• <corename>_ooc.xdc
• <corename>.xdc
• <corename>_clocks.xdc
The first is used only by the example design; the second file is used for Out Of Context
support where this core can be synthesized without any wrappers; the third file is the main
XDC file for this core. The last file defines constraints which depend on clock period
definition, either those defined by other XDC files or those generated automatically by the
Xilinx tools, and this XDC file is marked for automatic late processing within the Vivado
design tools to ensure that definitions exist.
Device, Package, and Speed Grade Selections

See the appropriate device data sheet listed in References to determine the maximum line
rate supported. Not all devices, packages and speed grades can operate at the maximum
line rate supported by the IP.

93
Clock Frequencies
The reference clock and core clock frequency constraints vary depending on the selected
line rate and reference clock when generating the core. See the generated XDC for details.
SYSREF Constraints
The example design provided with the JESD204 core has an example of a setup and hold
window assuming the SYSREF and clock have aligned edges. The following example is for
a transmit design with a 1 ns setup and hold window (the exact requirements for these
constraints depend on the chosen method of generating SYSREF and the board layout, the
constraints provided with the core are for example only):
set_input_delay -clock clk -max 0.5 [get_ports tx_sysref]
set_input_delay -clock clk -min -0.5 [get_ports tx_sysref]
If the SYSREF input sampling edge is changed, these constraints require modification. See
SYSREF Sampling Clock Edge in Chapter 3 for more details.
Clock Domains
There are also several paths where clock domains are crossed. These include the
management interface. See the generated XDC file for details.
Clock Management
Reference clock and core clock resources require location constraints appropriate to your
top-level design.
Clock Placement
Reference clock input should be given location constraints appropriate to your top-level
design and to the placement of the transceivers.
Core clock input (if required) should be given location constraints appropriate to your
top-level design.
Banking
All ports should be given location constraints appropriate to your top-level design within
banking limits.
Transceiver Placement
Transceivers should be given location constraints appropriate to your design. In some cases,
example transceiver location constraints can be found in the example design XDC file.

94
I/O Standard and Placement

All ports should be given I/O standard and location constraints appropriate to your
top-level design.
Simulation
TFor 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 21].
IMPORTANT: For cores targeting 7 series or Zynq-7000 AP SoC 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 17].

95
Chapter 5
Example Design
The JESD204 IP can be generated as an IP in TX or RX configuration. Both selections come
with a lightweight test harness to enable familiarization with the design and signal
interface.
In Vivado®, create a new empty project. Be sure to select the FPGA part that you wish to
use. Using the Vivado IP catalog, select the JESD204 IP core and configure as required.
Right-click the block under Design Sources and select Open IP Example Design, as shown
in Figure 5-1. This opens a new Vivado project containing the complete RX or TX design
example.
Figure 5‐1: Opening the Example Design

96
Common Design Elements

The example design is configured to model one ADC per lane, and samples at twice the core
clock rate. Both the RX and TX JESD204 IP blocks can be configured for 1 to 12 lanes. Your
generated design example reflects this choice. For all lane configurations, F is set to 2,
therefore for all examples LMF = LL2.
Valid configurations are 112, 222, 332, 442, 552, 662, 772, 882, 992, 10102, 11112 and
12122.
TX Design Example RX Design Example
Sine Wave Transport Layer JESD204 JESD204 Transport Layer Sine Wave
Generation to 32-bit JESD TX IP RX IP from 32-bit * L Checking
TX Interface JESD RX Interface
ADC(L) Lane(L) Lane(L) TEST(L)
ADC2 Lane2 Lane2 TEST2
Logic included in TX Logic included in RX

ADC1 Lane1 design example. RX logic design example. TX logic Lane1 TEST1
is modelled for testing is modelled to generate
data path. data for testing data path.
Figure 5‐2: TX to RX Data Path Summary

In both example designs, the JESD204 interface parameters are the same and are listed in
Table 5-1. The initialization sequences configure both designs. You can modify the line and
core clock rates during IP configuration if using UltraScale™ devices.
‘
Table 5‐1: Interface Parameter Description

Parameter Unit Value Comment
F (Octets per frame) 2 This can be modified as a multiple of two.
ADC Sample Width Bits 14 Two control bits are added to increase this to 16-bits.
Transport Layer Mapping

The JESD204 per-lane data interface is 32 bits wide. The AXI4-Stream interface is L*32-bits
wide. Samples must be mapped into and out of this interface. Refer to the appropriate
converter datasheet (References) for information on correctly mapping samples into the
transport layer.
This design example packages two samples per 32-bit data word passed to the AXI4-Stream
interface. Each sample is made up of a 14-bit sine wave sample and two example control
bits. The mapping is consistent across each lane. Samples are not distributed between
lanes. There is one sample per frame, and the sample bit mapping is:

97
• Sample (S)[15:14] – Example ADC control bits

• Sample (S)[13:0] – Sine wave sample value
Transport Layer interface, per LANE in TX design example Transport Layer interface, per LANE, in RX design example
Sample generation, from sine wave lookup Mapping to the De-mapping of Unpacked samples
table. Example CTRL bits are added to each 32 bit JESD TX 32-bit * L JESD
sample. A frame is made up of 2 samples interface RX interface
15 15 15 (L-1 * 32) (L-1 * 32) 15 15 15

14 14 14 + 31 + 31 14 14 14
13 13 13 JESD204 JESD204 13 13 13
Sample Sample
LLS3
LLS1
LLS5
LLS1
LLS3
LLS5
TX IP RX IP
(N+1) (N+1)
Samples as they appear on a TX GT lane. These are transmitted as 8b/10b
symbols. Transmission is from right to left
(L-1 * 32) (L-1 * 32)
0 0 0 + 16 + 16 0 0 0
LLS5 LLS4 LLS3 LLS2 LLS1 LLS0
15 15 15 (L-1 * 32) (L-1 * 32) 15 15 15
14 14 14 + 15 + 15 14 14 14
13 13 13 Frame 5 Frame 4 Frame 3 Frame 2 Frame 1 Frame 0 13 13 13
Sample Sample
LLS0
LLS2
LLS4
LLS0
LLS4
LLS2
(N) (N)
(L-1 * 32) Logic Included in TX Logic Included in RX (L-1 * 32)

0 0 0 +0 design example. RX logic design example. TX logic +0 0 0 0
data path data for testing data path
Figure 5‐3: Per-lane Data Generation and Transport Layer Mapping of Data
Octet mapping in the transport layer, per LANE, in TX Transport layer interface, per LANE, in RX design
design example example
Sample generation, from sine wave Sample unpacked format in relation to

lookup table. Example CTRL bits are TX data stream. Earliest samples shown
added to each sample. A frame is made on left
up of two samples.
15 15 15 15
oct3
oct7
14 14
oct7
oct3
14 14
13 13 JESD204 JESD204 13 13
LLS1
LLS3
TX IP RX IP
LLS3
LLS1
Samples as they appear on a TX GT lane. These are transmitted

as 8b/10b symbols. Transmission is from right to left.
oct2
oct6
oct6
oct2
LLS2 LLS2 LLS1 LLS1 LLS0 LLS0 0 0

0 0
oct5 oct4 oct3 oct2 oct1 oct0
15 15 15 15
oct5
oct1
14 14
oct5
oct1
14 14
13 13 Frame 2 Frame 1 Frame 0 13 13
LLS0
LLS2
LLS2
LLS0
oct0
oct4
oct4
oct0
Logic Included in TX Logic Included in RX

design example. RX logic design example. TX logic 0 0
0 0
data path. data for testing data path.
Figure 5‐4: Per-lane Transport Layer Octet/Frame Mapping
sysref Generation
The sysref signal is generated in both the TX and RX test bench using tx_core_clk/
rx_core_clk.

98
TX Block Layout
The design example is the same for both shared logic options. There is a subtle hierarchical
name change denoting the top-level of the IP within the example design. In Figure 5-5 and
Figure 5-6, the blocks included in the generated top-level IP are shown within the shaded
box.
TX Example Design (Shared Logic in Example Design)
<component_name>_example_design
<component_name>_support
<component_name>
<component_name>_clocking
(IP Core top level)
<component_name>_block
Configuration registers
AXI Lite IPIF
Test pattern generators
<component_name>_phy
Mapping to
Per lane,
32-bit * L JESD204_vX.X_top
14-bit Sine +
AXI-Stream (encrypted RTL)
2-bit Ctrl
Interface
Figure 5‐5: TX Example Design with Shared Logic in Example Design

TX Example Design (Shared Logic in Core)
<component_name>
(IP Core top level)
<component_name>_clocking
Configuration registers
AXI Lite IPIF
Test pattern generators
Mapping to <component_name>_phy
Per lane,
32-bit * L JESD204_vX.X_top
14-bit Sine +
AXI-Stream (encrypted RTL)
2-bit Ctrl
Interface
Figure 5‐6: TX Example Design with Shared Logic in Core

99
TX Transport Layer Mapping

wide. Samples must be mapped into and out of this interface. The design example packages
two samples per 32-bit data word passed to the AXI4-Stream interface. Each sample is made
up of a 14-bit sine wave sample and two example control bits. The mapping is consistent
across each lane. Samples are not distributed between lanes. There is one sample per frame,
and the sample bit mapping is:

Transport Layer Interface per Lane in TX Design Example
Sample generation from sine wave lookup Mapping to the

table. Example CTRL bits are added to each 32-bit JESD TX
sample. A frame is made up of two samples. Interface
15 15 15 (L-1 * 32)
14 14 14 + 31
13 13 13 JESD204
Sample
LLS5
LLS3
LLS1
TX IP
(N+1)
(L-1 * 32)
0 0 0 + 16
15 15 15 (L-1 * 32)
14 14 14 + 15
13 13 13 Frame 5 Frame 4 Frame 3 Frame 2 Frame 1 Frame 0
Sample
LLS4
LLS2
LLS0
(N)
(L-1 * 32)
0 0 0 +0
Figure 5‐7: Per-lane Generation and Transport Layer Mapping of Data for the TX Data Path

100
Transport Layer Mapping Interface per Lane

in TX Design Example
Sample generation from Mapping to the
sine wave lookup table. 32-bit JESD TX
Example CTRL bits are Interface
added to each sample. A
frame is made up of two
samples. 63
JESD204
Sample TX IP
(N+1)
L2S5
L2S3
L2S1
48
L2S5 L2S4 L2S3 L2S2 L2S1 L2S0
47
L2S4
L2S2
L2S0
Frame 5 Frame 4 Frame 3 Frame 2 Frame 1 Frame 0

Sample
(N)
32
31
Sample
(N+1)
L1S5
L1S3
L1S1
16
15
L1S4
L1S2
L1S0

Sample
(N)
Figure 5‐8: Data Generation and Transport Layer Mapping for a 2-Lane Example, LMF= 222

101
RX Block Layout
Similar to the TX, the design example is the same for both shared logic options. There is a
subtle hierarchical name change denoting the top-level of the IP within the example design.
In Figure 5-9 and Figure 5-10, the blocks included in the generated top-level IP are shown
within the shaded box.
RX Example Design (Shared logic in Example Design)
Per lane,
14-bit Sine + <component_name> <component_name>_clocking
2-bit Ctrl (IP Core top level)
AXI Lite IPIF Configuration registers
<component_name>_phy
De-mapping
Data stream from
check 32-bit * L JESD204_vX.X_top
function AXI-Stream (encrypted RTL)
Interface
Figure 5‐9: RX Example Design Hierarchy, Non-Shared

RX Example Design (Shared Logic in Core)
<component_name>
(IP Core top level)
Per lane,
14-bit Sine + <component_name>_support
2-bit Ctrl
<component_name>_block <component_name>_clocking
AXI Lite IPIF Configuration registers
De-mapping <component_name>_phy
Data stream from
check 32-bit * L JESD204_vX.X_top
function AXI-Stream (encrypted RTL)
Interface
Figure 5‐10: RX Example Design Hierarchy, Shared

102
RX Transport Layer Mapping

wide. Samples must be mapped into and out of this interface. The design example packages
two samples per 32-bit data word passed to the AXI4-Stream interface. Each sample is made
up of a 14-bit sine wave sample and two example control bits. The mapping is consistent
across each lane. Samples are not distributed between lanes. There is one sample per frame,
and the sample bit mapping is:

Tansport Layer Interface per Lane in RX Design Example
De-mapping of Unpacked Samples

32-bit * L JESD
RX Interface
(L-1 * 32) 15 15 15
+ 31 14 14 14
JESD204 13 13 13
Sample
LLS1
LLS3
LLS5
RX IP
(N+1)
(L-1 * 32)
+ 16 0 0 0
(L-1 * 32) 15 15 15
+ 15 14 14 14
Frame 5 Frame 4 Frame 3 Frame 2 Frame 1 Frame 0 13 13 13
Sample
LLS0
LLS2
LLS4
(N)
(L-1 * 32)
+0 0 0 0
Figure 5‐11: Per-lane Generation and Transport Layer Mapping of Data for the RX Data Path

103
De-mapping of Unpacked Samples

32-bit * L JESD
RX Interface
63
JESD204
RX IP Sample
(N+1)
L2S1
L2S3
L2S5
48
47
L2S0
L2S2
L2S4
Sample
(N)
32
31
Sample
(N+1)
L1S1
L1S3
L1S5
16
15
L1S0
L1S2
L1S4
Sample
(N)
Figure 5‐12: Data Generation and Transport Layer Mapping for a 2-Lane Example, LMF= 222

104
Chapter 6
Test Bench
The example design supplied with the JESD204 core provides a complete simulation
environment including a demonstration test bench that allows you to simulate the core and
view the inputs and outputs using the Vivado® Design Suite.
The test bench instantiates the example design described in Chapter 5, Example Design and
provides the necessary stimulus to show the example design functioning. The test bench
can be run at all stages of the design process from behavioral simulation of the RTL code
through full post-implementation timing simulation.
The demonstration test bench is delivered, in one of two formats depending on whether
you have created a transmitter or receiver core, as described in Chapter 5, Example Design.
Figure 6-1 shows the transmitter core test bench and Figure 6-2 shows the receiver core
test bench.
demo_tb.v
Example Design (TX) SYSREF
SYSREF
Stimulus
REFCLK
Clock GLBLCLK
Stimulus
AXI_CLK
Decode
N Test Control
and Lane
JESD204 Lanes and Checker
Alignment
AXI4-Lite
Control
Interface AXI_BUS SYNC
Stimulus
Figure 6‐1: JESD204 Transmitter Test Bench

105
demo_tb.v
Example Design (RX) SYSREF
SYSREF
Stimulus
REFCLK
Clock GLBLCLK
Stimulus
AXI_CLK
N
Encode Test Control
JESD204 Lanes
AXI4-Lite and Checker
Control
Interface AXI_BUS SYNC
Stimulus
RX_TDATA_OUT_PASS
Figure 6‐2: JESD204 Receiver Test Bench

Both the transmitter and receiver core test benches include the following common stimulus:
• Clocking – Includes clocking stimulus for REFCLK, GLBLCLK (if required by the
selected configuration), and the AXI4-Lite interface clock s_axi_aclk. The generated
clock frequencies reflect the frequency choices selected in the JESD204 core
configuration GUI.
• SYSREF – The test bench generates a repeating SYSREF signal with a period of four
multi-frames (equal to F*K frame clock periods).
• Configuration – The test bench configures the programmable core parameters using
the core register interface over the AXI4-Lite bus interface (see Register Space in
Chapter 2 for more details). The parameters are configured as shown in Table 6-1. The
following procedure is followed when programming the core registers:
a. Program the required core registers.
b. Assert core reset by writing 0x1 to the core reset register.
c. Poll the core reset register until the reset bit has cleared.
Table 6‐1: Parameter Descriptions

Encoded Value
Parameter Value Programmed Description
F 2 1 Number of octets per frame

K 32 31 Number of frames per multi-frame
L Lanes Lanes-1 Number of lanes for which the core was generated
M Lanes Lanes-1 Number of lanes for which the core was generated (test
bench simulates one converter per lane)
N 14 13 Converter resolution
N’ 16 15 Total number of bits per sample
S 1 0 Number of samples per converter per frame cycle

106
Table 6‐1: Parameter Descriptions (Cont’d)
Parameter Value Encoded Value Description

Programmed
SCR 0 0 Scrambling disabled
CF 1 1 Control words per frame clock
CS 2 2 Number of control bits per sample
SUBCLASSV 1 1 JESD204 Subclass version = 1
The transmitter core test bench includes logic to:
• Decode the 8B/10B serialized data streams from the TX ports of the example design.
• Align the received data lanes.
• Check the data from the example design. The test bench expects 14-bit sine wave
samples with 2-bit control information generated in the transmitter core example
design.
The receiver core test bench includes logic to:
• Generate and map 14-bit sine wave samples with 2-bit control information as expected
by the receiver core example design.
• Encode and serialize 8B/10B data into the RX ports of the example design.
• Check the rx_tdata_out_pass signal from the example design. This output bit
confirms the example design has received the data as expected.
To run the test bench and simulate the example design, ensure you have first opened the
example design and select Run Simulation under the Simulation flow in the Vivado IDE. For
further details on setting up the simulation, see the Vivado Design Suite User Guide:
Designing with IP (UG896) [Ref 17].
After selecting Run Simulation, by default Vivado does the following:
• Compiles the test bench and example design including your generated core.
• Launches the simulator.
• Opens the waveforms widow and displays the signals in the test bench.
• Runs the simulation for 1 ms.
Now, the simulation has only just started. You are required to manually run the simulator
until the simulation completes. You should see the following log output in the simulator
console after a successful simulation run.

107
TX core log:
Resetting the core...

Test Started
** Reset Done, Wait for GT reset
Version = Major 6 Minor 0 Rev 0
** GT Reset Done
** Wait for K28.5
Reset complete..
** Assert Sync
** ILA Start
*** End of Multi Frame 1
** ILA Complete
** Test Passed
** Test completed successfully
RX core log:
Resetting the core...

Test Started
** Reset Done
Version = Major 6 Minor 0 Rev 0
Reset complete..
** Rx sync asserted
Sync complete..
** Sysref asserted
** Init sequence complete. Sending sample data
** Test Passed
** Test completed successfully
To gain a better understanding of the operation of the signals into and out of your
generated core, observe in the simulation what is happening inside the example design. To
see this, right-click the DUT instance and select Add To Wave Window. This shows all the
signals from the example design level of the hierarchy. You must rerun the simulation from
the start to see the values for the added waveforms.

108
Appendix AJESD204 v7.2
Verification, Compliance, and

Interoperability
The JESD204 core has been verified using both simulation and hardware testing.
Simulation
A highly parameterizable transaction-based simulation test suite has been used to verify
the core. Tests include:
• Scrambling and alignment

• Loss and regain of synchronization
• Frame transmission
• Frame reception
• Recovery from error conditions
Hardware Testing
The core has been used in many hardware test platforms within Xilinx and in interoperability
testing with external hardware vendors.

109
Appendix B
Hardware Demonstration Design

For information on the Hardware Demonstration Design see the documentation
(registration required).

110
Appendix C
Migrating and Upgrading

This appendix contains information about upgrading to a recent version of the IP core.
Migrating to the Vivado Design Suite

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

This section provides information about any changes to the user logic or port designations
between core versions.
Device Migration
If you are migrating from a 7 series GTX or GTH device to an UltraScale GTH device, the
prefixes of the optional transceiver debug ports for single-lane cores are changed from
gt0, gt1 to gt, and the postfix _in and _out are dropped. For multi-lane cores, the
prefixes of the optional transceiver debug ports gt(n) are aggregated into a single port.
For example, gt0_gtrxreset and gt1_gtrxreset now become gt_gtrxreset
[1:0]. This is true for all ports, with the exception of the DRP buses which follow the
convention of gt(n)_drpxyz.
It is important to 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 23].

111
Upgrading from v7.1 to v7.2

No changes are required.
Upgrading from v7.0 to v7.1

For 7-Series Designs and Ultrascale designs generated with Shared logic in example design.
For Ultrascale Designs generated with Shared logic in Core, the single ended core clock
input has been replaced with a differential clock input (global clock). The option to enable
or disable this input (depending on IP settings) has been added to the GUI.
When upgrading it may be required to connect this clock source manually.
Upgrading from JESD204 v6.2 to v7.0

The core design now supports a maximum of 8 lanes with a single instantiation. Links
requiring more than 8 lanes must be modified to use multiple JESD204 cores.
To simplify system level clocking. The AXI stream clock ports tx_aclk and rx_aclk have
been removed.
These clock output ports were copies of tx_core_clk and rx_core_clk respectively.
Designs that use these clocks must be modified to use the clock driving the tx_core_clk
or rx_core_clk input to the core to also drive the logic previously driven by tx_aclk or
rx_aclk.
For UltraScale devices generated with shared logic in the core, there is no longer a
differential input for glblclk. This has been replaced with a single ended input called
tx_core_clk or rx_core_clk. Designs which require glblclk can instantiate the
differential buffer external to the core.

For designs the are built with shared logic in the core, no changes are required. For designs
that are built with shared logic in the example design, upgrading the JESD204 PHY will
produce critical warnings about external port differences. The JESD204 PHY core has two
new reset ports added (tx_sys_rst and rx_sys_rst). These ports should be connected
to the reset source that drives the tx_reset and rx_reset input to your JESD204 cores. See
[Ref 4] for further detail on the new JESD204 PHY ports.

112


Upgrading to the JESD204 v6.0 core depends on your use of the core. This section includes
upgrade information for the following solutions:
• Transmitter with Shared Logic in Example Design

• Transmitter with Shared Logic in Example Design Converted to Include Shared Logic in
Core
• Receiver with Shared Logic in Example Design
• Receiver with Shared Logic in Example Design Converted to Include Shared Logic in
Core
• Transmitter with Shared Logic in Core
• Receiver with Shared Logic in Core
Transmitter with Shared Logic in Example Design

The interface between the core and the Transceiver has been changed to have separate
buses for each lane in the link. An example of the changes is shown below for a 2-lane
design. The ports:
• output [63:0] gt_txdata_out

• output [63:0] gt_txcharisk_out
have been replaced with:
• Lane 0
° output [31:0] gt0_txdata
° output [3:0] gt0_txcharisk

• Lane 1
° output [31:0] gt1_txdata
° output [3:0] gt1_txcharisk

113
To change a design using v5.2 of the core to use v6.0, follow the changes shown in
Figure C-1.
X-Ref Target - Figure C-1
Figure C‐1: Upgrading Transmitter with Shared Logic in Example Design
Transmitter with Shared Logic in Example Design Converted to Include Shared

Logic in Core
IMPORTANT: This is a more complicated upgrade, and if the transceiver logic has been modified from
that provided with the example design, it is best to follow the steps for Transmitter with Shared Logic in
Example Design.
This scenario is now possible because the transceiver parameters can be updated using the
JESD204 IP GUI. To perform the upgrade:
1. Upgrade the JESD204 IP and ignore the critical warnings about pin changes.
2. Double-click on the JESD204 XCI file to re-customize the IP.
3. Change from using shared logic in example design to shared logic in core in the Shared
Logic Tab.
4. Check that the transceiver line rate and reference clock match the values used in your
existing Transceiver Wizard instantiation.
5. Allow the IP to regenerate.

114
6. Modify the instantiation of jesd204_0_support in jesd204_0_example_design.v or

your own RTL top-level that instantiates jesd204_0_support, as shown in Figure C-2.
Figure C‐2: Upgrading Transmitter with Shared Logic in Ex. Des. Converted to Incl. Shared Logic in Core
TIP: There will be redundant files in the project which can be removed, these contain the old Transceiver
Wizard and associated logic.
Receiver with Shared Logic in Example Design

The interface between the core and the transceiver has been changed to have separate
buses for each lane in the link. An example of the changes is shown below for a 2-lane
design. The ports:
• input [63:0] gt_rxdata_in

• input [7:0] gt_rxcharisk_in
• input [7:0] gt_rxdisperr_in
• input [7:0] gt_rxnotintable_in
have been replaced with:
• input [31:0] gt0_rxdata

115
• input [3:0] gt0_rxcharisk

• input [3:0] gt0_rxdisperr
• input [3:0] gt0_rxnotintable
• input [31:0] gt1_rxdata
• input [3:0] gt1_rxcharisk
• input [3:0] gt1_rxdisperr
• input [3:0] gt1_rxnotintable
To change a design using v5.2 of the core to use v6.0, make the changes to the IP
instantiation as shown in Figure C-3.
Figure C‐3: Upgrading Receiver with Shared Logic in Example Design

116
Receiver with Shared Logic in Example Design Converted to Include Shared

Logic in Core
IMPORTANT: This is a more complicated upgrade, and if the transceiver logic has been modified from
that provided with the example design, it is better to follow the steps for Transmitter with Shared Logic
in Example Design .
This is now possible because the transceiver parameters can be updated using the JESD204
IP GUI. To perform the upgrade:
1. Upgrade the JESD204 IP and ignore the critical warnings about pin changes.
2. Double-click the JESD204 XCI file to re-customize the IP.
3. Change from using shared logic in example design to shared logic in core in the Shared
Logic Tab.
4. Check that the transceiver line rate and reference clock match the values used in your
existing Transceiver Wizard instantiation.
5. Allow the IP to regenerate.
6. Modify the instantiation of jesd204_0_support in jesd204_0_example_design.v or
your own RTL top-level that instantiates jesd204_0_support, as shown in Figure C-4.:

117
Figure C‐4: Upgrading Receiver with Shared Logic in Ex. Des. Converted to Include Shared Logic in Core
Transmitter with Shared Logic in Core

To upgrade this configuration to the v6.0 core, remove the following redundant pins from
the core instantiation:
• common_pll0_lock_out
• common_pll0_refclk_out
• common_pll0_clk_out
• tx_pll_select
• txusrclk_out
• txclk_rdy_out
In addition, change the core instantiation as shown in Figure C-5.

118
Figure C‐5: Upgrading Transmitter with Shared Logic in Core
Receiver with Shared Logic in Core

To upgrade this configuration to the v6.0 core, remove the following redundant pins from
the core instantiation:
• common_pll0_lock_out
• common_pll0_refclk_out
• common_pll0_clk_out
• rx_pll_select
• rxusrclk_out
• rxclk_rdy_out
In addition, change the core instantiation as shown in Figure C-6.

119
Figure C‐6: Upgrading Receiver with Shared Logic in Core

120
Appendix D
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 JESD204, 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 JESD204. 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.
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)

121
• Summary of the issue encountered
A filter search is available after results are returned to further target the results.
Master Answer Record for the JESD204 Core
AR: 54480
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.
Debug Tools
There are many tools available to address JESD204 design issues. It is important to know
which tools are useful for debugging various situations.
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 allow 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 LogiCORE IP cores, including:
• ILA 2.0 (and later versions)

• VIO 2.0 (and later versions)
See the Vivado Design Suite User Guide: Programming and Debugging (UG908) [Ref 24].

122
Reference Boards
Various Xilinx development boards support the JESD204. These boards can be used to
prototype designs and establish that the core can communicate with the system.
• 7 series FPGA evaluation boards:
° KC705
° AC701
° ZC706
° VC709
• Kintex Ultrascale evaluation board:
° KCU105

123
Simulation Debug
The simulation debug flow for QuestaSim is illustrated in Figure D-1. A similar approach can
be used with other simulators.
X-Ref Target - Figure D-1
1UESTA3IM
3IMULATION $EBUG
3ECURE)0 MODELS ARE USED TO

SIMULATE THE -'4S #HECK FOR THE LATEST SUPPORTED
4O USE THESE MODELS A 6ERILOG VERSIONS OF 1UESTA 3)- IN THE $ATASHEET .O
5PDATE TO THIS VERSION
,2- )%%% ENCRYPTION )S THIS VERSION BEING USED
COMPLIANT SIMULATOR IS REQUIRED
9ES
! 6ERILOG LICENSE IS REQUIRED TO

SIMULATE WITH THE 3ECURE)0 MODELS )F USING 6($, DO YOU HAVE A .O
/BTAIN A MIXED MODE
)F THE USER DESIGN USES 6($, A MIXED MODE SIMULATION LICENSE SIMULATION LICENSE
MIXED MODE SIMULATION LICENSE IS
REQUIRED
9ES
)F THE LIBRARIES ARE NOT COMPILED AND
MAPPED CORRECTLY IT WILL CAUSE ERRORS
SUCH AS
%RROR VOPT &AILED TO ACCESS .EED TO COMPILE AND MAP THE
9ES CORRECT LIBRARIES 3EE THE 6IVADO
LIBRARY gSECUREIPg AT SECUREIP $O YOU GET ERRORS REFERRING TO
.O SUCH FILE OR DIRECTORY FAILING TO ACCESS LIBRARY $ESIGN 3UITE 5SER 'UIDE ,OGIC
ERRNO %./%.4 3IMULATION 5'
%RROR EXAMPLE?DESIGN
XAUI?CORE?BLOCKV
,IBRARY SECUREIP NOT FOUND .O
4O MODEL THE -'4S THE 3ECURE)0 &OR VERILOG SIMULATIONS ADD THE , SWITCH
$O YOU GET ERRORS INDICATING 9ES WITH THE APPROPRIATE LIBRARY REFERENCE TO THE
MODELS ARE USED 4HESE MODELS '40?$5!, OR OTHER ELEMENTS LIKE
MUST BE REFERENCED DURING THE VSIM VSIM COMMAND LINE &OR EXAMPLE , SECUREIP
"5&' NOT DEFINED OR , UNISIMS?VER
CALL !LSO IT IS NECESSARY TO
REFERENCE THE UNISIMS LIBRARY
.O
4HE EXAMPLE DESIGN SHOULD

ALLOW THE USER TO QUICKLY DETERMINE
IF THE SIMULATOR IS SET UP CORRECTLY $OES SIMULATING THE EXAMPLE 9ES 3EE %XAMPLE $ESIGN CHAPTER IN
THE CORE ACHIEVES 39.# AND TRANSMITS DESIGN GIVE THE EXPECTED OUTPUT THIS 0RODUCT 'UIDE
OR RECEIVES AN ),! SEQUENCE
.O
)F PROBLEM IS MORE DESIGN SPECIFIC OPEN

A CASE WITH 8ILINX 4ECHNICAL 3UPPORT
AND INCLUDE A WLF FILE DUMP OF THE SIMULATION
&OR THE BEST RESULTS DUMP THE ENTIRE DESIGN
HIERARCHY
Figure D‐1: QuestaSim Debug Flow Diagram

124
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 debug feature for debugging the specific problems.
General Checks
• Ensure that the core is correctly wired up. If using the JESD204_PHY core, ensure that
the lane based signals are wired to the correct location.
• Ensure that all the timing constraints for the core were met during implementation.
• Ensure that all clock sources are clean and in particular that the transceiver reference
clocks meet the transceiver requirements from the appropriate FPGA Data Sheet.
• Ensure all clock sources are stable before deasserting the external reset signal to the
core.
• Ensure that all transceiver PLLs have obtained lock by monitoring the QPLLLOCK_OUT
and/or CPLLLOCK_OUT port either using the debug feature or by routing the signals to
a spare pin.
Issues Obtaining Lane Synchronization

• Ensure that the AXI4-Lite registers have been programmed with the correct values for
the frame size parameters (octets per frame, frames per multiframe) and scrambling
enable/disable so the transmitter matches the receiver.
• In the case of a receiver ensure that SYNC is deasserted (set to 1) when valid K28.5
(0xBC) characters are received from the transceiver by monitoring RXDATA and
RXCHARISK from the GTP/GTX/GTH/GTY using the debug feature.
• In the case of a transmitter ensure that core generates valid K28.5 (0xBC) characters to
the transceiver by monitoring TXDATA and TXCHARISK from the transceiver using the
debug feature until SYNC is deasserted (set to 1).

125
Issues Losing Synchronization Soon After Gaining

Synchronization
• Ensure that the AXI4-Lite registers have been programmed with the correct values for
F (Octets per Frame) and K (Frames per Multiframe).
Interface Debug
AXI4-Lite Interfaces
Read from a register that does not have all 0s as a default to verify that the interface is
functional. 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.
• The interface is enabled, and s_axi_aclken is active-High (if used).
• The main core clocks are toggling and that the enables are also asserted.
• If the simulation has been run, verify in simulation and/or the Vivado Design Suite
debug feature capture that the waveform is correct for accessing the AXI4-Lite
interface.

126
Appendix E
Additional Resources and Legal Notices
Xilinx Resources
For support resources such as Answers, Documentation, Downloads, and Forums, see the
Xilinx Support web page.
References
These documents provide supplemental material useful with this product guide:
To search for JESD204 documentation, go to www.jedec.org
1. Serial Interface for Data Converters (JESD204B)

2. AMBA AXI and ACE Protocol Specification (ARM IHI 0022D)
3. AMBA AXI4-Stream Protocol Specification (ARM IHI 0051A)
4. JESD204 PHY LogiCORE IP Product Guide (PG198)
5. 7 Series FPGAs Configurable Logic Block User Guide (UG474)
6. UltraScale Architecture GTH Transceivers User Guide (UG576)
7. UltraScale Architecture GTY Transceivers User Guide (UG578)
8. 7 Series FPGAs GTX/GTH Transceivers User Guide (UG476)
9. 7 Series FPGAs GTP Transceivers User Guide (UG482)
10. Artix-7 FPGAs Data Sheet: DC and Switching Characteristics (DS181)
11. Zynq-7000 All Programmable SoC (Z-7010, Z-7015, and Z-7020): DC and AC Switching
Characteristics (DS187)
12. Kintex-7 FPGAs Data Sheet: DC and Switching Characteristics (DS182)
13. Virtex-7 FPGAs Data Sheet: DC and Switching Characteristics (DS183)
14. Zynq-7000 All Programmable SoC (Z-7030, Z-7045, and Z-7100): DC and AC Switching
Characteristics (DS191)

127
15. Kintex UltraScale Architecture Data Sheet: DC and AC Switching Characteristics (DS892)
16. Xilinx Vivado AXI Reference Guide (UG1037)
17. Vivado Design Suite User Guide: Designing with IP (UG896)
18. Vivado Design Suite User Guide: Designing IP Subsystems Using IP Integrator (UG994)
19. Vivado Design Suite User Guide: Getting Started (UG910)
20. 7 Series data sheets
21. Vivado Design Suite User Guide: Logic Simulation (UG900)
22. ISE to Vivado Design Suite Migration Guide (UG911)
23. UltraScale Architecture Migration Methodology Guide (UG1026)
24. Vivado Design Suite User Guide: Programming and Debugging (UG908)
25. Virtex Ultrascale Architecture Data Sheet: DC and AC switching Characteristics (DS893)
Revision History
The following table shows the revision history for this document.
Date Version Revision

10/04/2017 7.2 • Note stating support for running at non-standard line rates up to
16.375Gb/s.
• Added recommendations for clocking schemes.
• Added note on transmitter test modes.
06/07/2017 7.1 Modified UltraScale and UltraScale+ simple clocking.
04/05/2017 7.1 • Added supported line rate tables for UltraScale+ devices.
• Added detail on JESD204B standard registers.
10/05/2016 7.1 • Added section - Achieving Repeatable Latency.
• Updated description of Minimum Deterministic latency support.
• Added latency values for GTHE4 and GTYE4.
• Added new reset bit that is held until cleared.
• Modified test modes register to allow control of transceiver PRBS test
patterns.
04/06/2016 7.0 • Reduced maximum lanes for a single core to 8.
• Removed tx_aclk and rx_aclk ports.
• Added rx_start_of_mutiframe and rx_end_of_multiframe ports.
• Removed registers for lanes 9-12.
• Added new register DEBUG_STATUS.
• Updated RX core latency figures and calculation.
• Updated diagrams to show new ports and connections.
11/18/2015 6.2 Added support for UltraScale+ families.

128

09/30/2015 6.2 • Added support for GTY transceivers.
• Removed tx_aclk and rx_aclk from the AXI stream interface signals. Noted
these signals may be removed in subsequent versions of the core.
• Updated description on transceiver debug ports gt_rxpd and gt_txpd.
• Updated description of lanes in use register.
• Updated diagrams to show the new JESD PHY ports tx_sys_reset and
rx_sys_reset.
• Updated latency figures and calculations.
04/01/2015 6.1 • Added GT Port important note in Transceiver Control and Status Ports
section.
• Updated Fig. 2-2: Transmit Data Interface Timing for F = 8 and K = 4 for F
= 8 to Fig. 2-4: Receive Data Interface Timing for F = 7.
• Updated Table 2-14: Optional Transceiver Debug Ports (7 Series Devices)
and Table 2-15: Optional Transceiver Debug Ports (UltraScale
Architecture-Based Devices).
• Added Lane 0 to 12 ID registers.
• Updated Bit[16] default value to 1 in Table 2-18: Reset.
• Updated Bit[31] description in Table 2-24: Link Error Status.
• Updated Table 2-27: Lanes in Use.
• Updated Bits[12:0] description in Table 2-29: RX Buffer Delay (RX Only).
• Updated Table 2-30: Error Reporting (RX Only).
• Updated description in Transceiver Sharing section.
• Updated Table 3-4: Frequency Ranges for Kintex UltraScale
Architecture-Based Devices.
• Updated description in Clocking for Subclass 0 Mode section.
• Added description in Receive Latency section.
• Updated Table 3-6: Receive Datapath Latencies and Table 3-7: Transmit
Datapath Latencies.
• Updated the Sharing Transceivers between Transmit and Receive section.
• Updated Figs. 4-1 to 4-3 in Design Flow Steps chapter.
• Added JESD204 PHY Configuration Tab section.
• Updated Table 4-1: Vivado IDE Parameter to User Parameter Relationship.
• Added UNISIM important note in Simulation section.
• Added Upgrading from JESD204 v6.0 section.
10/01/2014 6.0 Updated details about the example design and test bench.
06/04/2014 5.2 • Updated migration instructions.
• Added Table 4-1 for Vivado IDE parameter to user parameter relationship.
04/02/2014 5.2 • Added core support for 12 lanes.
• Updated Port Descriptions to clarify port differences for TX or RX cores and
Shared Logic options.
• Updated Register Space section to separate address map from register
descriptions.
• Restructured Chapter 3, Designing with the Core section and added
introductory content.
• Updated instructions for transceiver configuration update.
12/18/2013 5.1 Added UltraScale™ architecture support.

129

10/02/2013 5.0 • Revision number advanced to 5.0 to align with core version number.
• Replaced option to generate shared core with option to include or exclude
shareable logic resources in the core.
• Added option to include or exclude RPAT and JSPAT modules.
• Added optional transceiver control and status ports.
• Removed GUI option for JESD204 subclass selection; subclass is now
selected using a register.
• AXI4-Lite address map has been updated.
• A single AXI4-Stream bus is used for all txdata and rxdata lanes
03/20/2013 3.0 Updated to core version 4.0:
• Hierarchy updated; block level now the default core top-level
• AXI4-Lite address map corrections, including addition of byte write support
• Added Artix® -7 support
• Increase rx_buffer_adjust from 256 to 1024
• Pipeline stage added to receiver to improve timing
• Zynq support added to HW demonstration platform
12/18/2012 2.0 Updated for 2012.4:
• The core now supports 1, 2, 3, 4, 5, 6, 7 and 8 lane configurations in 7 series
devices
• Added 12.5 Gb/s line rate support
• Removed JESD204A (new designs should use JESD204B Subclass 0)
• Removed ISE
• Added three new test modes
• Added software lane select
• Added a hardware demonstration design targeting the KC705 evaluation
board, Appendix B, Hardware Demonstration Design
• Updated Appendix D, Debugging
07/25/2012 1.0 Initial Xilinx release. This Product Guide is derived from DS814 and UG774.

130
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 https://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 https://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–2017 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. AMBA, AMBA Designer, ARM,
ARM1176JZ-S, CoreSight, Cortex, and PrimeCell are trademarks of ARM in the EU and other countries. All other trademarks are the
property of their respective owners.

131

JESD Specifications

Uploaded by

Copyright:

Available Formats

JESD Specifications

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

JESD Specifications

Uploaded by

Copyright:

Available Formats

JESD204 v7.

LogiCORE IP Product Guide

Vivado Design Suite

Chapter 2: Product Specification

Chapter 3: Designing with the Core

Chapter 4: Design Flow Steps

JESD204 v7.2 www.xilinx.com Send Feedback

Chapter 5: Example Design

Chapter 6: Test Bench

Appendix A: Verification, Compliance, and Interoperability

Appendix B: Hardware Demonstration Design

Appendix C: Migrating and Upgrading

Appendix E: Additional Resources and Legal Notices

JESD204 v7.2 www.xilinx.com Send Feedback

Introduction LogiCORE IP Facts Table

Resources Performance and Resource Utilization web page

Provided with Core

Example Design Verilog

• Supports up to 8 lanes per core and up to Constraints File XDC

JESD204 v7.2 www.xilinx.com Send Feedback 4

JESD204 Transmitter Core

Figure 1‐1: Transmitter Core Overview

1. Non-standard line rates up to 16.375 Gb/s are supported.

JESD204 v7.2 www.xilinx.com Send Feedback

The main blocks are:

• Single AXI4-Stream interface for all lanes

Figure 1‐2: Receiver Core Overview

The main blocks are:

• Single AXI4-Stream interface for all lanes

JESD204 v7.2 www.xilinx.com Send Feedback

• Local Multiframe Clock (LMFC) state machine and SYNC/SYSREF interface

Core Level Architecture

• Inside the core for basic simplex applications

JESD204 v7.2 www.xilinx.com Send Feedback

ADC Device FPGA

Figure 1‐3: Example ADC Application

FPGA DAC Device

Figure 1‐4: Example DAC Application

JESD204 v7.2 www.xilinx.com Send Feedback

Licensing and Ordering Information

For more information, visit the JESD204 product web page.

JESD204 v7.2 www.xilinx.com Send Feedback

Full System Hardware Evaluation

• Gate-level functional simulation support

JESD204 v7.2 www.xilinx.com Send Feedback

Obtaining Your License Key

Full System Hardware Evaluation License

1. Navigate to the JESD204 product page for this core.

Obtaining a Full License

Installing Your License File

JESD204 v7.2 www.xilinx.com Send Feedback

*%3$ VERSION  *%3$ REVISION ! AND "

Figure 2‐1: System Overview

JESD204 v7.2 www.xilinx.com Send Feedback

Clock and Reset Ports – TX Core

JESD204 v7.2 www.xilinx.com Send Feedback

JESD204 v7.2 www.xilinx.com Send Feedback

Clock and Reset Ports – RX Core

JESD204 v7.2 www.xilinx.com Send Feedback

JESD204 PHY and Transceiver Interface Ports – TX Core

%3$ VERSION %3$ REVISION ! AND "

TX?START?OF?MULTIFRAME;=

RX?START?OF?FRAME;=

RX?END?OF?FRAME;=