Jesd204 V6.1: Logicore Ip Product Guide
Jesd204 V6.1: Logicore Ip Product Guide
Chapter 1: Overview
Transmitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Core Level Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Unsupported Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Licensing and Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix D: Debugging
Finding Help on Xilinx.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Debug Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Simulation Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Hardware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Interface Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Overview
The LogiCORE™ IP JESD204 core implements a JESD204B interface supporting line rates
between 1 and 12.5 Gb/s on 1 to 12 lanes using GTX, GTH, or GTP 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.
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
-(6'7UDQVPLWWHU&RUH
7;/DQHV
$OLJQPHQW
&KDUDFWHU
*HQHUDWRU *7;
$;,6WUHDP 6FUDPEOHU *7+
7H[W
/DQH
7H[W *73
$OLJQPHQW
-(6'
6HTXHQFH
6HULDO'DWD
53$7
*HQHUDWRU
6\QF6<65() 7;&RXQWHUV
-63$7
*HQHUDWRU
$;,/LWH $;,/LWH,3,)
&RQWURO 5HJLVWHUV
Receiver
Figure 1-2 shows an overview block diagram for the receiver of the JESD204 core.
X-Ref Target - Figure 1-2
-(6'5HFHLYH&RUH
5;/DQHV
7H[W
7H[W 5HSODFH
*7; 'HVFUDPEOHU $OLJQPHQW
'DWD
*7+ $;,6WUHDP
*73 'HFRGH/DQH
$OLJQPHQW
6HTXHQFH
/LQN
(UURU
&RXQWHU
/0)&DQG
6<65() 6\QF
6WDWXV
$;,/LWH $;,/LWH,3,)
&RQWURO 5HJLVWHUV
° ILA capture
° Descrambling
° Alignment character detection and replacement logic
• Local Multiframe Clock (LMFC) state machine and SYNC/SYSREF interface
• Transceiver wrapper logic
• Error counters for each lane
• AXI4-Lite Management interface and control/status registers
Core-level Verilog wrappers are provided to instantiate the JESD204 IP, the clock/reset logic,
Management block, the GTX/GTH/GTP 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 to be
instantiated 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
datalink 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 transceiver in the example
design to allow it to be shared by multiple cores (see Shared Logic Tab).
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.
$'&'HYLFH )3*$
/DQHV
$'&
-(6'%7;
-(6'%7;
8VHU
/RJLF
$'&
[
)3*$ '$&'HYLFH
/DQHV
'$&
-(6'%5;
-(6'%7;
8VHU
/RJLF
'$&
[
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.
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.
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.
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.)
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:
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.
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.
Revision A and B extend this to cover multiple converters, each linked to the logic device
using multiple lanes. See Figure 2-1.
X-Ref Target - 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
Standards
JEDEC® Serial Interface for Data Converters (JESD204B) available from www.jedec.org.
Resource Utilization
Resources required for the JESD204 core have been estimated for the Virtex® UltraScale™
device (Table 2-1) and Kintex®-7 FPGA (Table 2-2). These values were generated using the
Vivado® Design Suite. These values are for cores generated using the Shared Logic in core
option and include the resources used in the core support layer and transceiver support
logic.
Table 2-1: Device Utilization – UltraScale Devices (XCVU095 FFVD 1924 -2 E ES1)
Number of
Lanes FF LUTs BUFG Block RAM 36
Transceivers
RX 1 1660 1635 3 1 1
RX 2 2875 2778 3 2 2
RX 3 4071 3911 3 3 3
RX 4 5267 5045 3 4 4
RX 5 6447 6146 3 5 5
RX 6 7627 7247 3 6 6
RX 7 8827 8347 3 7 7
RX 8 10030 9456 3 8 8
RX 9 11186 10056 3 9 9
RX 10 12342 10667 3 10 10
RX 11 13506 11557 3 11 11
RX 12 14670 12442 3 12 12
TX 1 1262 1403 3 0 1
TX 2 1881 1855 3 0 2
TX 3 2460 2356 3 0 3
TX 4 3060 2836 3 0 4
TX 5 3640 3280 3 0 5
TX 6 4200 3694 3 0 6
TX 7 4790 4220 3 0 7
TX 8 5360 4749 3 0 8
TX 9 5935 5214 3 0 9
TX 10 6517 5680 3 0 10
TX 11 7097 6159 3 0 11
TX 12 7678 6639 3 0 12
Table 2-2: Device Utilization – Kintex-7 FPGAs (XC7K325T FFG900 -2) (Cont’d)
Number of
Lanes FF LUTs BUFG Block RAM 36 Transceivers
RX 10 Lane 10127 9860 2 10 10
RX 11 Lane 11045 10730 2 11 11
RX 12 Lane 11975 11680 2 12 12
TX 1 Lane 1200 1375 2 0 1
TX 2 Lane 1561 1647 2 0 2
TX 3 Lane 1903 1969 2 0 3
TX 4 Lane 2243 2282 2 0 4
TX 5 Lane 2585 2578 2 0 5
TX 6 Lane 2931 2902 2 0 6
TX 7 Lane 3275 3232 2 0 7
TX 8 Lane 3618 3655 2 0 8
TX 9 Lane 3961 3966 2 0 9
TX 10 Lane 4293 4137 2 0 10
TX 11 Lane 4637 4437 2 0 11
TX 12 Lane 4978 4751 2 0 12
Port Descriptions
The port descriptions for the JESD204 core are described in the following sections.
Table 2-3: TX Core: Clock and Reset Ports – Shared Logic in Example Design
Signal Name Direction Description
tx_core_clock Core logic clock input.
In
Frequency = serial line rate/40
tx_reset In Core asynchronous logic reset.
tx_reset_gt Out Transceiver reset. Core output to reset connected transceiver(s)(1).
tx_aclk AXI4-Stream clock. Associated with the transmit data interface.
Out
Runs at the same frequency as tx_core_clock.
tx_aresetn AXI4-Stream reset. Active-Low. Associated with the transmit data
Out
interface.
s_axi_aclk In AXI4-Lite clock. Associated with the management interface.
Table 2-3: TX Core: Clock and Reset Ports – Shared Logic in Example Design (Cont’d)
Signal Name Direction Description
s_axi_aresetn AXI4-Lite reset. Active-Low. Associated with the management
In
interface.
Notes:
1. For Artix®-7 devices this port is not available and the transceiver reset is internal to the transceiver wrapper logic.
Table 2-4: TX Core: Clock and Reset Ports – Shared Logic in Core
Signal Name Direction Description
refclk_p/refclk_n Differential transceiver reference clock input
In
Reference clock for the transceiver(s) and Quad Common PLL(s)
glblclk_p/glblclk_n Differential core logic clock input. Additional global logic clock
required for Subclass 1 or Subclass 2 operation where the
In reference clock cannot be used for the synchronous capture of
SYSREF or SYNC.
Frequency = serial line rate/40. (See Clocking)
drpclk Dynamic Reconfiguration Port (DRP) clock. A free-running DRP
In clock is required for UltraScale architecture-based devices and
optional for 7 series devices.
common0_pll_clk_out Clock output from the QPLL (Quad 0) associated with serial lanes
Out
0–3. This port is only present when using QPLL.
common0_pll_refclk_out Reference Clock output from the QPLL (Quad 0) associated with
Out
serial lanes 0–3. This port is only present when using QPLL.
common0_pll_lock_out Clock Lock output from the QPLL (Quad 0) associated with serial
Out lanes 0–3. This port is only present when using QPLL.
• 1 = Indicates that the QPLL is locked
common1_pll_clk_out Clock output from the QPLL (Quad 1) associated with serial lanes
Out 4–7. This port is only present for configurations with 5 to 12 lanes
and QPLL is selected.
common1_pll_refclk_out Reference Clock output from the QPLL (Quad 1) associated with
Out serial lanes 4–7. This port is only present for configurations with 5
to 12 lanes.
common1_pll_lock_out Clock Lock output from the QPLL (Quad 1) associated with serial
lanes 4–7. This port is only present for configurations with 5 to 12
Out
lanes and QPLL is selected.
• 1 = Indicates that the QPLL is locked.
common2_pll_clk_out Clock output from the QPLL (Quad 2) associated with serial lanes
Out 8–11. This port is only present for configurations with 9 to 12 lanes
and QPLL selected.
common2_pll_refclk_out Reference clock output from the QPLL (Quad 2) associated with
Out serial lanes 8–11. This port is only present for configurations with
9 to 12 lanes and QPLL selected.
common2_pll_lock_out Clock lock output from the QPLL (Quad 2) associated with serial
lanes 8–11. This port is only present for configurations with 9 to
Out
12 lanes and QPLL selected.
• 1 = Indicates that the QPLL is locked.
tx_core_clk_out Core logic clock output.
Out
Frequency = serial line rate/40
Table 2-4: TX Core: Clock and Reset Ports – Shared Logic in Core (Cont’d)
Signal Name Direction Description
tx_aclk AXI4-Stream clock. Associated with the transmit data interface.
Out
This runs at the same frequency as tx_core_clock.
tx_aresetn AXI4-Stream reset. Active-Low. Associated with the transmit data
Out
interface.
s_axi_aclk In AXI4-Lite clock. Associated with the management interface.
s_axi_aresetn AXI4-Lite reset. Active-Low. Associated with the management
In
interface.
Table 2-5: RX Core: Clock and Reset Ports – Shared Logic in Example Design
Signal Name Direction Description
Core logic clock.
rx_core_clock In
Frequency = serial line rate/40
rx_reset In Core asynchronous logic reset.
rx_reset_gt Out Transceiver reset. Core output to reset connected transceiver(s)(1).
AXI4-Stream clock. Associated with the receive data interface.
rx_aclk Out
This runs at the same frequency as rx_core_clock.
AXI4-Stream reset. Active-Low. Associated with the receive data
rx_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.
Notes:
1. For Artix-7 devices this port is not available and the transceiver reset is internal to the transceiver wrapper logic.
Table 2-6: RX Core: Clock and Reset Ports – Shared Logic in Core
Signal Name Direction Description
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)
DRP clock. A free-running DRP clock is required for UltraScale
drpclk In
architecture-based devices and optional 7 series devices.
Table 2-6: RX Core: Clock and Reset Ports – Shared Logic in Core (Cont’d)
Signal Name Direction Description
Clock output from the QPLL (Quad 0) associated with serial lanes
common0_pll_clk_out Out
0–3. This port is present only when QPLL is selected.
Reference Clock output from the QPLL (Quad 0) associated with
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
Clock output from the QPLL (Quad 1) associated with serial lanes
common1_pll_clk_out Out 4–7. This port is only present for configurations with 5 to 12 lanes
and QPLL is selected.
Reference Clock output from the QPLL (Quad 1) associated with
common1_pll_refclk_out Out serial lanes 4–7. This port is only present for configurations with 5
to 12 lanes and QPLL is selected.
Clock Lock output from the QPLL (Quad 1) associated with serial
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 12 lanes and QPLL is selected.
Clock output from the QPLL (Quad 2) associated with serial lanes
common2_pll_clk_out Out 8–11. This port is only present for configurations with 9 to 12 lanes
and QPLL is selected.
Reference Clock output from the QPLL (Quad 2) associated with
common2_pll_refclk_out Out
serial lanes 8–11 and QPLL is selected.
Clock Lock output from the QPLL (Quad 2) associated with serial
common2_pll_lock_out Out lanes 8–11. 1 = Indicates that the QPLL is locked. This port is only
present for configurations with 9 to 12 lanes and QPLL is selected.
Core logic clock output.
rx_core_clk_out Out
Frequency = serial line rate/40
AXI4-Stream clock. Associated with the RX data interface. This runs
rx_aclk Out
at the same frequency as rx_core_clock.
AXI4-Stream reset. Active-Low. Associated with the RX data
rx_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-7: TX Core: Transceiver Interface Ports – Shared Logic in Example Design
Signal Name Direction Description
gtN_txdata[31:0] Out TX data to transceiver. N = Lanes - 1
gtN_txcharisk[3:0] Out TX Char is K to transceiver. N = Lanes - 1
Table 2-9: RX Core: Transceiver Interface Ports – Shared Logic in Example Design
Signal Name Direction Description
gtN_rxdata[31:0] In RX data from transceiver. N = 0 to (Lanes - 1)
gtN_rxcharisk[3:0] In RX Char is K from transceiver. N = Lanes - 1
gtN_rxdisperr[3:0] In RX disparity error from transceiver. N = Lanes - 1
gtN_rxnotintable[3:0] In RX Not In Table from transceiver. N = Lanes - 1
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].
X-Ref Target - Figure 2-2
TX?ACLK
TX?TREADY
TX?TDATA;= $$$$ $$$$ $$$$ $$$$ $$$$ $$$$ $$$$ $$$$ $$$$ $$$$
TX?START?OF?FRAME;=
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.
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].
RX?ACLK
RX?TVALID
&RAME 3IZE
RX?ACLK
RX?TVALID
RX?START?OF?FRAME;=
RX?END?OF?FRAME;=
&RAME 3IZE
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], 7 Series FPGAs GTX/GTH
Transceivers User Guide (UG476) [Ref 7], or 7 Series FPGAs GTP Transceivers User Guide
(UG482) [Ref 8]) for a detailed description of these pins. This interface is only present on the
core when “Include Shared Logic in core” and “Additional transceiver control and status
ports” options are selected when generating the core.
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-15).
Table 2-15: Optional Transceiver Debug Ports (UltraScale Architecture-Based Devices) (Cont’d)
Signal Name(1) Direction Clock Domain Description
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]
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]
Table 2-15: Optional Transceiver Debug Ports (UltraScale Architecture-Based Devices) (Cont’d)
Signal Name(1) Direction Clock Domain Description
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 rx_core_clock 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 tx_core_clock 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]
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]
Table 2-15: Optional Transceiver Debug Ports (UltraScale Architecture-Based Devices) (Cont’d)
Signal Name(1) Direction Clock Domain Description
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
gt_rxpd [(LANES-1):0] In Async RX Power Down
gt_txpd [(LANES-1):0] In tx_core_clock TX Power Down
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-16.
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.
Notes:
1. Applicable to GTXE2 transceivers only.
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.
31:1 – Reserved
0 0 1 = Enable Scrambling; 0 = Disable Scrambling
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
31:3 – Reserved
Test Mode Select
000: Normal operation
001: Transmit/Receive /K28.5/ indefinitely
010: Synchronize as normal then transmit/receive repeated ILA sequences
2:0 000
011: Transmit/receive /D21.5/ indefinitely
101: Transmit Modified Random Pattern (RPAT) [TX ONLY]
111: Transmit Scrambled Jitter Pattern (JSPAT) [TX ONLY]
Other bit combinations: unsupported
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.
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)
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)
31:12 – Reserved
Lanes in Use: Allows the number of active lanes to be set for
test purposes.
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 – 1 are set to 1.
11: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.
31:13 – 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
12: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.
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
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.
Notes:
1. Registers for remaining Lane IDs are similar to the one above except for the default value. This increases by 1 for
each lane.
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.
31:8 – Reserved
7:0 – F (Octets per Frame)
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.
31:5 – Reserved
4:0 – K (Frames per Multiframe)
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.
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.
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.
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. SCR value cannot be programmed, it is
generated automatically by the core based on the configuration.
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. FCHK value cannot be programmed, it is
calculated automatically by the core for each lane.
31:17 – Reserved
16 0 ADJDIR (Adjust Direction) [Subclass 2 Only]
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.
See Chapter 5, Detailed Example Design for information about using and customizing the
example designs for the JESD204 core.
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.
Contact your local Xilinx representative for a closer review and estimation for your specific
requirements.
In most instances, the serial line rate selection is governed by the specifications of the ADC/
DAC Convertor 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 serial transceivers 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.
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 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 can be supported by the JESD204 core, within the
limitations and constraints imposed by line rates and clock sources (see Sharing
Transceivers between Transmit and Receive).
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).
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:
These parameters are dictated by the configurations available in the ADC/DAC convertor
device to which the core is interfacing.
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). 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
convertors 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 serial transceivers require a stable, low-jitter
reference clock which has a device and speed grade dependant range. In some
circumstances, the same source clock can supply both the reference clock and core
clock.
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.
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.
For Subclass 0, where there are no such constraints, the clocking requirements are
simplified, and alternative clocking arrangements can be used.
7R&RQYHUWHUV
'HYLFH&ORFN0+]
6<65()6XEFODVV
)3*$
75$16&(,9(5
0+]
5()&/.
&ORFN*HQHUDWRU
&ORFNLQJ
6RXUFH&ORFN 0RGXOH
9&2 7;5;865&/.V
UHIFON0+]
,%8)'6B*7
H[DPSOHIUHTXHQFLHV
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/40 th of the serial
line rate).
This configuration must be used where the reference clock frequency is out of the range
that can be used for the core clock and support 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-5).
7R&RQYHUWHUV
'HYLFH&ORFN0+]
6<65()6XEFODVV
)3*$
0+]
75$16&(,9(5
&ORFN*HQHUDWRU
6RXUFH &ORFNLQJ 5()&/.
&ORFN 9&2 0RGXOH
7;5;865&/.V
UHIFON0+]
,%8)'6B*7
&25(/2*,&
%8)*
6<65() &25(B&/.
*HQHUDWLRQ
6<65()6XEFODVV
6XEFODVV 6<65()6XEFODVV
H[DPSOHIUHTXHQFLHV
Notes:
1. Further limitations might apply: see the Artix-7 FPGAs Data Sheet: DC and Switching Characteristics (DS181) [Ref 9]
and the Zynq-7000 All Programmable SoC (Z-7010, Z-7015, and Z-7020): DC and AC Switching Characteristics
(DS187) [Ref 10] 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.
Notes:
1. Further limitations might apply—see the Kintex-7 FPGAs Data Sheet: DC and Switching Characteristics (DS182)
[Ref 11] and Virtex-7 FPGAs Data Sheet: DC and Switching Characteristics (DS183) [Ref 12] and Zynq-7000 All
Programmable SoC (Z-7030, Z-7045, and Z-7100): DC and AC Switching Characteristics (DS191) [Ref 13] 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).
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.
Notes:
1. Further limitations might apply —see the Virtex-7 FPGAs Data Sheet: DC and Switching Characteristics (DS183)
[Ref 11] for full specifications.
2. If these conditions are met, the clocking in Figure 3-2 can be used. Otherwise, the clocking in Figure 3-1 must be
used.
Notes:
1. Further limitations might apply—see the Kintex UltraScale Architecture Data Sheet: DC and Switching
Characteristics (DS892) [Ref 14] for full specifications.
2. If these conditions are met, the clocking in Figure 3-2 can be used. Otherwise, the clocking in Figure 3-1 must be
used.
Notes:
1. If these conditions are met, the clocking in Figure 3-2 can be used. Otherwise, the clocking in Figure 3-1 must be
used.
Detailed Clocking
For Kintex-7, Virtex-7, Kintex UltraScale architecture and Virtex UltraScale architecture
family devices (GTXE2, GTHE2 and GTHE3 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 Artix-7 family devices, the GTP transceiver uses a 16-bit internal datapath. This imposes
an extra requirement for TXUSRCLK/RXUSRCLK (supplied to the GTP transceiver) which runs
at twice the core clock rate. TXUSRCLK2/RXUSRCLK2 runs at the same rate as the core clock.
To support this, an MMCM is normally used as shown in Figure 3-3. For Artix-7 devices, the
generated example clocking source code modules delivered include the relevant MMCM
configuration.
For most Artix-7 devices, the line rate and reference clock limitations are such that the
configuration shown in Figure 3-2 (refclk as core clock) external clocking configuration
can be used. Figure 3-3 shows an example of the required clocking for this configuration.
For -1 speed grade devices only, and line rates below 3.2 Gb/s, it is necessary to provide a
separate device clock because refclk is limited to 80 MHz. Figure 3-4 shows an example
of the required clocking for this configuration.
X-Ref Target - Figure 3-3
$UWL[)3*$
ƌĞĨĐůŬ
ϭϱϯ͘ϲD,njΎ ,%8)'6B*7
0+]
*73
5()&/.
&25(/2*,&
&25(B&/.
6<65()
6<65()6XEFODVV
H[DPSOHIUHTXHQFLHV
$UWL[)3*$
UHIFON
0+]
,%8)'6B*7 *73
0+]
5()&/.
JOEOFON
0+]
,%8)'6 00&0 %8)*
&/.,1 [ 0+]
7;5;865&/.
%8)* %8)*
0+]
[ 7;5;865&/.
&25(/2*,&
&25(B&/.
H[DPSOHIUHTXHQFLHV
Figure 3-4: Artix-7 Clock Configuration Using Separate refclk and Core Clock
In these cases it is possible to use the TXOUTCLK from the transceiver to generate the core
clock where glblclk becomes optional and can be left open. Figure 3-5 shows the generic
case for use with most devices. However, Artix-7 devices require an additional MMCM as
shown in Figure 3-6 for generation of TXUSRCLK/RXUSRCLK at twice the core clock. The
core clock is the same as TXUSRCLK2/RXUSRCLK2.
Note: No example of this clocking configuration is generated for any 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.
)3*$
&ORFNLQJ0RGXOH
UHIFON 75$16&(,9(5
,%8)'6B*7
0+]
5()&/.
7;287&/.
%8)*
0+]
7;5;865&/.V
&25(/2*,&
&25(B&/.
H[DPSOHIUHTXHQFLHV
$UWL[)3*$
UHIFON *73
,%8)'6B*7
0+]
5()&/.
7;287&/.
00&0 %8)*
0+]
&/.,1 7;5;865&/.
%8)+ %8)*
0+]
7;5;865&/.
&25(/2*,&
&25(B&/.
H[DPSOHIUHTXHQFLHV
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.
Software Reset
A register is provided through the AXI4-Lite interface which triggers a complete transmit or
receive reset under software control. The configuration registers are unaffected by this
operation.
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.
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-7: 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.
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.
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-8 shows the timing relationships
between the signals on a JESD204B link. Subclass 1 is recommended for designs requiring
deterministic latency.
X-Ref Target - Figure 3-8
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
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_aclk or rx_aclk).
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.
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 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 are applied in the example design to align the clock and SYSREF edges within
1 ns, as follows.
# 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-9. This example uses the following
settings:
The report_datasheet command gives a setup of 1.2 ns and hold of 1.8 ns for the
SYSREF input. Figure 3-9 is a timing diagram based on these values.
REFCLK
3932%&