Inc. Network Card User Manual

ManualsBrandsXilinx ManualsNetwork Card1000BASE-X

LogiCORE™ IP

Ethernet 1000BASE-X

PCS/PMA or SGMII v9.1

User Guide

UG155 March 24, 2008

Summary of content (230 pages)

PAGE 1
LogiCORE™ IP Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 2
R Xilinx is disclosing this Specification to you solely for use in the development of designs to operate on Xilinx FPGAs. Except as stated herein, none of the Specification may be copied, reproduced, distributed, republished, downloaded, displayed, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of Xilinx.
PAGE 3
Table of Contents Schedule of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedule of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 13 Preface: About This Guide Guide Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Conventions . . . . . . . . . . .
PAGE 4
R Implement the Ethernet 1000BASE-X PCS/PMA or SGMII Core in Your Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Chapter 5: Using the Client-side GMII Data Path Designing with the Client-side GMII for the 1000BASE-X Standard. . . . . . . . . . . . 53 GMII Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GMII Reception . . . . . . . . . . . . . . . . . . . . .
PAGE 5
R Virtex-5 LXT and SXT Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Virtex-5 FXT Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Chapter 9: Configuration and Status MDIO Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 MDIO Bus System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PAGE 6
R Virtex-5 RocketIO GTX Transceivers for SGMII or Dynamic Standards Switching Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ten-Bit Interface Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constraints When Implementing an External GMII . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding Timing Reports for Setup/Hold Timing . . . . . . . . . . . . . . . . . . . . . .
PAGE 7
R Appendix B: Core Latency Core Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Latency for 1000BASE-X PCS with TBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Latency for 1000BASE-X PCS and PMA Using a RocketIO Transceiver . . . . . . . . . . 208 Latency for SGMII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PAGE 8
R www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 9
Schedule of Figures Chapter 2: Core Architecture Figure 2-1: Functional Block Diagram Using RocketIO Transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-2: Functional Block Diagram with a Ten-Bit Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2-3: Component Pinout Using RocketIO Transceiver with PCS Management Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PAGE 10
R Chapter 6: The Ten-Bit Interface Figure 6-1: Figure 6-2: Figure 6-3: Figure 6-4: Figure 6-5: Figure 6-6: Figure 6-7: Figure 6-8: Ten-Bit Interface Transmitter Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ten-Bit-Interface Receiver Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TBI Receiver Logic for Spartan-3, Spartan-3E, and Spartan-3A Devices. . . . . . . . . . . . .
PAGE 11
R Chapter 11: Dynamic Switching of 1000BASE-X and SGMII Standards Figure 11-1: Typical Application for Dynamic Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Chapter 12: Constraining the Core Figure 12-1: Figure 12-2: Figure 12-3: Figure 12-4: Local Clock Place and Route for Top MGT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input TBI timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PAGE 12
R www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 13
Schedule of Tables Chapter 2: Core Architecture Table 2-1: GMII Interface Signal Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Table 2-2: Other Common Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Table 2-3: Optional MDIO Interface Signal Pinout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Table 2-4: Optional Configuration and Status Vectors . . . . . . . . . . . . . . . . . . . . . .
PAGE 14
R Table 9-21: PHY Identifier (Registers 2 and 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Table 9-22: SGMII Auto-Negotiation Advertisement (Register 4) . . . . . . . . . . . . . . . . . . 139 Table 9-23: SGMII Auto-Negotiation Link Partner Ability Base (Register 5) . . . . . . . . 140 Table 9-24: SGMII Auto-Negotiation Expansion (Register 6) . . . . . . . . . . . . . . . . . . . . . . 141 Table 9-25: SGMII Auto-Negotiation Next Page Transmit (Register 7). . . . . . . . . .
PAGE 15
R Preface About This Guide The LogiCORE™ IP Ethernet 1000BASE-X PCS/PMA or SGMII User Guide provides information about generating a Xilinx Ethernet 1000BASE-X PCS/PMA or SGMII core, customizing and simulating the core using the provided example design, and running the design files through implementation using the Xilinx tools. Guide Contents This guide contains the following information.
PAGE 16
R Preface: About This Guide • Chapter 11, “Dynamic Switching of 1000BASE-X and SGMII Standards” provides general guidelines for using the core to perform dynamic standards switching between 1000BASE-X and SGMII. • Chapter 12, “Constraining the Core” defines the constraint requirements of the core. • Chapter 13, “Interfacing to Other Cores” describes additional design considerations associated with implementing the core with the 1-Gigabit Ethernet MAC and TriMode Ethernet MAC cores.
PAGE 17
R Conventions Convention Meaning or Use Example An optional entry or parameter. However, in bus specifications, such as bus[7:0], they are required. ngdbuild [option_name] design_name A list of items from which you must choose one or more lowpwr ={on|off} Separates items in a list of choices lowpwr ={on|off} Vertical ellipsis . . . Repetitive material that has been omitted IOB #1: Name = QOUT’ IOB #2: Name = CLKIN’ . . . Horizontal ellipsis . . .
PAGE 18
R 20 Preface: About This Guide www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 19
R Chapter 1 Introduction The Ethernet 1000BASE-X PCS/PMA or SGMII core is a fully verified solution that supports Verilog HDL and VHDL. In addition, the example design provided with the core supports both Verilog and VHDL. This chapter introduces the Ethernet 1000BASE-X PCS/PMA or SGMII core and provides related information, including recommended design experience, additional resources, technical support, and methods for submitting feedback to Xilinx.
PAGE 20
R Chapter 1: Introduction Additional Core Resources For detailed information and updates about the Ethernet 1000BASE-X PCS/PMA or SGMII core, see the following documents, located on the Xilinx Ethernet 100BASE-X PCS/PMA product page.
PAGE 21
R Feedback Document For comments or suggestions about this document, please submit a WebCase from www.support.xilinx.com/. Be sure to include the following information: • • • • Document title Document number Page number(s) to which your comments refer Explanation of your comments Ethernet 1000BASE-X PCS/PMA or SGMII v9.1 UG155 March 24, 2008 www.xilinx.
PAGE 22
R 24 Chapter 1: Introduction www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 23
R Chapter 2 Core Architecture This chapter describes the architecture of the Ethernet 1000BASE-X PCS/PMA or SGMII core, including all interfaces and major functional blocks. System Overview Ethernet 1000BASE-X PCS/PMA or SGMII Using A RocketIO Transceiver The Ethernet 1000BASE-X PCS/PMA or SGMII core provides the functionality to implement the 1000BASE-X PCS and PMA sub-layers or used to provide a GMII to SGMII bridge when used with a RocketIO transceiver.
PAGE 24
R Chapter 2: Core Architecture LogiCORE Ethernet 1000BASE-X PCS/PMA or SGMII Core Optional Auto-Negotiation RocketIO Transeiver GMII to MAC RocketIO I/F Block GMII Block PCS Transmit Engine To PMD Sublayer PCS Receive Engine and Synchronization MDIO Interface Optional PCS Management Figure 2-1: Functional Block Diagram Using RocketIO Transceiver GMII Block A client-side GMII is provided with the core, which can be used as an internal interface for connection to an embedded Media Access Contro
PAGE 25
R System Overview Optional PCS Management Registers Configuration and status of the core, including access to and from the optional AutoNegotiation function, uses the 1000BASE-X PCS Management Registers defined in IEEE 802.3 clause 37. These registers are accessed through the serial Management Data Input/Output Interface (MDIO), defined in IEEE 802.3 clause 22, as if it were an externally connected PHY.
PAGE 26
R Chapter 2: Core Architecture 8B/10B Encoder 8B10B encoding, as defined in IEEE 802.3 (Tables 36-1a to 36-1e and Table 36-2), is implemented in a block SelectRAM™, configured as ROM, and used as a large look-up table. 8B/10B Decoder 8B10B decoding, as defined in IEEE 802.3 (Table 36-1a to 36-1e and Table 36-2), is implemented in a block SelectRAM, configured as ROM, and used as a large look-up table.
PAGE 27
R Core Interfaces functionality. For more information, see Chapter 3, “Generating and Customizing the Core.
PAGE 28
R Chapter 2: Core Architecture Figure 2-4 shows the pinout for the Ethernet 1000BASE-X PCS/PMA or SGMII core using a RocketIO transceiver without the optional PCS Management Registers GMII gmii_txd[7:0] gmii_tx_en gmii_tx_er gmii_rxd[7:0] gmii_rx_dv gmii_rx_er gmii_isolate MDIO Replacement RocketIO Interface mgt_rx_reset mgt_tx_reset userclk userclk2 dcm_locked rxbufstatus[1:0] rxchariscomma rxcharisk rxclkcorcnt[2:0] rxdata[7:0] rxdisperr rxnotintable rxrundisp txbuferr configuration_vector[3:0] po
PAGE 29
R Core Interfaces Figure 2-5 shows the pinout for the Ethernet 1000BASE-X PCS/PMA or SGMII core when using the TBI with optional PCS Management Registers. The signals shown in the AutoNegotiation box are included only when the core includes the Auto-Negotiation functionality (see Chapter 3, “Generating and Customizing the Core”). ).
PAGE 30
R Chapter 2: Core Architecture Figure 2-6 shows the pinout for the Ethernet 1000BASE-X PCS/PMA or SGMII core when using a TBI without the optional PCS Management Registers.
PAGE 31
R Core Interfaces Figure 2-7 shows the pinout for the Ethernet 1000BASE-X PCS/PMA or SGMII core using the optional dynamic switching logic (between 1000BASE-X and SGMII standards). This mode is shown used with a RocketIO transceiver interface. For more information, see Chapter 11, “Dynamic Switching of 1000BASE-X and SGMII Standards.
PAGE 32
R Chapter 2: Core Architecture Table 2-1: GMII Interface Signal Pinout Signal Direction Description gmii_txd[7:0]1 Input GMII Transmit data from MAC. gmii_tx_en1 Input GMII Transmit control signal from MAC. gmii_tx_er1 Input GMII Transmit control signal from MAC. gmii_rxd[7:0]2 Output GMII Received data to MAC. gmii_rx_dv2 Output GMII Received control signal to MAC. gmii_rx_er2 Output GMII Received control signal to MAC.
PAGE 33
R Core Interfaces Common Signal Pinout Table 2-2 describes the remaining signals common to all parameterizations of the core. Table 2-2: Other Common Signals Signal Direction Description reset Input Asynchronous reset for the entire core. Active High. Clock domain is not applicable. signal_detect Input Signal direct from PMD sublayer indicating the presence of light detected at the optical receiver. If set to ’1,’ indicates that the optical receiver has detected light.
PAGE 34
R Chapter 2: Core Architecture MDIO Management Interface Pinout (Optional) Table 2-3 describes the optional MDIO interface signals of the core used to access the PCS Management Registers. These signals are typically connected to the MDIO port of a MAC device, either off-chip or to an internally integrated MAC core. For more information, see “Management Registers” in Chapter 9. Table 2-3: Optional MDIO Interface Signal Pinout Direction Clock Domain mdc Input N/A Management clock (<= 2.5 MHz).
PAGE 35
R Core Interfaces Configuration Vector (Optional) Table 2-4 shows the alternative to the optional MDIO Management Interface, the configuration vector. See “Optional Configuration Vector” in Chapter 9. Table 2-4: Optional Configuration and Status Vectors Signal Direction configuration_vector[3:0]1 Input Description Bit[0]: Reserved (currently unused) Bit[1]: Loopback Control • When the core with RocketIO transceiver is used, the core is placed in internal loopback mode.
PAGE 36
R Chapter 2: Core Architecture Dynamic Switching Signal Pinout Table 2-6 describes the signals present when the optional Dynamic Switching mode (between 1000BASE-X and SGMII standards) is selected. In this case, the MDIO (Table 2-3) and RocketIO transceiver (Table 2-7) interfaces are always present.
PAGE 37
R Core Interfaces Table 2-7: Optional RocketIO Transceiver Interface Pinout Signal Direction Description mgt_rx_reset1 Output Reset signal issued by the core to the RocketIO transceiver receiver path. Connect to RXRESET signal of RocketIO transceiver. mgt_tx_reset1 Output Reset signal issued by the core to the RocketIO transceiver transmitter path. Connect to TXRESET signal of RocketIO transceiver. userclk Input Also connected to TXUSRCLK and RXUSRCLK of the RocketIO transceiver.
PAGE 38
R Chapter 2: Core Architecture 1000BASE-X PCS with TBI Pinout Table 2-8 describes the optional TBI signals, used as an alternative to the RocketIO receiver interface. The appropriate HDL example design delivered with the core connects these signals to IOBs to provide an external TBI suitable for connection to an off-chip PMA SERDES device. When the core is used with the TBI, gtx_clk is used as the 125 MHz reference clock for the entire core. For more information, see Chapter 6, “The Ten-Bit Interface.
PAGE 39
R Chapter 3 Generating and Customizing the Core The Ethernet 1000BASE-X PCS/PMA or SGMII core is generated using the CORE Generator. This chapter describes the GUI options used to generate and customize the core. GUI Interface Figure 3-1 displays the Ethernet 1000BASE-X PCS/PMA or SGMII customization screen, used to set core parameters and options. For help starting and using CORE Generator on your system, see the documentation included with ISE™, including the CORE Generator Guide, at www.xilinx.
PAGE 40
R Chapter 3: Generating and Customizing the Core Select Standard Select from the following standards for the core: • 1000BASE-X. 1000BASE-X Physical Coding Sublayer (PCS) functionality is designed to the IEEE 802.3 specification. Depending on the choice of physical interface, the functionality may be extended to include the 1000BASE-X Physical Medium Attachment (PMA) sublayer. Default setting. • SGMII.
PAGE 41
R GUI Interface Physical Interface Depending on the target architecture, two physical interface options are available for the core. • RocketIO. Uses a RocketIO transceiver specific to the selected device family to extend the 1000BASE-X functionality to include both PCS and PMA sub-layers. For this reason, it is available only for Virtex-II Pro, Virtex-4 FX, Virtex-5 LXT, Virtex-5 SXT, and Virtex-5 FXT devices. For additional information, see “RocketIO Transceiver Logic” in Chapter 7.
PAGE 42
R Chapter 3: Generating and Customizing the Core Figure 3-3: SGMII/Dynamic Standard Switching Options Screen This screen lets you select the Receiver Elastic Buffer type to be used with the core. Before selecting this option, see “Receiver Elastic Buffer Implementations” in Chapter 8. 42 www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 43
R Parameter Values in the XCO File RocketIO Tile Configuration The RocketIO Tile Configuration screen is only displayed if the RocketIO interface is used with the Virtex-4 or Virtex-5 device families. Figure 3-4: RocketIO Tile Configuration Screen RocketIO transceivers for Virtex-4 FX and Virtex-5 device families are available in tiles, each tile consisting of a pair of transceivers.
PAGE 44
R Chapter 3: Generating and Customizing the Core Table 3-1 describes the XCO file parameters, values and summarizes the GUI defaults.
PAGE 45
R Chapter 4 Designing with the Core This chapter provides information about creating your own designs using the Ethernet 1000BASE-X PCS/PMA or SGMII core. Design guidelines, as well as the variety of implementations presented, are based on the example design delivered with the core. See the Xilinx Ethernet 1000BASE-X PCS/PMA or SGMII Getting Started Guide for information about the example design delivered with the core.
PAGE 46
R Chapter 4: Designing with the Core 1000BASE-X Standard Using RocketIO Transceiver Example Design Figure 4-1 illustrates the example design in 1000BASE-X mode using the Virtex-II Pro or Virtex-4 MGT, Virtex-5 GTP or Virtex-5 GTX transceiver. As illustrated, the example is split between two hierarchical layers.
PAGE 47
R Design Overview 1000BASE-X Standard with TBI Example Design Figure 4-2 illustrates the example design in 1000BASE-X mode using a TBI. As illustrated, the example is split between two hierarchical layers. The block level is designed so that it can be instantiated directly into customer designs and performs the following functions: • Instantiates the core from HDL • Connects the physical-side interface of the core to device IOBs, creating an external TBI. See Chapter 6, “The Ten-Bit Interface.
PAGE 48
R Chapter 4: Designing with the Core SGMII Standard Using a RocketIO Transceiver Example Design Figure 4-3 illustrates the example design in SGMII mode using the Virtex-II Pro or Virtex4 MGT, Virtex-5 GTP or Virtex-5 GTX transceiver. This is also the example design created when the Dynamic Switching capability between SGMII and 1000BASE-X standards is present. As illustrated, the example is split between two hierarchical layers.
PAGE 49
R Design Overview SGMII Standard with TBI Transceiver Example Design Figure 4-3 illustrates the example design with the SGMII standard using a TBI. This is also the example design created when the Dynamic Switching capability between SGMII and 1000BASE-X standards is present. As illustrated, the example is split between two hierarchical layers.
PAGE 50
R Chapter 4: Designing with the Core Design Guidelines Generate the Core Generate the core using the CORE Generator, as described in Chapter 3, “Generating and Customizing the Core.
PAGE 51
R Design Guidelines Write an HDL Application After reviewing the example design delivered with the core, write an HDL application that uses single or multiple instances of the block level module for the Ethernet 1000BASE-X PCS/PMA or SGMII core. Client-side interfaces and operation of the core are described in Chapter 5, “Using the Client-side GMII Data Path.
PAGE 52
R Chapter 4: Designing with the Core Table 4-1: Degree of Difficulty for Various Implementations Device Family Difficulty Spartan-3E Difficult Spartan-3A Difficult Keep it Registered To simplify timing and to increase system performance in an FPGA design, keep all inputs and outputs registered between the user application and the core. All inputs and outputs from the user application should come from, or connect to, a flip-flop.
PAGE 53
R Chapter 5 Using the Client-side GMII Data Path This chapter provides general guidelines for creating designs using client-side GMII of the Ethernet 1000BASE-X PCS/PMA or SGMII core. Designing with the Client-side GMII for the 1000BASE-X Standard It is not within the scope of this document to define the Gigabit Media Independent Interface (GMII)— see clause 35 of the IEEE 802.3 specification for information about the GMII. Timing diagrams and descriptions are provided only as an informational guide.
PAGE 54
R Chapter 5: Using the Client-side GMII Data Path Error Propagation gmii_txd[7:0] SFD A corrupted frame transfer is illustrated in Figure 5-2. An error may be injected into the frame by asserting gmii_tx_er at any point during the gmii_tx_en assertion window. The core ensures that all errors are propagated through both transmit and receive paths so that the error is eventually detected by the link partner.
PAGE 55
R Designing with the Client-side GMII for the 1000BASE-X Standard Normal Frame Reception with Extension Field In accordance with the IEEE 802.3, clause 36, state machines for the 1000BASE-X PCS, gmii_rx_er may be driven high following reception of the end frame in conjunction with gmii_rxd[7:0] containing the hexadecimal value of 0x0F to signal carrier extension. This is illustrated in Figure 5-4. See Appendix D, “1000BASE-X State Machines” for more information.
PAGE 56
R Chapter 5: Using the Client-side GMII Data Path False Carrier Figure 5-6 illustrates the GMII signaling for a False Carrier condition. False Carrier is asserted by the core in response to certain error conditions, such as a frame with a corrupted start code, or for random noise. gmii_rxd[7:0] 0x0E gmii_rx_dv gmii_rx_er False Carrier Indication Figure 5-6: False Carrier Indication status_vector[4:0] signals Bit[0]: Link Status This signal indicates the status of the link.
PAGE 57
R Designing with the Client-side GMII for the 1000BASE-X Standard Bits[4:2]: Code Group Reception Indicators These signals indicate the reception of particular types of group, as defined below. Figure 5-7 illustrates the timing of these signals, showing that they are aligned with the code groups themselves, as they appear on the output gmii_rxd[7:0] port.
PAGE 58
R Chapter 5: Using the Client-side GMII Data Path gmii_txd[7:0] preamble SFD be included in the frame supplied to the core. The RocketIO transceiver will replace these four bytes with the calculated CRC value. gmii_tx_en gmii_tx_er 4 place holder bytes Figure 5-8: GMII Frame Transmission with RocketIO Transceiver CRC Logic Enabled GMII Reception The timing of normal inbound frame transfer with RocketIO transceiver CRC functionality is illustrated in Figure 5-9.
PAGE 59
R Designing with Client-side GMII for the SGMII Standard Designing with Client-side GMII for the SGMII Standard Overview When the core is generated for the SGMII standard, changes are made to the core that affect the PCS Management Registers and the Auto-Negotiation function (see “Select Standard” in Chapter 3). However, the data path through both transmitter and receiver sections of the core remains unchanged.
PAGE 60
R Chapter 5: Using the Client-side GMII Data Path 10 Megabit per Second Frame Transmission The operation of the core remains unchanged. It is the responsibility of the client logic (for example, an Ethernet MAC), to enter data at the correct rate. When operating at a speed of 10 Mbps, every byte of the MAC frame (from destination address to the frame check sequence field, inclusive) should each be repeated for 100 clock periods to achieve the desired bit rate.
PAGE 61
R Using the GMII as an Internal Connection 10 Megabit per Second Frame Reception The operation of the core remains unchanged. When operating at a speed of 10 Mbps, every byte of the MAC frame (from destination address to the frame check sequence field, inclusive) is repeated for 100 clock periods to achieve the desired bit rate. It is the responsibility of the client logic (for example, an Ethernet MAC) to sample this data correctly.
PAGE 62
R Chapter 5: Using the Client-side GMII Data Path Virtex-II Pro and Virtex-II Devices Figure 5-14 illustrates how to create an external GMII transmitter in a Virtex-II family device. The signal names and logic shown on the figure exactly match those delivered with the example design. Figure 5-14 shows that the input transmitter signals are registered in device IOBs before presenting them to the FPGA fabric. This logic achieves the required setup and hold times.
PAGE 63
R Implementing External GMII Spartan-3, Spartan-3E and Spartan-3A Devices The logic described previously for Virtex-II and Virtex-II Pro devices does not meet the input setup and hold requirements for GMII with Spartan-3, Spartan-3E, and Spartan-3A devices. A DCM must be used on the gmii_tx_clk clock path, as illustrated in Figure 5-15. This is performed by the top-level example design delivered with the core (all signal names and logic match Figure 5-15).
PAGE 64
R Chapter 5: Using the Client-side GMII Data Path Virtex-4 Devices The logic described previously for Virtex-II and Virtex-II Pro devices does not meet the input setup and hold requirements for GMII with Virtex-4 devices. Two possible solutions are: 1. A DCM may be used on the gmii_tx_clk clock path for the Spartan-3 family, as illustrated in Figure 5-15. 2. Input Delay Elements may be used on the GMII data path, as illustrated in Figure 5-16.
PAGE 65
R Implementing External GMII Virtex-5 Devices Figure 5-17 illustrates how to create an external GMII transmitter in a Virtex-5 family device. The signal names and logic shown on the figure exactly match those delivered with the example design. The IODELAY elements can be adjusted to fine-tune the setup and hold times at the GMII IOB input flip-flops. The delay is applied to the IODELAY element using constraints in the UCF; these can be edited if desired.
PAGE 66
R Chapter 5: Using the Client-side GMII Data Path GMII Receiver Logic Figure 5-18 illustrates an external GMII receiver created in a Virtex-II family device. The signal names and logic shown in the figure exactly match those delivered with the example design when the GMII is selected. If other families are selected, equivalent primitives and logic specific to that family is automatically used in the example design.
PAGE 67
R Implementing External GMII IOB LOGIC FDDRRSE Q D '0' userclk2 (if RocketIO is used) gtx_clk (if TBI is used) gmii_rx_clk gmii_rx_clk_obuf OPAD OBUFT Q D '1' Ethernet 1000BASE-X PCS/PMA or SGMII LogiCORE gmii_isolate gmii_rxd[0] gmii_rxd_obuf[0] OPAD Q D gmii_rxd[0] Q D gmii_rx_dv Q D gmii_rx_er OBUFT gmii_rx_dv gmii_rx_dv_obuf OPAD OBUFT gmii_rx_er gmii_rx_er_obuf OPAD OBUFT Figure 5-18: Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 68
R 68 Chapter 5: Using the Client-side GMII Data Path www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 69
R Chapter 6 The Ten-Bit Interface This chapter provides general guidelines for creating 1000BASE-X, SGMII or Dynamic Standards Switching designs using the Ten-Bit Interface (TBI). An explanation of the TBI logic in all supported device families is provided, as well as examples in which multiple instantiations of the core are required. Whenever possible, clock sharing should occur to save device resources.
PAGE 70
R Chapter 6: The Ten-Bit Interface IOB LOGIC BUFG IBUFG gtx_clk IPAD gtx_clk_ibufg (125 MHz) gtx_clk_bufg component_name_block (Block Level from example design) IOB LOGIC Ethernet 1000BASE-X PCS/PMA or SGMII LogiCORE FDDRRSE '0' D Q OBUF gtx_clk pma_tx_clk_obuf pma_tx_clk OPAD '1' tx_code_group[0] tx_code_group[9] Figure 6-1: tx_code_group_int[0] tx_code_group_int[9] D Q D Q D Q tx_code_group_reg[0] OBUF tx_code_group[0] OPAD tx_code_group_reg[9] OBUF tx_code_group[9] OPAD Te
PAGE 71
R Ten-Bit-Interface Logic synchronous to pma_rx_clk0_bufg and pma_rx_clk1_bufg, respectively. These busses are then immediately registered inside the core on their respective clock. component_name_block (Block Level from example design) IOB LOGIC Ethernet 1000BASE-X PCS/PMA or SGMII LogiCORE pma_rx_clk0 pma_rx_clk0_bufg (62.5 MHz) IBUFG BUFG pma_rx_clk0 pma_rx_clk0_ibufg IPAD IOB LOGIC pma_rx_clk1 pma_rx_clk1_bufg (62.
PAGE 72
R Chapter 6: The Ten-Bit Interface Spartan-3, Spartan-3E and Spartan-3A Devices The logic described previously for Virtex-II and Virtex-II Pro devices does not meet the input setup and hold requirements for TBI with Spartan-3, Spartan-3E and Spartan-3A devices. A DCM must be used on both the pma_rx_clk0 and pma_rx_clk1 clock paths (see Figure 6-3). This is performed by the example design delivered with the core (all signal names and logic match Figure 6-3).
PAGE 73
R Ten-Bit-Interface Logic Virtex-4 Devices Method 1 The Virtex-4 FPGA logic used by the example design delivered with the core is illustrated in Figure 6-4. This shows a Virtex-4 device IDDR primitive used with the DDR_CLK_EDGE attribute set to SAME_EDGE (see the Virtex-4 FPGA User Guide). This uses local inversion of pma_rx_clk0 within the IOB logic to receive the rx_code_group[9:0] data bus on both the rising and falling edges of pma_rx_clk0.
PAGE 74
R Chapter 6: The Ten-Bit Interface Method 2 This logic from method 1 relies on pma_rx_clk0 and pma_rx_clk1 being exactly 180 degrees out of phase with each other since the falling edge of pma_rx_clk0 is used in place of pma_rx_clk1. See the data sheet for the attached SERDES to verify that this is the case. If not, then the logic of Figure 6-5 illustrates an alternative implementation where both pma_rx_clk0 and pma_rx_clk1 are used as intended.
PAGE 75
R Ten-Bit-Interface Logic Virtex-5 Devices Method 1 The Virtex-5 FPGA logic used by the example design delivered with the core is illustrated in Figure 6-6. This shows a Virtex-5 device IDDR primitive used with the DDR_CLK_EDGE attribute set to SAME_EDGE (see the Virtex-5 FPGA User Guide). This uses local inversion of pma_rx_clk0 within the IOB logic to receive the rx_code_group[9:0] data bus on both the rising and falling edges of pma_rx_clk0.
PAGE 76
R Chapter 6: The Ten-Bit Interface Method 2 This logic from method 1 relies on pma_rx_clk0 and pma_rx_clk1 being exactly 180 degrees out of phase with each other because the falling edge of pma_rx_clk0 is used in place of pma_rx_clk1. See the data sheet for the attached SERDES to verify that this is the case. If not, the logic of Figure 6-7 illustrates an alternate implementation where both pma_rx_clk0 and pma_rx_clk1 are used as intended.
PAGE 77
R Clock Sharing across Multiple Cores with TBI Clock Sharing across Multiple Cores with TBI Figure 6-8 illustrates sharing clock resources across multiple instantiations of the core when using the TBI. gtx_clk may be shared between multiple cores, resulting in a common clock domain across the device. The receiver clocks pma_rx_clk0 and pma_rx_clk1 cannot be shared. Each core will be provided with its own versions of these clocks from its externally connected SERDES.
PAGE 78
R 78 Chapter 6: The Ten-Bit Interface www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 79
R Chapter 7 1000BASE-X with RocketIO Transceivers This chapter provides general guidelines for creating 1000BASE-X designs that use RocketIO transceivers for Virtex-II Pro, Virtex-4, and Virtex-5 devices. Information about RocketIO transceiver and core logic in all supported device families is provided, as well as information about designs requiring multiple instantiations of the core. Note that clock sharing should occur whenever possible to save device resources.
PAGE 80
R Chapter 7: 1000BASE-X with RocketIO Transceivers IOB LOGIC brefclkp IBUFGDS IPAD brefclk (62.5MHz) IPAD brefclkn DCM BUFG userclk (62.
PAGE 81
R RocketIO Transceiver Logic Virtex-4 FX Devices The core is designed to integrate with the Virtex-4 RocketIO MGT. Figure 7-2 illustrates the connections and logic required between the core and MGT—the signal names and logic in the figure precisely match those delivered with the example design when an MGT is used. Note: A small logic shim (included in the block-level wrapper) is required to convert between the port differences between the Virtex-II Pro and Virtex-4 RocketIO transceivers.
PAGE 82
R Chapter 7: 1000BASE-X with RocketIO Transceivers brefclkp (250 MHz) Virtex-4 GT11CLK_MGT IPAD MGTCLKP IPAD brefclkn (250 MHz) MGTCLKN BUFG SYNCLK1OUT synclk1 userclk2 (125MHz) component_name_block (Block Level from example design) Virtex-4 GT11 RocketIO (used) REFCLK1 Ethernet 1000BASE-X PCS/PMA or SGMII LogiCORE TXOUTCLK1 '0' userclk TXUSRCLK TXUSRCLK2 '0' RXUSRCLK RXUSRCLK2 userclk2 rxchariscomma RXCHARISCOMMA rxbufstatus[1:0] RXBUFERR rxcharisk rxclkcorcnt[2:0] RXCHARISK LOGIC
PAGE 83
R RocketIO Transceiver Logic Virtex-5 LXT and SXT Devices The core is designed to integrate with the Virtex-5 RocketIO GTP transceiver. Figure 7-3 illustrates the connections and logic required between the core and the GTP transceiver— the signal names and logic in the figure precisely match those delivered with the example design when a GTP transceiver is used.
PAGE 84
R Chapter 7: 1000BASE-X with RocketIO Transceivers brefclkp IPAD IBUFGDS IPAD brefclkn BUFG clkin (125MHz) userclk2 (125MHz) rocketio_wrapper_gtp component_name_block (Block Level from example design) rocketio_wrapper_gtp_tile Virtex-5 GTP RocketIO (0) CLKIN Ethernet 1000BASE-X PCS/PMA or SGMII LogiCORE REFCLKOUT TXUSRCLK0 TXUSRCLK20 userclk RXUSRCLK0 RXUSRCLK20 userclk2 rxchariscomma RXCHARISCOMMA0 rxbufstatus[1:0] RXBUFERR0 rxcharisk rxdisperr RXCHARISK0 LOGIC SHIM rxdata[7:0] rxrund
PAGE 85
R RocketIO Transceiver Logic Virtex-5 FXT Devices The core is designed to integrate with the Virtex-5 RocketIO GTX transceiver. Figure 7-4 illustrates the connections and logic required between the core and the GTX transceiver— the signal names and logic in the figure precisely match those delivered with the example design when a GTX transceiver is used.
PAGE 86
R Chapter 7: 1000BASE-X with RocketIO Transceivers DCM BUFG userclk2 (125MHz) CLKIN CLK0 FB CLKDV userclk (62.
PAGE 87
R Clock Sharing Across Multiple Cores with RocketIO Clock Sharing Across Multiple Cores with RocketIO Virtex-II Pro Devices Figure 7-5 illustrates sharing clock resources across two instantiations of the core on the same half of the device when using the core with the Virtex-II Pro MGT. Note that more can be added by instantiating the cores using the block level (from the example design) and continuing to share userclk, userclk2, and brefclk across all instantiations.
PAGE 88
R Chapter 7: 1000BASE-X with RocketIO Transceivers Virtex-4 FX Devices Figure 7-6 illustrates sharing clock resources across multiple instantiations of the core when using MGTs. Note that the example design, when using the Virtex-4 family, can be generated to connect either a single instance of the core, or connect a pair of core instances to the transceiver pair present in an MGT tile.
PAGE 89
R Clock Sharing Across Multiple Cores with RocketIO Virtex-4 GT11CLK_MGT brefclkp (250MHz) IPAD BUFG MGTCLKP IPAD brefclkn (250MHz) MGTCLKN SYNCLK1OUT component_name_block (Block Level) synclk1 (250MHz) MGT tile Ethernet 1000BASE-X PCS/PMA or SGMII core Virtex-4 GT11 RocketIO (A) TXOUTCLK1 userclk userclk2 userclk2 (125 MHz) REFCLK1 ‘0’ TXUSRCLK TXUSRCLK2 ‘0’ Ethernet 1000BASE-X PCS/PMA or SGMII core RXUSRCLK RXUSRCLK2 Virtex-4 GT11 RocketIO (B) userclk userclk2 NC ‘0’ TXOUTCLK1 REFCL
PAGE 90
R Chapter 7: 1000BASE-X with RocketIO Transceivers Virtex-5 LXT and SXT Devices Figure 7-7 illustrates sharing clock resources across multiple instantiations of the core when using Virtex-5 RocketIO GTP transceivers. The example design can be generated to connect either a single instance of the core or connect a pair of core instances to the transceiver pair present in a GTP tile.
PAGE 91
R Clock Sharing Across Multiple Cores with RocketIO brefclkp IPAD IBUFGDS IPAD brefclkn BUFG clkin (125MHz) rocketio_wrapper_gtp component_name_block (Block Level) rocketio_wrapper_gtp_tile Ethernet 1000BASE-X PCS/PMA or SGMII core Virtex-5 GTP RocketIO (0) REFCLKOUT userclk userclk2 userclk2 (125 MHz) TXUSRCLK0 TXUSRCLK20 RXUSRCLK0 Ethernet 1000BASE-X PCS/PMA or SGMII core RXUSRCLK20 CLKIN Virtex-5 GTP RocketIO (1) userclk userclk2 TXUSRCLK1 TXUSRCLK21 RXUSRCLK1 RXUSRCLK21 rocketio_wrappe
PAGE 92
R Chapter 7: 1000BASE-X with RocketIO Transceivers Virtex-5 FXT Devices Figure 7-8 illustrates sharing clock resources across multiple instantiations of the core when using Virtex-5 RocketIO GTX transceivers. The example design can be generated to connect either a single instance of the core or connect a pair of core instances to the transceiver pair present in a GTX tile.
PAGE 93
R Clock Sharing Across Multiple Cores with RocketIO DCM BUFG CLKIN CLK0 BUFG FB CLKDV userclk (62.
PAGE 94
R 94 Chapter 7: 1000BASE-X with RocketIO Transceivers www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 95
R Chapter 8 SGMII / Dynamic Standards Switching with RocketIO Transceivers This chapter provides general guidelines for creating SGMII designs, and designs capable of switching between 1000BASE-X and SGMII standards (Dynamic Standards Switching), using a RocketIO transceiver. Throughout this chapter, any reference to SGMII also applies to the Dynamic Standards Switching implementation.
PAGE 96
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers (see the next section). However, there are logical implementations where this can be reliable and has the benefit of lower logic utilization. The Requirement for the FPGA Fabric Rx Elastic Buffer Figure 8-1 illustrates a simplified diagram of a common situation where the core, in SGMII mode, is interfaced to an external PHY device. Separate oscillator sources are used for the FPGA and the external PHY.
PAGE 97
R Receiver Elastic Buffer Implementations Considering the 10 Mbps case, we would need 152200/5000 = 31 FIFO entries in the Elastic Buffer above and below the half way point to guarantee that the buffer will not under or overflow during frame reception. This assumes that frame reception begins when the buffer is exactly half full. The size of the Rx Elastic Buffer in the RocketIOs is 64 entries. However, we cannot assume that the buffer is exactly half full at the start of frame reception.
PAGE 98
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers Closely Related Clock Sources Case 1 Figure 8-2 illustrates a simplified diagram of a common situation where the core, in SGMII mode, is interfaced to an external PHY device. A common oscillator source is used for both the FPGA and the external PHY.
PAGE 99
R RocketIO Logic with the Fabric Rx Elastic Buffer RocketIO Logic with the Fabric Rx Elastic Buffer The example design delivered with the core is split between two hierarchical layers, as illustrated in Figure 4-3.
PAGE 100
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers IOB LOGIC brefclkp IBUFGDS IPAD brefclk (62.5MHz) IPAD brefclkn DCM BUFG userclk (62.
PAGE 101
R RocketIO Logic with the Fabric Rx Elastic Buffer Virtex-4 Devices for SGMII or Dynamic Standards Switching The core is designed to integrate with the Virtex-4 MGT. The connections and logic required between the core and MGT transceiver are illustrated in Figure 8-4–the signal names and logic in the figure precisely match those delivered with the example design when an MGT transceiver is used.
PAGE 102
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers Caution! The PHY connected via SGMII may always provide dynamic SGMII data (when powered up). If not, and if signal_detect is not present, the RX_SIGNAL_DETECT port of the calibration block must be driven by an alternative method. See XAPP732 for more information.
PAGE 103
R RocketIO Logic with the Fabric Rx Elastic Buffer Virtex-5 LXT or SXT Devices for SGMII or Dynamic Standards Switching The core is designed to integrate with the Virtex-5 RocketIO GTP transceiver. The connections and logic required between the core and GTP transceiver are illustrated in Figure 8-5–the signal names and logic in the figure precisely match those delivered with the example design when a GTP transceiver is used.
PAGE 104
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers .
PAGE 105
R RocketIO Logic with the Fabric Rx Elastic Buffer Virtex-5 FXT Devices for SGMII or Dynamic Standards Switching The core is designed to integrate with the Virtex-5 RocketIO GTX transceiver. The connections and logic required between the core and GTX transceiver are illustrated in Figure 8-6–the signal names and logic in the figure precisely match those delivered with the example design when a GTX transceiver is used.
PAGE 106
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers Getting Started Guide and the CORE Generator Guide, at www.xilinx.com/support/software_manuals.htm . DCM BUFG userclk2 (125MHz) CLKIN CLK0 FB CLKDV IBUFGDS brefclkp IPAD userclk (62.
PAGE 107
R Clock Sharing - Multiple Cores with RocketIO, Fabric Elastic Buffer Clock Sharing - Multiple Cores with RocketIO, Fabric Elastic Buffer Virtex-II Pro Devices Figure 8-7 illustrates sharing clock resources across multiple instantiations of the core on the same half of the device when using the core with the RocketIO MGT.
PAGE 108
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers the device. For more information, see the Virtex-II Pro RocketIO Transceiver User Guide. Each brefclk domain must use its own DCM to derive its version of userclk and userclk2. brefclkp IPAD IBUFGDS IPAD brefclkn brefclk (62.5MHz) DCM CLKIN BUFG CLK0 userclk (62.
PAGE 109
Clock Sharing - Multiple Cores with RocketIO, Fabric Elastic Buffer R Virtex-4 FX Devices Figure 8-8 illustrates sharing clock resources across multiple instantiations of the core when using the Virtex-4 RocketIO MGT. Note that the example design, when using the Virtex-4 family, can be generated to connect either a single instance of the core, or connect a pair of core instances to the transceiver pair present in a MGT tile.
PAGE 110
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers Virtex-4 GT11CLK_MGT brefclkp (250MHz) IPAD BUFG MGTCLKP IPAD brefclkn (250MHz) MGTCLKN SYNCLK1OUT component_name_block (Block Level) synclk1 (250MHz) MGT tile Ethernet 1000BASE-X PCS/PMA or SGMII core Virtex-4 GT11 RocketIO (A) TXOUTCLK1 userclk userclk2 userclk2 (125 MHz) REFCLK1 ‘0’ TXUSRCLK TXUSRCLK2 ‘0’ FPGA fabric Rx Elastic Buffer RXRECCLK1 BUFR Ethernet 1000BASE-X PCS/PMA or SGMII core RXUSRCLK RXUSRCLK
PAGE 111
Clock Sharing - Multiple Cores with RocketIO, Fabric Elastic Buffer R Virtex-5 LXT and SXT Devices Figure 8-9 illustrates sharing clock resources across multiple instantiations of the core when using the Virtex-5 RocketIO GTP transceiver. The example design can be generated to connect either a single instance of the core, or connect a pair of core instances to the transceiver pair present in a GTP transceiver tile.
PAGE 112
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers .
PAGE 113
Clock Sharing - Multiple Cores with RocketIO, Fabric Elastic Buffer R Virtex-5 FXT Devices Figure 8-9 illustrates sharing clock resources across multiple instantiations of the core when using the Virtex-5 RocketIO GTX transceiver. The example design can be generated to connect either a single instance of the core, or connect a pair of core instances to the transceiver pair present in a GTX transceiver tile.
PAGE 114
R Chapter 8: SGMII / Dynamic Standards Switching with RocketIO Transceivers . DCM BUFG CLKIN CLK0 BUFG FB CLKDV brefclkp IPAD userclk (62.
PAGE 115
R Chapter 9 Configuration and Status This chapter provides general guidelines for configuring and monitoring the Ethernet 1000BASE-X PCS/PMA or SGMII core, including a detailed description of the core management registers. It also describes Configuration Vector and status signals, an alternative to using the optional MDIO Management Interface.
PAGE 116
R Chapter 9: Configuration and Status . MAC (STA) PHY1 (MMD) Configuration Registers 0 to 31 (REGAD) Host Bus I/F MDIO slave MDIO MDC MDIO master Physical Address (PHYAD) =1 PHY2 (MMD) Configuration Registers 0 to 31 (REGAD) MDIO slave Physical Address (PHYAD) =2 UG194_5_01_011906 Figure 9-1: A Typical MDIO-managed System The MDIO bus system is a standardized interface for accessing the configuration and status registers of Ethernet PHY devices.
PAGE 117
R MDIO Management Interface Table 9-1: Abbreviations and Terms (Continued) Abbreviation Term PHYAD Physical address REGAD Register address TA Turnaround Write Transaction Figure 9-2 shows a write transaction across the MDIO, defined as OP=”01.” The addressed PHY device (with physical address PHYAD) takes the 16-bit word in the Data field and writes it to the register at REGAD.
PAGE 118
R Chapter 9: Configuration and Status known by the MDIO master (in this case an Ethernet MAC), and placed into the PHYAD field of the MDIO frame (see “MDIO Transactions”). The PHYAD field for an MDIO frame is a 5-bit binary value capable of addressing 32 unique addresses. However, every MDIO slave must respond to physical address 0. This requirement dictates that the physical address for any particular PHY must not be set to 0 to avoid MDIO contention.
PAGE 119
R Management Registers . Ethernet 1000BASE-X PCS/PMA or SGMII LogiCORE IOB LOGIC IBUF mdc O I IPAD mdc IOPAD mdio IOB LOGIC IOBUF mdio_tri T mdio_out I IO mdio_in O Figure 9-4: Creating an External MDIO Interface Management Registers The contents of the Management Registers can be accessed using the REGAD field of the MDIO frame. Contents will vary depending on the CORE Generator options, and are defined in the following sections in this guide.
PAGE 120
R Chapter 9: Configuration and Status Table 9-2: MDIO Registers for 1000BASE-X with Auto-Negotiation (Continued) Register Address Register Name 2,3 PHY Identifier 4 Auto-Negotiation Advertisement Register 5 Auto-Negotiation Link Partner Ability Base Register 6 Auto-Negotiation Expansion Register 7 Auto-Negotiation Next Page Transmit Register 8 Auto-Negotiation Next Page Receive Register 15 Extended Status Register 16 Vendor Specific: Auto-Negotiation Interrupt Control Register 0: Contr
PAGE 121
R Management Registers Table 9-3: Bit(s) Control Register (Register 0) (Continued) Name Description Attributes Default Value Returns 0 0 Read/write 1 Read/ write 0 Read/write 1 Read/write 0 0.13 Speed Selection (LSB) Always returns a 0 for this bit. Together with bit 0.6, speed selection of 1000 Mbps is identified 0.12 AutoNegotiation Enable 1 = Enable Auto-Negotiation Process Power Down 1 = Power down 0.
PAGE 122
R Chapter 9: Configuration and Status Register 1: Status Register MDIO Register 1: Status Register 3 2 AUTO-NEG ABILITY LINK STATUS 1 0 EXTENDED CAPABILITY 4 JABBER DETECT 5 REMOTE FAULT UNIDIRECTIONAL ANILITY 6 MF PREAMBLE SUPPRESSION 7 AUTO-NEG COMPLETE 8 EXTENDED STATUS 15 14 13 12 11 10 9 Reg 1 100BASE-T2 HALF DUPLEX 100BASE-T2 FULL DUPLEX 10Mb/s HALF DUPLEX 10Mb/s FULL DUPLEX 122 100BASE-X HALF DUPLEX Bit(s) 100BASE-X FULL DUPLEX 100BASE-T4 Table 9-4: Status Register (Regi
PAGE 123
R Management Registers Table 9-4: Bit(s) 1.4 Status Register (Register 1) (Continued) Name Description Remote Fault Attributes Default Value Read only 0 1 = Remote fault condition detected 0 = No remote fault condition detected Selfclearing on read 1.3 Auto- Negotiation Ability Always returns a ‘1’ for this bit to indicate that the PHY is capable of AutoNegotiation. Returns 1 1 1.
PAGE 124
R Chapter 9: Configuration and Status Table 9-5: PHY Identifier (Registers 2 and 3) Bit(s) Name Description Attributes Default Value 2.15:0 Organizationally Unique Identifier Always return 0s returns 0s 0000000000000000 3.15:10 Organizationally Unique Identifier Always return 0s returns 0s 000000 3.9:4 Manufacturer’s model number Always return 0s returns 0s 000000 3.
PAGE 125
R Management Registers Table 9-6: Bit(s) Auto-Negotiation Advertisement Register (Register 4) (Continued) Name Description Attributes Default Value returns 0 0 read/write 1 returns 0s 00000 4.6 Half Duplex Always returns a ‘0’ for this bit since Half Duplex Mode is not supported 4.5 Full Duplex 1 = Full Duplex Mode is advertised Reserved Always return 0s , writes ignored 4.
PAGE 126
R Chapter 9: Configuration and Status Table 9-7: Bit(s) Auto-Negotiation Link Partner Ability Base Register (Register 5) Name 5.6 5.5 5.
PAGE 127
R Management Registers Table 9-9: Bit(s) 7.15 Auto-Negotiation Next Page Transmit (Register 7) Name Description Next Page Attributes Default Value 1 = Additional Next Page(s) will follow read/ 0 0 = Last page write 7.14 Reserved Always returns ‘0’ returns 0 0 7.13 Message Page 1 = Message Page read/ 1 0 = Unformatted Page write Acknowled ge 2 1 = Comply with message read/ 0 = Cannot comply with message write 7.11 Toggle Value toggles between subsequent Next Pages 7.
PAGE 128
R Chapter 9: Configuration and Status Table 9-10: Bit(s) 8.12 Auto-Negotiation Next Page Receive (Register 8) (Continued) Name Description Acknowledge 2 1 = Comply with message Attributes Default Value read only 0 0 = Cannot comply with message 8.11 Toggle Value toggles between subsequent Next Pages read only 0 8.10:0 Message / Unformatted Code Field Message Code Field or Unformatted Page Encoding as dictated by 8.
PAGE 129
R Management Registers Register 16: Vendor-Specific Auto-Negotiation Interrupt Control MDIO Register 16: Vendor Specific Auto-Negotiation Interrupt Control 1 0 INTERRUPT STATUS INTERRUPT ENABLE 2 15 Reg 16 RESERVED Table 9-12: Vendor Specific Register: Auto-Negotiation Interrupt Control Register (Register 16) Bit(s) Name Description Attributes Default Value 16.15:2 Reserved Always return 0s returns 0s 00000000000000 16.
PAGE 130
R Chapter 9: Configuration and Status Register 0: Control Register MDIO Register 0: Control Register 8 7 6 5 DUPLEX MODE COLLISION TEST SPEED UNIDIRECTIONAL ENABLE 15 14 13 12 11 10 9 4 0 Reg 0 RESERVED RESTART AUTO-NEG POWER DOWN ISOLATE 0.14 AUTO-NEG ENABLE 0.
PAGE 131
R Management Registers Table 9-14: Control Register (Register 0) (Continued) Name Description Attributes Default Value 0.9 Restart AutoNegotiation Ignore this bit because Auto-Negotiation is not included. read/ write 0 0.8 Duplex Mode Always returns a ‘1’ for this bit to signal Full-Duplex Mode. returns 1 1 0.7 Collision Test Always returns a ‘0’ for this bit to disable COL test. returns 0 0 0.6 Speed Selection(MS B) Always returns a ‘1’ for this bit. Together with bit 0.
PAGE 132
R Chapter 9: Configuration and Status Table 9-15: Bit(s) Status Register (Register 1) (Continued) Name Description Attributes Default Value 1.10 100BASE-T2 Full Duplex Always returns a ‘0’ for this bit since 100BASE-T2 Full Duplex is not supported returns 0 0 1.9 100BASE-T2 Half Duplex Always returns a ‘0’ for this bit since 100BASE-T2 Half Duplex is not supported returns 0 0 1.
PAGE 133
R Management Registers Registers 2 and 3: Phy Identifier MDIO Registers 2 and 3: PHY Identifier 15 0 Reg 2 10 9 ORGANIZE UNIQUE ID 15 4 0 3 Reg 3 REVISION NO MAUFACTURER MODEL NO ORGANIZE UNIQUE ID Table 9-16: PHY Identifier (Registers 2 and 3) Bit(s) Name Description Attributes Default Value 2.15:0 Organizationally Unique Identifier Always return 0s returns 0s 0000000000000000 3.15:10 Organizationally Unique Identifier Always return 0s returns 0s 000000 3.
PAGE 134
R Chapter 9: Configuration and Status Table 9-17: Bit(s) 134 Extended Status (Register 15) Name Description Attributes Default Value 15.15 1000BASE-X Full Duplex Always returns a ‘1’ since 1000BASEX Full Duplex is supported returns 1 1 15.14 1000BASE-X Half Duplex Always returns a ‘0’ since 1000BASEX Half Duplex is not supported returns 0 0 15.13 1000BASE-T Full Duplex Always returns a ‘0’ since 1000BASET Full Duplex is not supported returns 0 0 15.
PAGE 135
R Management Registers SGMII Standard Using the Optional Auto-Negotiation The registers provided for SGMII operation in this core are adaptations of those defined in IEEE 802.3 clauses 37 and 22. In an SGMII implementation, two different types of links exist. They are the SGMII link between the MAC and PHY (SGMII link) and the link across the Ethernet Medium itself (Medium). See Figure 10-2. Information regarding the state of both of these links is contained within the following registers.
PAGE 136
R Chapter 9: Configuration and Status Table 9-19: Bit(s) 0.15 0.14 SGMII Control (Register 0) Name Reset Loopback Attributes Default Value 1 = Core Reset read/write 0 0 = Normal Operation self clearing 1 = Enable Loopback Mode read/write 0 Description 0 = Disable Loopback Mode When used with a RocketIO transceiver, the core is placed in internal loopback mode. With the TBI version, Bit 1 is connected to ewrap. When set to ‘1’ indicates to the external PMA module to enter loopback mode.
PAGE 137
R Management Registers Table 9-19: Bit(s) SGMII Control (Register 0) (Continued) Name Description 0.5 Unidirectiona l Enable Enable transmit regardless of whether a valid link has been established 0.
PAGE 138
R Chapter 9: Configuration and Status Table 9-20: Bit(s) SGMII Status (Register 1) (Continued) Name Description Attributes Default Value 1.7 Unidirectional Ability Always returns ‘1,’ writes ignored returns 1 1 1.6 MF Preamble Suppression Always returns a ‘1’ for this bit to indicate that Management Frame Preamble Suppression is supported returns 1 1 1.
PAGE 139
R Management Registers Registers 2 and 3: PHY Identifier MDIO Registers 2 and 3: PHY Identifier 15 0 Reg 2 10 9 ORGANIZE UNIQUE ID 15 4 0 3 Reg 3 REVISION NO MAUFACTURER MODEL NO ORGANIZE UNIQUE ID Table 9-21: PHY Identifier (Registers 2 and 3) Bit(s) Name Description Attributes Default Value 2.15:0 Organizationally Unique Identifier Always return 0s returns 0s 0000000000000000 3.15:10 Organizationally Unique Identifier Always return 0s returns 0s 000000 3.
PAGE 140
R Chapter 9: Configuration and Status Register 5: SGMII Auto-Negotiation Link Partner Ability MDIO Register 5: SGMII Auto-Negotiation Link Partner Ability 15 14 13 12 11 10 9 1 0 Reg 5 RESERVED RESERVED SPEED RESERVED DUPLEX MODE ACKNOWLEDGE PHY LINK STATUS The Auto-Negotiation Ability Base Register (Register 5) contains information related to the status of the link between the PHY and its physical link partner across the Medium.
PAGE 141
R Management Registers Register 6: SGMII Auto-Negotiation Expansion MDIO Register 6: SGMII Auto-Negotiation Expansion 1 0 PAGE RECEIVED 2 RESERVED 3 15 Reg 6 SGMII Auto-Negotiation Expansion (Register 6) Bit(s) Name 6.15:3 Reserved 6.2 6.1 6.
PAGE 142
R Chapter 9: Configuration and Status Table 9-25: Bit(s) 7.12 SGMII Auto-Negotiation Next Page Transmit (Register 7) Name Description Attributes Default Value 0 Acknowled ge 2 1 = Comply with message read/ 0 = Cannot comply with message write 7.11 Toggle Value toggles between subsequent Next Pages 7.10:0 Message / Unformatte d Code Field Message Code Field or Unformatted Page Encoding as dictated by 7.
PAGE 143
R Management Registers Register 15: SGMII Extended Status MDIO Register 15: SGMII Extended Status 15 14 13 12 11 0 Reg 15 RESERVED 1000BASE-T HALF DUPLEX 1000BASE-X HALF DUPLEX Bit(s) 1000BASE-T FULL DUPLEX 1000BASE-X FULL DUPLEX Table 9-27: SGMII Extended Status Register (Register 15) Name Description Attributes Default Value 15.15 1000BASE-X Full Duplex Always returns a ‘1’ for this bit since 1000BASE-X Full Duplex is supported returns 1 1 15.
PAGE 144
R Chapter 9: Configuration and Status Register 16: SGMII Auto-Negotiation Interrupt Control MDIO Register 16: SGMII Auto-Negotiation Interrupt Control 1 0 INTERRUPT STATUS INTERRUPT ENABLE 2 15 Reg 16 RESERVED Table 9-28: SGMII Auto-Negotiation Interrupt Control (Register 16) Bit(s) Name Description Attributes Default Value 16.15:2 Reserved Always return 0s returns 0s 00000000000000 16.
PAGE 145
R Management Registers SGMII Standard without the Optional Auto-Negotiation The Registers provided for SGMII operation in this core are adaptations of those defined in IEEE 802.3 clauses 37 and 22. In an SGMII implementation, two different types of links exist. They are the SGMII link between the MAC and PHY (SGMII link) and the link across the Ethernet Medium itself (Medium). See Figure 10-2. Information about the state of the SGMII link is available in registers that follow.
PAGE 146
R Chapter 9: Configuration and Status Table 9-30: Bit(s) 0.15 0.14 SGMII Control (Register 0) Name Reset Loopback Attributes Default Value 1 = Core Reset read/write 0 0 = Normal Operation self clearing 1 = Enable Loopback Mode read/write 0 Description 0 = Disable Loopback Mode When used with a RocketIO transceiver, the core is placed in internal loopback mode. With the TBI version, Bit 1 is connected to ewrap. When set to ‘1’ indicates to the external PMA module to enter loopback mode.
PAGE 147
R Management Registers Table 9-30: Bit(s) SGMII Control (Register 0) (Continued) Name Description 0.5 Unidirectiona l Enable Enable transmit regardless of whether a valid link has been established 0.
PAGE 148
R Chapter 9: Configuration and Status Table 9-31: Bit(s) SGMII Status (Register 1) (Continued) Name Description Attributes Default Value 1.7 Unidirectional Ability Always returns ‘1,’ writes ignored returns 1 1 1.6 MF Preamble Suppression Always returns a ‘1’ for this bit to indicate that Management Frame Preamble Suppression is supported returns 1 1 1.5 Auto- Negotiation Complete Ignore this bit because Auto-Negotiation is not included. returns 1 0 1.
PAGE 149
R Management Registers Registers 2 and 3: PHY Identifier MDIO Registers 2 and 3: PHY Identifier 15 0 Reg 2 10 9 ORGANIZE UNIQUE ID 15 4 0 3 Reg 3 REVISION NO MAUFACTURER MODEL NO ORGANIZE UNIQUE ID Table 9-32: PHY Identifier (Registers 2 and 3) Bit(s) Name Description Attributes Default Value 2.15:0 Organizationally Unique Identifier Always return 0s returns 0s 0000000000000000 3.15:10 Organizationally Unique Identifier Always return 0s returns 0s 000000 3.
PAGE 150
R Chapter 9: Configuration and Status Register 15: SGMII Extended Status MDIO Register 15: SGMII Extended Status 15 14 13 12 11 0 Reg 15 RESERVED 1000BASE-T HALF DUPLEX 1000BASE-X HALF DUPLEX Bit(s) 1000BASE-T FULL DUPLEX 1000BASE-X FULL DUPLEX Table 9-34: SGMII Extended Status Register (Register 15) Name Description Attributes Default Value 15.15 1000BASE-X Full Duplex Always returns a ‘1’ for this bit since 1000BASE-X Full Duplex is supported returns 1 1 15.
PAGE 151
R Optional Configuration Vector Register 17: Vendor-specific Standard Selection Register 1 15 0 Reg 17 BASEX OR SGMII RESERVED Figure 9-5: Dynamic Switching (Register 17) Table 9-35: Vendor-specific Register: Standard Selection Register (Register 17) Bit(s) Name 17.15:1 Reserved 16.0 Standard Description Attributes Default Value Always return 0s Returns 0s 000000000000000 0 = Core will perform the 1000BASE-X standard.
PAGE 152
R Chapter 9: Configuration and Status These signals may be changed by the user application at any time. The Clock Domain heading denotes the clock domain the configuration signal is registered in before use by the core. It is not necessary to drive the signal from this clock domain.
PAGE 153
R Chapter 10 Auto-Negotiation This chapter provides general guidelines for using the Auto-Negotiation function of the Ethernet 1000BASE-X PCS/PMA or SGMII core. Auto-Negotiation is controlled and monitored through the PCS Management Registers and is only available when the optional MDIO Management Interface is present. For more information, see Chapter 9, “Configuration and Status.
PAGE 154
R Chapter 10: Auto-Negotiation a link segment (the link partner) and to detect corresponding operational modes that the link partner advertises. Figure 10-1 illustrates the operation of 1000BASE-X AutoNegotiation. The following describes typical operation when Auto-Negotiation is enabled. 1. 2. Auto-Negotiation starts automatically when any of the following conditions are met.
PAGE 155
R Overview of Operation SGMII Standard Figure 10-2 illustrates the operation of SGMII Auto-Negotiation. Additional information about SGMII Standard Auto-Negotiation is provided in the following sections.
PAGE 156
R Chapter 10: Auto-Negotiation Setting the Configurable Link Timer The optional Auto-Negotiation function has a Link Timer (link_timer[8:0]) port. This port sets the period of the Auto-Negotiation Link Timer. This port should be permanently tied to a logical binary value, and a binary value should be placed on this port. The duration of the timer is approximately equal to the binary value multiplied by 32.768 microseconds (4,96 clock periods of the 125 MHz clock provided to the core).
PAGE 157
R Chapter 11 Dynamic Switching of 1000BASE-X and SGMII Standards This chapter provides general guidelines for using the core to perform dynamic standards switching between 1000BASE-X and SGMII. The core will only provide this capability if generated with the appropriate option, as described in Chapter 3, “Generating and Customizing the Core.
PAGE 158
R Chapter 11: Dynamic Switching of 1000BASE-X and SGMII Standards Operation of the Core Selecting the Power-On / Reset Standard The external port of the core, basex_or_sgmii (see “Dynamic Switching Signal Pinout” in Chapter 2), will select the default standard of the core as follows: • Tie to logic ‘0’ in the core instantiation. The core powers-up and comes out of a reset cycle operating in the 1000BASE-X standard. • Tie to logic ‘1’ in the core instantiation.
PAGE 159
R Operation of the Core replace the link_timer_value[8:0] port that is used when the core is generated for a single standard. • link_timer_basex[8:0] The value placed on this port is sampled at the beginning of the Auto-Negotiation cycle by the Link Timer when the core is set to perform the 1000BASE-X standard. • link_timer_sgmii[8:0] The value placed on this port is sampled at the beginning of the Auto-Negotiation cycle by the Link Timer when the core is set to perform the SGMII standard.
PAGE 160
R 160 Chapter 11: Dynamic Switching of 1000BASE-X and SGMII Standards www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 161
R Chapter 12 Constraining the Core This chapter defines the constraint requirements of the Ethernet 1000BASE-X PCS/PMA or SGMII core. An example UCF is provided with the HDL example design for the core to implement the constraints defined in this chapter. See the Ethernet 1000BASE-X PCS/PMA or SGMII Getting Started Guide for a complete description of the CORE Generator output files and for details on the HDL example design.
PAGE 162
R Chapter 12: Constraining the Core the HDL source code for the example design and with the information contained in Chapter 7, “1000BASE-X with RocketIO Transceivers.” Clock Period Constraints The clock provided to userclk must be constrained for a clock frequency of 62.5 MHz. The clock provided to userclk2 must be constrained for a clock frequency of 125 MHz. The following UCF syntax shows the necessary constraints being applied to the example design.
PAGE 163
R Required Constraints ############################################################ # Rocket I/O placement: # ############################################################ # Place the Rocket I/O INST "rocketio/mgt" LOC = "GT_X0Y1"; # Locate the SERDES alignment logic near the Rocket I/O. # Please Refer to the Rocket I/O User Guide (Chapter 2, # SERDES Alignment, Ports and Attributes, ENPCOMMAALIGN, # ENMCOMMAALIGN).
PAGE 164
R Chapter 12: Constraining the Core Legend: Green - Vertical Long Line Orange - VFULLHEX Red - HFULLHEX Yellow - BRAM/ Multiplier/Slices/ MGT Figure 12-1: Local Clock Place and Route for Top MGT Virtex-4 RocketIO MGTs for 1000BASE-X Constraints The constraints defined in this section are implemented in the UCF for the example designs delivered with the core.
PAGE 165
R Required Constraints The following UCF syntax shows these constraints being applied.
PAGE 166
R Chapter 12: Constraining the Core Virtex-4 RocketIO MGTs for SGMII or Dynamic Standards Switching Constraints All the constraints described in the section “Virtex-4 RocketIO MGTs for 1000BASE-X Constraints.” In addition, if the FPGA Fabric Rx Elastic Buffer is selected, an extra clock period constraint of 16 ns is required for rxrecclk1. With the MGT Rx Elastic Buffer bypassed, rxrecclk1 is provided by the MGT to the FPGA fabric for the recovered receiver data signals leaving the transceiver.
PAGE 167
R Required Constraints Virtex-5 RocketIO GTP Transceivers for SGMII or Dynamic Standards Switching Constraints If the core is generated to use the GTP Rx Elastic Buffer, all of the constraints apply, as defined in “Clock Period Constraints,” page 166.
PAGE 168
R Chapter 12: Constraining the Core NET "*clkin" TNM_NET = "clkin"; TIMESPEC "TS_clkin" = PERIOD "clkin" 8 ns HIGH 50 %; NET "*refclkout" TNM_NET = "refclkout"; TIMESPEC "TS_refclkout" = PERIOD "refclkout" 8 ns HIGH 50 %; Setting GTX Transceiver Attributes The Virtex-5 GTX transceiver has many attributes that are set directly from HDL source code for the transceiver wrapper file delivered with the example design. These can be found in the rocketio_wrapper_gtx_tile.
PAGE 169
R Required Constraints Clock Period Constraints The clocks provided to pma_rx_clk0 and pma_rx_clk1 must be constrained for a clock frequency of 62.5 MHz. The clock provided to gtx_clk must be constrained for a clock frequency of 125 MHz. The following UCF syntax shows the constraints being applied to the example design.
PAGE 170
R Chapter 12: Constraining the Core In addition, the example design provides pad locking on the TBI for several families. This is included as a guideline only, and there are no specific I/O location constraints for this core. TBI Input Setup/Hold Timing Input TBI Timing Specification PMA_RX_CLK0 PMA_RX_CLK1 rx_code_group[9:0] tSETUP tHOLD Figure 12-2: tSETUP tHOLD Input TBI timing Figure 12-2 and Table 12-1 illustrate the setup and hold time window for the input TBI signals.
PAGE 171
R Required Constraints INST "core_wrapper/tbi_rx_clk1_dcm" CLKOUT_PHASE_SHIFT = FIXED; INST "core_wrapper/tbi_rx_clk1_dcm" PHASE_SHIFT = -10; INST "core_wrapper/tbi_rx_clk1_dcm" DESKEW_ADJUST = 0; The values of PHASE_SHIFT are preconfigured in the example designs to meet the setup and hold constraints for the example TBI pinout in the particular device. The setup/hold timing which is achieved after place-and-route is reported in the datasheet section of the TRCE report (created by the implement script).
PAGE 172
R Chapter 12: Constraining the Core Virtex-5 Devices Figure 6-6, page 75 illustrates the TBI input logic provided by the example design for the Virtex-5 family. IODELAY elements are instantiated on the TBI data input path as illustrated: the number of tap delays is currently set to zero. This can be modified in the UCF file, if desired, to de-skew the bus for PCB routing.
PAGE 173
R Required Constraints ############################################################ # GMII Clock period Constraints: please do not relax # ############################################################ NET "gmii_tx_clk_bufg" TNM_NET = "gmii_tx_clk"; TIMESPEC "ts_gmii_tx_clk" = PERIOD "gmii_tx_clk" 8000 ps HIGH 50 %; GMII IOB Constraints The following constraints target the flip-flops that are inferred in the top level HDL file for the example design.
PAGE 174
R Chapter 12: Constraining the Core GMII Input Setup/Hold Timing Input GMII timing specification GMII_TX_CLK GMII_TXD[7:0], GMII_TX_EN, GMII_TX_ER tSETUP tHOLD Figure 12-3: Input GMII timing Figure 12-3 and Table 12-2 illustrate the setup and hold time window for the input GMII signals. These are the worst-case data valid window presented to the FPGA device pins. Observe that there is, in total, a 2 ns data valid window of guaranteed data which is presented across the GMII input bus.
PAGE 175
R Required Constraints timing which is achieved after place-and-route is reported in the datasheet section of the TRCE report (created by the implement script). For customers fixing their own pinout, the setup and hold figures reported in the TRCE report can be used to initially setup the approximate DCM phase shift. Appendix C, “Calculating the DCM Fixed Phase Shift Value” describes a more accurate method for fixing the phase shift by using hardware measurement of a unique PCB design.
PAGE 176
R Chapter 12: Constraining the Core INST INST INST INST INST INST INST "gmii_data_bus[6].delay_gmii_txd" "gmii_data_bus[5].delay_gmii_txd" "gmii_data_bus[4].delay_gmii_txd" "gmii_data_bus[3].delay_gmii_txd" "gmii_data_bus[2].delay_gmii_txd" "gmii_data_bus[1].delay_gmii_txd" "gmii_data_bus[0].
PAGE 177
R Required Constraints Data Sheet report: ----------------All values displayed in nanoseconds (ns) Setup/Hold to clock gmii_tx_clk ------------+------------+------------+------------------+--------+ | Setup to | Hold to | | Clock | Source | clk (edge) | clk (edge) |Internal Clock(s) | Phase | ------------+------------+------------+------------------+--------+ gmii_tx_en | -6.501(R)| 7.875(R)|gmii_tx_clk_bufg | 0.000| gmii_tx_er | -6.504(R)| 7.878(R)|gmii_tx_clk_bufg | 0.000| gmii_txd<0> | -6.506(R)| 7.
PAGE 178
R 178 Chapter 12: Constraining the Core www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 179
R Chapter 13 Interfacing to Other Cores This chapter describes some additional design considerations associated with implementing the Ethernet 1000BASE-X PCS/PMA or SGMII core with other cores. • 1-Gigabit Ethernet MAC • Tri-Mode Ethernet MAC Integrating with the 1-Gigabit Ethernet MAC Core The 1000BASE-X PCS/PMA or SGMII core can be integrated in a single device with the 1-Gigabit Ethernet MAC core to extend the system functionality to include the MAC sublayer.
PAGE 180
R Chapter 13: Interfacing to Other Cores IOB LOGIC gtx_clk IBUFG BUFG gtx_clk_bufg (125 MHz) IPAD component_name_block (Block Level from example design) Ethernet 1000BASE-X PCS/PMA or SGMII LogiCORE 1-Gigabit Ethernet MAC LogiCORE gtx_clk gtx_clk gmii_rx_clk gmii_txd[7:0] gmii_txd[7:0] gmii_tx_en gmii_tx_en gmii_tx_er gmii_tx_er gmii_rxd[7:0] gmii_rxd[7:0] gmii_rx_dv gmii_rx_dv gmii_rx_er gmii_rx_er mdc mdc mdio_in mdio_in mdio_out mdio_out mdio_tri Figure 13-1: 180 TBI no conn
PAGE 181
R Integrating with the 1-Gigabit Ethernet MAC Core Integration of the 1-Gigabit Ethernet MAC Using a RocketIO Transceiver Virtex-II Pro Devices Figure 13-2 illustrates the connections and clock management logic required to interface the Ethernet 1000BASE-X PCS/PMA or SGMII core (when used in 1000BASE-X mode) to the 1-Gigabit Ethernet MAC core. IOB LOGIC brefclkp IBUFGDS IPAD brefclk (62.5MHz) IPAD brefclkn DCM CLKIN BUFG userclk (62.
PAGE 182
R Chapter 13: Interfacing to Other Cores • If both cores have been generated with the optional management interface, the MDIO port can be connected up to that of the 1-Gigabit Ethernet MAC core, allowing the MAC to access the embedded configuration and status registers of the Ethernet 1000BASE-X PCS/PMA or SGMII core. • Due to the embedded Receiver Elastic Buffer in the MGT, the entire GMII is synchronous to a single-clock domain.
PAGE 183
R Integrating with the 1-Gigabit Ethernet MAC Core Features of this configuration include: • Direct internal connections are made between the GMII interfaces between the two cores. • If both cores have been generated with the optional management interface, the MDIO port can be connected up to that of the 1-Gigabit Ethernet MAC core, allowing the MAC to access the embedded configuration and status registers of the Ethernet 1000BASE-X PCS/PMA or SGMII core.
PAGE 184
R Chapter 13: Interfacing to Other Cores Features of this configuration include: • Direct internal connections are made between the GMII interfaces between the two cores. • If both cores have been generated with the optional management interface, the MDIO port can be connected up to that of the 1-Gigabit Ethernet MAC core, allowing the MAC to access the embedded configuration and status registers of the Ethernet 1000BASE-X PCS/PMA or SGMII core.
PAGE 185
R Integrating with the Tri-Mode Ethernet MAC Core Features of this configuration include: • Direct internal connections are made between the GMII interfaces between the two cores. • If both cores have been generated with the optional management interface, the MDIO port can be connected up to that of the 1-Gigabit Ethernet MAC core, allowing the MAC to access the embedded configuration and status registers of the Ethernet 1000BASE-X PCS/PMA or SGMII core.
PAGE 186
R Chapter 13: Interfacing to Other Cores • If both cores have been generated with the optional management interface, the MDIO port can be connected to that of the Tri-Speed Ethernet MAC core, allowing the MAC to access the embedded configuration and status registers of the Ethernet 1000BASE-X PCS/PMA or SGMII core. • Due to the Receiver Elastic Buffer in the core, the entire GMII (transmitter and receiver paths) is synchronous to a single clock domain.
PAGE 187
R Integrating with the Tri-Mode Ethernet MAC Core IOB LOGIC gtx_clk BUFG IBUFG IPAD component_name_block (Block Level from example design) Ethernet 1000BASE-X PCS/PMA or SGMII LogiCORE Tri-Speed Ethernet MAC LogiCORE txgmiimiiclk rxgmiimiiclk SGMII Adaptation module clientemacrxenable clientemactxenable NC sgmii_clk_en gtx_clk sgmii_clk_r userclk2 speed_is_10_100 speedis10100 clk125m speed_is_100 speedis100 gmii_txd_in[7:0] emacphytxd7:0] gmii_txd_out[7:0] gmii_txd[7:0] emacphytxen gm
PAGE 188
R Chapter 13: Interfacing to Other Cores Integration of the Tri-Mode Ethernet MAC to Provide SGMII (or Dynamic Switching) Functionality using RocketIO Transceivers Virtex-II Pro Devices Figure 13-7 illustrates the connections and clock management logic required to interface the Ethernet 1000BASE-X PCS/PMA or SGMII core (when used in SGMII mode with the Virtex-II Pro MGT) to the Tri-Mode Ethernet MAC core. The following is a description of the functionality.
PAGE 189
R Integrating with the Tri-Mode Ethernet MAC Core IOB LOGIC brefclkp IBUFGDS IPAD brefclk (62.5MHz) IPAD brefclkn DCM CLKIN BUFG userclk (62.
PAGE 190
R Chapter 13: Interfacing to Other Cores Virtex-4 Devices Figure 13-8 illustrates the connections and clock management logic required to interface the Ethernet 1000BASE-X PCS/PMA or SGMII core (when used in SGMII mode with the Virtex-4 MGT) to the Tri-Mode Ethernet MAC core. The following conditions apply. • The SGMII Adaptation module, as provided in the example design for the Ethernet 1000BASE-X PCS/PMA or SGMII core, when generated to the SGMII standard can be used to interface the two cores.
PAGE 191
R Integrating with the Tri-Mode Ethernet MAC Core brefclkp (250MHz) IPAD Virtex-4 GT11CLK_MGT MGTCLKP IPAD brefclkn (250MHz) MGTCLKN synclk1 (250MHz) SYNCLK1OUT BUFG userclk2 (125 MHz) Tri-Speed Ethernet MAC LogiCORE component_name_block (Block Level from example design) txgmiimiiclk rxgmiimiiclk SGMII Adaptation module clientemacrxenable clientemactxenable NC sgmii_clk_en userclk2 sgmii_clk_r userclk TXOUTCLK1 REFCLK1 ‘0’ speed_is_10_100 speedis10100 Virtex-4 GT11 RocketIO (used) Ethern
PAGE 192
R Chapter 13: Interfacing to Other Cores Virtex-5 LXT and SXT Devices Figure 13-9 illustrates the connections and clock management logic required to interface the Ethernet 1000BASE-X PCS/PMA or SGMII core (when used in SGMII mode with the Virtex-5 GTP) to the Tri-Mode Ethernet MAC core. The following conditions apply.
PAGE 193
R Integrating with the Tri-Mode Ethernet MAC Core brefclkp IPAD BUFG IBUFGDS IPAD brefclkn clkin (125MHz) userclk2 (125 MHz) Tri-Speed Ethernet MAC LogiCORE component_name_block (Block Level from example design) txgmiimiiclk rxgmiimiiclk SGMII Adaptation module clientemacrxenable clientemactxenable NC Virtex-5 GTP RocketIO Ethernet 1000BASE-X PCS/PMA or SGMII LogiCORE sgmii_clk_en userclk2 sgmii_clk_r userclk REFCLKOUT CLKIN TXUSRCLK0 speed_is_10_100 speedis10100 clk125m speed_is_100
PAGE 194
R Chapter 13: Interfacing to Other Cores Virtex-5 FXT Devices Figure 13-10 illustrates the connections and clock management logic required to interface the Ethernet 1000BASE-X PCS/PMA or SGMII core (when used in SGMII mode with the Virtex-5 GTX) to the Tri-Mode Ethernet MAC core. The following conditions apply. • The SGMII Adaptation module, as provided in the example design for the Ethernet 1000BASE-X PCS/PMA or SGMII core when generated to the SGMII standard, can be used to interface the two cores.
PAGE 195
R Integrating with the Tri-Mode Ethernet MAC Core DCM CLKIN BUFG userclk2 (125MHz) CLK0 BUFG FB brefclkp IPAD userclk (62.
PAGE 196
R 196 Chapter 13: Interfacing to Other Cores www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 197
R Chapter 14 Special Design Considerations This chapter describes the unique design considerations associated with implementing the Ethernet 1000BASE-X PCS/PMA or SGMII core. Power Management No power management considerations are recommended for the Ethernet 1000BASE-X PCS/PMA or SGMII core when using it with the TBI.
PAGE 198
R Chapter 14: Special Design Considerations page 38). This instructs the attached PMA SERDES device to enter loopback mode as illustrated in Figure 14-1. FPGA Ethernet 1000BASE-X PCS/PMA or SGMII Core 1000BASE-X PMA SERDES Tx TBI Rx Loopback occurs in external SERDES Figure 14-1: Loopback Implementation Using the TBI Core with RocketIO Transceiver The loopback path is implemented in the core as illustrated in Figure 14-2.
PAGE 199
R Loopback FPGA Ethernet 1000BASE-X PCS/PMA or SGMII Core Idle Stream RocketIO Transceiver Tx PCS Tx Engine PCS Rx Engine Rx loopback control Loopback occurs in core Figure 14-2: Loopback Implementation When Using the Core with RocketIO Transceivers Ethernet 1000BASE-X PCS/PMA or SGMII v9.1 UG155 March 24, 2008 www.xilinx.
PAGE 200
R 200 Chapter 14: Special Design Considerations www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 201
R Chapter 15 Implementing the Design This chapter describes how to simulate and implement your design containing the Ethernet 1000BASE-X PCS/PMA or SGMII core. Pre-implementation Simulation A functional model of the Ethernet 1000BASE-X PCS/PMA or SGMII core netlist is generated by the CORE Generator to allow simulation of the core in the design-phase of the project.
PAGE 202
R Chapter 15: Implementing the Design See the XST User Guide for more information on creating project and synthesis script files, and running the xst program. XST - Verilog There is a module declaration for the Ethernet 1000BASE-X PCS/PMA or SGMII core in the CORE Generator project directory: /implement/_mod.v Use this module to help instance the Ethernet 1000BASE-X PCS/PMA or SGMII core into your Verilog source.
PAGE 203
R Post-Implementation Simulation layout and timing requirements specified within the PCF file. The par command outputs the placed and routed physical design to an NCD file. An example of the par command is: $ par top_level_module_name_map.ncd top_level_module_name.ncd \ top_level_module_name.pcf Static Timing Analysis The trce command must be executed to evaluate timing closure on a design and create a Timing Report file (TWR) that is derived from static timing analysis of the Physical Design file (NCD).
PAGE 204
R Chapter 15: Implementing the Design In addition, use the following guidlines to determine the simulator type required: Virtex-5 Devices Virtex-5 device designs incorporating a RocketIO transceiver require either a Verilog LRMIEEE 1364-2005 encryption-compliant simulator or a SWIFT-compliant simulator. • For a Verilog LRM-IEEE 1364-2005 encryption-compliant simulator, ModelSim v6.3c is currently supported. • For a SWIFT-compliant simulator, Cadence IUS v6.1 and Synopsys Synopsys VCS 2006.
PAGE 205
R Appendix A Core Verification, Compliance, and Interoperability Verification The Ethernet 1000BASE-X PCS/PMA or SGMII core has been verified with extensive simulation and hardware verification. Simulation A highly parameterizable transaction based test bench was used to test the core.
PAGE 206
R 206 Appendix A: Core Verification, Compliance, and Interoperability www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 207
R Appendix B Core Latency Core Latency The standalone core does not meet all the latency requirements specified in IEEE 802.3 due to the latency of the Elastic Buffers in both TBI and RocketIO transceiver versions. However, the core may be used for backplane and other applications where strict adherence to the IEEE latency specification is not required. Where strict adherence to the IEEE 802.
PAGE 208
R Appendix B: Core Latency Latency for 1000BASE-X PCS and PMA Using a RocketIO Transceiver These measurements are for the core only–they do not include the latency through the Virtex-II Pro or Virtex-4 MGT, Virtex-5 GTP transceiver, or the Transmitter Elastic Buffer added in the example design.
PAGE 209
R Appendix C Calculating the DCM Fixed Phase Shift Value Requirement for DCM Phase Shifting A DCM is used in the clock path to meet the input setup and hold requirements when using the core with a TBI (see Chapter 6, “The Ten-Bit Interface”) and with an external GMII implementation in Spartan-3, Spartan-3E, Spartan-3A, Spartan-3AN and Spartan-3A DSP devices (see “Spartan-3, Spartan-3E and Spartan-3A Devices,” page 63). In these cases, a fixed phase shift offset is applied to the DCM to skew the clock.
PAGE 210
R Appendix C: Calculating the DCM Fixed Phase Shift Value phase shift values must be tested; increments of 4 (52, 56, 60, etc.) correspond to roughly one DCM tap, and consequently provide an appropriate step size. It is not necessary to characterize areas outside the working phase shift range. At the edge of the operating phase shift range, system behavior changes dramatically. In eight phase shift settings or fewer, the system can transition from no errors to exhibiting errors.
PAGE 211
R Appendix D 1000BASE-X State Machines This appendix is intended to serve as a reference for the basic operation of the 1000BASE-X IEEE 802.3 clause 36 transmitter and receiver state machines. Introduction Table D-1 illustrates the Ordered Sets defined in IEEE 802.3 clause 36. These code group characters are inserted by the PCS Transmit Engine into the transmitted data stream, encapsulating the Ethernet frames indicated via the GMII transmit signals.
PAGE 212
R Appendix D: 1000BASE-X State Machines Start of Frame Encoding The Even Transmission Case Figure D-1 illustrates the translation of GMII encoding into the code-group stream performed by the PCS Transmit Engine. This stream is transmitted out of the core, either serially using the RocketIO transceiver or in parallel across the TBI. gmii_txd[7:0] preamble SFD It is important to note that the encoding of Idle periods /I2/ is constructed from a couple of code groups—the /K28.
PAGE 213
R Start of Frame Encoding Reception of the Even Case Figure D-2 illustrates the reception of the in-bound code-group stream, received either serially using the RocketIO transceiver, or in parallel across the TBI, and translation of this code-group stream into the receiver GMII. This is performed by the PCS Receive Engine. rx_code_group I2 I2 I2 S preamble SFD The Start of Packet code group /S/ is replaced with a preamble byte. This results in the restoration of the full preamble field.
PAGE 214
R gmii_txd[7:0] preamble SFD Appendix D: 1000BASE-X State Machines gmii_tx_en gmii_tx_er tx_code_group I2 Figure D-3: I2 I2 S preamble SFD PCS Transmit Engine Encoding 1000BASE-X Transmit State Machine Operation (Odd Case) Reception of the Odd Case Figure D-4 illustrates the reception of the in-bound code-group stream, received either serially using the RocketIO transceiver, or in parallel across the TBI, and translation of this code-group stream into the receiver GMII.
PAGE 215
R End of Frame Encoding Preamble Shrinkage As previously described, a single byte of preamble can be lost across the 1000BASE-X system (the actual loss occurs in the 1000BASE-X PCS transmitter state machine). • There is no specific statement for this preamble loss in the IEEE 802.3-2002 specification; the preamble loss falls out as a consequence of the state machines (see figures 36-5 and 36-6 in the IEEE 802.3-2002 specification). • IEEE 802.3ah-2004 does, however, specifically state in clause 65.1.3.
PAGE 216
R Appendix D: 1000BASE-X State Machines Reception of the Even Case Figure D-6 illustrates the reception of the in-bound code-group stream, received either serially using the RocketIO transceiver, or in parallel across the TBI, and translation of this code-group stream into the receiver GMII. This is performed by the PCS Receive Engine.
PAGE 217
R End of Frame Encoding Note: The first Idle to follow the frame termination sequence will be a /I1/ if the frame ended with positive running disparity or a /I2/ if the frame ended with negative running disparity. This is illustrated as the shaded code group.
PAGE 218
R 218 Appendix D: 1000BASE-X State Machines www.xilinx.com Ethernet 1000BASE-X PCS/PMA or SGMII v9.
PAGE 219
R Appendix E Rx Elastic Buffer Specifications This appendix is intended to serve as a reference for the Rx Elastic Buffer sizes used in the core, and the related maximum frame sizes that can be used without causing a buffer underflow or overflow error. Throughout this appendix, all analyses are based on 100 ppm clock tolerances on both sides of the elastic buffer (200 ppm total difference). This corresponds to the Ethernet clock tolerance specification.
PAGE 220
R Appendix E: Rx Elastic Buffer Specifications Virtex-II Pro/Virtex-5 RocketIO Transceiver Rx Elastic Buffer Virtex-4 FX RocketIO Transceiver Rx Elastic Buffer 57 - Overflow Mark 52 - Overflow Mark CLK_COR_MAX_LAT + 2 34 30 64 64 CLK_COR_MIN_LAT - 2 16 - Underflow Mark 12 - Underflow Mark Figure E-1: Elastic Buffer Sizes for all RocketIO Transceiver Families Virtex-II Pro and Virtex-5 Devices Consider the Virtex-II Pro and Virtex-5 FPGA example, where the shaded area represents the usable buffer
PAGE 221
Rx Elastic Buffers: Depths and Maximum Frame Sizes R Virtex-4 FX Consider the Virtex-4 FX case also illustrated in Figure E-1. The thresholds are different to that of the Virtex-II Pro/Virtex-5 case, but the overall size of the buffer is the same. Instead of the half full point, there are configurable clock correction thresholds. During the interframe gap, clock correction will attempt to restore the occupancy to within these two thresholds.
PAGE 222
R Appendix E: Rx Elastic Buffer Specifications SGMII Fabric Rx Elastic Buffer Figure E-2 illustrates the alternative FPGA fabric Rx Elastic Buffer depth and thresholds in Virtex-II Pro, Virtex-4 FX and Virtex-5 LXT device families. Each FIFO word corresponds to a single character of data (equivalent to a single byte of data following 8B10B decoding). This buffer can optionally be used to replace the Rx Elastic Buffers of the RocketIO (see “Receiver Elastic Buffer Implementations” in Chapter 8).
PAGE 223
R Rx Elastic Buffers: Depths and Maximum Frame Sizes Table E-2: Maximum Frame Sizes: Fabric Rx Elastic Buffers (100ppm Clock Tolerance) Standard / Speed Maximum Frame Size 1000BASE-X (1 Gbps only) 280000 SGMII (1 Gbps) 280000 SGMII (100 Mbps) 28000 SGMII (10 Mbps) 2800 TBI Rx Elastic Buffer For SGMII / Dynamic Switching The Rx Elastic Buffer used for the SGMII or Dynamic Standards Switching is identical to the method use in “SGMII Fabric Rx Elastic Buffer.
PAGE 224
R Appendix E: Rx Elastic Buffer Specifications Note that this analysis assumes that the buffer is approximately at the half-full level at the start of the frame reception. As illustrated, there are two locations of uncertainty above and below the exact half-full mark of 16. This is as a result of the clock correction decision, and is based across an asynchronous boundary.
PAGE 225
R Clock Correction Idle Character Removal at 100 Mbps (SGMII) At SGMII, 100 Mbps, each byte is repeated 10 times. This also applies to the interframe gap period. For this reason, the minimum of 8 bytes for the 1 Gbps case corresponds to a minimum of 80 bytes for the 100 Mbps case. Additionally, the majority of characters in this 80-byte interframe-gap period are going to be the /I2/ clock correction characters.
PAGE 226
R Appendix E: Rx Elastic Buffer Specifications Maximum Frame Sizes for Sustained Frame Reception Sustained frame reception refers to the maximum size of frames which can be continuously received when each frame is separated by a minimum interframe gap.
PAGE 227
R Appendix F Debugging Guide This appendix provides assistance for debugging the core within a system. For additional help, contact Xilinx by submitting a WebCase at support.xilinx.com/. General Checks • Ensure that all the timing constraints for the core were met during Place and Route. • Does it work in timing simulation? If problems are seen in hardware but not in timing simulation, this could indicate a PCB issue. • Ensure that all clock sources are clean.
PAGE 228
R Appendix F: Debugging Guide If data is being transmitted and received between the core and its link partner, but with a high rate of packet loss, see “Problems with a High Bit Error Rate.” Problems with Auto-Negotiation Determine whether Auto-Negotiation has completed successfully by doing one of the following. • Poll the Auto-Negotiation completion bit 1.
PAGE 229
R Problems with a High Bit Error Rate RocketIO Transceiver Specific When using a RocketIO transceiver, perform these additional checks: • Ensure that the polarities of the TXN/TXP and RXN/RXP lines are not reversed. If they are, this can be easily fixed by using the TXPOLARITY and RXPOLARITY ports of the RocketIO. • For Virtex-II Pro, ensure that the REF_CLK_V_SEL attribute matches the REFCLK or BREFCLK port that the clock source to which it is connected.
PAGE 230
R Appendix F: Debugging Guide RocketIO Transceiver Specific Checks Perform these additional checks when using a RocketIO transceiver: • Directly monitor the following ports of the RocketIO by attaching error counters to them, or by triggering on them using Chipscope or an external logic analyzer. RXDISPERR RXNOTINTABLE These signals should not be asserted over the duration of a few seconds, minutes or even hours. If they are frequently asserted, it may indicate a problem with the RocketIO.