Xilinx RocketIO Transceiver User Guide (Ug024)
Xilinx RocketIO Transceiver User Guide (Ug024)
Transceiver
User Guide
R
R
“Xilinx” and the Xilinx logo shown above are registered trademarks of Xilinx, Inc. Any rights not expressly granted herein are reserved.
CoolRunner, RocketChips, Rocket IP, Spartan, StateBENCH, StateCAD, Virtex, XACT, XC2064, XC3090, XC4005, and XC5210 are
registered trademarks of Xilinx, Inc.
RocketIO™ Transceiver User Guide www.xilinx.com UG024 (v3.0) February 22, 2007
RocketIO™ Transceiver User Guide
UG024 (v3.0) February 22, 2007
The following table shows the revision history for this document.
UG024 (v3.0) February 22, 2007 www.xilinx.com RocketIO™ Transceiver User Guide
Date Version Revision
06/12/03 2.1 • Table 1-2: Added qualifying footnote to XAUI 10GFC.
• Table 1-5: Corrected definition of RXRECCLK.
• Section “RocketIO Transceiver Instantiations” in Chapter 1: added text briefly
explaining what the Instantiation Wizard does.
• Table 2-14: Changed numerics from exact values to rounded-off approximations
(nearest 5,000), and added footnote calling attention to this.
• Section “Clocking” in Chapter 2: added text recommending use of an IBUFGDS for
reference clock input to FPGA fabric.
• Section “RXRECCLK” in Chapter 2: Deleted references to SERDES_10B attribute and
to divide-by-10. (RXRECCLK is always 1/20th the data rate.).
• Section “CRC_FORMAT” in Chapter 2: Corrected minimum data length for
USER_MODE to “greater than 20”.
• Table 3-5: Clarified the significance of the VTTX/VTRX voltages shown in this table.
• Section “AC and DC Coupling” in Chapter 3: Explanatory material added regarding
VTRX/VTTX settings when AC or DC coupling is used.
• Table 4-1: Corrected pinouts for FG256 and FG456.
• Table 4-3: Corrected pinouts for FF1517 (XC2VP70).
11/07/03 2.2 • Section “Clock Signals” in Chapter 2: Added material that states:
♦ the reference clock must be provided at all times.
♦ any added jitter on the reference clock will be reflected on the RX/TX I/O.
• Figure 2-3: Added a BUFG after the IBUFGDS reference clock buffer.
• Section “RX_BUFFER_USE” in Chapter 2: Corrected erroneous “USRCLK2” to
“RXUSRCLK/RXUSRCLK2”.
• Table 2-20: Added footnotes qualifying the maximum receive-side latency parameters
given in the table.
• Section “FIBRE_CHAN” in Chapter 2: Added specification for minimum data length
(24 bytes not including CRC placeholder).
• Section “ETHERNET” in Chapter 2: Added note indicating that Gigabit Ethernet 802.3
frame specifications must be adhered to.
• Table 2-23: Corrected “External” to “Internal” loopback. Improved explanation of
Parallel Mode loopback.
• Added Figure 2-28, “Serial and Parallel Loopback Logic.”
• Section “Clock and Data Recovery” in Chapter 3: Corrected text to make clear that
RXRECCLK is always 1/20th the incoming data rate, and that CDR requires a
minimum number of transitions to achieve and maintain a lock on the received data.
• Section “Voltage Regulation” in Chapter 3: Added material defining voltage regulator
requirements when a device other than the LT1963 is used.
• Section “AC and DC Coupling” in Chapter 3: Added footnote to Table 3-8 clarifying
VTRX/VTTX voltage compliance.
• Figure 3-17 and section “Epson EG-2121CA 2.5V (LVPECL Outputs)” in Chapter 3:
Added material specifying the optional use of an LVPECL buffer as an alternative to
the LVDS buffer previously specified.
• Table 4-2: Added pinouts for FG676 package, XC2VP20 and XC2VP30.
• Table A-5: Added BREFCLK parameters TBREFPWH and TBREFPWL.
• Section “Application Notes” in Appendix C: Included new Xilinx Application Notes
XAPP648, XAPP669, and XAPP670.
• Various non-technical edits and corrections.
RocketIO™ Transceiver User Guide www.xilinx.com UG024 (v3.0) February 22, 2007
Date Version Revision
02/24/04 2.3 • Table 2-3, page 41: Added FG676 row to BREFCLK Pin Numbers.
• Figure 2-4, page 47: Added note above Figure 2-4 stating, “These local MGT clock
input inverters, shown and noted in Figure 2-4, are not included in the
FOUR_BYTE_CLK templates.
• Section“RXRECCLK” in Chapter 2: Added paragraph to section explaining how
RXRECCLK changes monotonically and how the recovered bit clock is derived.
• Section “Data Path Latency” in Chapter 2: Revised first sentence to read: “With the
many configurations of the MGT, both the transmit and receive data path latencies
vary.”
• Section “RXBUFSTATUS” in Chapter 2: Revised the description of RXBUFSTATUS.
• Figure 3-1, page 103: Replaced old Figure 3-1, page 101, with new Figure 3-1 showing
“Differential Amplifier.”
• Figure 3-6, page 107: Added new Figure 3-6, page 105, showing “MGT Receiver.”
• Table 3-4, page 108: Added text to CDR Parameters (TLOCK parameter in Conditions
column) and edited Note 3.
• Section “Voltage Regulation” in Chapter 3: Added Linear Technology part numbers
(LT1963A, LT1964).
• Section “Passive Filtering” in Chapter 3: Added new cap rules for RocketIO
transceiver.
• Figure 3-8, page 111: Replaced old Figure 3-8 with new figure showing “Power
Filtering Network on Devices with Internal and External Capacitors.”
• Table 3-7, page 112: Added Device and Package combinations table.
• Figure 3-9, page 113: Added new Figure 3-10, page 110, showing “Example Power
Filtering PCB Layout for Four MGTs, in Device with Internal Capacitors, Bottom
Layer.” Modified the text describing Figure 3-9, page 113.
• Figure 3-10, page 114: Replaced old Figure 3-10 with new figure showing “Example
Power Filtering PCB Layout for Four MGTs, in Device with External Capacitors, Top
Layer.” Removed the text describing old Figure 3-10.
• Figure 3-11, page 115: Replaced old Figure 3-11 with new figure showing “Example
Power Filtering PCB Layout for Four MGTs, in Device with External Capacitors,
Bottom Layer.” Removed the text describing old Figure 3-11.
• Table 3-8, page 118: Added VTRX and VTTX voltages for different coupling
environments.
05/20/04 2.3.1 • Changed the value of TRCLK/RFCLK in Table 3-4.
06/24/04 2.3.2 • Modified Figure 2-3.
08/25/04 2.4 • Fixed error in Hex value in Table 2-15, page 74.
• Add application notes to Appendix C, “Related Online Documents.”
• Replaced “Voltage Regulation” section with
“Voltage Regulator Selection and Use” in Chapter 3.
• Removed all references to the XCVP125 device.
• Modified Note 4 in Table 3-5.
12/09/04 2.5 • Added PCI Express and new note to Table 1-2. Added sentence to REFCLK definition
in Table 1-5. Updated Table 3-5.
• Fixed typo in “Epson EG-2121CA 2.5V (LVPECL Outputs),” page 119.
• Added XAPP572 to Appendix C, “Related Online Documents” and added references
to XAPP572 inTable 1-6 (under SERDES_10B description) and “Half-Rate Clocking
Scheme,” page 54.
UG024 (v3.0) February 22, 2007 www.xilinx.com RocketIO™ Transceiver User Guide
Date Version Revision
02/22/07 3.0 • “Example 1a: Two-Byte Clock with DCM,” page 43: Corrected code in
TWO_BYTE_CLK definition (VHDL).
• “Example 2: Four-Byte Clock,” page 46: Corrected code in DCM instantiation
(VHDL).
• “RX_LOSS_OF_SYNC_FSM,” page 77: Added note that PLL must be locked for
attribute values to be valid.
• “CRC Operation,” page 84: Added CRC logic start state on reset.
• “Power Conditioning,” page 109: Fixed broken link to Data Sheet DS083.
• “Passive Filtering,” page 111: Corrected part number of Murata ferrite bead.
• “Pletronics LV1145B (LVDS Outputs),” page 119: Corrected I/O standard name to
LVDS_25_DT.
• “Powering the RocketIO Transceivers,” page 120: Added section “Pin Connections on
the Unused RocketIO Transceivers.”
• “The POWERDOWN Port,” page 120: Added that toggling POWERDOWN properly
initializes the PMA.
• “HSPICE,” page 121 and “Characterization Reports,” page 149: Fixed obsolete links
to SPICE Model and Characterization Report web pages.
• Figure 2-12: In 8B/10B Data Flow block diagram, moved Comma Detect function
from PMA to PCS.
• Table 3-4:
♦ Corrected REFCLK/BREFCLK typical rise/fall time from 400 ps to 600 ps.
♦ Corrected TLOCK acquisition time from Typ to Max.
• Table 3-5: Corrected voltage range in heading to 1.6V–1.8V.
• Table B-1: Corrected data characters D18.2, D09.3, D10.3, D18.5, and D18.6.
RocketIO™ Transceiver User Guide www.xilinx.com UG024 (v3.0) February 22, 2007
Table of Contents
Schedule of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Schedule of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8B/10B Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Ports and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
TXBYPASS8B10B,
RX_DECODE_USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
TXCHARDISPVAL,
TXCHARDISPMODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
TXCHARISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
TXRUNDISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
TXKERR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
RXCHARISK,
RXRUNDISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
RXDISPERR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
RXNOTINTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Vitesse Disparity Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Transmitting Vitesse Channel Bonding Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Receiving Vitesse Channel Bonding Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8B/10B Bypass Serial Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8B/10B Serial Output Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
HDL Code Examples: Transceiver Bypassing of 8B/10B Encoding. . . . . . . . . . . . . . . 66
SERDES Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Serializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Deserializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Ports and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ALIGN_COMMA_MSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ENPCOMMAALIGN,
ENMCOMMAALIGN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
PCOMMA_DETECT,
MCOMMA_DETECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
COMMA_10B_MASK,
PCOMMA_10B_VALUE,
MCOMMA_10B_VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
DEC_PCOMMA_DETECT,
DEC_MCOMMA_DETECT,
DEC_VALID_COMMA_ONLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
RXREALIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
RXCHARISCOMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
RXCOMMADET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Clock Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Clock Synthesizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Clock and Data Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Clock Correction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Ports and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
CLK_CORRECT_USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
RX_BUFFER_USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
CLK_COR_SEQ_*_* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
CLK_COR_SEQ_LEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
CLK_COR_INSERT_IDLE_FLAG,
CLK_COR_KEEP_IDLE,
CLK_COR_REPEAT_WAIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Synchronization Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
RX_DATA_WIDTH,
TX_DATA_WIDTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
SERDES_10B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
TERMINATION_IMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
TXPOLARITY,
RXPOLARITY,
TXINHIBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
TX_DIFF_CTRL,
PRE_EMPHASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
LOOPBACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Other Important Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Receive Data Path 32-bit Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
32-bit Alignment Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Preface
RocketIO Features
The RocketIO transceiver’s flexible, programmable features allow a multi-gigabit serial
transceiver to be easily integrated into any Virtex-II Pro design:
• Variable-speed, full-duplex transceiver, allowing 600 Mb/s to 3.125 Gb/s baud
transfer rates
• Monolithic clock synthesis and clock recovery system, eliminating the need for
external components
• Automatic lock-to-reference function
• Five levels of programmable serial output differential swing (800 mV to 1600 mV
peak-peak), allowing compatibility with other serial system voltage levels
• Four levels of programmable pre-emphasis
• AC and DC coupling
• Programmable 50Ω/75Ω on-chip termination, eliminating the need for external
termination resistors
• Serial and parallel TX-to-RX internal loopback modes for testing operability
• Programmable comma detection to allow for any protocol and detection of any 10-bit
character.
Guide Contents
The RocketIO Transceiver User Guide contains these sections:
• Preface, “About This Guide” — This section.
• Chapter 1, “RocketIO Transceiver Overview” — An overview of the transceiver’s
capabilities and how it works.
• Chapter 2, “Digital Design Considerations” — Ports and attributes for the six
provided communications protocol primitives; VHDL/Verilog code examples for
clocking and reset schemes; transceiver instantiation; 8B/10B encoding; CRC; channel
bonding.
• Chapter 3, “Analog Design Considerations” — RocketIO serial overview; pre-
emphasis; jitter; clock/data recovery; PCB design requirements.
Additional Resources
For additional information, go to http://support.xilinx.com. The following table lists
some of the resources you can access from this website. You can also directly access these
resources using the provided URLs.
Resource Description/URL
Tutorials Tutorials covering Xilinx design flows, from design entry to
verification and debugging
http://support.xilinx.com/support/techsup/tutorials/index.htm
Answer Browser Database of Xilinx solution records
http://support.xilinx.com/xlnx/xil_ans_browser.jsp
Application Notes Descriptions of device-specific design techniques and approaches
http://support.xilinx.com/apps/appsweb.htm
Data Sheets Device-specific information on Xilinx device characteristics,
including readback, boundary scan, configuration, length count,
and debugging
http://support.xilinx.com/xlnx/xweb/xil_publications_index.jsp
Problem Solvers Interactive tools that allow you to troubleshoot your design issues
http://support.xilinx.com/support/troubleshoot/psolvers.htm
Tech Tips Latest news, design tips, and patch information for the Xilinx
design environment
http://www.support.xilinx.com/xlnx/xil_tt_home.jsp
Conventions
Conventions
This document uses the following conventions. An example illustrates each typographical
and online convention.
Comma Definition
A comma is a “K-character” used by the transceiver to align the serial data on a
byte/half-word boundary (depending on the protocol used), so that the serial data is
correctly decoded into parallel data.
Typographical
The following typographical conventions are used in this document:
Online Document
The following conventions are used in this document:
Chapter 1
The transceiver module is designed to operate at any serial bit rate in the range of
600 Mb/s to 3.125 Gb/s per channel, including the specific bit rates used by the
communications standards listed in Table 1-2. The serial bit rate need not be configured in
the transceiver, as the operating frequency is implied by the received data, the reference
clock applied, and the SERDES_10B attribute (see Table 1-3).
PACKAGE
PINS MULTI-GIGABIT TRANSCEIVER CORE FPGA FABRIC
AVCCAUXRX
2.5V RX Power Down POWERDOWN
VTRX RXRECCLK
Termination Supply RX
RXPOLARITY
RXREALIGN
RXCOMMADET
ENPCOMMAALIGN
ENMCOMMAALIGN
CRC RXCHECKINGCRC
Check RXCRCERR
RXDATA[15:0]
RXDATA[31:16]
RXP RX RXNOTINTABLE[3:0]
RXN Comma Elastic RXDISPERR[3:0]
Deserializer Detect 8B/10B Buffer RXCHARISK[3:0]
Realign Decoder RXCHARISCOMMA[3:0]
RXRUNDISP[3:0]
RXBUFSTATUS[1:0]
ENCHANSYNC
Channel Bonding
Parallel Loopback Path
CHBONDDONE
Serial Loopback Path
and
Clock Correction CHBONDI[3:0]
CHBONDO[3:0]
Clock RXLOSSOFSYNC
Manager RXCLKCORCNT
TXBUFERR
TXFORCECRCERR
TXDATA[15:0]
TXDATA[31:16]
TX 8B/10B TXBYPASS8B10B[3:0]
CRC
FIFO Encoder TXCHARISK[3:0]
TXP
TXCHARDISPMODE[3:0]
TXN Serializer Output
Polarity TXCHARDISPVAL[3:0]
TXKERR[3:0]
TXRUNDISP[3:0]
TXPOLARITY
TXINHIBIT
LOOPBACK[1:0]
TXRESET
RXRESET
REFCLK
GNDA REFCLK2
TX/RX GND REFCLKSEL
BREFCLK
AVCCAUXTX
2.5V TX BREFCLK2
RXUSRCLK
VTTX
Termination Supply TX RXUSRCLK2
TXUSRCLK
TXUSRCLK2
DS083-2_04_090402
Table 1-4 lists the sixteen gigabit transceiver primitives provided. These primitives carry
attributes set to default values for the communications protocols listed in Table 1-2. Data
widths of one, two, and four bytes are selectable for each protocol.
Notes:
1. The GT_CUSTOM ports are always the maximum port size.
2. GT_FIBRE_CHAN and GT_ETHERNET ports do not have the three CHBOND** or ENCHANSYNC ports.
3. The port size changes with relation to the primitive selected, and also correlates to the byte mapping.
4. External ports only accessible from package pins.
Primitive Attributes
Primitive Attributes
The primitives also contain attributes set by default to specific values controlling each
specific primitive’s protocol parameters. Included are channel-bonding settings (for
primitives supporting channel bonding), clock correction sequences, and CRC. Table 1-6
shows a brief description of each attribute. Table 1-7 and Table 1-8 have the default values
of each primitive.
CHAN_BOND_LIMIT Integer 1-31 that defines maximum number of bytes a slave receiver can read
following a channel bonding sequence and still successfully align to that
sequence.
CHAN_BOND_MODE STRING
OFF, MASTER, SLAVE_1_HOP, SLAVE_2_HOPS
OFF: No channel bonding involving this transceiver.
MASTER: This transceiver is master for channel bonding. Its CHBONDO
port directly drives CHBONDI ports on one or more SLAVE_1_HOP
transceivers.
SLAVE_1_HOP: This transceiver is a slave for channel bonding.
SLAVE_1_HOP’s CHBONDI is directly driven by a MASTER transceiver
CHBONDO port. SLAVE_1_HOP’s CHBONDO port can directly drive
CHBONDI ports on one or more SLAVE_2_HOPS transceivers.
SLAVE_2_HOPS: This transceiver is a slave for channel bonding.
SLAVE_2_HOPS CHBONDI is directly driven by a SLAVE_1_HOP
CHBONDO port.
Primitive Attributes
Primitive Attributes
Modifiable Primitives
As shown in Table 1-7 and Table 1-8, only certain attributes are modifiable for any
primitive. These attributes help to define the protocol used by the primitive. Only the
GT_CUSTOM primitive allows the user to modify all of the attributes to a protocol not
supported by another transceiver primitive. This allows for complete flexibility. The other
primitives allow modification of the analog attributes of the serial data lines and several
channel-bonding values.
CHAN_BOND_LIMIT 16 16 1
CHAN_BOND_OFFSET 8 8 0
CHAN_BOND_SEQ_LEN 1 1 1
CHAN_BOND_WAIT 8 8 7
Modifiable Primitives
CLK_COR_SEQ_LEN 4 (4) 1 2
REF_CLK_V_SEL 0 0 0
Notes:
1. All GT_CUSTOM attributes are modifiable.
2. Modifiable attribute for specific primitives.
3. Depends on primitive used: either 1, 2, or 4.
4. Attribute value only when RX_DATA_WIDTH is 4. When RX_DATA_WIDTH is 1 or 2, attribute value is 2.
5. Attribute value only when RX_DATA_WIDTH is 4. When RX_DATA_WIDTH is 1 or 2, attribute value is 0.
6. CRC_EOP and CRC_SOP are not applicable for this primitive.
CHAN_BOND_LIMIT 1 16 16
CHAN_BOND_OFFSET 0 8 8
CHAN_BOND_SEQ_LEN 1 4 1
CHAN_BOND_WAIT 7 8 8
Modifiable Primitives
CLK_COR_SEQ_LEN 4 1 1
REF_CLK_V_SEL 0 0 0
Notes:
1. Modifiable attribute for specific primitives.
2. Depends on primitive used: either 1, 2, or 4.
3. CRC_EOP and CRC_SOP are not applicable for this primitive.
Byte Mapping
Most of the 4-bit wide status and control buses correlate to a specific byte of TXDATA or
RXDATA. This scheme is shown in Table 1-9. This creates a way to tie all the signals
together regardless of the data path width needed for the GT_CUSTOM. All other
primitives with specific data width paths and all byte-mapped ports are affected by this
situation. For example, a 1-byte wide data path has only 1-bit control and status bits
(TXKERR[0]) correlating to the data bits TXDATA[7:0]. Footnote 3 in Table 1-5 shows the
ports that use byte mapping.
Chapter 2
Clock Signals
There are eight clock inputs into each RocketIO transceiver instantiation (Table 2-1).
REFCLK and BREFCLK are reference clocks generated from an external source and
presented to the FPGA as differential inputs. The reference clocks connect to the REFCLK
or BREFCLK ports of the RocketIO multi-gigabit transceiver (MGT). While only one of
these reference clocks is needed to drive the MGT, BREFCLK or BREFCLK2 must be used
for serial speeds of 2.5 Gb/s or greater. (See “BREFCLK,” page 41.)
To clock the serial data, the PLL architecture for the transceiver uses the reference clock as
the interpolation source. Removing the reference clock stops the RX and TX PLLs from
working. Therefore, a reference clock must be provided at all times. This is especially
important at the end of configuration when the PMA portion of the MGT requires a
reference clock in order to properly initialize. If a reference clock is not available at this
point, the user should toggle the POWERDOWN pin when the reference clock becomes
available to ensure the PMA is properly initialized.
The reference clock also clocks a Digital Clock Manager (DCM) or a BUFG to generate all of
the other clocks for the MGT. Never run a reference clock through a DCM, since unwanted
jitter will be introduced. Any additional jitter on the reference clock will be transferred to
the transceiver’s RX and TX serial I/O.
It is recommended that all reference clock sources into the FPGA be LVDS or LVPECL
IBUFGDS. The DCI or DT attributes of LVDS are optional. Refer to the Virtex-II Pro Platform
FPGA User Guide (Chapter 3, “Design Considerations”) for a complete listing and
discussion of IBUFGDS and other available I/O primitives. Also see section “Reference
Clock” in Chapter 3 of this Guide.
Typically, TXUSRCLK = RXUSRCLK and TXUSRCLK2 = RXUSRCLK2. The transceiver
uses one or two clocks generated by the DCM. As an example, USRCLK and USRCLK2
clocks run at the same speed if the 2-byte data path is used. The USRCLK must always be
frequency-locked to the reference clock of the RocketIO transceiver when SERDES_10B =
FALSE (full-rate operation).
Note: The reference clock must be at least 50 MHz (for full-rate operation only; 60 MHz for half-
rate operation) with a duty cycle between 45% and 55%, and should have a frequency stability of
±100 ppm or better, with jitter as low as possible. Module 3 of the Virtex-II Pro data sheet gives
further details.
Notes:
1. TXUSRCLK and TXUSRCLK2 must be driven by clock sources, even if only the receiver of the MGT is
being used.
Notes:
1. Because of dedicated routing to reduce jitter, BREFCLK cannot be routed through the fabric.
2. While this option is available in the silicon, this topography adds extra jitter to the reference clock
which can affect the overall performance of the transceiver.
Clocking
BREFCLK
At speeds of 2.5 Gb/s or greater, REFCLK configuration introduces more than the
maximum allowable jitter to the RocketIO transceiver. For these higher speeds, BREFCLK
configuration is required. The BREFCLK configuration uses dedicated routing resources
that reduce jitter.
BREFCLK must enter the FPGA through dedicated clock I/O. BREFCLK can connect to the
BREFCLK inputs of the transceiver and the CLKIN input of the DCM for creation of
USRCLKs. If all the transceivers on a Virtex-II Pro FPGA are to be used, two BREFCLKs
must be created, one for the top of the chip and one for the bottom. These dedicated clocks
use the same clock inputs for all packages:
P GCLK4S P GCLK6P
BREFCLK BREFCLK
N GCLK5P N GCLK7S
Top Bottom
P GCLK2S P GCLK0P
BREFCLK2 BREFCLK2
N GCLK3P N GCLK1S
refclk REF_CLK_V_SEL
0
1.5V
refclk2
1
0
REFCLKSEL refclk_out
to PCS and PMA
1
brefclk
0
2.5V
brefclk2
1
ug024_35_091802
Table 2-3 shows the BREFCLK pin numbers for all packages. Note that these pads must be
used for BREFCLK operations.
Clock Ratio
USRCLK2 clocks the data buffers. The ability to send/receive parallel data to/from the
transceiver at three different widths requires the user to change the frequency of
USRCLK2. This creates a frequency ratio between USRCLK and USRCLK2. The falling
edges of the clocks must align. Table 2-4 shows the ratios for each of the three data widths.
Notes:
1. Each edge of the slower clock must align with the falling edge of the faster clock.
Clocking
Notes:
1. Since CLK0 is needed for feedback, it can be used instead of CLK180 to clock USRCLK or USRCLK2 of the transceiver with the use
of the transceiver’s local inverter, saving a global buffer (BUFG).
Clocks for 2-Byte Data Path MGT + DCM for 2-Byte Data Path
GT_std_2
REFCLK 0 REFCLKSEL
IBUFGDS DCM REFCLK
REFCLK_P
TXUSRCLK CLKIN TXUSRCLK2
REFCLK_N
CLKFB RXUSRCLK2
RXUSRCLK
TXUSRCLK
TXUSRCLK2 RST CLK0 RXUSRCLK
RXUSRCLK2 BUFG
ug024_02a_112202
VHDL Template
-- Module: TWO_BYTE_CLK
-- Description: VHDL submodule
-- DCM for 2-byte GT
--
-- Device: Virtex-II Pro Family
---------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
--
-- pragma translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- pragma translate_on
--
entity TWO_BYTE_CLK is
port (
REFCLKIN : in std_logic;
RST : in std_logic;
USRCLK_M : buffer std_logic;
REFCLK : buffer std_logic;
LOCK : out std_logic
);
end TWO_BYTE_CLK;
--
architecture TWO_BYTE_CLK_arch of TWO_BYTE_CLK is
--
-- Components Declarations:
component BUFG
port (
I: in std_logic;
O : out std_logic
);
end component;
--
component IBUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
--
component DCM
port (
CLKIN : in std_logic;
CLKFB : in std_logic;
DSSEN : in std_logic;
PSINCDEC : in std_logic;
PSEN : in std_logic;
PSCLK : in std_logic;
RST : in std_logic;
CLK0 : out std_logic;
CLK90 : out std_logic;
CLK180 : out std_logic;
CLK270 : out std_logic;
CLK2X : out std_logic;
CLK2X180 : out std_logic;
CLKDV : out std_logic;
CLKFX : out std_logic;
CLKFX180 : out std_logic;
LOCKED : out std_logic;
PSDONE : out std_logic;
STATUS : out std_logic_vector ( 7 downto 0 )
);
end component;
--
-- Signal Declarations:
--
signal GND : std_logic;
signal CLK0_W : std_logic;
begin
Clocking
U_DCM: DCM
port map (
CLKIN => REFCLK,
CLKFB => USRCLK_M,
DSSEN => GND,
PSINCDEC => GND,
PSEN => GND,
PSCLK => GND,
RST => RST,
CLK0 => CLK0_W,
LOCKED => LOCK
);
--
-- BUFG Instantiation
U_BUFG: IBUFG
port map (
I => REFCLKIN,
O => REFCLK
);
U2_BUFG: BUFG
port map (
I => CLK0_W,
O => USRCLK_M
);
end TWO_BYTE_CLK_arch;
Verilog Template
//Module: TWO_BYTE_CLK
//Description: Verilog Submodule
// DCM for 2-byte GT
//
// Device: Virtex-II Pro Family
module TWO_BYTE_CLK (
REFCLKIN,
REFCLK,
USRCLK_M,
DCM_LOCKED
);
input REFCLKIN;
output REFCLK;
output USRCLK_M;
output DCM_LOCKED;
wire REFCLKIN;
wire REFCLK;
wire USRCLK_M;
wire DCM_LOCKED;
wire REFCLKINBUF;
wire clk_i;
DCM dcm1 (
.CLKFB ( USRCLK_M ),
.CLKIN ( REFCLKINBUF ),
.DSSEN ( 1'b0 ),
.PSCLK ( 1'b0 ),
.PSEN ( 1'b0 ),
.PSINCDEC ( 1'b0 ),
.RST ( 1'b0 ),
.CLK0 ( clk_i ),
.CLK90 ( ),
.CLK180 ( ),
.CLK270 ( ),
.CLK2X ( ),
.CLK2X180 ( ),
.CLKDV ( ),
.CLKFX ( ),
.CLKFX180 ( ),
.LOCKED ( DCM_LOCKED ),
.PSDONE ( ),
.STATUS ( )
);
BUFG buf1 (
.I ( clk_i ),
.O ( USRCLK_M )
);
IBUFG buf2(
.I ( REFCLKIN ),
.O ( REFCLKINBUF )
);
endmodule
Clocking
any interface logic. Both USRCLK and USRCLK2 are aligned on the falling edge, since
USRCLK_M is 180° out of phase when using local inverters with the transceiver.
Note: These local MGT clock input inverters, shown and noted in Figure 2-4, are not included
in the FOUR_BYTE_CLK templates.
Clocks for 4-Byte Data Path MGT + DCM for 4-Byte Data Path
GT_std_4
CLKDV_DIVIDE = 2 0 REFCLKSEL
REFCLK IBUFGDS DCM BUFG
REFCLK
REFCLK_P
TXUSRCLK REFCLK_N
CLKIN CLKDV TXUSRCLK2
CLKFB RXUSRCLK2
RXUSRCLK
TXUSRCLK
TXUSRCLK2 RST CLK0 RXUSRCLK
RXUSRCLK2 MGT clock input invert-
BUFG
ers (acceptable skew)
UG024_03_112202
VHDL Template
-- Module: FOUR_BYTE_CLK
-- Description: VHDL submodule
-- DCM for 4-byte GT
--
-- Device: Virtex-II Pro Family
---------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
--
-- pragma translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- pragma translate_on
--
entity FOUR_BYTE_CLK is
port (
REFCLKIN : in std_logic;
RST : in std_logic;
USRCLK_M : out std_logic;
USRCLK2_M : out std_logic;
REFCLK : out std_logic;
LOCK : out std_logic
);
end FOUR_BYTE_CLK;
--
architecture FOUR_BYTE_CLK_arch of FOUR_BYTE_CLK is
--
-- Components Declarations:
component BUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
--
component IBUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
--
component DCM
port (
CLKIN : in std_logic;
CLKFB : in std_logic;
DSSEN : in std_logic;
PSINCDEC : in std_logic;
PSEN : in std_logic;
PSCLK : in std_logic;
RST : in std_logic;
CLK0 : out std_logic;
CLK90 : out std_logic;
CLK180 : out std_logic;
CLK270 : out std_logic;
CLK2X : out std_logic;
CLK2X180 : out std_logic;
CLKDV : out std_logic;
CLKFX : out std_logic;
CLKFX180 : out std_logic;
LOCKED : out std_logic;
PSDONE : out std_logic;
STATUS : out std_logic_vector ( 7 downto 0 )
);
end component;
--
-- Signal Declarations:
--
signal GND : std_logic;
signal CLK0_W : std_logic;
signal CLKDV_W : std_logic;
signal USRCLK2_M_W: std_logic;
begin
USRCLK2_M <= USRCLK2_M_W;
GND <= '0';
-- DCM Instantiation
U_DCM: DCM
port map (
CLKIN => REFCLK,
-- BUFG Instantiation
U_BUFG: IBUFG
port map (
I => REFCLKIN,
Clocking
O => REFCLK
);
U2_BUFG: BUFG
port map (
I => CLK0_W,
O => USRCLK_M
);
U3_BUFG: BUFG
port map (
I => CLKDV_W,
O => USRCLK2_M_W
);
end FOUR_BYTE_CLK_arch;
Verilog Template
// Module: FOUR_BYTE_CLK
// Description: Verilog Submodule
// DCM for 4-byte GT
//
// Device: Virtex-II Pro Family
module FOUR_BYTE_CLK(
REFCLKIN,
REFCLK,
USRCLK_M,
USRCLK2_M,
DCM_LOCKED
);
input REFCLKIN;
output REFCLK;
output USRCLK_M;
output USRCLK2_M;
output DCM_LOCKED;
wire REFCLKIN;
wire REFCLK;
wire USRCLK_M;
wire USRCLK2_M;
wire DCM_LOCKED;
wire REFCLKINBUF;
wire clkdv2;
wire clk_i;
DCM dcm1 (
.CLKFB ( USRCLK_M ),
.CLKIN ( REFCLKINBUF ) ,
.DSSEN ( 1'b0 ),
.PSCLK ( 1'b0 ),
.PSEN ( 1'b0 ),
.PSINCDEC ( 1'b0 ),
.RST ( 1'b0 ),
.CLK0 ( clk_i ),
.CLK90 ( ),
.CLK180 ( ),
.CLK270 ( ),
.CLK2X ( ),
.CLK2X180 ( ),
.CLKDV ( clkdv2 ),
.CLKFX ( ),
.CLKFX180 ( ),
.LOCKED ( DCM_LOCKED ),
.PSDONE ( ),
.STATUS ( )
);
BUFG buf1 (
.I ( clkdv2 ),
.O ( USRCLK2_M )
);
BUFG buf2 (
.I ( clk_i ),
.O ( USRCLK_M )
);
IBUFG buf3(
.I ( REFCLKIN ),
.O ( REFCLKINBUF )
);
endmodule
Clocks for 1-Byte Data Path MGT + DCM for 1-Byte Data Path
REFCLK GT_std_1
0 REFCLKSEL
IBUFGDS DCM BUFG
TXUSRCLK REFCLK
REFCLK_P
RXUSRCLK CLKIN CLK2X180 TXUSRCLK2
REFCLK_N
CLKFB RXUSRCLK2
TXUSRCLK2 TXUSRCLK
RXUSRCLK2 RST CLK0 RXUSRCLK
BUFG
UG024_04_112202
VHDL Template
-- Module: ONE_BYTE_CLK
-- Description: VHDL submodule
-- DCM for 1-byte GT
--
-- Device: Virtex-II Pro Family
---------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
Clocking
--
-- pragma translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- pragma translate_on
--
entity ONE_BYTE_CLK is
port (
REFCLKIN : in std_logic;
RST : in std_logic;
USRCLK_M : out std_logic;
USRCLK2_M : out std_logic;
REFCLK : out std_logic;
LOCK : out std_logic
);
end ONE_BYTE_CLK;
--
architecture ONE_BYTE_CLK_arch of ONE_BYTE_CLK is
--
-- Components Declarations:
component BUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
--
component IBUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
--
component DCM
port (
CLKIN : in std_logic;
CLKFB : in std_logic;
DSSEN : in std_logic;
PSINCDEC : in std_logic;
PSEN : in std_logic;
PSCLK : in std_logic;
RST : in std_logic;
CLK0 : out std_logic;
CLK90 : out std_logic;
CLK180 : out std_logic;
CLK270 : out std_logic;
CLK2X : out std_logic;
CLK2X180 : out std_logic;
CLKDV : out std_logic;
CLKFX : out std_logic;
CLKFX180 : out std_logic;
LOCKED : out std_logic;
PSDONE : out std_logic;
STATUS : out std_logic_vector ( 7 downto 0 )
);
end component;
--
-- Signal Declarations:
--
signal GND : std_logic;
signal CLK0_W : std_logic;
signal CLK2X180_W : std_logic;
signal USRCLK2_M_W : std_logic;
signal USRCLK_M_W : std_logic;
begin
);
U2_BUFG: BUFG
port map (
I => CLK0_W,
O => USRCLK_M_W
);
U4_BUFG: BUFG
port map (
I => CLK2X180_W,
O => USRCLK2_M_W
);
end ONE_BYTE_CLK_arch;
Verilog Template
// Module: ONE_BYTE_CLK
// Description: Verilog Submodule
// DCM for 1-byte GT
// Device: Virtex-II Pro Family
module ONE_BYTE_CLK (
REFCLKIN,
REFCLK,
Clocking
USRCLK_M,
USRCLK2_M,
DCM_LOCKED
);
input REFCLKIN;
output REFCLK;
output USRCLK_M;
output USRCLK2_M;
output DCM_LOCKED;
wire REFCLKIN;
wire REFCLK;
wire USRCLK_M;
wire USRCLK2_M;
wire DCM_LOCKED;
wire REFCLKINBUF;
wire clk_i;
wire clk_2x_180;
DCM dcm1 (
.CLKFB ( USRCLK_M ),
.CLKIN ( REFCLKINBUF),
.DSSEN ( 1'b0 ),
.PSCLK ( 1'b0 ),
.PSEN ( 1'b0 ),
.PSINCDEC ( 1'b0 ),
.RST ( 1'b0 ),
.CLK0 ( clk_i ),
.CLK90 ( ),
.CLK180 ( ),
.CLK270 ( ),
.CLK2X ( ),
.CLK2X180 ( clk2x_180 ),
.CLKDV ( ),
.CLKFX ( ),
.CLKFX180 ( ),
.LOCKED ( DCM_LOCKED ),
.PSDONE ( ),
.STATUS ( )
);
BUFG buf1 (
.I ( clk2x_180 ),
.O ( USRCLK2_M )
);
BUFG buf2 (
.I ( clk_i ),
.O ( USRCLK_M )
);
IBUFGbuf3 (
.I ( REFCLKIN ),
.O ( REFCLKINBUF )
);
endmodule
GT_std_2
Clocks for 2-Byte Data Path CLKDV = divide by 2
0 REFCLKSEL
(SERDES_10B = TRUE) IBUFGDS DCM REFCLK
REFCLK_P
CLKIN TXUSRCLK
REFCLK REFCLK_N
RXUSRCLK
TXUSRCLK2
TXUSRCLK CLKDV RXUSRCLK2
RXUSRCLK BUFG
TXUSRCLK2
CLKFB CLK0
RXUSRCLK2
BUFG
UG024_30_013103
Clocking
IBUFGDS
REFCLK_P GT_std_2
REFCLK_N
REFCLK
REFCLK2_P
REFCLK2_N
REFCLK2
REFCLKSEL
DCM
CLKIN TXUSRCLK2
CLKFB RXUSRCLK2
TXUSRCLK
RST CLK0 RXUSRCLK
REFCLKSEL
Use of 2 DCMs is required
DCM to maintain correct
CLKIN IBUFG/DCM/BUFGMUX topology
CLKFB 0 for clock skew compensation
RST CLK0 1
BUFGMUX UG024_05a_112202
IBUFGDS
REFCLK_P GT_std_2
REFCLK_N
REFCLK
REFCLK2_P
REFCLK2
REFCLK2_N
REFCLKSEL
REFCLKSEL TXUSRCLK2
RXUSRCLK2
0 TXUSRCLK
RXUSRCLK
1
BUFGMUX UG024_05b_021503
RXRECCLK
RXRECCLK is a recovered clock derived by dividing by 20 the received data stream bit rate
(whether full-rate or half-rate). If clock correction is bypassed, it is not possible to
compensate for differences in the clock embedded in the received data and the REFCLK-
created USRCLKs. In this case, RXRECCLK is used to generate the RXUSRCLKs, as shown
in Figure 2-11.
RXRECCLK changes monotonically when it changes from being locked to the reference
clock to being locked to data and vice versa. The recovered bit clock jumps by a maximum
of 1/16th of a bit period every eight RXRECCLK cycles (20 ps for a data rate of 3.125 Gb/s
with a 320-ps bit period) in the interpolator. RXRECCLK is derived from this bit clock
through a divide-by-20 process. When the data input is kept static, however, the recovered
clock does not frequency-lock to the reference clock exactly, but can deviate from it by up
to 400 ppm.
DCM 0 REFCLKSEL
IBUFGDS BUFG
REFCLK
REFCLK_P
CLKIN CLK0 TXUSRCLK
REFCLK_N
CLKFB TXUSRCLK2
RXUSRCLK
RST
RXUSRCLK2
BUFG
RXRECCLK
UG024_38_112202
Note: Bypassing the RX elastic buffer is not recommended, as the skew created by the DCM
and routing to global clock resources is uncertain and may cause unreliable performance.
Clock Dependency
All signals used by the FPGA fabric to interact between user logic and the transceiver
depend on an edge of USRCLK2. These signals all have setup and hold times with respect
to this clock. For specific timing values, see Module 3 of the Virtex-II Pro data sheet. The
timing relationships are further discussed and illustrated in Appendix A, “RocketIO
Transceiver Timing Model.”
Reset/Power Down
Reset/Power Down
The receiver and transmitter have their own synchronous reset inputs. The transmitter
reset recenters the transmission FIFO, and resets all transmitter registers and the 8B/10B
encoder. The receiver reset recenters the receiver elastic buffer, and resets all receiver
registers and the 8B/10B decoder. Neither reset signal has any effect on the PLLs.
After the DCM-locked signal is asserted, the resets can be asserted. The resets must be
asserted for two USRCLK2 cycles to ensure correct initialization of the FIFOs. Although
both the transmit and receive resets can be attached to the same signal, separate signals are
preferred. This allows the elastic buffer to be cleared in case of an over/underflow without
affecting the ongoing TX transmission. The following example is an implementation that
resets all three data-width transceivers.
Additional reset and power control descriptions are given in Table 2-8 and Table 2-9.
Notes:
1. Unused transceivers are automatically configured as powered-down by the implementation tools.
VHDL Template
-- Module: gt_reset
-- Description: VHDL submodule
-- reset for GT
--
-- Device: Virtex-II Pro Family
---------------------------------------------------------------------
LIBRARY IEEE;
USE IEEE.std_logic_1164.all;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.Numeric_STD.all;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
--
-- pragma translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- pragma translate_on
--
entity gt_reset is
port (
USRCLK2_M : in std_logic;
LOCK : in std_logic;
REFCLK : out std_logic;
DCM_LOCKED: in std_logic;
RST : out std_logic);
end gt_reset;
--
architecture RTL of gt_reset is
--
signal startup_count : std_logic_vector (7 downto 0);
begin
Reset/Power Down
begin
if (USRCLK2_M' event and USRCLK2_M = '1') then
if(DCM_LOCKED = '0') then
startup_count <= "00000000";
elsif (DCM_LOCKED = '1') then
startup_count <= startup_count + "00000001";
end if;
end if;
end process;
end RTL;
Verilog Template
// Module: gt_reset
// Description: Verilog Submodule
// reset for4-byte GT
//
// Device: Virtex-II Pro Family
module gt_reset(
USRCLK2_M,
DCM_LOCKED,
RST
);
input USRCLK2_M;
input DCM_LOCKED;
output RST;
wire USRCLK2_M;
wire DCM_LOCKED;
reg RST;
reg [7:0] startup_counter;
endmodule
8B/10B Encoding/Decoding
Overview
The RocketIO transceiver has the ability to encode eight bits into a 10-bit serial stream
using standard 8B/10B encoding. This guarantees a DC-balanced, edge-rich serial stream,
facilitating DC- or AC-coupling and clock recovery. Table 2-10, page 62, shows the
significance of 8B/10B ports that change purpose, depending on whether 8B/10B is
bypassed or enabled.
8B/10B Encoder
A bypassable 8B/10B encoder is included in the transmitter. The encoder uses the same
256 data characters and 12 control characters (shown in Appendix B, “8B/10B Valid
Characters”) that are used for Gigabit Ethernet, XAUI, Fibre Channel, and InfiniBand.
The encoder accepts 8 bits of data along with a K-character signal for a total of 9 bits per
character applied. If the K-character signal is High, the data is encoded into one of the
twelve possible K-characters available in the 8B/10B code. (See Table B-2, page 143.) If the
K-character input is Low, the 8 bits are encoded as standard data. If the K-character input
is High and a user applies other than one of the twelve possible combinations, TXKERR
indicates the error.
8B/10B Decoder
An optional 8B/10B decoder is included in the receiver. A programmable option allows the
decoder to be bypassed. When it is bypassed, the 10-bit character order is as shown in
Figure 2-14, page 65. The decoder uses the same table that is used for Gigabit Ethernet,
Fibre Channel, and InfiniBand.
The decoder separately detects both “disparity errors” and “out-of-band” errors. A
disparity error occurs when a 10-bit character is received that exists within the 8B/10B table
(Table B-1, page 135), but has an incorrect disparity. An out-of-band error occurs when a 10-
bit character is received that does not exist within the 8B/10B table. It is possible to obtain
an out-of-band error without having a disparity error. The proper disparity is always
computed for both legal and illegal characters. The current running disparity is available at
the RXRUNDISP signal.
The 8B/10B decoder performs a unique operation if out-of-band data is detected. Should
this occur, the decoder signals the error, passes the illegal 10 bits through, and places them
on the outputs. This can be used for debugging purposes if desired.
The decoder also signals reception of one of the twelve valid K-characters (Table B-2,
page 143) by way of the RXCHARISK port.
In addition, a programmable comma detect is included. The comma detect signal
RXCOMMADET registers a comma on the receipt of any plus-comma, minus-comma, or
both. Since the comma is defined as a 7-bit character, this includes several out-of-band
characters. RXCHARISCOMMA allows the decoder to detect only the three defined
commas (K28.1, K28.5, and K28.7) as plus-comma, minus-comma, or both. In total, there
are six possible options, three for valid commas and three for “any comma.”
Note that all bytes (1, 2, or 4) at the RX FPGA interface each have their own individual
8B/10B indicators (K-character, disparity error, out-of-band error, current running
disparity, and comma detect).
8B/10B Encoding/Decoding
Transceiver Module
TX Clock Generator
50 – 156.3 MHz REFCLK Transmitter
Loop-back (parallel)
Loop-back
Channel Bonding
and 20X Multiplier
Clock Correction
Receiver
CRC RX Clock Recovery
32/16/8 bits
Elastic 8B/10B Receive RX+
RXDATA Decode Deserializer
Buffer Buffer RX−
Comma Detect
UG024_09_020507
TXCHARDISPVAL,
TXCHARDISPMODE
TXCHARDISPVAL and TXCHARDISPMODE are dual-purpose ports for the transmitter
depending upon whether 8B/10B encoding is enabled. Table 2-10 shows this dual
functionality. When encoding is enabled, these ports function as byte-mapped control
ports controlling the running disparity of the transmitted serial data.
In the encoding configuration, the disparity of the serial transmission can be controlled
with the TXCHARDISPVAL and TXCHARDISPMODE ports. When TXCHARDISPMODE
is set High, the running disparity is set before encoding the specific byte.
TXCHARDISPVAL determines if the disparity is negative (set Low) or positive (set High).
Table 2-11 illustrates this.
8B/10B Encoding/Decoding
TXCHARISK
TXCHARISK is a byte-mapped control port that is used only when the 8B/10B encoder is
implemented. This port controls whether the byte of TXDATA is to be encoded as a control
(K) character (when asserted High) or as a data character (when de-asserted). When
8B/10B encoding is bypassed, this port is undefined.
TXRUNDISP
TXRUNDISP is a status port that is byte-mapped to TXDATA. This port indicates the
running disparity after the byte of TXDATA is encoded. When High, the disparity is
positive. When Low, the disparity is negative.
TXKERR
TXKERR is a status port that is byte-mapped to TXDATA. This port is defined only if
8B/10B encoding is enabled. If a bit is asserted High, it means that TXDATA and
TXCHARISK have combined to create an invalid control (K) character. The transmission,
reception, and decode of this invalid character will create unexpected RXDATA results in
the RocketIO receiver, or in other transceivers.
RXCHARISK,
RXRUNDISP
RXCHARISK and RXRUNDISP are dual-purpose ports for the receiver depending
whether 8B/10B decoding is enabled. Table 2-10 shows this dual functionality. When
decoding is enabled, the ports function as byte-mapped status ports for the received data.
In the 8B/10B decoding configuration, RXCHARISK asserted High indicates the received
byte of data is a control (K) character. Otherwise, the received byte of data is a data
character. See Appendix B, “8B/10B Valid Characters”.
The RXRUNDISP port indicates the disparity of the received byte is either negative or
positive. RXRUNDISP asserted High indicates positive disparity. This is used in cases like
the “Vitesse Disparity Example” below. When CLK_COR_INSERT_IDLE_FLAG = TRUE,
RXRUNDISP is asserted to flag the presence of an inserted clock correction sequence.
In the bypassed configuration, RXCHARISK and RXRUNDISP are additional data bits for
the 10-, 20-, or 40-bit buses, similar to the configuration on the transmit side. RXCHARISK
[0:3] relates to bits 9, 19, 29, and 39, while RXRUNDISP pertains to bits 8, 18, 28, and 38 of
the data bus. See Figure 2-14.
RXDISPERR
RXDISPERR is a status port for the receiver that is byte-mapped to RXDATA. When a bit in
RXDISPERR is asserted High, it means that a disparity error has occurred in the received
data. This usually indicates data corruption (bit errors) or transmission of an invalid
control character. It can also occur in cases where normal disparity is not required, such as
in the “Vitesse Disparity Example”.
RXNOTINTABLE
RXNOTINTABLE is a status port for the receiver that is byte-mapped to RXDATA. When it
is asserted High, it means that the received data is not in the 8B/10B tables. This port is
only used when the 8B/10B decoder is enabled.
8B/10B Encoding/Decoding
The RocketIO core receives this data, but for cases where TXCHARDISPVAL is set High
during data transmission, the disp_err bit in CHAN_BOND_SEQ must also be set High.
TXCHARDISPMODE[0]
TXCHARDISPVAL[0]
TXDATA[7] . . . . . . TXDATA[0]
a b c d e i f g h j
0 1 2 3 4 5 6 7 8 9
During receive when 8B/10B decoding is enabled, the running disparity of the serial
transmission can be read by the transceiver from the RXRUNDISP port, while the
RXCHARISK port indicates presence of a K-character. When 8B/10B decoding is
bypassed, these bits remain as Bits “b” and “a”, respectively, of the 10-bit encoded data that
the transceiver passes on to the user logic. Figure 2-14 illustrates the RX data map during
8B/10B bypass.
RXCHARISK[0]
RXRUNDISP[0]
RXDATA[7] . . . . . . RXDATA[0]
a b c d e i f g h j
0 1 2 3 4 5 6 7 8 9
H G F E D C B A
Parallel 7 6 5 4 3 2 1 0
8B/10B
a b c d e i f g h j
Serial 0 1 2 3 4 5 6 7 8 9
The serial data bit sequence is dependent on the width of the parallel data. The most
significant byte is always sent first, regardless of the whether 1-byte, 2-byte, or 4-byte paths
are used. The least significant byte is always last. Figure 2-16 shows a case when the serial
data corresponds to each byte of the parallel data. TXDATA [31:24] is serialized and sent
out first, followed by TXDATA [23:16], TXDATA [15:8], and finally TXDATA [7:0]. The
2-byte path transmits TXDATA [15:8] and then TXDATA [7:0].
H3 − A3 H2 − A2 H1 − A1 H0 − A0
8B/10B
a3 − j3 a2 − j2 a1 − j1 a0 − j0
SERDES Alignment
SERDES Alignment
Overview
Serializer
The multi-gigabit transceiver multiplies the reference frequency provided on the reference
clock input (REFCLK) by 20, or by 10 if half-rate operation is selected. Data is converted
from parallel to serial format and transmitted on the TXP and TXN differential outputs.
The electrical polarity of TXP and TXN can be interchanged through the TXPOLARITY
port. This option can either be programmed or controlled by an input at the FPGA core TX
interface. This facilitates recovery from situations where printed circuit board traces have
been reversed.
Deserializer
The RocketIO transceiver core accepts serial differential data on its RXP and RXN inputs.
The clock/data recovery circuit extracts clock phase and frequency from the incoming data
stream and re-times incoming data to this clock. The recovered clock is presented on
output RXRECCLK at 1/20 of the received serial data rate.
The receiver is capable of handling either transition-rich 8B/10B streams or scrambled
streams, and can withstand a string of up to 75 non-transitioning bits without an error.
Word alignment is dependent on the state of comma detect bits. If comma detect is
enabled, the transceiver recognizes up to two 10-bit preprogrammed characters. Upon
detection of the character or characters, RXCOMMADET is driven High and the data is
synchronously aligned. If a comma is detected and the data is aligned, no further
alignment alteration takes place. If a comma is received and realignment is necessary, the
data is realigned and RXREALIGN is asserted. The realignment indicator is a distinct
output. The transceiver continuously monitors the data for the presence of the 10-bit
character(s). Upon each occurrence of the 10-bit character, the data is checked for word
alignment. If comma detect is disabled, the data is not aligned to any particular pattern.
The programmable option allows a user to align data on plus-comma, minus-comma, both,
or a unique user-defined and programmed sequence.
The electrical polarity of RXP and RXN can be interchanged through the RXPOLARITY
port. This can be useful in the event that printed circuit board traces have been reversed.
ALIGN_COMMA_MSB
This attribute determines where the commas will reside in the parallel received data. The
comma indicates to the deserializer how to parallelize the data. However, with the
multiple data path widths available, the PCS portion must determine where to place the
comma in the parallel data bytes.
When ALIGN_COMMA_MSB is FALSE, the PCS may place the comma in any of the
RXDATA bytes. In the 1-byte mode, of course, there is only one location in which the
comma can be placed. In the 2-byte and 4-byte paths, some uncertainty exists as to which
byte will contain the comma, as shown in Table 2-12.
When ALIGN_COMMA_MSB is TRUE, the PCS places the comma into the most
significant byte (MSB) of RXDATA in the 2-byte mode. Because the PCS is optimized for
the 2-byte mode, some uncertainty exists in the 4-byte mode as to which byte will contain
the comma, as shown in Table 2-12. See “Receive Data Path 32-bit Alignment” for more
details on this case.
TRUE √ √ √ √
FALSE √ √ √ √ √ √ √
ENPCOMMAALIGN,
ENMCOMMAALIGN
These two alignment ports control how the PMA aligns incoming serial data. It can align
on a minus-comma (negative disparity), a plus-comma (positive disparity), both, or
neither if comma alignment is not desired. These signals are latched inside the transceiver
with RXRECCLK.
Care must be taken not to de-assert these signals at the improper time. Comma detection
may be vulnerable to spurious realignment if RXRECCLK occurs at the wrong time. To
avoid this problem, ENPCOMMAALIGN and ENMCOMMAALIGN should be passed
through a flip-flop that is clocked with RXRECCLK. These flip-flops should be located
near the MGT, and RXRECCLK should use local interconnect (not global clock resources)
to reduce skew. For both top and bottom edges, the best slices to use are in the CLB
immediately to the left of the transceiver, next to the bottom of the transceiver. For the top
side of the chip, this is the fourth CLB row; for the bottom side, the bottom CLB row. For
example, for the XC2VP7, here are the best slices to use for two of the transceivers:
• For GT_X0Y1 (top edge), the best slices are SLICE_X15Y72 and SLICE_X15Y73.
• For GT_X0Y0 (bottom edge), the best slices are SLICE_X14Y0 and SLICE_X14Y1.
This must be done for each MGT. Figure 2-17 shows this recommendation.
GT_std_
*
PCOMMA_CONTROL D Q ENPCOMMAALIGN
RXRECCLK
MCOMMA_CONTROL D Q ENMCOMMAALIGN
UG024_39_013103
SERDES Alignment
Figure 2-18 and Figure 2-19 show floorplanner layouts for the two examples given above.
ug024_43_031303
ug024_44_031303
PCOMMA_DETECT,
MCOMMA_DETECT
These two control attributes define when RXCOMMADET signals that a comma has been
received. When only PCOMMA_DETECT is TRUE, RXCOMMADET signals when a plus-
comma is received, but not a minus-comma. When only MCOMMA_DET is TRUE,
RXCOMMADET signals when a minus-comma is received, but not a plus-comma. If both
attributes are TRUE, RXCOMMADET will signal when either comma character is received.
COMMA_10B_MASK,
PCOMMA_10B_VALUE,
MCOMMA_10B_VALUE
The RocketIO transceiver allows the user to define a comma character using these three
attributes. The COMMA_10B_MASK bits are used in conjunction with
PCOMMA_10B_VALUE (to define a plus-comma) or MCOMMA_10B_VALUE (to define a
minus-comma) to define some number of recognized comma characters. High bits in the
mask condition the corresponding bits in PCOMMA_10B_VALUE or
MCOMMA_10B_VALUE to matter, while Low bits in the mask function as a “don’t care”
conditioner.
For example, with COMMA_10B_MASK set to 1111111000 (meaning the three least
significant bits don’t matter) and PCOMMA_10B_VALUE is 0011111000, the comma
detection unit will recognize the following characters as plus-commas:
0011111000 (K28.7)
0011111001 (K28.1)
0011111010 (K28.5)
0011111011 through 0011111111 (not valid comma characters)
Using the same value in PCOMMA_10B_VALUE but setting COMMA_10B_MASK to
1111111111 (meaning all the bits in PCOMMA_10B_VALUE matter), the comma
detection unit will recognize only the 0011111000 (K28.7) sequence, which matches the
value of PCOMMA_10B_VALUE exactly.
DEC_PCOMMA_DETECT,
DEC_MCOMMA_DETECT,
DEC_VALID_COMMA_ONLY
These signals only pertain to the 8B/10B decoder, not the comma alignment circuitry. The
DEC_PCOMMA_DETECT and DEC_MCOMMA_DETECT control the 8B/10B decoder to
signal the RXCHARISCOMMA port if a plus-comma or minus-comma is received. This is
described in the table below.
DEC_VALID_COMMA_ONLY, for most applications, should be set to TRUE. If valid data
is being transmitted and hence received, then an invalid comma would arise only in the
case of a bit error, in which case RXCHARISCOMMA would not be asserted in the
presence of bit errors. If set to FALSE, then RXCHARISCOMMA will be asserted for
invalid K-characters.
RXREALIGN
This status signal indicates whenever, the serial data is realigned from a comma character
in the data stream. This signal will not necessarily go High after the transceiver is reset. If
Clock Recovery
ENPCOMMAALIGN and ENMCOMMAALIGN are both set to zero then this signal
should not go High. See Table 2-13.
RXCHARISCOMMA
This signal is similar to RXCHARISK, except that it signals that a specific byte of RXDATA
is a comma character. However, this definition only holds true for when 8B/10B
encoding/decoding is enabled. This port is controlled by the DEC_* attributes and is
shown in Table 2-13. If the 8B/10B decoder is bypassed, this port is undefined.
RXCOMMADET
This signal indicates if a comma character has been detected in the serial data. The
definition of this port is defined by the PCOMMA_DETECT and MCOMMA_DETECT
attributes. This signal is clocked off RXRECCLK, and to reliably have the signal pulse for
all the data width configurations, this pulse may change with respect to the USRCLKs.
DEC_VALID_COMMA_ONLY
DEC_PCOMMA_DETECT √
DEC_MCOMMA_DETECT
PCOMMA_10B_VALUE
√ √
MCOMMA_10B_VALUE
PCOMMA_DETECT
√
MCOMMA_DETECT
ENPCOMMAALIGN
√
ENMCOMMAALIGN
Clock Recovery
Overview
Clock Synthesizer
Synchronous serial data reception is facilitated by a clock/data recovery circuit. This
circuit uses a fully monolithic Phase-Locked Loop (PLL), which does not require any
external components. The clock/data recovery circuit extracts both phase and frequency
from the incoming data stream. The recovered clock is presented on output RXRECCLK at
1/20 of the serial received data rate.
The gigabit transceiver multiplies the reference frequency provided on the reference clock
input (REFCLK) by 20.
No fixed phase relationship is assumed between REFCLK, RXRECCLK, and/or any other
clock that is not tied to either of these clocks. When the 4-byte or 1-byte receiver data path
is used, RXUSRCLK and RXUSRCLK2 have different frequencies (1:2), and each edge of
the slower clock is aligned to a falling edge of the faster clock. The same relationships
apply to TXUSRCLK and TXUSRCLK2. See Table 2-5, page 43, for details.
Clock Correction
Clock RXRECCLK (the recovered clock) reflects the data rate of the incoming data. Clock
RXUSRCLK defines the rate at which the FPGA core consumes the data. Ideally, these rates
are identical. However, since the clocks typically have different sources, one of the clocks is
faster than the other. The receiver buffer accommodates this difference between the clock
rates. See Figure 2-20.
Read Write
RXUSRCLK RXRECCLK
Nominally, the buffer is always half-full. This is shown in the top buffer, where the shaded
area represents buffered data not yet read. Received data is inserted via the write pointer
under control of RXRECCLK. The FPGA core reads data via the read pointer under control
of RXUSRCLK. The half-full/half-empty condition of the buffer gives a cushion for the
differing clock rates. This operation continues indefinitely, regardless of whether or not
“meaningful” data is being received. When there is no meaningful data to be received, the
incoming data consists of IDLE characters or other padding.
If RXUSRCLK is faster than RXRECCLK, the buffer becomes more empty over time. The
clock correction logic corrects for this by decrementing the read pointer to reread a
repeatable byte sequence. This is shown in the middle buffer, Figure 2-20, where the solid
read pointer decrements to the value represented by the dashed pointer. By decrementing
the read pointer instead of incrementing it in the usual fashion, the buffer is partially
refilled. The transceiver inserts a single repeatable byte sequence when necessary to refill a
buffer. If the byte sequence length is greater than one, and if attribute
CLK_COR_REPEAT_WAIT is 0, then the transceiver can repeat the same sequence
multiple times until the buffer is refilled to the half-full condition.
Clock Recovery
Similarly, if RXUSRCLK is slower than RXRECCLK, the buffer fills up over time. The clock
correction logic corrects for this by incrementing the read pointer to skip over a removable
byte sequence that need not appear in the final FPGA core byte stream. This is shown in the
bottom buffer, Figure 2-20, where the solid read pointer increments to the value
represented by the dashed pointer. This accelerates the emptying of the buffer, preventing
its overflow. The transceiver design skips a single byte sequence, when necessary, to
partially empty a buffer. If attribute CLK_COR_REPEAT_WAIT is 0, the transceiver can
also skip four consecutive removable byte sequences in one step, to further empty the
buffer when necessary.
These operations require the clock correction logic to recognize a byte sequence that can be
freely repeated or omitted in the incoming data stream. This sequence is generally an IDLE
sequence, or other sequence comprised of special values that occur in the gaps separating
packets of meaningful data. These gaps are required to occur sufficiently often to facilitate
the timely execution of clock correction.
The clock correction logic has the ability to remove up to four IDLE sequences during a
clock correction. How many IDLEs are removed depends on several factors, including
how many IDLEs are received and whether CLK_COR_KEEP_IDLE is TRUE or FALSE.
For example, if three IDLEs are received and CLK_COR_KEEP_IDLE is set to TRUE, at
least one IDLE sequence must remain after clock correction has been completed. This
limits the clock correction logic to remove only two of the three IDLE sequences. If
CLK_COR_KEEP_IDLE is FALSE, then all three IDLEs can be removed.
Table 2-14 illustrates the relationship between the number of IDLE sequences removed, the
inherent stability of REFCLK, and the number of bytes allowed between clock correction
sequences.
Notes:
1. All numbers are approximate.
2. IDLE = the defined clock correction sequence.
Clock correction may be used with other encoding protocols, but they must have a 10-bit
alignment scheme. This is required so the comma detection logic can properly align the
data in the elastic buffer, allowing the clock correction logic to properly read out data to the
FPGA fabric.
RX_BUFFER_USE
The RX_BUFFER_USE attribute controls if the elastic buffer is bypassed or not. Most
applications use this buffer for clock correction and channel bonding. (See “Channel
Bonding (Channel Alignment),” page 79.) It is recommended that this attribute always be
set to TRUE, since this buffer allows a way to cross the clock domains of RXRECCLK and
the fabric RXUSRCLK/RXUSRCLK2.
CLK_COR_SEQ_*_*
To accommodate many different protocols, the MGT features programmability that allows
it to detect a 1-, 2-, or 4-byte clock correction sequence (CCS), such as may be used in
Gigabit Ethernet (2-byte) or Fibre Channel (4-byte). The attributes CLK_COR_SEQ_*_*
and CLK_COR_SEQ_LEN (below) define the CCS that the PCS recognizes. Both SEQ_1
and SEQ_2 can be used at the same time if multiple CCSs are required. As shown in
Table 2-15, the example CCS has two possible modes, one for when 8B/10B encoding is
used, the other for when 8B/10B encoding is bypassed. The most significant bit of the CCS
determines whether it is applicable to an 8-bit (encoded) or a 10-bit (unencoded) sequence.
These sequences require that the encoding scheme allows the comma detection and
alignment circuitry to properly align data in the elastic buffer. (See
“CLK_CORRECT_USE”, above). The bit definitions are the same as shown earlier in the
Vitesse channel-bonding example. (See “Receiving Vitesse Channel Bonding Sequence.”)
Table 2-15: Clock Correction Sequence / Data Correlation for 16-Bit Data Port
Attribute Settings
TXDATA
10-Bit Data Mode Character CHARISK
CLK_COR_SEQ 8-Bit Data Mode (hex)
(8B/10B Bypass)
Clock Recovery
CLK_COR_SEQ_LEN
To define the CCS length, this attribute takes the integer value 1, 2, 3, or 4. Table 2-16 shows
which sequences are used for the four possible settings of CLK_COR_SEQ_LEN.
Notes:
1. Applicable only if CLK_COR_SEQ_2_USE is set to TRUE.
CLK_COR_INSERT_IDLE_FLAG,
CLK_COR_KEEP_IDLE,
CLK_COR_REPEAT_WAIT
These attributes help control how clock correction is implemented.
CLK_COR_INSERT_IDLE_FLAG is a TRUE/FALSE attribute that defines the output of
the RXRUNDISP port. When set to TRUE, RXRUNDISP is raised for the first byte of each
inserted (repeated) clock correction sequence (8B/10B decoding enabled). When set to
FALSE (default), RXRUNDISP denotes the running disparity of RXDATA (8B/10B
decoding enabled).
CLK_COR_KEEP_IDLE is a TRUE/FALSE attribute that controls whether or not the final
byte stream must retain at least one clock correction sequence. When set to FALSE
(default), the clock correction logic is allowed to remove all clock correction sequences if
needed to recenter the elastic buffer. When set to TRUE, it forces the clock correction logic
to retain at least one clock correction sequence per continuous stream of clock correction
sequences.
Example: Elastic buffer is 75% full and clock correction is needed. (IDLE is the defined clock
correction sequence.)
Data stream written into elastic buffer:
D0 IDLE IDLE IDLE IDLE D1 D2
clock correction must occur before another clock correction sequence can occur. If this
attribute is 0, no limit is placed on how frequently clock correction can occur.
Example: Elastic buffer is 25% full, clock correction is needed, and one sequence is repeated
per clock correction. (IDLE is the defined clock correction sequence.)
Data stream written into elastic buffer:
D0 IDLE IDLE IDLE D1 D2
The percent that the buffer is full, together with the value of CLK_COR_REPEAT_WAIT,
determines how many times the clock correction sequence is repeated during each clock
correction.
Synchronization Logic
Overview
For some applications, it is beneficial to know if incoming data is valid or not, and if the
MGT is synchronized on the data. For applications using the 8B/10B encoding scheme, the
RX_LOSS_OF_SYNC FSM does this. It can be programmed to lose sync after a specified
number of invalid data characters are received.
Synchronization Logic
RX_LOS_INVALID_INCR,
RX_LOS_THRESHOLD
These two signals determine how fast an invalid character advances the RXLOSSOFSYNC
FSM counter before loss of sync is considered to have occurred. RX_LOS_INVALID_INCR
determines how quickly the occurrence of invalid characters is “forgotten” in the presence
of subsequent valid characters. For example, RX_LOS_INVALID_INCR = 4 means that
four consecutive valid characters after an invalid character will reset the counter.
RX_LOS_THRESHOLD determines when the counter has reached the point where the link
is considered to be “out of sync.”
RX_LOSS_OF_SYNC_FSM
The transceiver’s FSM is driven by RXRECCLK and uses status from the data stream prior
to the elastic buffer. This is intended to give early warning of possible problems well before
corrupt data appears on RXDATA. RX_LOSS_OF_SYNC_FSM, a TRUE/FALSE attribute,
indicates what the output of the RXLOSSOFSYNC port (see below) means.
Note: RX_LOSS_OF_SYNC_FSM only indicates valid data. It is assumed that the PLL is locked.
The values are undefined if the PLL is not locked.
RXLOSSOFSYNC
If RX_LOSS_OF_SYNC_FSM = FALSE, then RXLOSSOFSYNC[1] High indicates that the
transceiver has received an invalid character, and RXLOSSOFSYNC[0] High indicates that
a channel-bonding sequence has been recognized.
If RX_LOSS_OF_SYNC_FSM = TRUE, then the two bits of RXLOSSOFSYNC reflect the
state of the RXLOSSOFSYNC FSM. The state machine diagram in Figure 2-21 and the three
subsections following describe the three states of the RXLOSSOFSYNC FSM
00
count = RX_LOS_THRESHOLD
channel alignment
or
comma realignment
01 10
RESYNC LOSS_OF_SYNC
comma received
UG024_40_031803
Overview
Some gigabit I/O standards such as XAUI specify the use of multiple transceivers in
parallel for even higher data rates. Words of data are split into bytes, with each byte sent
over a separate channel (transceiver). See Figure 2-22.
In Transmitters:
Full word SSSS sent over four channels, one byte per channel
In Receivers:
Read Read
RXUSRCLK RXUSRCLK
PQRS T PQRS T
PQRS T PQRS T
PQRS T PQRS T
PQRS T PQRS T
The top half of the figure shows the transmission of words split across four transceivers
(channels or lanes). PPPP, QQQQ, RRRR, SSSS, and TTTT represent words sent over the
four channels.
The bottom-left portion of the figure shows the initial situation in the FPGA’s receivers at
the other end of the four channels. Due to variations in transmission delay—especially if
the channels are routed through repeaters—the FPGA core might not correctly assemble
the bytes into complete words. The bottom-left illustration shows the incorrect assembly of
data words PQPP, QRQQ, RSRR, etc.
To support correction of this misalignment, the data stream includes special byte
sequences that define corresponding points in the several channels. In the bottom half of
Figure 2-22, the shaded “P” bytes represent these special characters. Each receiver
recognizes the “P” channel bonding character, and remembers its location in the buffer. At
some point, one transceiver designated as the Master instructs all the transceivers to align
to the channel bonding character “P” (or to some location relative to the channel bonding
character). After this operation, the words transmitted to the FPGA core are properly
aligned: RRRR, SSSS, TTTT, etc., as shown in the bottom-right portion of Figure 2-22. To
ensure that the channels remain properly aligned following the channel bonding
operation, the Master transceiver must also control the clock correction operations
described in the previous section for all channel-bonded transceivers.
Note: All standards that use both clock correction and channel bonding require a gap greater
than or equal to 4 bytes between clock correction and channel bonding sequences. If a user
creates his/’her own protocol that uses clock correction and channel bonding, the user must
ensure that there is at least a 4 byte gap between the sequences.
The channel bonding sequence is similar in format to the clock correction sequence. This
sequence is set to the appropriate sequence for the primitives supporting channel bonding.
The GT_CUSTOM is the only primitive allowing modification to the sequence. These
sequences are comprised of one or two sequences of length up to 4 bytes each, as set by
CHAN_BOND_SEQ_LEN and CHAN_BOND_SEQ_2_USE. Other control signals include
the attributes:
• CHAN_BOND_WAIT
• CHAN_BOND_OFFSET
• CHAN_BOND_LIMIT
• CHAN_BOND_ONE_SHOT
Typical values for these attributes are:
CHAN_BOND_WAIT = 8
CHAN_BOND_OFFSET = CHAN_BOND_WAIT
CHAN_BOND_LIMIT = 2 x CHAN_BOND_WAIT
Lower values are not recommended. Use higher values only if channel bonding sequences
are farther apart than 17 bytes.
ENCHANSYNC
ENCHANSYNC controls when channel bonding is enabled. Table 2-19 shows the
recommended settings for Master and Slaves. To counter the possibility of a bit error
causing a false channel bonding sequence to occur, this port is usually de-asserted once a
group of channels have been successfully aligned.
CHAN_BOND_ONE_SHOT
As with ENCHANSYNC, many applications will require that the channels be aligned only
once. CHAN_BOND_ONE_SHOT = TRUE allows the Master to initiate a channel bonding
only once. This remains true even if more channel bonding sequences are received. (The
channels may be aligned again if RXRESET is asserted and then deasserted, and
ENCHANSYNC is deasserted and then reasserted.)
CHAN_BOND_ONE_SHOT may be set to FALSE when very few channel bonding
sequences appear in the data stream. (For Slave instantiations, this attribute should always
be set to FALSE. See Table 2-19.) When the channel bonding sequence appears frequently
in the data stream, however, it is recommended that this attribute be set to TRUE in order
to prevent the RX buffer from over- or underflowing.
CHAN_BOND_SEQ_*_*,
CHAN_BOND__SEQ_LEN,
CHAN_BOND_SEQ_2_USE
The channel bonding sequence (CBS) is similar in format to the clock correction sequence. The
CBS is set to the appropriate sequence for the primitives supporting channel bonding.
GT_CUSTOM is the only primitive allowing modification to the sequence. These
sequences are comprised of one or two sequences of length up to 4 bytes each, as set by
CHAN_BOND_SEQ_LEN and CHAN_BOND_SEQ_2_USE.
These CBSs should be unique from other delimiters in the data stream, including Clock
Correction Sequence, IDLE, Start of Frame, and End of Frame. As with clock correction,
there are multiple sequences that can be defined (GT_CUSTOM only). The primary CBS is
defined by CHAN_BOND_SEQ_1_*, where * = a number from 1 to 4.
If a second CBS is required, CHAN_BOND_SEQ_2_USE must be set to TRUE, and
CHAN_BOND_SEQ_2_* used to define the second CBS; otherwise,
CHAN_BOND_SEQ_2_USE should be left at its default value, FALSE. See “Receiving
Vitesse Channel Bonding Sequence,” page 65, for the bit breakdown of the sequence
definition.
Finally, CHAN_BOND_SEQ_LEN defines the CBS length as 1 to 4 bytes. When set to
anything other than 4, only those sequences are defined. For example, if
CHAN_BOND_SEQ_LEN is set to 2, only CHAN_BOND_SEQ_1_1 and
CHAN_BOND_SEQ_1_2 need to be defined.
CHAN_BOND_WAIT,
CHAN_BOND_OFFSET,
CHAN_BOND_LIMIT
These three attributes define how the Master performs channel alignment of the RX buffer.
The typical values of these attributes are:
CHAN_BOND_WAIT = 8
CHAN_BOND_WAIT roughly defines the maximum number of bytes by which the Slave
can lag the Master. Due to internal pipelining, the equation should be
(CHAN_BOND_WAIT - 3.5) bytes = # of bytes Slave may lag Master. For example, if
CHAN_BOND_WAIT = 8, the Slave may lag the Master by 4.5 bytes. While this type of lag
is equivalent to approximately 14 ns at 3.125 Gb/s, it is recommended that channel links be
matched as closely as possible.
The equation that produces this maximum lag time result is
lag time [ns] = (1 / serial speed [Gb/s] ) • number of lag bytes • 10 bits/byte
or, for schemes that do not use 8B/10B encoding,
(1 / serial speed [Gb/s] ) • number of 10-bit lag characters • 10 bits/character
In the example above, 1/3.125 Gb/s • 4.5 bytes • 10 bits/byte = 14.4 ns.
The recommended setting of 8 is set for protocols such as Infiniband and XAUI, which can
repeat the CBS every 16 and 17 bytes respectively. However, CHAN_BOND_WAIT can
grow accordingly if CBSs are spaced farther apart.
CHAN_BOND_OFFSET = CHAN_BOND_WAIT
CHAN_BOND_OFFSET measures the number of bytes past the beginning of the channel
bonding sequence. However, this value must always equal CHAN_BOND_WAIT.
CHAN_BOND_LIMIT = 2X CHAN_BOND_WAIT
CHAN_BOND_LIMIT defines the expiration time after which the Slave will invalidate the
most recently seen CBS location in the RX buffer. For proper alignment, this value must
always be set to two times CHAN_BOND_WAIT.
CHBONDDONE
This port indicates when a channel alignment has occurred in the MGT. When it is
asserted, RXDATA is valid after RXCLKCORCNT goes to a 101.
Note: The Slave's RXCLKCORCNT will go to 101 regardless of whether the channel bonding
was successful or not. To determine if channel bonding was successful, check both this signal
and RXCLKCORCNT.
CHBONDI,
CHBONDO
These two 4-bit ports are used by the Master MGT to control its clock correction and
channel bonding, as well as those of any Slaves bonded to it. CHBONDO of the Master is
connected to CHBONDI of a SLAVE_1_HOP. The signal is then daisy-chained from
SLAVE_1_HOP CHBONDO to a SLAVE_2_HOPS CHBONDI. See Figure 4-1 and
Figure 4-2, page 122, and Table 2-18, page 80, for examples. The three least significant bits
correlate to the value of the RXCLKCORCNT port. These four bits allow the Master to
control when the Slaves perform clock correction. This keeps channels from going out of
sync if, for instance, one Slave repeated a CCS while another skipped.
RXCLKCORCNT,
RXLOSSOFSYNC
These signals are mainly used for clock correction. However, they can convey some
information relevant to channel bonding as well. Refer to “RXCLKCORCNT” and
“RXLOSSOFSYNC,” page 77.
Troubleshooting
Factors that influence channel bonding include:
• Skew between Master and Slave CBS arrival time, both Master-lags-Slave and Slave-lags-
Master cases. The larger the separation, the larger CHAN_BOND_WAIT needs to be.
• Arrival time between consecutive CBSs. The smaller the separation is between
consecutive CBSs, the smaller CHAN_BOND_WAIT needs to be set to ensure that the
Master aligns to the intended sequence instead of the one after or the one before.
There are several possibilities that could cause unsuccessful channel bonding:
• Slave’s CBS lagging the master by too much. Essentially, the Slave does not see a CBS
when CHBONDO is asserted.
• Master CBS lags the slave by too much. In this case, the slave’s CBS sequence has
exceeded CHAN_BOND_LIMIT and has expired.
• CBS sequences appear more frequently than CHAN_BOND_LIMIT allows, causing the
Slave to align to a CBS before or after the expected one.
CRC Operation
On the transmitter side, the CRC logic recognizes where the CRC bytes should be inserted
and replaces four placeholder bytes at the tail of a data packet with the computed CRC. For
Gigabit Ethernet and Fibre Channel, transmitter CRC can adjust certain trailing bytes to
generate the required running disparity at the end of the packet. This is discussed further
in the “FIBRE_CHAN” and “ETHERNET” sections under “CRC_FORMAT,” page 85.
On the receiver side, the CRC logic verifies the received CRC value, supporting the same
standards as above.
Upon reset, the CRC logic starts with an initial value of all 1s.
CRC Generation
RocketIO transceivers support a 32-bit invariant CRC (fixed 32-bit polynomial shown
below) for Gigabit Ethernet, Fibre Channel, Infiniband, and user-defined modes.
32 26 23 22 16 12 11 10 8 7 5 4 2 1
x +x +x +x +x +x +x +x +x +x +x +x +x +x +1
The CRC recognizes the SOP (Start of Packet), EOP (End of Packet), and other packet
features to identify the beginning and end of data. These SOP and EOP are defined by
CRC_FORMAT for ETHERNET, INFINIBAND, and FIBRE_CHAN, and in these cases the
user does not need to set CRC_START_OF_PKT and CRC_END_OF_PKT. Where
CRC_FORMAT is USER_MODE (user-defined), CRC_START_OF_PKT and
CRC_END_OF_PKT are used to define SOP and EOP.
The transmitter computes 4-byte CRC on the packet data between the SOP and EOP
(excluding the CRC placeholder bytes). The transmitter inserts the computed CRC just
before the EOP. The transmitter modifies trailing Idles or EOP if necessary to generate
correct running disparity for Gigabit Ethernet and Fibre Channel. The receiver recomputes
CRC and verifies it against the inserted CRC. Figure 2-23 shows the packet format for CRC
generation. The empty boxes are only used in certain protocols (Ethernet). The user logic
must create a four-byte placeholder for the CRC by placing it in TXDATA. Otherwise, data
is overwritten.
CRC Latency
Enabling CRC increases the transmission latency from TXDATA to TXP and TXN. The
enabling of CRC does not affect the latency from RXP and RXN to RXDATA. The typical
and maximum latencies, expressed in TXUSRCLK/RXUSRCLK cycles, are shown in
Table 2-20. For timing diagrams expressing these relationships, please see Module 3 of the
Virtex-II Pro Data Sheet.
Notes:
1. See Table 2-6 and Table 2-7 for all MGT block latency parameters.
2. This maximum may occur when certain conditions are present, and clock correction and channel
bonding are enabled. If these functions are both disabled, the maximum will be near the typical
values.
3. To further reduce receive-side latency, refer to Appendix C, “Related Online Documents.”
CRC_FORMAT
There are four possible CRC modes: USER_MODE, FIBRE_CHAN, ETHERNET, and
INFINIBAND. This attribute is modifiable only for the GT_XAUI and GT_CUSTOM
primitives. Each mode has a Start of Packet (SOP) and End of Packet (EOP) setting to
determine where to start and end the CRC monitoring. USER_MODE allows the user to
define the SOP and EOP by setting the CRC_START_OF_PKT and CRC_END_OF_PKT to
one of the valid K-characters (Table B-2, page 143). The CRC is controlled by RX_CRC_USE
and TX_CRC_USE. Whenever these attributes are set to TRUE, CRC is used.
The four modes are defined in the subsections following.
USER_MODE
USER_MODE is the simplest CRC methodology. The CRC checks for the SOP and EOP,
calculates CRC on the data, and leaves the four remainders directly before the EOP. The
CRC form for the user-defined mode is shown in Figure 2-24, along with the timing for
when RXCHECKINGCRC and RXCRCERR are asserted High with respect to the incoming
data.
To check the CRC error detection logic in a testing mode such as serial loopback, a CRC
error can be forced by setting TXFORCECRCERR to High, which incorporates an error into
the transmitted data. When that data is received, it appears “corrupted,” and the receiver
signals an error by asserting RXCRCERR High at the same time RXCHECKINGCRC goes
High. User logic determines the procedure that is invoked when a CRC error occurs.
Note: Data length must be greater than 20 bytes for USER_MODE CRC generation. For CRC
to operate correctly, at least four gap bytes are required between EOP of one packet and SOP of
the next packet. The gap may contain clock correction sequences, provided that at least 4 bytes
of gap remain after all clock corrections.
FIBRE_CHAN
The FIBRE_CHAN CRC is similar to USER_MODE CRC (Figure 2-24), with one exception:
In FIBRE_CHAN, SOP and EOP are predefined protocol delimiters. Unlike USER_MODE,
FIBRE_CHAN does not need to define the attributes CRC_START_OF_PKT and
CRC_END_OF_PKT. Both USER_MODE and FIBRE_CHAN, however, disregard SOP and
EOP in CRC computation.
RXCHECKINGCRC
RXCRCERR
UG024_12_022803
Designs should generate only the EOP frame delimiter for a beginning running disparity
(RD) that is negative. (These are the frame delimiters that begin with /K28.5/D21.4/ or
/K28.5/D10.4/.) Never generate the EOP frame delimiter for a beginning RD that is
positive. (These are the frame delimiters that begin with /K28.5/D21.5/ or
/K28.5/D10.5/.) When the RocketIO CRC determines that the running disparity must be
inverted to satisfy Fibre Channel requirements, it will convert the second byte of the EOP
frame delimiter (D21.4 or D10.4) to the value required to invert the running disparity
(D21.5 or D10.5).
Note that CRC generation for EOP requires that the transmitted K28.5 be left-justified in
the MGT’s internal two-byte data path. Observing the following restrictions assures
correct alignment of the packet delimiters:
• 4-byte data path: K28.5 must appear in TXDATA[31:24] or TXDATA[15:8].
• 2-byte data path: K28.5 must appear in TXDATA[15:8].
• 1-byte data path: K28.5 must be strobed into the MGT on rising TXUSRCLK2 only
when TXUSRCLK is High.
Note: Minimum data length for this mode is 24 bytes, not including the CRC placeholder.
Note: When CRC_FORMAT=FIBRE_CHAN, TX_CRC_USE must be set to TRUE. Otherwise,
occasional errors will occur in the transmitted data stream. RX_CRC_USE can be either TRUE
or FALSE in this usage.
ETHERNET
The Ethernet CRC is more complex (Figure 2-25). The SOP, EOP, and Preamble are
neglected by the CRC. The extension bytes are special “K” characters in special cases. The
extension bytes are untouched by the CRC as are the Trail bits, which are added to
maintain packet length.
Designs should generate only the /K28.5/D16.2/ IDLE sequence for transmission, never
/K28.5/D5.6/. When the RocketIO CRC determines that the running disparity must be
inverted to satisfy Gigabit Ethernet requirements, it will convert the first /K28.5/D16.2/
IDLE following a packet to /K28.5/D5.6/, performing the necessary conversion.
Note: As noted in Figure 2-25, pad bits are used to assure that the header, data, and CRC total
to the 64-byte minimum packet length. For packets that are already 64 bytes or longer, pad bits
are not used.
Note that CRC generation for IDLE requires that the transmitted K28.5 be left-justified in
the MGT’s internal two-byte data path. Observing the following restrictions assures
correct alignment of the packet delimiters:
• 4-byte data path: K28.5 must appear in TXDATA[31:24] or TXDATA[15:8].
• 2-byte data path: K28.5 must appear in TXDATA[15:8].
• 1-byte data path: K28.5 must be strobed into the MGT on rising TXUSRCLK2 only
when TXUSRCLK is High.
Note: Minimum data length for this mode is defined by the protocol requirements.
Note: For correct operation of the Gigabit Ethernet CRC function, transmitted and received
frames must comply with the 802.3 specification regarding Gigabit Ethernet. This includes the
preamble maximum length.
INFINIBAND
The Infiniband CRC is the most complex mode, and is not supported in the CRC generator.
Infiniband CRC contains two computation types: an invariant 32-bit CRC, the same as in
Ethernet protocol; and a variant 16-bit CRC, which is not supported in the hard core.
Infiniband CRC must be implemented entirely in the FPGA fabric.
There are also two Infiniband Architecture (IBA) packets, a local and a global. Both of these
IBA packets are shown in Figure 2-26.
Local IBA
Packet R0
SOP LRH BTH R1 R2 R3 Variant CRC EOP
Payload
Global IBA
Packet R0 R1 R2 R3
SOP LRH GRH BTH Variant CRC EOP
Payload
UG024_14_020802
The CRC is calculated with certain bits masked in LRH and GRH, depending on whether
the packet is local or global. The size of these headers is shown in Table 2-21.
The CRC checks the LNH (Link Next Header) of the LRH. LRH is shown in Figure 2-27,
along with the bits the CRC uses to evaluate the next packet.
B0 B17 − B10 B2 B3 B4 B5 B6 B7
Note: Minimum data length for this mode is defined by the protocol requirements.
Because of the complexity of the CRC algorithms and implementations, especially with
Infiniband, a more in-depth discussion is beyond the scope of this manual.
CRC_START_OF_PACKET,
CRC_END_OF_PACKET
When implementing USER_MODE CRC, Start of Packet (SOP) and End of Packet (EOP)
must be defined for the CRC logic. These delimiters must be one of the defined
K-characters (see Table B-2, page 143). These must be different than a clock correction
sequence (CCS) or IDLE sequence; otherwise, the CRC will mistake the CCS or IDLE for
SOP/EOP.
Note: These attribute are not applicable to the other CRC formats.
RXCHECKINGCRC,
RXCRCERR
These two signals are status ports for the CRC circuitry.
RXCHECKINGCRC is asserted within several USRCLKs of the EOF being received from
RXDATA. This signals that the CRC circuitry has identified the SOF and the EOF.
If a CRC error occurred, RXCRCERR will be asserted at the same time that
RXCHECKINGCRC goes High.
TXFORCECRCERR,
TX_CRC_FORCE_VALUE
To test the CRC logic in either the MGT or the FPGA fabric, TXFORCECRCERR and
TX_CRC_FORCE_VALUE may be used to invoke a CRC error. When TXFORCECRCERR
is asserted High for at least one USRCLK2 cycle during data transmission (between SOP
and EOP), the CRC circuitry is forced to XOR TXDATA with TX_CRC_FORCE_VALUE,
creating a bit error. This should cause the receiver to register that a CRC error has occurred.
Receiver Buffer
The receiver buffer is required for two reasons:
• To accommodate the slight difference in frequency between the recovered clock
RXRECCLK and the internal FPGA core clock RXUSRCLK (clock correction)
• To allow realignment of the input stream to ensure proper alignment of data being
read through multiple transceivers (channel bonding)
The receiver uses an elastic buffer, where “elastic” refers to the ability to modify the read
pointer for clock correction and channel bonding.
TX_BUFFER_USE
This attribute allows the user to bypass the transmit buffer. A value of FALSE bypasses the
buffer, while a TRUE keeps the buffer in the data path. This attribute should always be set
to TRUE.
RXBUFSTATUS
This 2-bit port indicates the status of the receiver elastic buffer. RXBUFSTATUS[1] High
indicates if an overflow/underflow error has occurred. (Once set High, the assertion of
RXRESET or RXREALIGN clears this bit.) RXBUFSTATUS[0] High indicates that the elastic
buffer is at least half-full.
RX_BUFFER_USE
When set to FALSE, this attribute causes the receive buffer to be bypassed. It should
normally be set to TRUE, since channel bonding and clock correction use the receive buffer
for realignment. When the buffer is bypassed, the user logic must be clocked with
RXRECCLK.
Miscellaneous Signals
Ports and Attributes
Several ports and attributes of the MGT have very unique functionality. The following do
not have large roles in the other functionality discussed so far:
RX_DATA_WIDTH,
TX_DATA_WIDTH
These two attributes define the data width in bytes of RXDATA and TXDATA respectively.
The possible values of each attribute are 1, 2, and 4, which correspond to 8-, 16-, and 32-bit
data buses when 8B/10B encoding/decoding is used. (See “8B/10B Encoding/Decoding,”
page 60.) The bus widths are 10, 20, and 40 bits when 8B/10B encoding/decoding is
bypassed.
SERDES_10B
This attribute allows the MGT to expand its serial speed range. The normal operational
speed range of 1.0 Gb/s to 3.125 Gb/s (20 times the reference clock rate) is obtained when
this attribute is set to FALSE. When set to TRUE, the MGT serial data will run at 10 times
the reference clock rate, producing a speed range of 600 Mb/s to 1 Gb/s.
Miscellaneous Signals
TERMINATION_IMP
Receive Termination
On-chip termination is provided at the receiver, eliminating the need for external
termination. The receiver includes programmable on-chip termination circuitry for 50Ω
(default) or 75Ω impedance.
Transmit Termination
On-chip termination is provided at the transmitter, eliminating the need for external
termination. Programmable options exist for 50Ω (default) and 75Ω termination.
TXPOLARITY,
RXPOLARITY,
TXINHIBIT
A differential pair has a positive-designated and a negative-designated component. If for
some reason the polarity of these components is switched between two transceivers, the
data will not be passed properly. If this occurs, TXPOLARITY will invert the definition of
the TXN and TXP pins. On the receiver side of the MGT, the RXPOLARITY port can invert
the definition of RXN and RXP.
For some protocols, the MGT must turn off the TXN/TXP pins. The TXINHIBT port shuts
off the transmit pins and forces them to a constant value (TXN = 0, TXP = 1). Asserting
TXINHIBIT also disables internal serial loopback.
TX_DIFF_CTRL,
PRE_EMPHASIS
These two attributes control analog functionality of the MGT.
The TX_DIFF_CTRL attribute is used to compensate for signal attenuation in the link
between transceivers. It has five possible values of 400, 500, 600, 700, and 800 mV. These
values represent the peak-to-peak amplitude of one component of the differential pair; the
full differential peak-to-peak amplitude is two times these values.
The PRE_EMPHASIS attribute has four values—10%, 20%, 25%, and 33%—which are
designated by 0, 1, 2, and 3 respectively. Pre-emphasis is discussed in greater detail in
Chapter 3, “Analog Design Considerations.”
LOOPBACK
To facilitate testing without the requirement to apply patterns or measure data at gigahertz
rates, two programmable loopback features are available.
One option, serial loopback, places the gigabit transceiver into a state where transmit data
is directly fed back to the receiver. An important point to note is that the feedback path is
at the output pads of the transmitter. This tests the entirety of the transmitter and receiver.
The second loopback path is a parallel path that checks only the digital circuitry. When the
parallel option is enabled, the serial loopback path is disabled. However, the transmitter
outputs remain active and data is transmitted over the serial link. If TXINHIBIT is asserted,
TXN is forced High and TXP is forced Low until TXINHIBIT is de-asserted.
LOOPBACK allows the user to send the data that is being transmitted directly to the
receiver of the transceiver. Table 2-23 shows the three loopback modes.
PARALLEL SERIAL
LOOPBACK = 01 LOOPBACK = 10
When RXDATA is 32-bit aligned, the logic should pass RXDATA though to the protocol
logic without modification. A properly aligned data flow is shown in Figure 2-29.
When RXDATA is 32-bit misaligned, the word requiring alignment is split between
consecutive RXDATA words in the data stream, as shown in Figure 2-30. (RXDATA_REG
in the figure refers to the design example code in “32-bit Alignment Design,” page 95.)
This conditional shift/delay operation on RXDATA also must be performed on the status
outputs RXNOTINTABLE, RXDISPERR, RXCHARISK, RXCHARISCOMMA, and
RXRUNDISP in order to keep them properly synchronized with RXDATA.
It is not possible to adjust RXCLKCORCNT appropriately for shifted/delayed RXDATA,
because RXCLKCORCNT is summary data, and the summary for the shifted case cannot
be recalculated.
Verilog
/*********************************************************************
*
* XILINX IS PROVIDING THIS DESIGN, CODE, OR INFORMATION “AS IS”
* AS A COURTESY TO YOU, SOLELY FOR USE IN DEVELOPING PROGRAMS AND
* SOLUTIONS FOR XILINX DEVICES. BY PROVIDING THIS DESIGN, CODE,
* OR INFORMATION AS ONE POSSIBLE IMPLEMENTATION OF THIS FEATURE,
* APPLICATION OR STANDARD, XILINX IS MAKING NO REPRESENTATION
* THAT THIS IMPLEMENTATION IS FREE FROM ANY CLAIMS OF INFRINGEMENT,
* AND YOU ARE RESPONSIBLE FOR OBTAINING ANY RIGHTS YOU MAY REQUIRE
* FOR YOUR IMPLEMENTATION. XILINX EXPRESSLY DISCLAIMS ANY
* WARRANTY WHATSOEVER WITH RESPECT TO THE ADEQUACY OF THE
* IMPLEMENTATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR
* REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE FROM CLAIMS OF
* INFRINGEMENT, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE.
*
* (c) Copyright 2002 Xilinx Inc.
* All rights reserved.
*
*********************************************************************/
// rxchariscomma3 -- RXCHARISCOMMA[3]
// rxchariscomma1 -- RXCHARISCOMMA[1]
//
input usrclk2;
input rxreset;
input [31:0] rxdata;
input [3:0] rxisk;
input rxrealign;
input rxcommadet;
input rxchariscomma3;
input rxchariscomma1;
end
else
begin
if ( count && ( wait_to_sync != 4'b0000 ) )
wait_to_sync <= wait_to_sync - 4'b0001;
if ( rxcommadet )
count <= 1'b1;
end
end
endmodule // align_comma_32
VHDL
-- *
-- ***********************************************************
-- ***********************************************************
-- *
-- * XILINX IS PROVIDING THIS DESIGN, CODE, OR INFORMATION “AS IS”
-- * AS A COURTESY TO YOU, SOLELY FOR USE IN DEVELOPING PROGRAMS AND
-- * SOLUTIONS FOR XILINX DEVICES. BY PROVIDING THIS DESIGN, CODE,
-- * OR INFORMATION AS ONE POSSIBLE IMPLEMENTATION OF THIS FEATURE,
-- * APPLICATION OR STANDARD, XILINX IS MAKING NO REPRESENTATION
-- * THAT THIS IMPLEMENTATION IS FREE FROM ANY CLAIMS OF INFRINGEMENT,
-- * AND YOU ARE RESPONSIBLE FOR OBTAINING ANY RIGHTS YOU MAY REQUIRE
-- * FOR YOUR IMPLEMENTATION. XILINX EXPRESSLY DISCLAIMS ANY
-- * WARRANTY WHATSOEVER WITH RESPECT TO THE ADEQUACY OF THE
-- * IMPLEMENTATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR
-- * REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE FROM CLAIMS OF
-- * INFRINGEMENT, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
-- * FOR A PARTICULAR PURPOSE.
-- *
-- * (c) Copyright 2002 Xilinx Inc.
-- * All rights reserved.
-- *
--************************************************************
-- usrclk2 -- RXUSRCLK2
-- rxreset -- RXRESET
-- rxdata[31:0] RXDATA[31:0] -- (commas aligned to
-- [31:24] or [15:8])
-- rxisk[3:0] - RXCHARISK[3:0]
-- rxrealign -- RXREALIGN
-- rxcommadet -- RXCOMMADET
-- rxchariscomma3 -- RXCHARISCOMMA[3]
-- rxchariscomma1 -- RXCHARISCOMMA[1]
--
LIBRARY IEEE;
USE IEEE.std_logic_1164.all;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.Numeric_STD.all;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
ENTITY align_comma_32 IS
PORT (
aligned_data : OUT std_logic_vector(31 DOWNTO 0);
aligned_rxisk : OUT std_logic_vector(3 DOWNTO 0);
sync : OUT std_logic;
usrclk2 : IN std_logic;
rxreset : IN std_logic;
rxdata : IN std_logic_vector(31 DOWNTO 0);
rxisk : IN std_logic_vector(3 DOWNTO 0);
rxrealign : IN std_logic;
rxcommadet : IN std_logic;
rxchariscomma3 : IN std_logic;
rxchariscomma1 : IN std_logic);
END ENTITY align_comma_32;
BEGIN
aligned_data <= rxdata_hold;
aligned_rxisk <= rxisk_hold;
sync <= sync_hold;
PROCESS (usrclk2)
BEGIN
IF (usrclk2'EVENT AND usrclk2 = '1') THEN
IF (rxreset = '1') THEN
wait_to_sync <= “1111”;
count <= '0';
ELSE
IF (rxrealign = '1') THEN
wait_to_sync <= “1111”;
count <= '1';
ELSE
IF (count = '1') THEN
IF (wait_to_sync /= “0000”) THEN
wait_to_sync <= wait_to_sync - “0001”;
END IF;
END IF;
IF (rxcommadet = '1') THEN
count <= '1';
END IF;
END IF;
END IF;
END IF;
END PROCESS;
PROCESS (usrclk2)
BEGIN
IF (usrclk2'EVENT AND usrclk2 = '1') THEN
IF ((rxreset OR rxrealign) = '1') THEN
sync_hold <= '0';
ELSE
IF (wait_to_sync = “0000”)THEN
IF ((rxchariscomma3 OR rxchariscomma1) = '1') THEN
sync_hold <= '1';
END IF;
END IF;
END IF;
END IF;
END PROCESS;
-- byte_sync=0 state.
Chapter 3
AVCCAUXTX
Pullup
Network
TXP pin
50Ω or 75Ω
PMA
TXP VTTX
PMA
TXN 50Ω or 75Ω
TXN pin
GNDA UG024_46_021704
The RocketIO transceiver is implemented in Current Mode Logic (CML). A CML output
consists of transistors configured as shown in Figure 3-1. CML uses a positive supply and
offers easy interface requirements. In this configuration, both legs of the driver, VP and VN,
sink current, with one leg always sinking more current than its complement. The CML
output consists of a differential pair with 50Ω (or, optionally, 75Ω) source resistors. The
signal swing is created by switching the current in a common-drain differential pair.
The differential transmitter specification is shown in Table 3-1, page 103.
Pre-emphasis Techniques
In pre-emphasis, the initial differential voltage swing is boosted to create a stronger rising
or falling waveform. This method compensates for high frequency loss in the transmission
media that would otherwise limit the magnitude of this waveform. The effects of
pre-emphasis are shown in four scope screen captures, Figure 3-2 through Figure 3-5 on
the pages following.
The STRONG notation in Figure 3-3 is used to show that the waveform is greater in voltage
magnitude, at this point, than the LOGIC or normal level (i.e., no pre-emphasis).
A second characteristic of RocketIO transceiver pre-emphasis is that the STRONG level is
reduced after some time to the LOGIC level, thereby minimizing the voltage swing
necessary to switch the differential pair into the opposite state.
Lossy transmission lines cause the dissipation of electrical energy. This pre-emphasis
technique extends the distance that signals can be driven down lossy line media and
increases the signal-to-noise ratio at the receiver.
It should be noted that high pre-emphasis settings are not appropriate for short links (a
fraction of the maximum length of 40 inches of FR4). Excessive pre-emphasis can actually
degrade the bit error rate (BER) of a multi-gigabit link. Careful simulation and/or lab
testing of the system should always be used to verify that the optimal pre-emphasis setting
is in use. Consult the Virtex-II Pro RocketIO™ Multi-Gigabit Transceiver Characterization
Summary for more detailed information on the waveforms to be expected at the various
pre-emphasis levels.
The four levels of pre-emphasis are shown in Table 3-2.
Pre-emphasis Techniques
UG024_17_020802
Logic High
Strong High
Logic Low
Strong Low
UG024_18_020802
ug024_36_031803
Figure 3-4: Eye Diagram, 10% Pre-Emphasis, 20" FR4, Worst-Case Conditions
ug024_37_031803
Figure 3-5: Eye Diagram, 33% Pre-Emphasis, 20" FR4, Worst-Case Conditions
Differential Receiver
Differential Receiver
The differential receiver accepts the VP and VN signals, carrying out the difference
calculation VP – VN electronically.
All input data must be differential and nominally biased to a common mode voltage of
0.5 V – 2.5 V, or AC coupled. Internal terminations provide for simple 50Ω or 75Ω
transmission line connection. See Figure 3-6.
AVCCAUXRX
RXP Pullup
Pin Network
50 or 75
PMA
VTRX RXP
PMA
RXN
50 or 75
RXN
Pin
GNDA UG024_47_012904
Notes:
1. UI = Unit Interval
Jitter
Jitter is defined as the short-term variations of significant instants of a signal from their
ideal positions in time (ITU). Jitter is typically expressed in a decimal fraction of Unit
Interval (UI), e.g. 0.3 UI.
Total Jitter = Deterministic Jitter (DJ) + Random Jitter (RJ).
Deterministic Jitter (DJ) is data pattern dependant jitter, attributed to a unique source (e.g.,
Inter Symbol Interference (ISI) due to loss effects of the media). DJ is linearly additive.
Random Jitter (RJ) is due to stochastic sources, such as substrate, power supply, etc. RJ is
additive as the sum of squares, and follows a bell curve.
Notes:
1. BREFCLK for speeds of 2.5 Gb/s or greater.
2. Jitter measured at BGA ball.
3. TLOCK depends on serial speed and length/type of sequence used.
An additional feature of CDR is its ability to accept an external precision clock, REFCLK,
which either acts to clock incoming data or to assist in synchronizing the derived
RXRECCLK.
For further clarity, TXUSRCLK is used to clock data from the FPGA core to the TX FIFO.
The FIFO depth accounts for the slight phase difference between these two clocks. If the
clocks are locked in frequency, then the FIFO acts much like a pass-through buffer.
Power Conditioning
Each RocketIO transceiver has five power supply pins, all of which are sensitive to noise.
Table 3-5 summarizes the power supply pins, their names, and associated voltages. For
power and current requirements of each supply, refer to the data sheet (DS083).
To operate properly, the RocketIO transceiver requires a certain level of noise isolation
from surrounding noise sources. For this reason, it is required that both dedicated voltage
regulators and passive high-frequency filtering be used to power the RocketIO circuitry.
Notes:
1. See section “AC and DC Coupling,” page 117, and Table 3-8 for VTRX supply restrictions in AC- and
DC-coupled cases.
2. Pre-emphasis and swing settings are optimal at VTTX = 2.5V ±5%. VTTX can be powered with as low
as 1.8V in applications with data rates below 1.25 Gb/s (LVDS interfacing). Contact your Xilinx FAE
for more information on such interfaces.
Voltage regulators in this category typically are available in both fixed and adjustable
output varieties. Those with fixed output voltage require no output adjustment resistors,
whereas adjustable versions require a two resistor voltage divider to determine the output
voltage. See vendor data to select these resistors and for information on connection of all
other regulator pins (Sense, Shutdown, etc.).
Vendor application examples typically recommend a 10 μF capacitor on the input and a
10 μF capacitor on the output of the regulator. For use with RocketIO transceivers, Xilinx
requires that this be modified according to the capacitor topology shown in Figure 3-7. The
10 μF capacitor on the input is not changed. However, the 10 μF output capacitor is
replaced with one 330 μF capacitor and eight 1.0 μF capacitors. In cases where more than
16 MGTs are powered from a single regulator, an additional 1.0 μF capacitor is required for
every two additional MGTs. Tantalum is the recommended capacitor type for the 330 μF
capacitor, though the low-ESR electrolytic type is also acceptable. X7R or X5R ceramic is
the recommended capacitor type for the 1.0 μF and 10 μF capacitors. These capacitors can
be placed anywhere on the board, but preferably in close proximity to the regulator.
+ +
10μF 330μF 1μF 1μF 1μF 1μF 1μF 1μF 1μF 1μF
GND
GND GND
UG024_026_080404
Termination Voltage
Termination voltages VTTX and VTRX can be of any value in the range of 1.8V to 2.625V
(VTTX) or 1.6V to 2.525 V (VTRX). In cases where the RocketIO transceiver is interfacing
with a transceiver from another vendor, termination voltage can be dictated by the
specifications of the other transceiver. In cases where the RocketIO transceiver is
interfacing with another RocketIO transceiver, any termination voltage can be used. With
AVCCAUXTX and AVCCAUXRX already powered with 2.5V, an obvious choice for VTTX
and VTRX is 2.5V. However, it should be noted that when AC coupling is used, the
optimum value for VTRX is 1.7V. See “AC and DC Coupling” section for more
information.
Passive Filtering
To achieve the necessary isolation from high-frequency power supply noise, passive filter
networks are required on the power supply pins. Figure 3-8 illustrates the difference in
power filtering networks between a device that does contain capacitors (Internal) and a
device that does not contain capacitors (External).
2.5 V 2.5 V
AVCCAUXTX AVCCAUXTX
AVCCAUXRX AVCCAUXRX
VTT VTT
VTTX VTTX
VTR VTR
VTRX VTRX
GNDA
GNDA
UG024_48_032805
Figure 3-8: Power Filtering Network on Devices with Internal & External Capacitors
Each transceiver power pin requires one capacitor and one ferrite bead. The capacitors
must be of value 0.22 µF in an 0603 (EIA) SMT package of X7R or X5R dielectric material at
15% tolerance, rated to at least 5 V. The ferrite bead is either the Murata BLM18AG102SN1
or the Murata BLM15AG102SNID. These components may not be shared among multiple
RocketIO power supply pins under any circumstances.
Many of the Virtex-II Pro devices have power filtering capacitors incorporated into the
package to reduce component count on the PCB and improve the effectiveness of these
capacitors. Table 3-7 outlines which device/package combinations have 0.22 μF capacitors
internal to the package and which devices do not. External ferrite beads must be used in all
cases, as ferrite beads are not included inside the package in any device. Table boxes
labeled “External” denote a device for which the user must provide power filtering
capacitors externally on the PCB; those labeled “Internal” denote a device that contains all
necessary 0.22 μF capacitors for RocketIO power pins. Table boxes that say “No MGTs”
denote a device that does not have any RocketIO transceivers.
Table 3-7: Device and Package Combinations showing Devices with RocketIO Power Filtering Capacitors
Internal to the Package and Externally Mounted on the PCB
XC2VP2 XC2VP4 XC2VP7 XC2VP20 XC2VP30 XC2VP40 XC2VP50 XC2VP70 XC2VP100
FF1696 No MGTs
For devices that do not contain filtering capacitors in their package, the 0.22 μF capacitors
must be placed within 1 cm of the pins they are connected to.
Figure 3-9, Figure 3-10, and Figure 3-11 show example layouts of the power filtering
network for four transceivers (in one case in a package with internal capacitors, in another
case in a package with external capacitors).
The device in Figure 3-9 is in an FF672 package, which has eight transceivers total—four on
the top edge (rows A/B), and four on the bottom edge (rows AE/AF). This device contains
internal capacitors, so it is only necessary to have ferrite beads on the PCB. Figure 3-9
shows the bottom PCB layer, with lands for ferrite beads of the VTTX, VTRX,
AVCCAUXTX, and AVCCAUXRX supplies. The ferrite beads are mounted at the sixteen
“L[n]” locations.
Figure 3-9: Example Power Filtering PCB Layout for Four MGTs, in Device with
Internal Capacitors, Bottom Layer
The device in Figure 3-10 and Figure 3-11 is an FG456 package, which also has eight
transceivers total – four on the top edge, and four on the bottom edge. This device does not
have capacitors inside the package, so it is necessary to have both capacitors and ferrite
beads mounted on the PCB. Figure 3-10 shows the top PCB layer, with lands for the
capacitors and ferrite beads of the VTTX and VTRX supplies. Figure 3-11 shows the bottom
PCB layer, with lands for the capacitors and ferrite beads of the AVCCAUXTX and
AVCCAUXRX supplies. The ferrite beads are mounted at the eight “L[n]” locations; the
capacitors are mounted at the eight “C[n]” locations.
Figure 3-10: Example Power Filtering PCB Layout for Four MGTs, In Device with
External Capacitors, Top Layer
Figure 3-11: Example Power Filtering PCB Layout for Four MGTs, in Device with
External Capacitors, Bottom Layer
routing of high-speed serial traces should be on signal layers that share a reference plane.
If the signal layers do not share a reference plane, a capacitor of value 0.01 μF should be
connected across the two reference layers close to the vias where the signals change layers.
If both of the reference layers are DC coupled (if they are both ground), they can be
connected with vias close to where the signals change layers.
To control crosstalk, serial differential traces should be spaced at least five trace separation
widths from all other PCB routes, including other serial pairs. A larger spacing is required
if the other PCB routes carry especially noisy signals, such as TTL and other similarly noisy
standards.
The RocketIO transceiver is designed to function at 3.125 Gb/s through 40 inches of PCB
with two high-bandwidth connectors. Longer trace lengths require either a low-loss
dielectric or considerably wider serial traces.
Er = 4.3 H
Dielectric
Reference Plane
UG024_21_042903
Trace lengths up to 20" in FR4 may be of any width, provided that the differential
impedance is 100Ω or 150Ω. Trace lengths between 20" and 40" in FR4 must be at least
8 mils wide and have a differential impedance of 100Ω or 150Ω. For information on other
dielectric materials, please contact your Xilinx representative or the Xilinx Hotline.
Differential impedance of traces on the finished PCB should be verified with Time Domain
Reflectometry (TDR) measurements.
Tight coupling of differential traces is recommended. Tightly coupled traces (as opposed to
loosely coupled) maintain a very close proximity to one another along their full length.
Since the differential impedance of tightly coupled traces depends heavily on their
proximity to each other, it is imperative that they maintain constant spacing along their full
length, without deviation. If it is necessary to separate the traces in order to route through
a pin field or other PCB obstacle, it can be helpful to modify the trace geometry in the
vicinity of the obstacle to correct for the impedance discontinuity (increase the individual
trace width where trace separation occurs). Figure 3-13 and Figure 3-14 show examples of
PCB geometries that result in 100Ω differential impedance.
Reference Plane
AC and DC Coupling
AC coupling (use of DC blocking capacitors in the signal path) should be used in cases
where transceiver differential voltages are compatible, but common mode voltages are not.
Some designs require AC coupling to accommodate hot plug-in, and/or differing power
supply voltages at different transceivers. This is illustrated in Figure 3-15.
Capacitors of value 0.01 μF in a 0402 (EIA) package are suitable for AC coupling at
3.125 Gb/s when 8B/10B encoding is used. Different data rates and different encoding
schemes may require a different value.
C1
TX Z0 = 100Ω Differential RX
C2
UG024_23_042503
TX Z0 = 100Ω Differential RX
UG024_24_042503
The RocketIO differential receiver produces the best bit-error rates when its common-
mode voltage falls between 1.6V and 1.8V. When the receiver is AC-coupled to the line,
VTRX is the sole determinant of the receiver common-mode voltage, and therefore must be
set to a value within this range. When two transceivers, both terminated with 2.5V, are DC-
coupled, the common-mode voltage will establish itself at around 1.7V to 1.8V.
The VTRX and VTTX voltages for different coupling environments are summarized in
Table 3-8.
Table 3-8: Recommended VTRX and VTTX for AC- and DC-Coupled Environments
Coupling VTRX VTTX
AC 1.6V to 1.8V 2.5V ±5%
DC 2.5V ±5% (1) 2.5V ±5% (1)
Notes:
1. The recommended voltage for DC-coupled implementations is 2.5V. However,
any voltage is valid as long as both VTRX and VTTX are the same voltage, and
within the specifications shown in Table 3-5, page 109.
Reference Clock
A high degree of accuracy is required from the reference clock. For this reason, it is
required that one of the oscillators listed in this section be used:
Z0
EG2121CA LVDS or
2.5V-PECL 100Ω 100Ω LVPECL
Z0
100Ω UG024_025a_110603
Z0
EG2121CA 100Ω
2.5V-PECL 100Ω LVDS_25
_DT
Z0
100Ω UG024_025c_071504
Z0
LV1145B
2.5V-LVDS 100Ω LVDS
Z0
UG024_025b_050102
Z0
LV1145B
LVDS_25_DT
2.5V-LVDS
100Ω
Z0
UG024_025d_071504
Chapter 4
SmartModels
SmartModels are encrypted versions of the actual HDL code. These models allow the user
to simulate the actual functionality of the design without having access to the code itself.
A simulator with SmartModel capability is required to use SmartModels.
The models must be extracted before they can be used. For information on how to extract
the SmartModels under ISE 5.1i, see Solution Record 15501.
HSPICE
HSPICE is an analog design model that allows simulation of the RX and TX high-speed
transceiver. To obtain these HSPICE models, go to the Xilinx Download Center at:
http://www.xilinx.com/xlnx/xil_sw_updates_home.jsp.
Select HSPICE and Eldo Models and then Virtex-II Pro from the pull-down menus.
Online registration is required. Follow the instructions on the web page to register.
Implementation Tools
Par
For place and route, the transceiver has one restriction. This is required when channel
bonding is implemented. Because of the delay limitations on the CHBONDO to CHBONDI
ports, linking of the Master to a Slave_1_hop must run either in the X or Y direction, but not
both.
In Figure 4-1, the two Slave_1_hops are linked to the master in only one direction. To
navigate to the other slave (a Slave_2_hops), both X and Y displacement is needed. This
slave needs one level of daisy-chaining, which is the basis of the Slave_2_hops setting.
Figure 4-2 shows the channel bonding mode and linking for a 2VP50, which (optionally)
contains more transceivers (16) per chip.
MASTER SLAVE_1_HOP
Top of device
Bottom of device
SLAVE_1_HOP SLAVE_2_HOPS
UG024_08_020802
CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO
Top of device
Bottom of device
CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI CHBONDO CHBONDI
UG024_08_020802
Table 4-1: LOC Grid & Package Pins Correlation for FG256/456 & FF672
GT_X0_Y0 T4, T5, T6, T7 AB7, AB8, AB3, AB4, AF18, AF17, AF23, AF22,
AB9, AB10 AB5, AB6 AF16, AF15 AF21, AF20
GT_X0_Y1 A4, A5, A6, A7, A8, A9, A3, A4, A5, A18, A17, A23, A22,
A7 A10 A6 A16, A15 A21, A20
GT_X1_Y0 T10, T11, T12, AB13,AB14, AB7, AB8, AF12, AF11, AF18, AF17,
T13 AB15, AB16 AB9, AB10 AF10, AF9 AF16, AF15
GT_X1_Y1 A10, A11, A13, A14, A7, A8, A9, A12, A11, A18, A17,
A12, A13 A15, A16 A10 A10, A9 A16, A15
Table 4-2: LOC Grid & Package Pins Correlation for FG676, FF896, and FF1152
FG676 FF896 FF1152
LOC
Constraints 2VP20 2VP7 2VP20
2VP40 2VP30 2VP40 2VP50
/2VP30 /2VP20 /2VP30
GT_X0_Y0 AF7, AF6, AK27, AK26, AK27, AK26, AP29, AP28, AP33, AP32, AP33, AP32,
AF5, AF4 AK25, AK24 AK25, AK24 AP27, AP26 AP31AP30 AP31AP30
GT_X0_Y1 A7, A6, A5, A27, A26, A27, A26, A29, A28, A33, A32, A33, A32,
A4 A25, A24 A25, A24 A27, A26 A31, A30 A31, A30
GT_X1_Y0 AF12, AF11, AF7, AF6, AK20, AK19, AK20, AK19, AP21, AP20, AP29, AP28, AP29, AP28,
AF10, AF9 AF5, AF4 AK18, AK17 AK18, AK17 AP19, AP18 AP27, AP26 AP27, AP26
GT_X1_Y1 A12, A11, A7, A6, A5, A20, A19, A20, A19, A21, A20, A29, A28, A29, A28,
A10, A9 A4 A18, A17 A18, A17 A19, A18 A27, A26 A27, A26
GT_X2_Y0 AF18, AF17, AF12, AF11, AK14, AK13, AK14, AK13, AP17, AP16, AP21, AP20, AP25, AP24,
AF16, AF15 AF10, AF9 AK12, AK11 AK12, AK11 AP15, AP14 AP19, AP18 AP23, AP22
GT_X2_Y1 A18, A17, A12, A11, A14, A13, A14, A13, A17, A16, A21, A20, A25, A24,
A16, A15 A10, A9 A12, A11 A12, A11 A15, A14 A19, A18 A23, A22
GT_X3_Y0 AF23, AF22, AF18, AF17, AK7, AK6, AK7, AK6, AP9, AP8, AP17, AP16, AP21, AP20,
AF21, AF20 AF16, AF15 AK5, AK4 AK5, AK4 AP7, AP6 AP15, AP14 AP19, AP18
GT_X3_Y1 A23, A22, A18, A17, A7, A6, A5, A7, A6, A5, A9, A8 A7, A17, A16, A21, A20,
A21, A20 A16, A15 A4 A4 A6 A15, A14 A19, A18
GT_X8_Y0
GT_X8_Y1
GT_X9_Y0
GT_X9_Y1
Table 4-3: LOC Grid & Package Pins Correlation for FF1517 and FF1704
GT_X10_Y0
GT_X10_Y1
GT_X11_Y0
GT_X11_Y1
Appendix A
There are many signals entering and exiting the RocketIO core. (Refer to Figure A-1.) The
model presented in this section treats the RocketIO core as a “black box.” Propagation
delays internal to the RocketIO core logic are ignored. Signals are characterized with setup
and hold times for inputs, and with clock to valid output times for outputs.
There are five clocks associated with the RocketIO core, but only three of these clocks—
RXUSRCLK, RXUSRCLK2, and TXUSRCLK2—have I/Os that are synchronous to them.
The following table gives a brief description of all of these clocks. For an in-depth
discussion of clocking the RocketIO core, refer to Chapter 2, “Digital Design
Considerations.”.
PACKAGE
PINS MULTI-GIGABIT TRANSCEIVER CORE FPGA FABRIC
AVCCAUXRX
2.5V RX Power Down POWERDOWN
VTRX RXRECCLK
Termination Supply RX
RXPOLARITY
RXREALIGN
RXCOMMADET
ENPCOMMAALIGN
ENMCOMMAALIGN
CRC RXCHECKINGCRC
Check RXCRCERR
RXDATA[15:0]
RXDATA[31:16]
RXP RX RXNOTINTABLE[3:0]
RXN Comma Elastic RXDISPERR[3:0]
Deserializer Detect 8B/10B Buffer RXCHARISK[3:0]
Realign Decoder RXCHARISCOMMA[3:0]
RXRUNDISP[3:0]
RXBUFSTATUS[1:0]
ENCHANSYNC
Channel Bonding
Parallel Loopback Path
CHBONDDONE
Serial Loopback Path
and
Clock Correction CHBONDI[3:0]
CHBONDO[3:0]
Clock RXLOSSOFSYNC
Manager RXCLKCORCNT
TXBUFERR
TXFORCECRCERR
TXDATA[15:0]
TXDATA[31:16]
TX 8B/10B TXBYPASS8B10B[3:0]
CRC
FIFO Encoder TXCHARISK[3:0]
TXP
TXCHARDISPMODE[3:0]
TXN Serializer Output
Polarity TXCHARDISPVAL[3:0]
TXKERR[3:0]
TXRUNDISP[3:0]
TXPOLARITY
TXINHIBIT
LOOPBACK[1:0]
TXRESET
RXRESET
REFCLK
GNDA REFCLK2
TX/RX GND REFCLKSEL
BREFCLK
AVCCAUXTX
2.5V TX BREFCLK2
RXUSRCLK
VTTX
Termination Supply TX RXUSRCLK2
TXUSRCLK
TXUSRCLK2
DS083-2_04_090402
Timing Parameters
Timing Parameters
Parameter designations are constructed to reflect the functions they perform, as well as the
I/O signals to which they are synchronous. The following subsections explain the meaning
of each of the basic timing parameter designations used in the tables.
ParameterName Format:
TGxCK = Setup time before clock edge
TGCKx = Hold time after clock edge
where
x = C (Control inputs)
D (Data inputs)
ParameterName Format:
TGCKx = Delay time from clock edge to output
where
x = CO (Control outputs)
DO (Data outputs)
ST (Status outputs)
Notes:
1. REFCLK is not synchronous to any RocketIO signals.
2. BREFCLK is not synchronous to any RocketIO signals.
3. TXUSRCLK is not synchronous to any RocketIO signals.
1 2
TxGWL
TxGWH
CLOCK
TGCCK
TGCKC
CONTROL
INPUTS
TGCKCO
CONTROL
OUTPUTS
TGCKDO
DATA
OUTPUTS
TGDCK
TGCKD
DATA
INPUTS
UG012_106_02_100101
Appendix B
Appendix C
Application Notes
Application Notes
in this document uses the PPC405 core device control register (DCR) bus interface to
implement a simple solution with a minimum of FPGA resources.
Characterization Reports
This application note describes how to use the RocketIO multi-gigabit transceivers
available in the Virtex-II Pro family of FPGA devices to implement a transmitter that can
support both SD-SDI and HD-SDI. The flexibility of the RocketIO transceivers combined
with the programmable logic of the Virtex-II Pro devices makes it possible to implement
multi-rate SDI interfaces.
Since all Virtex-II Pro devices have four or more RocketIO transceivers, it is possible to
implement multiple HD-SDI and SDI-SDI interfaces in a single FPGA.
Characterization Reports
Characterization Reports can be accessed from:
http://www.xilinx.com/xlnx/xweb/xil_publications_index.jsp?category=Reports.
SPICE models can be accessed from the Xilinx Download Center at:
http://www.xilinx.com/xlnx/xil_sw_updates_home.jsp.
Select HSPICE and Eldo Models and then Virtex-II Pro from the pull-down menus.
Online registration is required. Follow the instructions on the web page to register.
White Papers
White Papers
T
Termination Voltage 110
Timing Parameters 129
Total Jitter (DJ + RJ) 107
Transmitter and Elastic (Receiver) Buffers
89
Transmitter Buffer (FIFO) 89
U
User Guide conventions
online references 20
port and attribute names 19
typographical 19
V
Vitesse Disparity Example 64
Voltage Regulator Selection and Use 109