LogiCORE IP RXAUI v2.4

Transcription

1 LogiCORE P RXAU v2.4 Product Guide

2 Table of Contents SECTON : SUMMARY P Facts Chapter 1: Overview Feature Summary Applications Functional escription Licensing and Ordering nformation Chapter 2: Product Specification Standards Performance Resource Utilization Port escriptions Register Space Chapter 3: esigning with the Core General esign Guidelines Clocking Resets esign Considerations Protocol escription SECTON : VVAO ESGN SUTE Chapter 4: Customizing and Generating the Core GU Output Generation LogiCORE RXAU v

3 Chapter 5: Constraining the Core Required Constraints Clock Frequencies Clock Management Transceiver Placement MO Chapter 6: etailed Example esign Example esign emonstration Test Bench mplementation Simulation SECTON : SE ESGN SUTE Chapter 7: Customizing and Generating the Core GU Parameter Values in the XCO File Output Generation Pre-implementation Simulation Chapter 8: Constraining the Core evice, Package, and Speed Grade Selections Clock Frequencies Clock Management Transceiver Placement MO Chapter 9: etailed Example esign irectory and File Contents Example esign emonstration Test Bench Generating the Core mplementation Simulation SECTON V: APPENCES LogiCORE RXAU v

4 Appendix A: Verification, Compliance, and nteroperability Simulation Hardware Testing Appendix B: Migrating Appendix C: ebugging Solution Centers Finding Help on xilinx.com Contacting Xilinx Technical Support ebug Tools Simulation Specific ebug Hardware ebug Appendix : Additional Resources Xilinx Resources References Technical Support Revision History Notice of isclaimer LogiCORE RXAU v

5 SECTON : SUMMARY P Facts Overview Product Specification esigning with the Core C Model Reference LogiCORE RXAU v

6 P Facts ntroduction The LogiCORE P RXAU core is a high-performance, low pin count 10 Gb/s interface intended to allow physical separation between the data-link layer and physical layer devices in a 10 Gb Ethernet system. Supported evice Family (1) Supported User nterfaces LogiCORE P Facts Table Core Specifics Zynq -7000, Virtex-7, Kintex-7, Artix -7, Virtex-6 XGM, MO Resources See Table 2-1 and Table 2-2. The RXAU core implements a single-speed full-duplex 10 Gb/s Ethernet Reduced Pin extended Attachment Unit nterface (RXAU) solution for Xilinx 7 series and Virtex -6 FPGAs that comply with the une Networks and Marvell RXAU specifications. 7 series and Virtex-6 FPGAs in combination with the RXAU core, enable the design of RXAU-based interconnects whether they are chip-to-chip, over backplanes, or connected to 10 Gb optical modules. esign Files Example esign Test Bench Constraints File Simulation Model Supported S/W river Provided with Core Tested esign Flows (2) SE: NGC Netlist Vivado: Encrypted RTL Verilog/VHL Verilog/VHL SE: UCF Vivado: XC VHL/Verilog N/A Features esigned to une Networks and Marvell RXAU specifications Uses two transceivers at 6.25 Gb/s line rate to achieve 10 Gb/s data rate mplements TE XGXS, PHY XGXS, and 10GBASE-X PCS in a single netlist EEE clause 45 MO interface (optional) esign Entry Simulation Synthesis SE esign Suite v14.3 Vivado esign Suite v Mentor Graphics ModelSim Cadence ncisive Enterprise Simulator (ES) Synopsys VCS and VCS MX Support Xilinx Synthesis Technology (XST) Vivado Synthesis Provided by Notes: 1. For a complete listing of supported devices, see the release notes for this core. 2. For the supported versions of the tools, see the Xilinx esign Tools: Release Notes Guide. Available under the Xilinx End User License Agreement LogiCORE RXAU v Product Specification

7 Chapter 1 Overview The RXAU standard was developed as a means to improve the 10-Gigabit Ethernet port density. The number of XAU interfaces that could be implemented was limited by the number of available transceivers, with capacity and performance still to be utilized. RXAU halves the number of transceivers required compared with a XAU implementation. RXAU is a two-lane, 6.25 Gb/s-per-lane serial interface. t is intended to work with an existing XAU implementation and multiplexes/demultiplexes the two physical RXAU lanes into 4 logical XAU lanes. Each RXAU lane is a differential pair carrying current mode logic (CML) signaling, and the data on each lane is 8B/10B encoded before transmission. n this document: Virtex -7, Kintex -7 and Virtex-6 FPGAs GTX transceivers are abbreviated to GTX transceivers. Virtex-7 FPGA GTH transceiver is abbreviated to GTH transceiver. Artix -7 FPGA GTP transceiver is abbreviated to GTP transceiver. Feature Summary The RXAU core can be configured in one of two modes. une Networks: This RXAU implementation maintains 8B/10B disparity on the RXAU physical lane. The une Networks RXAU standard is fully specified in N-S-RXAU-Spec v.1.0. Marvell: This RXAU implementation maintains 8B/10B disparity on the XAU logical lane. The Marvell RXAU standard is fully specified in MV-S Management nterface: The RXAU Core can be customized with either a two-wire low-speed serial MO nterface, or a configuration and status vector interface. LogiCORE RXAU v

8 Chapter 1: Overview Applications The applications of RXAU have extended beyond 10-Gigabit Ethernet to the backplane and other general high-speed interconnect applications. A typical backplane application is shown in Figure 1-1. X-Ref Target - Figure 1-1 Figure 1-1: Typical Backplane Application for RXAU Functional escription Figure 1-2 shows a block diagram of the une Networks RXAU core implementation. The major functional blocks of the core include the following: Transmit dle Generation Logic: Creates the code groups to allow synchronization and alignment at the receiver. emux Logic: Separates the two physical RXAU lanes into four logical XAU lanes. Synchronization State Machine (one per lane): dentifies byte boundaries in incoming serial data. eskew State Machine: e-skews the four received lanes into alignment. Optional MO nterface: A two-wire low-speed serial interface used to manage the core. Embedded Transceivers: Provide high-speed transceivers as well as 8B/10B encode and decode, and elastic buffering in the receive datapath. LogiCORE RXAU v

9 Chapter 1: Overview X-Ref Target - Figure 1-2 Figure 1-2: mplementation of une Networks RXAU Core Figure 1-3 shows a block diagram of the Marvell RXAU core implementation. The major functional blocks of the core include the ones previously described in the une Networks implementation, and the following: 8B/10B encoder / decoder: Performs 8B/10B data conversion eskew: e-skews the four received lanes into alignment Clock Correction: Elastic buffer and clock correction manipulation to handle difference in clock rates. The core is implemented with the transceiver instantiations in the source code rather than in the netlist. This provides more flexibility in a particular application to use additional device-specific transceiver features and resolve placement issues. LogiCORE RXAU v

10 Chapter 1: Overview X-Ref Target - Figure 1-3 Figure 1-3: mplementation of Marvell RXAU Core Licensing and Ordering nformation This Xilinx LogiCORE P module is provided at no additional cost with the Xilinx Vivado esign Suite and SE esign Suite tools under the terms of the Xilinx End User License. nformation about this and other Xilinx LogiCORE P modules is available at the Xilinx ntellectual Property page. For information about pricing and availability of other Xilinx LogiCORE P modules and tools, contact your local Xilinx sales representative. LogiCORE RXAU v

11 Chapter 2 Product Specification Standards The RXAU P core is designed to the une Networks [Ref 2] and Marvell RXAU [Ref 3] specifications. Performance Latency These measurements are for the core only - they do not include the latency through the transceiver. The latency through the transceiver can be obtained from the relevant user guide. Transmit Path Latency As measured from the input port xgmii_txd[63:0] of the transmitter side XGM (until that data appears on mgt_txdata[63:0] on the transceiver interface), the latency through the core for the internal XGM interface configuration in the transmit direction is 3 clock periods of the core input usrclk for une Networks mode and 4 clock periods for Marvell mode. Receive Path Latency Measured from the input into the core on mgt_rxdata[63:0] until the data appears on xgmii_rxdata[63:0] of the receiver side XGM interface, the latency through the core in the receive direction for une Networks mode is equal to 5-7 clock cycles of usrclk. The latency depends on comma alignment position and data positioning within the transceiver 4-byte interface. For Marvell Mode, the exact latency depends on comma alignment position, lane skew, and elastic buffer occupancy. Typically this is 9-14 RXCLK cycles usrclk cycles. There is an additional 1 clock cycle of usrclk RX pipelining in the rxaui_block.v[hd] file if this is being used. LogiCORE RXAU v

12 Chapter 2: Product Specification Resource Utilization Table 2-1 provides approximate utilization for the various core options on Virtex-6 LXT FPGAs using the SE esign Suite. Table 2-1: Table 2-2 provides approximate utilization for the various core options on Virtex-7 and Kintex-7 FPGAs using the SE esign Suite. Table 2-2: Table 2-3 provides approximate utilization for the various core options on Virtex-7 (GTH) FPGAs using the SE esign Suite. Table 2-3: evice Utilization Virtex-6 LXT FPGAs MO Management RXAU Mode LUTs FFs BUFRs FALSE une TRUE une FALSE Marvell TRUE Marvell evice Utilization Zynq -7000, Virtex-7 (GTX) and Kintex-7 FPGAs MO Management RXAU Mode LUTs FFs FALSE une TRUE une FALSE Marvell TRUE Marvell Table 2-4 provides approximate utilization for the various core options on Artix -7 FPGAs using the SE esign Suite. Table 2-4: evice Utilization Virtex-7 (GTH) FPGAs MO Management RXAU Mode LUTs FFs FALSE une TRUE une FALSE Marvell TRUE Marvell evice Utilization Artix-7 FPGAs MO Management RXAU Mode LUTs FFs FALSE une TRUE une FALSE Marvell TRUE Marvell LogiCORE RXAU v

13 Chapter 2: Product Specification Port escriptions Client-Side nterface The signals of the client-side interface (between the User Logic block and the Core Netlist block in Figure 1-2) are shown in Table 2-5. See Protocol escription for details on connecting to the client-side interface. Table 2-5: Client-Side nterface Ports Signal Name irection escription XGM_TX[63:0] N Transmit data, eight bytes wide XGM_TXC[7:0] N Transmit control bits, one bit per transmit data byte XGM_RX[63:0] OUT Received data, eight bytes wide XGM_RXC[7:0] OUT Receive control bits, one bit per received data byte Transceiver nterface The interface to the device-specific transceivers is a simple pin-to-pin interface on those pins that need to be connected. Table 2-6 and Table 2-7 show the transceiver ports on the core depending on the RXAU mode chosen when customizing the core. These are connected between the core and the transceivers in the 'block' HL as part of the example output products (Vivado) or example design (CORE Generator). Table 2-6 shows the RXAU une Mode ports and Table 2-7 shows the RXAU Marvell Mode Ports. See Protocol escription for details on connecting the device-specific transceivers to the RXAU core. Table 2-6: une Networks Transceiver nterface Ports Signal Name irection escription MGT_TXATA[63:0] OUT Transceiver transmit data MGT_TXCHARSK[7:0] OUT Transceiver transmit control flag MGT_RXATA[63:0] N Transceiver receive data MGT_RXCHARSK[7:0] N Transceiver receive control signals MGT_COEVAL[7:0] N Transceiver receive control signals MGT_COECOMMA[7:0] N Transceiver receive control signals MGT_ENABLE_ALGN[1:0] OUT Transceiver control signals MGT_ENCHANSYNC OUT Transceiver control signal MGT_RXLOCK[1:0] N evice-specific transceiver control signals MGT_LOOPBACK OUT Transceiver control signal MGT_POWEROWN OUT Transceiver control signal SGNAL_ETECT[1:0] N Status signal from attached optical module LogiCORE RXAU v

14 Chapter 2: Product Specification Table 2-7: The SGNAL_ETECT signals are intended to be driven by an attached optical module; they signify that each of the two optical receivers is receiving illumination and is therefore not just putting out noise. f an optical module is not in use, this two-wire bus should be tied to 11. No timing diagrams are presented here for the device-specific transceiver signals. You should treat this interface as a black box. f customization of this interface is required, see the Virtex-6 FPGA GTX Transceivers User Guide [Ref 9], the 7 Series FPGAs GTX/GTH Transceivers User Guide [Ref 10], or the 7 Series FPGAs GTP Transceivers User Guide [Ref 11] for detailed descriptions of the transceiver ports. This section describes the interfaces available for dynamically setting the configuration and obtaining the status of the RXAU core. There are two interfaces for configuration; depending on the core customization, only one is available in a particular core instance. n addition, there are output ports on the core signalling alignment and synchronization status. These ports are described in Alignment and Synchronization Status Ports. MO Ports Marvell Transceiver nterface Ports Signal Name irection escription MGT_TXATA[79:0] OUT Transceiver transmit data MGT_RXATA[39:0] N Transceiver receive data MGT_ENABLE_ALGN[1:0] OUT Transceiver control signals MGT_LOOPBACK OUT Transceiver control signal MGT_POWEROWN OUT Transceiver control signal SGNAL_ETECT[1:0] N Status signal from attached optical module (if present) The RXAU core, when generated with an MO interface, implements an MO nterface Register block. The core responds to MO transactions as either a 10GBASE-X PCS, a TE XS, or a PHY XS depending on the setting of the type_sel port (see Table 3-3). The MO nterface Ports are described in Table 2-8. More information on using this interface can be found in MO nterface. Table 2-8: MO Management nterface Ports Signal Name irection escription MC N Management clock MO_N N MO input MO_OUT OUT MO output MO_TR OUT MO 3-state. 1 disconnects the output driver from the MO bus. TYPE_SEL[1:0] N Type select PRTA[4:0] N MO port address LogiCORE RXAU v

15 Chapter 2: Product Specification Configuration and Status Signals The Configuration and Status Signals are shown in Table See Configuration and Status Vectors for details on these signals, including a breakdown of the configuration and status vectors. Table 2-9: Configuration and Status Ports Signal Name irection escription CONFGURATON_ VECTOR[6:0] N Configuration information for the core. STATUS_VECTOR[7:0] OUT Status information from the core. ALGN_STATUS OUT 1 when the RXAU receiver is aligned across all four logical XAU lanes, 0 otherwise. SYNC_STATUS[3:0] OUT Each pin is 1 when the respective XAU logical lane receiver is synchronized to byte boundaries, 0 otherwise. Clocking and Reset Signals and Module ncluded in the example design top-level sources are circuits for clock and reset management. These can include Mixed-Mode Clock Managers (MMCMs), reset synchronizers, or other useful utility circuits that can be useful in your particular application. Table 2-10 shows the ports on the netlist that are associated with system clocks and resets. Table 2-10: Clock and Reset Ports Signal Name irection escription USRCLK N MHz system clock for core. RESET N Reset port synchronous to USRCLK. SOFT_RESET OUT Reset signal controlled by MO register bit. This reset signal also resets the transceivers. MGT_TX_RESET N The reset signal used to drive the transceiver TXRESET signal. MGT_RX_RESET N The reset signal used to drive the transceiver RXRESET signal. RXCLK N Transceiver recovered clock (Marvell Mode Only). LogiCORE RXAU v

16 Chapter 2: Product Specification Register Space This section describes the interfaces available for dynamically setting the configuration and obtaining the status of the RXAU core. There are two interfaces for configuration; depending on the core customization, only one is available in a particular core instance. The interfaces are: MO nterface Registers Configuration and Status Vectors n addition, there are output ports on the core signalling alignment and synchronization status. These ports are described in Alignment and Synchronization Status Ports. MO nterface Registers For a description of the MO nterface, see MO nterface. 10GBASE-X PCS/PMA Register Map When the core is configured as a 10GBASE-X PCS/PMA, it occupies MO evice Addresses 1 and 3 in the MO register address map, as shown in Table LogiCORE RXAU v

17 Chapter 2: Product Specification Table 2-11: 10GBASE-X PCS/PMA MO Registers Register Address Register Name 1.0 PMA/PM Control PMA/PM Status 1 1.2,1.3 PMA/PM evice dentifier 1.4 PMA/PM Speed Ability 1.5, 1.6 PMA/PM evices in Package G PMA/PM Control G PMA/PM Status Reserved G PM Receive Signal OK 1.11 TO 1.13 Reserved 1.14, 1.15 PMA/PM Package dentifier 1.16 to Reserved 3.0 PCS Control PCS Status 1 3.2, 3.3 PCS evice dentifier 3.4 PCS Speed Ability 3.5, 3.6 PCS evices in Package G PCS Control G PCS Status to 3.13 Reserved 3.14, 3.15 Package dentifier 3.16 to 3.23 Reserved GBASE-X PCS Status GBASE-X Test Control 3.26 to Reserved LogiCORE RXAU v

18 Chapter 2: Product Specification MO Register 1.0: PMA/PM Control 1 Figure 2-1 shows the MO Register 1.0: PMA/PM Control 1. X-Ref Target - Figure 2-1 Figure 2-1: PMA/PM Control 1 Register Table 2-12 shows the PMA Control 1 register bit definitions. Table 2-12: PMA/PM Control 1 Register Bit efinitions Bit(s) Name escription Attributes Reset 1 = Block reset 0 = Normal operation The RXAU block is reset when this bit is set to 1. t returns to 0 when the reset is complete. The soft_reset pin is connected to this bit. This can be connected to the reset of any other MMs Reserved The block always returns 0 for this bit and ignores writes Speed Selection The block always returns 1 for this bit and ignores writes Reserved The block always returns 0 for this bit and ignores writes Power down 1 = Power down mode 0 = Normal operation When set to 1, the serial transceivers are placed in a low power state. Set to 0 to return to normal operation :7 Reserved The block always returns 0 for these bits and ignores writes Speed Selection 1.0.5:2 Speed Selection The block always returns 1 for this bit and ignores writes. The block always returns 0s for these bits and ignores writes Reserved The block always returns 0 for this bit and ignores writes Loopback 1 = Enable loopback mode 0 = isable loopback mode The RXAU block loops the signal in the serial transceivers back into the receiver. R/W Self-clearing efault Value 0 R/O 0 R/O 1 R/O 0 R/W 0 R/O All 0s R/O 1 R/O R/O All 0s All 0s R/W 0 LogiCORE RXAU v

19 Chapter 2: Product Specification MO Register 1.1: PMA/PM Status 1 Figure 2-2 shows the MO Register 1.1: PMA/PM Status 1. X-Ref Target - Figure 2-2 Figure 2-2: PMA/PM Status 1 Register Table 2-13 shows the PMA/PM Status 1 register bit definitions. Table 2-13: PMA/PM Status 1 Register Bit efinitions Bit(s) Name escription Attributes :8 Reserved The block always returns 0 for this bit. R/O Local Fault The block always returns 0 for this bit. R/O :3 Reserved The block always returns 0 for this bit. R/O Receive Link Status Power own Ability efault Value The block always returns 1 for this bit. R/O 1 The block always returns 1 for this bit. R/O Reserved The block always returns 0 for this bit. R/O 0 LogiCORE RXAU v

20 Chapter 2: Product Specification MO Registers 1.2 and 1.3: PMA/PM evice dentifier Figure 2-3 shows the MO Registers 1.2 and 1.3: PMA/PM evice dentifier. X-Ref Target - Figure 2-3 Figure 2-3: Table 2-14 shows the PMA/PM evice dentifier registers bit definitions. Table 2-14: MO Register 1.4: PMA/PM Speed Ability PMA/PM evice dentifier Registers PMA/PM evice dentifier Registers Bit efinitions Bit(s) Name escription Attributes efault Value :0 PMA/PM dentifier :0 PMA/PM dentifier The block always returns 0 for these bits and ignores writes. The block always returns 0 for these bits and ignores writes. Figure 2-4 shows the MO Register 1.4: PMA/PM Speed Ability. R/O R/O All 0s All 0s X-Ref Target - Figure 2-4 Figure 2-4: PMA/PM Speed Ability Register Table 2-15 shows the PMA/PM Speed Ability register bit definitions. Table 2-15: PMA/PM Speed Ability Register Bit efinitions Bit(s) Name escription Attribute efault Value :1 Reserved The block always returns 0 for these bits and ignores writes G Capable The block always returns 1 for this bit and ignores writes. R/O All 0s R/O 1 LogiCORE RXAU v

21 Chapter 2: Product Specification MO Registers 1.5 and 1.6: PMA/PM evices in Package Figure 2-5 shows the MO Registers 1.5 and 1.6: PMA/PM evices in Package. X-Ref Target - Figure 2-5 Figure 2-5: PMA/PM evices in Package Registers Table 2-16 shows the PMA/PM evice in Package registers bit definitions. Table 2-16: PMA/PM evices in Package Registers Bit efinitions Bit(s) Name escription Attributes efault Value Vendor- specific evice 2 present Vendor-specific evice 1 present The block always returns 0 for this bit. R/O 0 The block always returns 0 for this bit. R/O :0 Reserved The block always returns 0 for these bits. R/O All 0s :6 Reserved The block always returns 0 for these bits. R/O All 0s TE XS present The block always returns 0 for this bit. R/O PHY XS present The block always returns 0 for this bit. R/O PCS present The block always returns 1 for this bit. R/O WS present The block always returns 0 for this bit. R/O PMA/PM present The block always returns 1 for this bit. R/O Clause 22 evice present The block always returns 0 for this bit. R/O 0 LogiCORE RXAU v

22 Chapter 2: Product Specification MO Register 1.7: 10G PMA/PM Control 2 Figure 2-6 shows the MO Register 1.7: 10G PMA/PM Control 2. X-Ref Target - Figure 2-6 Figure 2-6: 10G PMA/PM Control 2 Register Table 2-17 shows the PMA/PM Control 2 register bit definitions. Table 2-17: 10G PMA/PM Control 2 Register Bit efinitions Bit(s) Name escription Attributes :3 Reserved The block always returns 0 for these bits and ignores writes :0 PMA/PM Type Selection The block always returns 100 for these bits and ignores writes. This corresponds to the 10GBASE-X PMA/PM. R/O efault Value All 0s R/O 100 LogiCORE RXAU v

23 Chapter 2: Product Specification MO Register 1.8: 10G PMA/PM Status 2 Figure 2-7 shows the MO Register 1.8: 10G PMA/PM Status 2. X-Ref Target - Figure 2-7 Figure 2-7: 10G PMA/PM Status 2 Register Table 2-18 shows the PMA/PM Status 2 register bit definitions. Table 2-18: 10G PMA/PM Status 2 Register Bit efinitions Bit(s) Name escription Attributes efault Value :14 evice present The block always returns 10 for these bits. R/O Transmit Local Fault Ability The block always returns 0 for this bit. R/O Receive Local The block always returns 0 for this bit. R/O 0 Fault Ability Transmit Fault The block always returns 0 for this bit. R/O Receive Fault The block always returns 0 for this bit. R/O Reserved The block always returns 0 for this bit. R/O PM Transmit isable Ability The block always returns 0 for this bit. R/O GBASE-SR Ability The block always returns 0 for this bit. R/O GBASE-LR Ability The block always returns 0 for this bit. R/O GBASE-ER Ability The block always returns 0 for this bit. R/O GBASE-LX4 Ability The block always returns 1 for this bit. R/O GBASE-SW Ability The block always returns 0 for this bit. R/O GBASE-LW Ability The block always returns 0 for this bit. R/O GBASE-EW Ability The block always returns 0 for this bit. R/O PMA Loopback Ability The block always returns 1 for this bit. R/O 1 LogiCORE RXAU v

24 Chapter 2: Product Specification MO Register 1.10: 10G PM Signal Receive OK Figure 2-8 shows the MO 1.10 Register: 10G PM Signal Receive OK. X-Ref Target - Figure 2-8 Figure 2-8: 10G PM Signal Receive OK Register Table 2-19 shows the 10G PM Signal Receive OK register bit definitions. Table 2-19: 10G PM Signal Receive OK Register Bit efinitions Bit(s) Name escription Attributes efault Value :5 Reserved The block always returns 0s for these bits. R/O All 0s PM Receive Signal OK PM Receive Signal OK PM Receive Signal OK PM Receive Signal OK Global PM Receive Signal OK 1 = Signal OK on receive Lane 3 0 = Signal not OK on receive Lane 3 This is the value of the SGNAL_ETECT[3] port. 1 = Signal OK on receive Lane 2 0 = Signal not OK on receive Lane 2 This is the value of the SGNAL_ETECT[2] port. 1 = Signal OK on receive Lane 1 0 = Signal not OK on receive Lane 1 This is the value of the SGNAL_ETECT[1] port. 1 = Signal OK on receive Lane 0 0 = Signal not OK on receive Lane 0 This is the value of the SGNAL_ETECT[0] port. 1 = Signal OK on all receive lanes 0 = Signal not OK on all receive lanes R/O - R/O - R/O - R/O - R/O - LogiCORE RXAU v

25 Chapter 2: Product Specification MO Registers 1.14 and 1.15: PMA/PM Package dentifier Figure 2-9 shows the MO Registers 1.14 and 1.15: PMA/PM Package dentifier register. X-Ref Target - Figure 2-9 Figure 2-9: PMA/PM Package dentifier Registers Table 2-20 shows the PMA/PM Package dentifier registers bit definitions. Table 2-20: PMA/PM Package dentifier Registers Bit efinitions Bit(s) Name escription Attributes efault Value :0 PMA/PM Package dentifier :0 PMA/PM Package dentifier The block always returns 0 for these bits. R/O All 0s The block always returns 0 for these bits. R/O All 0s LogiCORE RXAU v

26 Chapter 2: Product Specification MO Register 3.0: PCS Control 1 Figure 2-10 shows the MO Register 3.0: PCS Control 1. X-Ref Target - Figure 2-10 Figure 2-10: PCS Control 1 Register Table 2-21 shows the PCS Control 1 register bit definitions. Table 2-21: PCS Control 1 Register Bit efinitions Bit(s) Name escription Attributes Reset 1 = Block reset 0 = Normal operation The RXAU block is reset when this bit is set to 1. t returns to 0 when the reset is complete GBASE-R Loopback Speed Selection The block always returns 0 for this bit and ignores writes. The block always returns 1 for this bit and ignores writes Reserved The block always returns 0 for this bit and ignores writes Power down 1 = Power down mode 0 = Normal operation When set to 1, the serial transceivers are placed in a low power state. Set to 0 to return to normal operation :7 Reserved The block always returns 0 for these bits and ignores writes Speed Selection 3.0.5:2 Speed Selection The block always returns 1 for this bit and ignores writes. The block always returns 0s for these bits and ignores writes :0 Reserved The block always returns 0 for this bit and ignores writes. R/W Self-clearing efault Value 0 R/O 0 R/O 1 R/O 0 R/W 0 R/O All 0s R/O 1 R/O R/O All 0s All 0s LogiCORE RXAU v

27 Chapter 2: Product Specification MO Register 3.1: PCS Status 1 Figure 2-11 shows the MO Register 3.1: PCS Status 1. X-Ref Target - Figure 2-11 Figure 2-11: Table 2-22 show the PCS 1 register bit definitions. Table 2-22: PCS Status 1 Register Bit efinition PCS Status 1 Register Bit(s) Name escription Attributes :8 Reserved The block always returns 0s for these bits and ignores writes Local Fault 1 = Local fault detected 0 = No local fault detected This bit is set to 1 whenever either of the bits , are set to :3 Reserved The block always returns 0s for these bits and ignores writes PCS Receive Link Status Power own Ability 1 = The PCS receive link is up 0 = The PCS receive link is down This is a latching Low version of bit R/O efault Value All 0s R/O - R/O R/O Self-setting The block always returns 1 for this bit. R/O Reserved The block always returns 0 for this bit and ignores writes. All 0s - R/O 0 LogiCORE RXAU v

28 . Chapter 2: Product Specification MO Registers 3.2 and 3.3: PCS evice dentifier Figure 2-12 shows the MO Registers 3.2 and 3.3: PCS evice dentifier. X-Ref Target - Figure 2-12 Figure 2-12: Table 2-23 shows the PCS evice dentifier registers bit definitions. Table 2-23: MO Register 3.4: PCS Speed Ability PCS evice dentifier Registers PCS evice dentifier Registers Bit efinition Bit(s) Name escription Attributes efault Value :0 PCS dentifier The block always returns 0 for these bits and ignores writes :0 PCS dentifier The block always returns 0 for these bits and ignores writes. Figure 2-13 shows the MO Register 3.4: PCS Speed Ability. R/O R/O All 0s All 0s X-Ref Target - Figure 2-13 Figure 2-13: PCS Speed Ability Register Table 2-24 shows the PCS Speed Ability register bit definitions. Table 2-24: PCS Speed Ability Register Bit efinition Bit(s) Name escription Attribute efault Value :1 Reserved The block always returns 0 for these bits and ignores writes G Capable The block always returns 1 for this bit and ignores writes. R/O All 0s R/O 1 LogiCORE RXAU v

29 Chapter 2: Product Specification MO Registers 3.5 and 3.6: PCS evices in Package Figure 2-14 shows the MO Registers 3.5 and 3.6: PCS evices in Package. X-Ref Target - Figure 2-14 Figure 2-14: PCS evices in Package Registers Table 2-25 shows the PCS evices in Package registers bit definitions. Table 2-25: PCS evices in Package Registers Bit efinitions Bit(s) Name escription Attributes efault Value Vendor-specific evice 2 present Vendor- specific evice 1 present The block always returns 0 for this bit. R/O 0 The block always returns 0 for this bit. R/O :0 Reserved The block always returns 0 for these bits. R/O All 0s :6 Reserved The block always returns 0 for these bits. R/O All 0s PHY XS present The block always returns 0 for this bit. R/O PHY XS present The block always returns 0 for this bit. R/O PCS present The block always returns 1 for this bit. R/O WS present The block always returns 0 for this bit. R/O PMA/PM present The block always returns 1 for this bit. R/O Clause 22 device present The block always returns 0 for this bit. R/O 0 LogiCORE RXAU v

30 Chapter 2: Product Specification MO Register 3.7: 10G PCS Control 2 Figure 2-15 shows the MO Register 3.7: 10G PCS Control 2. X-Ref Target - Figure 2-15 Figure 2-15: 10G PCS Control 2 Register Table 2-26 shows the 10 G PCS Control 2 register bit definitions. Table 2-26: 10G PCS Control 2 Register Bit efinitions Bit(s) Name escription Attributes :2 Reserved The block always returns 0 for these bits and ignores writes :0 PCS Type Selection The block always returns 01 for these bits and ignores writes. R/O efault Value All 0s R/O 01 LogiCORE RXAU v

31 Chapter 2: Product Specification MO Register 3.8: 10G PCS Status 2 Figure 2-16 shows the MO Register 3.8: 10G PCS Status 2. X-Ref Target - Figure 2-16 Figure 2-16: 10G PCS Status 2 Register Table 2-27 shows the 10G PCS Status 2 register bit definitions. Table 2-27: 10G PCS Status 2 Register Bit efinitions Bit(s) Name escription Attributes :14 evice present efault Value The block always returns 10. R/O :12 Reserved The block always returns 0 for these bits. R/O All 0s Transmit local fault Receive local fault 1 = Fault condition on transmit path 0 = No fault condition on transmit path 1 = Fault condition on receive path 0 = No fault condition on receive path R/O Latching High R/O Latching High 3.8.9:3 Reserved The block always returns 0 for these bits. R/O All 0s GBASE-W Capable GBASE-X Capable GBASE-R Capable The block always returns 0 for this bit. R/O 0 The block always returns 1 for this bit. R/O 1 The block always returns 0 for this bit. R/O LogiCORE RXAU v

32 Chapter 2: Product Specification MO Registers 3.14 and 3.15: PCS Package dentifier Figure 2-17 shows the MO Registers 3.14 and 3.15: PCS Package dentifier. X-Ref Target - Figure 2-17 Figure 2-17: Package dentifier Registers Table 2-28 shows the PCS Package dentifier registers bit definitions. Table 2-28: PCS Package dentifier Register Bit efinitions Bit(s) Name escription Attributes efault Value :0 Package dentifier The block always returns 0 for these bits. R/O All 0s :0 Package dentifier The block always returns 0 for these bits. R/O All 0s LogiCORE RXAU v

33 Chapter 2: Product Specification MO Register 3.24: 10GBASE-X Status Figure 2-18 shows the MO Register 3.24: 10GBase-X Status. X-Ref Target - Figure 2-18 Figure 2-18: 10GBASE-X Status Register Table 2-29 shows the 10GBase-X Status register bit definitions. Table 2-29: 10GBASE-X Status Register Bit efinitions Bit(s) Name escription Attributes efault Value :13 Reserved The block always returns 0 for these bits. R/O All 0s GBASE-X Lane Alignment Status Pattern Testing Ability 1 = 10GBASE-X receive lanes aligned 0 = 10GBASE-X receive lanes not aligned. RO - The block always returns 1 for this bit. R/O :4 Reserved The block always returns 0 for these bits. R/O All 0s Lane 3 Sync 1 = Lane 3 is synchronized 0 = Lane 3 is not synchronized Lane 2 Sync 1 =Lane 2 is synchronized 0 =Lane 2 is not synchronized Lane 1 Sync 1 = Lane 1 is synchronized 0 = Lane 1 is not synchronized Lane 0 Sync 1 = Lane 0 is synchronized 0 = Lane 0 is not synchronized. R/O - R/O - R/O - R/O - LogiCORE RXAU v

34 Chapter 2: Product Specification MO Register 3.25: 10GBASE-X Test Control Figure 2-19 shows the MO Register 3.25: 10GBase-X Test Control. X-Ref Target - Figure 2-19 Figure 2-19: Test Control Register Table 2-30 shows the 10GBase-X Test Control register bit definitions. Table 2-30: 10GBASE-X Test Control Register Bit efinitions Bit(s) Name escription Attributes efault Value :3 Reserved The block always returns 0 for these bits. R/O All 0s Transmit Test Pattern Enable :0 Test Pattern Select 1 = Transmit test pattern enable 0 = Transmit test pattern disabled 11 = Reserved 10 = Mixed frequency test pattern 01 = Low frequency test pattern 00 = High frequency test pattern R/W 0 R/W 00 LogiCORE RXAU v

35 Chapter 2: Product Specification TE XS MO Register Map When the core is configured as a TE XGXS, it occupies MO evice Address 5 in the MO register address map (Table 2-31). Table 2-31: TE XS MO Registers Register Address 5.0 TE XS Control TE XS Status 1 5.2, 5.3 TE XS evice dentifier 5.4 TE XS Speed Ability 5.5, 5.6 TE XS evices in Package 5.7 Reserved 5.8 TE XS Status to 5.13 Reserved 5.14, 5.15 TE XS Package dentifier 5.16 to 5.23 Reserved G TE XGXS Lane Status G TE XGXS Test Control Register Name LogiCORE RXAU v

36 Chapter 2: Product Specification MO Register 5.0:TE XS Control 1 Figure 2-20 shows the MO Register 5.0: TE XS Control 1. X-Ref Target - Figure 2-20 Figure 2-20: TE XS Control 1 Register Table 2-32 shows the TE XS Control 1 register bit definitions. Table 2-32: TE XS Control 1 Register Bit efinitions Bit(s) Name escription Attributes Reset 1 = Block reset 0 = Normal operation The RXAU block is reset when this bit is set to 1. t returns to 0 when the reset is complete Loopback 1 = Enable loopback mode 0 = isable loopback mode The RXAU block loops the signal in the serial transceivers back into the receiver Speed Selection The block always returns 1 for this bit and ignores writes Reserved The block always returns 0 for this bit and ignores writes Power down 1 = Power down mode 0 = Normal operation When set to 1, the serial transceivers are placed in a low power state. Set to 0 to return to normal operation :7 Reserved The block always returns 0s for these bits and ignores writes Speed Selection 5.0.5:2 Speed Selection The block always returns 1 for this bit and ignores writes. The block always returns 0s for these bits and ignores writes :0 Reserved The block always returns 0s for these bits and ignores writes. R/W Self-clearin g efault Value 0 R/W 0 R/O 1 R/O 0 R/W 0 R/O All 0s R/O 1 R/O R/O All 0s All 0s LogiCORE RXAU v

37 Chapter 2: Product Specification MO Register 5.1: TE XS Status 1 Figure 2-21 shows the MO Register 5.1: TE XS Status 1. X-Ref Target - Figure 2-21 Figure 2-21: TE XS Status 1 Register Table 2-33 shows the ET XS Status 1 register bit definitions. Table 2-33: TE XS Status 1 Register Bit efinitions Bit(s) Name escription Attributes :8 Reserved The block always returns 0s for these bits and ignores writes Local Fault 1 = Local fault detected 0 = No Local Fault detected This bit is set to 1 whenever either of the bits , are set to :3 Reserved The block always returns 0s for these bits and ignores writes TE XS Receive Link Status 1 = The TE XS receive link is up. 0 = The TE XS receive link is down. This is a latching Low version of bit R/O efault Value All 0s R/O - R/O R/O Selfsetting Power own Ability The block always returns 1 for this bit. R/O Reserved The block always returns 0 for this bit and ignores writes. All 0s - R/O 0 LogiCORE RXAU v

38 Chapter 2: Product Specification MO Registers 5.2 and 5.3: TE XS evice dentifier Figure 2-22 shows the MO Registers 5.2 and 5.3: TE XS evice dentifier. X-Ref Target - Figure 2-22 Figure 2-22: Table 2-34 shows the TE XS evice dentifier registers bit definitions. Table 2-34: MO Register 5.4: TE XS Speed Ability TE XS evice dentifier Registers TE XS evice dentifier Register Bit efinitions Bit(s) Name escription Attributes efault Value :0 TE XS dentifier :0 TE XS dentifier The block always returns 0 for these bits and ignores writes. The block always returns 0 for these bits and ignores writes. Figure 2-23 shows the MO Register 5.4: TE Speed Ability. R/O R/O All 0s All 0s X-Ref Target - Figure 2-23 Figure 2-23: TE XS Speed Ability Register Table 2-35 shows the TE XS Speed Ability register bit definitions. Table 2-35: TE XS Speed Ability Register Bit efinitions Bit(s) Name escription Attributes efault Value :1 Reserved The block always returns 0 for these bits and ignores writes G Capable The block always returns 1 for this bit and ignores writes. R/O All 0s R/O 1 LogiCORE RXAU v

39 Chapter 2: Product Specification MO Registers 5.5 and 5.6: TE XS evices in Package Figure 2-24 shows the MO Registers 5.5 and 5.6: TE XS evices in Package. X-Ref Target - Figure 2-24 Figure 2-24: TE XS evices in Package Register Table 2-36 shows the TE XS evices in Package registers bit definitions. Table 2-36: TE XS evices in Package Registers Bit efinitions Bit(s) Name escription Attributes Vendor-specific evice 2 present Vendor-specific evice 1 present efault Value The block always returns 0 for this bit. R/O 0 The block always returns 0 for this bit. R/O :0 Reserved The block always returns 0 for these bits. R/O All 0s :6 Reserved The block always returns 0 for these bits. R/O All 0s TE XS present The block always returns 1 for this bit. R/O PHY XS present The block always returns 0 for this bit. R/O PCS present The block always returns 0 for this bit. R/O WS present The block always returns 0 for this bit. R/O PMA/PM present Clause 22 evice present The block always returns 0 for this bit. R/O 0 The block always returns 0 for this bit. R/O 0 LogiCORE RXAU v

40 Chapter 2: Product Specification MO Register 5.8: TE XS Status 2 Figure 2-25 shows the MO Register 5.8: TE XS Status 2. X-Ref Target - Figure 2-25 Figure 2-25: TE XS Status 2 Register Table 2-37 show the TE XS Status 2 register bits definitions. Table 2-37: TE XS Status 2 Register Bit efinitions Bit(s) Name escription Attributes :14 evice present efault Value The block always returns 10. R/O :12 Reserved The block always returns 0 for these bits. R/O All 0s Transmit Local Fault Receive Local Fault 1 = Fault condition on transmit path 0 = No fault condition on transmit path 1 = Fault condition on receive path 0 = No fault condition on receive path R/O Latching High R/O Latching High 5.8.9:0 Reserved The block always returns 0 for these bits. R/O All 0s - - LogiCORE RXAU v

41 Chapter 2: Product Specification MO Registers 5.14 and 5.15: TE XS Package dentifier Figure 2-26 shows the MO Registers 5.14 and 5.15: TE XS Package dentifier. X-Ref Target - Figure 2-26 Figure 2-26: TE XS Package dentifier Registers Table 2-38 shows the TE XS Package dentifier registers bit definitions. Table 2-38: TE XS Package dentifier Register Bit efinitions Bit(s) Name escription Attributes efault Value :0 TE XS Package dentifier :0 TE XS Package dentifier The block always returns 0 for these bits. R/O All 0s The block always returns 0 for these bits. R/O All 0s Test Patterns The RXAU core is capable of sending test patterns for system debug. These patterns are defined in Annex 48A of EEE Std and transmission of these patterns is controlled by the MO Test Control Registers. There are three types of pattern available: High frequency test pattern of at each device-specific transceiver output Low frequency test pattern of at each device-specific transceiver output mixed frequency test pattern of at each device-specific transceiver output. LogiCORE RXAU v

42 Chapter 2: Product Specification MO Register 5.24: TE XS Lane Status Figure 2-27 shows the MO Register 5.24: TE XS Lane Status. X-Ref Target - Figure 2-27 Figure 2-27: TE XS Lane Status Register Table 2-39 shows the TE XS Lane Status register bit definitions. Table 2-39: TE XS Lane Status Register Bit efinitions Bit(s) Name escription Attributes efault Value :13 Reserved The block always returns 0 for these bits. R/O All 0s TE XGXS Lane Alignment Status Pattern testing ability 1 = TE XGXS receive lanes aligned 0 = TE XGXS receive lanes not aligned R/O - The block always returns 1 for this bit. R/O :4 Reserved The block always returns 0 for these bits. R/O All 0s Lane 3 Sync 1 = Lane 3 is synchronized 0 = Lane 3 is not synchronized Lane 2 Sync 1 = Lane 2 is synchronized 0 = Lane 2 is not synchronized Lane 1 Sync 1 = Lane 1 is synchronized 0 = Lane 1 is not synchronized Lane 0 Sync 1 = Lane 0 is synchronized 0 = Lane 0 is not synchronized. R/O - R/O - R/O - R/O - LogiCORE RXAU v

43 Chapter 2: Product Specification MO Register 5.25: 10G TE XGXS Test Control Figure 2-28 shows the MO Register 5.25: 10G TE XGXS Test Control. X-Ref Target - Figure 2-28 Figure 2-28: 10G TE XGXS Test Control Register Table 2-40 shows the 10G TE XGXS Test Control register bit definitions. Table 2-40: 10G TE XGXS Test Control Register Bit efinitions Bit(s) Name escription Attributes efault Value :3 Reserved The block always returns 0 for these bits. R/O All 0s Transmit Test Pattern Enable :0 Test Pattern Select 1 = Transmit test pattern enable 0 = Transmit test pattern disabled 11 = Reserved 10 = Mixed frequency test pattern 01 = Low frequency test pattern 00 = High frequency test pattern R/W 0 R/W 00 LogiCORE RXAU v

44 Chapter 2: Product Specification PHY XS MO Register Map When the core is configured as a PHY XGXS, it occupies MO evice Address 4 in the MO register address map (Table 2-41). Table 2-41: PHY XS MO Registers Register Address 4.0 PHY XS Control PHY XS Status 1 4.2, 4.3 evice dentifier 4.4 PHY XS Speed Ability 4.5, 4.6 evices in Package 4.7 Reserved 4.8 PHY XS Status to 4.13 Reserved 4.14, 4.15 Package dentifier 4.16 to 4.23 Reserved G PHY XGXS Lane Status G PHY XGXS Test Control Register Name LogiCORE RXAU v

45 Chapter 2: Product Specification MO Register 4.0: PHY XS Control 1 Figure 2-29 shows the MO Register 4.0: PHY XS Control 1. X-Ref Target - Figure 2-29 Figure 2-29: PHY XS Control 1 Register Table 2-42 shows the PHY XS Control 1 register bit definitions. Table 2-42: PHY XS Control 1 Register Bit efinitions Bit(s) Name escription Attributes Reset 1 = Block reset 0 = Normal operation The RXAU block is reset when this bit is set to 1. t returns to 0 when the reset is complete Loopback 1 = Enable loopback mode 0 = isable loopback mode The RXAU block loops the signal in the serial transceivers back into the receiver Speed Selection The block always returns 1 for this bit and ignores writes Reserved The block always returns 0 for this bit and ignores writes Power down 1 = Power down mode 0 = Normal operation When set to 1, the serial transceivers are placed in a low power state. Set to 0 to return to normal operation :7 Reserved The block always returns 0s for these bits and ignores writes Speed Selection 4.0.5:2 Speed Selection The block always returns 1 for this bit and ignores writes. The block always returns 0s for these bits and ignores writes :0 Reserved The block always returns 0s for these bits and ignores writes. R/W Selfclearing efault Value 0 R/W 0 R/O 1 R/O 0 R/W 0 R/O All 0s R/O 1 R/O R/O All 0s All 0s LogiCORE RXAU v

46 Chapter 2: Product Specification MO Register 4.1: PHY XS Status 1 Figure 2-30 shows the MO Register 4.1: PHY XS Status 1. X-Ref Target - Figure 2-30 Figure 2-30: PHY XS Status 1 Register Table 2-43 shows the PHY XS Status 1 register bit definitions. Table 2-43: PHY XS Status 1 Register Bit efinitions Bit(s) Name escription Attributes :8 Reserved The block always returns 0s for these bits and ignores writes Local Fault 1 = Local fault detected 0 = No Local Fault detected This bit is set to 1 whenever either of the bits , are set to :3 Reserved The block always returns 0s for these bits and ignores writes PHY XS Receive Link Status Power own Ability 1 = The PHY XS receive link is up. 0 =The PHY XS receive link is down. This is a latching Low version of bit R/O efault Value All 0s R/O - R/O R/O Self-setting The block always returns 1 for this bit. R/O Reserved The block always returns 0 for this bit and ignores writes. All 0s - R/O 0 LogiCORE RXAU v

47 Chapter 2: Product Specification MO Registers 4.2 and 4.3: PHY XS evice dentifier Figure 2-31 shows the MO Registers 4.2 and 4.3: PHY XS evice dentifier. X-Ref Target - Figure 2-31 Figure 2-31: Table 2-44 shows the PHY XS evices dentifier registers bit definitions. Table 2-44: MO Register 4.4: PHY XS Speed Ability PHY XS evice dentifier Registers PHY XS evice dentifier Registers Bit efinitions Bit(s) Name escription Attributes efault Value :0 PHY XS dentifier :0 PHY XS dentifier The block always returns 0 for these bits and ignores writes. The block always returns 0 for these bits and ignores writes. Figure 2-32 shows the MO Register 4.4: PHY XS Speed Ability. R/O R/O All 0s All 0s X-Ref Target - Figure 2-32 Figure 2-32: PHY XS Speed Ability Register Table 2-45 shows the PHY XS Speed Ability register bit definitions. Table 2-45: PHY XS Speed Ability Register Bit efinitions Bit(s) Name escription Attributes efault Value :1 Reserved The block always returns 0 for these bits and ignores writes G Capable The block always returns 1 for this bit and ignores writes. R/O All 0s R/O 1 LogiCORE RXAU v

48 Chapter 2: Product Specification MO Registers 4.5 and 4.6: PHY XS evices in Package Figure 2-33 shows the MO Registers 4.5 and 4.6: PHY XS evices in Package. X-Ref Target - Figure 2-33 Figure 2-33: PHY XS evices in Package Registers Table 2-46 shows the PHY XS evices in Package registers bit definitions. Table 2-46: PHY XS evices in Package Registers Bit efinitions Bit(s) Name escription Attributes Vendor-specific evice 2 present Vendor-specific evice 1 present efault Value The block always returns 0 for this bit. R/O 0 The block always returns 0 for this bit. R/O :0 Reserved The block always returns 0 for these bits. R/O All 0s :6 Reserved The block always returns 0 for these bits. R/O All 0s TE XS present The block always returns 0 for this bit. R/O PHY XS present The block always returns 1 for this bit. R/O PCS present The block always returns 0 for this bit. R/O WS present The block always returns 0 for this bit. R/O PMA/PM present The block always returns 0 for this bit. R/O Clause 22 device present The block always returns 0 for this bit. R/O 0 LogiCORE RXAU v

49 Chapter 2: Product Specification MO Register 4.8: PHY XS Status 2 Figure 2-34 shows the MO Register 4.8: PHY XS Status 2. X-Ref Target - Figure 2-34 Figure 2-34: PHY XS Status 2 Register Table 2-47 shows the PHY XS Status 2 register bit definitions. Table 2-47: PHY XS Status 2 Register Bit efinitions Bit(s) Name escription Attributes efault Value :14 evice present The block always returns 10. R/O :12 Reserved The block always returns 0 for these bits. R/O All 0s Transmit local fault Receive local fault 1 = Fault condition on transmit path 0 = No fault condition on transmit path 1 = Fault condition on receive path 0 = No fault condition on receive path R/O Latching High R/O Latching High 4.8.9:0 Reserved The block always returns 0 for these bits. R/O All 0s - - LogiCORE RXAU v

50 Chapter 2: Product Specification MO Registers 4.14 and 4.15: PHY XS Package dentifier Figure 2-35 shows the MO 4.14 and 4.15 Registers: PHY XS Package dentifier. X-Ref Target - Figure 2-35 Figure 2-35: PHY XS Package dentifier Registers Table 2-48 shows the Package dentifier registers bit definitions. Table 2-48: Package dentifier Registers Bit efinitions Bit(s) Name escription Attributes efault Value :0 PHY XS Package dentifier :0 PHY XS Package dentifier The block always returns 0 for these bits. R/O All 0s The block always returns 0 for these bits. R/O All 0s LogiCORE RXAU v

51 Chapter 2: Product Specification MO Register 4.24: 10G PHY XGXS Lane Status Figure 2-36 shows the MO Register 4.24: 10G XGXS Lane Status. X-Ref Target - Figure 2-36 Figure 2-36: 10G PHY XGXS Lane Status Register Table 2-49 shows the 10G PHY XGXS Lane register bit definitions. Table 2-49: 10G PHY XGXS Lane Status Register Bit efinitions Bit(s) Name escription Attributes efault Value :13 Reserved The block always returns 0 for these bits. R/O All 0s PHY XGXS Lane Alignment Status Pattern Testing Ability 1 = PHY XGXS receive lanes aligned 0 = PHY XGXS receive lanes not aligned. RO - The block always returns 1 for this bit. R/O :4 Reserved The block always returns 0 for these bits. R/O All 0s Lane 3 Sync 1 = Lane 3 is synchronized 0 = Lane 3 is not synchronized Lane 2 Sync 1 = Lane 2 is synchronized 0 = Lane 2 is not synchronized Lane 1 Sync 1 = Lane 1 is synchronized 0 = Lane 1 is not synchronized Lane 0 Sync 1 = Lane 0 is synchronized 0 = Lane 0 is not synchronized. R/O - R/O - R/O - R/O - LogiCORE RXAU v

52 Chapter 2: Product Specification MO Register 4.25: 10G PHY XGXS Test Control Figure 2-37 shows the MO Register 4.25: 10G XGXS Test Control. X-Ref Target - Figure 2-37 Figure 2-37: 10G PHY XGXS Test Control Register Table 2-50 shows the 10G PHY XGXS Test Control register bit definitions. Table 2-50: 10G PHY XGXS Test Control Register Bit efinitions Bit(s) Name escription Attributes efault Value :3 Reserved The block always returns 0 for these bits. R/O All 0s Transmit Test Pattern Enable :0 Test Pattern Select 1 = Transmit test pattern enable 0 = Transmit test pattern disabled 11 = Reserved 10 = Mixed frequency test pattern 01 = Low frequency test pattern 00 = High frequency test pattern R/W 0 R/W 00 LogiCORE RXAU v

53 Chapter 2: Product Specification Configuration and Status Vectors f the RXAU core is generated without an MO interface, the key configuration and status information is carried on simple bit vectors, which are: configuration_vector[6:0] status_vector[7:0] Table 2-51 shows the Configuration Vector bit definitions. Table 2-51: Configuration Vector Bit efinitions Bit(s) Name escription 0 Loopback Sets serial loopback in the device-specific transceivers. See bit in Table 2-32, page Power own Sets the device-specific transceivers into power down mode. See bit in Table 2-32, page Reset Local Fault Clears both TX Local Fault and RX Local Fault bits (status_vector[0] and status_vector[1]). See Table This bit should be driven by a register on the same clock domain as the RXAU core. 3 Reset Rx Link Status Sets the RX Link Status bit (status_vector[7]). See Table This bit should be driven by a register on the same clock domain as the RXAU core. 4 Test Enable Enables transmit test pattern generation. See bit in Table 2-40, page 43. 6:5 Test Select(1:0) Selects the test pattern. See bits :0 in Table 2-40, page 43. Table 2-52 shows the Status Vector bit definitions. Table 2-52: Status Vector Bit efinitions Bit(s) Name escription 0 Tx Local Fault 1 if there is a fault in the transmit path, otherwise 0. See bit in Table 2-37, page 40. Latches High. Cleared by rising edge on configuration_vector[2]. 1 Rx Local Fault 1 if there is a fault in the receive path, otherwise 0. See bit in Table 2-37, page 40. Latches High. Cleared by rising edge on configuration_vector[2]. 5:2 Synchronization Each bit is 1 if the corresponding RXAU lane is synchronized on receive, otherwise 0. See bits :0 in Table 2-38, page 41. These four bits are also used to generate the sync_status[3:0] signal described in Table Alignment 1 if the RXAU receiver is aligned over all four logical XAU lanes, otherwise 0. See bit in Table 2-38, page 41. This is also used to generate the align_status signal described in Table Rx Link Status 1 if the Receiver link is up, otherwise 0. See bit in Table 2-33, page 37. Latches Low. Cleared by rising edge on configuration_vector[3]. LogiCORE RXAU v

54 Chapter 2: Product Specification Bits 0 and 1 of the status_vector port, the Local Fault bits, are latching-high and cleared low by bit 2 of the configuration_vector port. Figure 2-38 shows how the status bits are cleared. X-Ref Target - Figure 2-38 Figure 2-38: Clearing the Local Fault Status Bits Bit 7 of the status_vector port, the RX Link Status bit, is latching-low and set high by bit 3 of the configuration vector. Figure 2-39 shows how the status bit is set. X-Ref Target - Figure 2-39 Figure 2-39: Setting the RX Link Status Bit Alignment and Synchronization Status Ports n addition to the configuration and status interfaces described in the previous section, there are always available two output ports signalling the alignment and synchronization status of the receiver. (Table 2-53.) Table 2-53: Port Name Alignment Status and Synchronization Status Ports escription align_status 1 when the RXAU receiver is aligned across all four XAU logical lanes, 0 otherwise. sync_status[3:0] Each pin is 1 when the respective XAU logical lane receiver is synchronized to byte boundaries, 0 otherwise. LogiCORE RXAU v

55 Chapter 3 esigning with the Core This chapter includes guidelines and additional information to facilitate designing with the core. General esign Guidelines This section describes the steps required to turn a RXAU core into a fully-functioning design with user-application logic. t is important to realize that not all implementations require all of the design steps listed in this chapter. Follow the logic design guidelines in this manual carefully. Use the Example esign as a Starting Point Each instance of the RXAU core is delivered with an example design that can be implemented in an FPGA and simulated. This design can be used as a starting point for your own design or can be used to sanity-check your application in the event of difficulty. See Chapter 6, etailed Example esign (Vivado esign Suite) and Chapter 9, etailed Example esign (SE esign Suite) for information about using and customizing the example designs for the RXAU core. Know the egree of ifficulty RXAU designs are challenging to implement in any technology, and the degree of difficulty is further influenced by: Maximum system clock frequency Targeted device architecture Nature of your application All RXAU implementations need careful attention to system performance requirements. Pipelining, logic mapping, placement constraints, and logic duplication are all methods that help boost system performance. LogiCORE RXAU v

56 Chapter 3: esigning with the Core Keep t Registered To simplify timing and increase system performance in an FPGA design, keep all inputs and outputs registered between your application and the core. This means that all inputs and outputs from your application should come from, or connect to a flip-flop. While registering signals might not be possible for all paths, it simplifies timing analysis and makes it easier for the Xilinx tools to place and route the design. Recognize Timing Critical Signals The UCF provided with the example design for the core identifies the critical signals and the timing constraints that should be applied. See Chapter 5, Constraining the Core (Vivado esign Suite or Chapter 9, etailed Example esign (SE esign Suite) for further information. Use Supported esign Flows Vivado esign Tools The core HL is added to the open Vivado project. Later the core is synthesized along with the rest of the project as part of project synthesis. SE esign Tools The core is synthesized in the CORE Generator tool and is delivered to you as an NGC netlist. The example implementation scripts provided currently use Xilinx Synthesis Technology (XST) as the synthesis tool for the HL example design that is delivered with the core. Other synthesis tools can be used for your application logic; the core is always unknown to the synthesis tool and appears as a black box. Post synthesis, only Xilinx SE esign Suite v14.3 tools are supported. Make Only Allowed Modifications The RXAU core is not user-modifiable. o not make modifications as they can have adverse effects on system timing and protocol compliance. Supported user configurations of the RXAU core can only be made by selecting the options from within the Vivado esign Suite or CORE Generator tool when the core is generated. See Chapter 4, Customizing and Generating the Core (Vivado esign Suite) or Chapter 7, Customizing and Generating the Core (SE esign Suite). LogiCORE RXAU v

57 Chapter 3: esigning with the Core Clocking The clocking schemes in this section are illustrative only and might require customization for a specific application. See Table 2-10 for information on the clock ports. Reference Clock The transceivers typically use a reference clock of MHz to operate at a line rate of 6.25 Gb/s. Transceiver Placement Common to all schemes shown is that a single BUFS_GTXE1 (Virtex-6 FPGA) or BUFS_GTE2 (7 series FPGAs) is used to feed the reference clocks for all transceivers. n addition, timing requirements are more easily met if both transceivers are placed next to each other. For details about transceiver clock distribution, see the section on Clocking in the Virtex-6 FPGA GTX Transceivers User Guide [Ref 9], the 7 Series FPGAs GTX/GTH Transceivers User Guide [Ref 10] and the 7 Series FPGAs GTP Transceivers User Guide [Ref 11]. une Networks RXAU (7 Series FPGAs) The clocking scheme for 7 Series GTX transceivers is as shown in Figure 3-1. The transceiver primitives require a MHz clock. The MHz clock is used as the clock for the netlist part of the RXAU core and is typically also used for your logic. A dedicated clock is used by the transceivers. The example design uses a 50 MHz clock. Choosing a different frequency might allow sharing of clock resources. See the 7 Series FPGAs GTX/GTH Transceivers User Guide [Ref 10] and the 7 Series FPGAs GTP Transceivers User Guide [Ref 11] for details about this clock. LogiCORE RXAU v

58 Chapter 3: esigning with the Core X-Ref Target - Figure 3-1 Figure 3-1: Clock Scheme for une Networks RXAU: 7 Series GTX Transceivers X-Ref Target - Figure 3-2 Figure 3-2: Clock Scheme for une Networks RXAU: 7 Series GTH Transceivers LogiCORE RXAU v

59 Chapter 3: esigning with the Core X-Ref Target - Figure 3-3 Figure 3-3: Clock Scheme for une Networks RXAU: 7 Series GTP Transceivers une Networks RXAU (Virtex-6 LXT/SXT/HXT FPGAs) The clocking scheme is shown in Figure 3-4. The GTX transceiver primitives require a MHz clock and a MHz clock. The MHz clock is used as the clock for the netlist part of the RXAU core and is typically also used for your logic. A dedicated clock is used by the GTX transceivers. The example design uses a 50 MHz clock. Choosing a different frequency allows sharing of clock resources. See the Virtex-6 FPGA GTX Transceivers User Guide [Ref 9] for details about this clock. Note: For the Virtex-6 FPGA GTX transceiver, the MMCM must be located in the same clock region as the GTX transceiver. See Virtex-6 FPGA MMCM Restrictions. LogiCORE RXAU v

60 Chapter 3: esigning with the Core X-Ref Target - Figure 3-4 Figure 3-4: Clock Scheme for une Networks RXAU: Virtex-6 LXT/SXT/XHT FPGAs Marvell RXAU (7 Series FPGAs) The transceivers require a MHz clock this is used to clock the transmit part of the transceiver (Figure 3-5). The MHz clock is used as the clock for the netlist part of the RXAU core and is typically also used for your logic. The RXAU core also uses the recovered clock from the transceivers to clock the receive path. This is connected to the core using a BUFH. A dedicated clock is used by the transceivers. The example design uses a 50 MHz clock. Choosing a different frequency might allow sharing of clock resources. See the 7Series FPGAs GTX/GTP Transceivers User Guide [Ref 10] and the 7 Series FPGAs GTP Transceivers User Guide [Ref 11] for details about this clock. LogiCORE RXAU v

61 Chapter 3: esigning with the Core X-Ref Target - Figure 3-5 Figure 3-5: Clock Scheme for Marvell RXAU: 7 Series GTX Transceivers X-Ref Target - Figure 3-6 Figure 3-6: Clock Scheme for Marvell RXAU: 7 Series GTH Transceivers LogiCORE RXAU v

62 Chapter 3: esigning with the Core X-Ref Target - Figure 3-7 Figure 3-7: Clock Scheme for Marvell RXAU: 7 Series GTP Transceivers Marvell nternal Client-Side nterface (Virtex-6 LXT/SXT/HXT FPGAs) The GTX transceivers require a MHz clock and a MHz clock. n Marvell mode this is used to clock the transmit part of the transceiver (Figure 3-8). The MHz clock is used as the clock for the netlist part of the RXAU core and is typically also used for your logic. The RXAU core also uses the recovered clock from the GTX transceivers to clock the receive path. This is connected to the core through a BUFR. A dedicated clock is used by the GTX transceivers. The example design uses a 50 MHz clock. Choosing a different frequency might allow sharing of clock resources. See the Virtex-6 FPGA GTX Transceivers User Guide [Ref 9] and the 7 Series FPGAs GTX/GTH Transceivers User Guide [Ref 10] for details about this clock. Note: For the Virtex-6 FPGA GTX transceiver, the MMCM must be located in the same clock region as the GTX transceiver. See Virtex-6 FPGA MMCM Restrictions. LogiCORE RXAU v

63 Chapter 3: esigning with the Core X-Ref Target - Figure 3-8 Figure 3-8: Clock Scheme for Marvell RXAU: Virtex-6 LXT/SXT/HXT FPGAs Virtex-6 FPGA MMCM Restrictions GTX TXOUTCLK must drive the MMCM directly with no BUFG in the path. By default, in the wrapper, TXOUTCLK already drives the MMCM directly with no BUFG in the path. This means that the MMCM is restricted to the same region as the GTX transceiver and you must not add a BUFG to move the MMCM out of the region. Each GTX Quad spans an entire clocking region and there are two available MMCMs per clocking region; the MMCM used must be constrained to the same clock region otherwise a BUFG is automatically inserted. These locations can be determined using the Virtex-6 FPGA Packaging and Pinout Specifications [Ref 12]. Resets See Table 2-10 for information on the reset ports. All register resets within the RXAU core netlist are synchronous to the usrclk port. LogiCORE RXAU v

64 Chapter 3: esigning with the Core esign Considerations This section describes considerations that can apply in particular design cases. Multiple Core nstances To instantiate multiple cores, instantiate the RXAU block level component multiple times. The clocking resources can be shared between multiple instances. See the Virtex-6 FPGA GTX Transceivers User Guide [Ref 9] and the 7 Series FPGAs GTX/GTH Transceivers User Guide [Ref 10] for details on sharing the reference clock and any limitations. n Virtex-7 and Kintex-7 devices, the reference clock can be shared from a neighboring quad. Logic clocks cannot be shared between core instances with the supplied design. The USRCLKs on each core and quad of transceivers must be sourced from the TXOUTCLK port of that quad. Some modification of the example design is required to enable the GTXE2_COMMON to be shared between two instances of the RXAU core. Receiver Termination: Virtex-7 and Kintex-7 FPGAs See the 7 Series FPGAs GTX/GTH Transceivers User Guide [Ref 10] and the 7 Series FPGAs GTP Transceivers User Guide [Ref 11]. Receiver Termination: Virtex-6 FPGAs The receiver termination must be set correctly. The default setting is 2/3 VTTRX. See the Virtex-6 FPGA GTX Transceivers User Guide [Ref 9]. Protocol escription ata nterface: nternal nterfaces nternal 64-bit SR Client-side nterface The 64-bit single-data rate (SR) client-side interface is based upon the 32-bit XGM-like interface. The bus is demultiplexed from 32- bits wide to 64-bits wide on a single rising clock edge. This demultiplexing is done by extending the bus upwards so that there are now eight lanes of data numbered 0-7; the lanes are organized such that data appearing on lanes 4 7 is transmitted or received later in time than that in lanes 0-3. LogiCORE RXAU v

65 Chapter 3: esigning with the Core The mapping of lanes to data bits is shown in Table 3-1. The lane number is also the index of the control bit for that particular lane; for example, XGM_TXC[2] and XGM_TX[23:16] are the control and data bits respectively for lane 2. Table 3-1: efinitions of Control Characters Reference is regularly made to certain XGM control characters signifying Start, Terminate, Error and others. These control characters all have in common that the control line for that lane is 1 for the character and a certain data byte value. The relevant characters are defined in the EEE Std and are reproduced in Table 3-2 for reference. Table 3-2: Lane XGM_TX, XGM_RX Lanes for nternal 64-bit Client-Side nterface nterfacing to the Transmit Client nterface nternal 64-bit Client-Side nterface XGM_TX, XGM_RX Bits 0 7:0 1 15:8 2 23: : : : : :56 Partial list of XGM Characters ata (Hex) Control Name, Abbreviation 00 to FF 0 ata () 07 1 dle () FB 1 Start (S) F 1 Terminate (T) FE 1 Error (E) The timing of a data frame transmission using the internal 64-bit client-side interface is shown in Figure 3-9. The beginning of the data frame is shown by the presence of the Start character (the /S/ codegroup in lane 4 of Figure 3-9) followed by data characters in lanes 5, 6, and 7. Alternatively the start of the data frame can be marked by the occurrence of a Start character in lane 0, with the data characters in lanes 1 to 7. LogiCORE RXAU v

66 Chapter 3: esigning with the Core When the frame is complete, it is completed by a Terminate character (the T in lane 1 of Figure 3-9). The Terminate character can occur in any lane; the remaining lanes are padded by XGM idle characters. X-Ref Target - Figure 3-9 usrclk xgmii_txd[7:0] xgmii_txd[15:8] T xgmii_txd[23:16] xgmii_txd[31:24] xgmii_txd[39:32] S xgmii_txd[47:40] xgmii_txd[55:48] xgmii_txd[63:56] xgmii_txc[7:0] FF 1F FE FF Figure 3-9: Normal Frame Transmission Across the nternal 64-bit Client-Side /F LogiCORE RXAU v

67 Chapter 3: esigning with the Core Figure 3-10 depicts a similar frame to that in Figure 3-9, with the exception that this frame is propagating an error. The error code is denoted by the letter E, with the relevant control bits set. X-Ref Target - Figure 3-10 usrclk xgmii_txd[7:0] E xgmii_txd[15:8] E xgmii_txd[23:16] E xgmii_txd[31:24] E xgmii_txd[39:32] S xgmii_txd[47:40] T xgmii_txd[55:48] xgmii_txd[63:56] xgmii_txd[7:0] FF 1F 00 0F E0 FF Figure 3-10: Frame Transmission with Error Across nternal 64-bit Client-Side /F LogiCORE RXAU v

68 Chapter 3: esigning with the Core nterfacing to the Receive Client nterface nternal 64-Bit Client-Side nterface The timing of a normal inbound frame transfer is shown in Figure As in the transmit case, the frame is delimited by a Start character (S) and by a Terminate character (T). The Start character in this implementation can occur in either lane 0 or in lane 4. The Terminate character, T, can occur in any lane. X-Ref Target - Figure 3-11 usrclk xgmii_rxd[7:0] S xgmii_rxd[15:8] xgmii_rxd[23:16] xgmii_rxd[31:24] T xgmii_rxd[39:32] E xgmii_rxd[47:40] E xgmii_rxd[55:48] E xgmii_rxd[63:56] E xgmii_rxc[7:0] FF F0 00 F8 FF Figure 3-11: Frame Reception Across the nternal 64-bit Client nterface LogiCORE RXAU v

69 Chapter 3: esigning with the Core Figure 3-12 shows an inbound frame of data propagating an error. n this instance, the error is propagated in lanes 4 to 7, shown by the letter E. X-Ref Target - Figure 3-12 usrclk xgmii_rxd[7:0] S xgmii_rxd[15:8] xgmii_rxd[23:16] xgmii_rxd[31:24] T xgmii_rxd[39:32] E xgmii_rxd[47:40] E xgmii_rxd[55:48] E xgmii_rxd[63:56] E xgmii_rxc[7:0] FF F0 00 F8 FF Figure 3-12: Frame Reception with Error Across the nternal 64-bit Client nterface MO nterface The Management ata nput/output (MO) interface is a simple, low-speed 2-wire interface for management of the RXAU core consisting of a clock signal and a bidirectional data signal. t is defined in clause 45 of EEE Standard An MO bus in a system consists of a single Station Management (STA) master management entity and several MO Managed evice (MM) slave entities. Figure 3-13 illustrates a typical system. All transactions are initiated by the STA entity. The RXAU core implements an MM. LogiCORE RXAU v

70 Chapter 3: esigning with the Core X-Ref Target - Figure 3-13 f implemented, the MO interface is implemented as four unidirectional signals. These can be used to drive a 3-state buffer either in the FPGA SelectO interface buffer or in a separate device. The type_sel port is registered into the core at FPGA configuration and core hard reset; changes after that time are ignored by the core. Table 3-3 shows the mapping of the type_sel setting to the implemented register map. The prtad[4:0] port sets the port address of the core instance. Multiple instances of the same core can be supported on the same MO bus by setting the prtad[4:0] to a unique value for each instance; the RXAU core ignores transactions with the PRTA field set to a value other than that on its prtad[4:0] port. MO Transactions The MO interface should be driven from a STA master according to the protocol defined in EEE Std An outline of each transaction type is described in the following sections. n these sections, these abbreviations apply: PRE: preamble ST: start OP: operation code PRTA: port address EVA: device address TA: turnaround Figure 3-13: A Typical MO-Managed System Table 3-3: Mapping of type_sel Port Settings to MO Register Type type_sel setting MO Register escription 00 or 01 10GBASE-X PCS/PMA When driving a 10GBASE-X PHY 10 TE XGXS When connected to a 10GMAC through XGM 11 PHY XGXS When connected to a PHY through XGM LogiCORE RXAU v

71 Chapter 3: esigning with the Core Set Address Transaction Figure 3-14 shows an Address transaction defined by OP=00. Set Address is used to set the internal 16-bit address register of the RXAU core for subsequent data transactions (called the current address in the following sections). X-Ref Target - Figure 3-14 STA drives MO mdc mdio Z Z LE P4 P3 P2 P1 P0 V4 V3 V2 V1 V Z bits PRE Write Transaction ST OP PRTA EVA TA 16-bit ARESS Figure 3-14: MO Set Address Transaction Figure 3-15 shows a Write transaction defined by OP=01. The RXAU core takes the 16-bit word in the data field and writes it to the register at the current address. Z LE UG693_05_06_ X-Ref Target - Figure 3-15 STA drives MO mdc mdio Z Z LE P4 P3 P2 P1 P0 V4 V3 V2 V1 V Z bits PRE Read Transaction ST OP PRTA EVA TA 16-bit WRTE ATA Figure 3-15: MO Write Transaction Figure 3-16 shows a Read transaction defined by OP=11. The RXAU core returns the 16-bit word from the register at the current address. Z LE UG693_05_07_ X-Ref Target - Figure 3-16 STA drives MO MM drives MO mdc mdio Z Z LE P4P3P2P1P0V4V3V2V1V0 Z Z bits PRE ST OP PRTA EVA TA 16-bit REA ATA Figure 3-16: MO Read Transaction Z LE LogiCORE RXAU v

72 Chapter 3: esigning with the Core Post-Read-increment-address Transaction Figure 3-17 shows a Post-read-increment-address transaction, defined by OP=10. The RXAU core returns the 16-bit word from the register at the current address then increments the current address. This allows sequential reading or writing by a STA master of a block of register addresses. X-Ref Target - Figure 3-17 STA drives MO MM drives MO mdc mdio Z Z LE P4 P3 P2 P1 P0 V4 V3 V2 V1 V0 Z Z bits PRE ST OP PRTA EVA TA 16-bit REA ATA Z LE Figure 3-17: MO Read-and-increment Transaction For detail on the MO registers, see MO nterface Registers. LogiCORE RXAU v

73 SECTON : VVAO ESGN SUTE Customizing and Generating the Core Constraining the Core etailed Example esign LogiCORE RXAU v

74 Chapter 4 Customizing and Generating the Core This chapter includes information about using Xilinx tools to customize and generate the core in the Vivado esign Suite environment. GU Figure 4-1 displays the main screen for customizing the RXAU core. X-Ref Target - Figure 4-1 Figure 4-1: RXAU Main Screen For general help with starting and using the Vivado GU, see the documentation supplied with the Vivado esign Suite. LogiCORE RXAU v

75 Chapter 4: Customizing and Generating the Core Component Name The component name is used as the base name of the output files generated for the core. Names must begin with a letter and must be composed from the following characters: a through z, 0 through 9 and _ (underscore). RXAU Mode This option selects between the three different RXAU implementations that are supported. n une mode, deinterleaving is performed on the A A double character that is received. n 'Marvell' mode multiplexing of the lanes is done to preserve 8B/10B disparity on the XAU logical lanes. This means that the deinterleaving must be performed prior to any other processing. 8B/10B, deskew, and clock correction are all performed within the core. MO Management Select this option to implement the MO interface for managing the core. eselect the option to remove the MO interface and expose a simple bit vector to manage the core. The default is to implement the MO interface. Output Generation The core has various selectable output products. These can be generated by right-clicking on the customized piece of P in the Sources window. Examples - Source HL and constraints for the example project Simulation - Simulation source files Synthesis - Synthesis source files Examples Simulation - Test bench for the example design nstantiation Template - Example instantiation template for the core level module. Miscellaneous - Simulation scripts and support files required for running netlist based functional simulation. The files delivered as part of this filegroup are not used or understood by Vivado tools. These files are delivered into the project source directory. LogiCORE RXAU v

76 Chapter 5 Constraining the Core This chapter is applicable to the Vivado esign Suite environment. This chapter describes how to constrain a design containing the RXAU core. This is illustrated by the XC delivered with the core at generation time. See Chapter 6, etailed Example esign, for a complete description of the Vivado esign Suite output files. Caution! Not all constraints are relevant to specific implementations of the core; consult the XC created with the core instance to see exactly what constraints are relevant. Required Constraints This section defines the constraint requirements for the core. Constraints are provided with an XC file. An XC is provided with the HL example design to give a starting point for constraints for the user design. The following constraints are required. f the MO interface is enabled, it should be constrained to 2.5 MHz. set_max_delay from [get_cells -hierarchical -filter {NAME =~rxaui_block/ rxaui_core/u0/rxaui_inst/xaui_i/*management_1/mdio_interface_1/*_reg*}] -to [get_cells -hierarchical -filter {NAME =~rxaui_block/rxaui_core/u0/rxaui_inst/ xaui_i/*management_1/*_reg*}] set_max_delay from [get_cells -hierarchical -filter {NAME =~rxaui_block/ rxaui_core/u0/rxaui_inst/xaui_i/*management_1/mdio_interface_1/*_reg*}] -to [get_cells -hierarchical -filter {NAME =~rxaui_block/rxaui_core/u0/rxaui_inst/ xaui_i/*management_1/mdio_interface_1/*_reg*}] LogiCORE RXAU v

77 Chapter 5: Constraining the Core Clock Frequencies A constraint is required to specify a MHz clock. This is typically sourced from the TXOUTCLK_OUT port on the transceiver. create_clock -name TXOUTCLK_OUT -period [get_pins rxaui_block/gt_wrapper_i/ gt0_<componentname>_gt_wrapper_i/gtxe2_i/txoutclk] Recovered Clock (Marvell Mode) create_clock -name RXOUTCLK_OUT -period [get_pins rxaui_block/gt_wrapper_i/ gt0_<componentname>_gt_wrapper_i/gtxe2_i/rxoutclk] General Clocking f used, CLK should also be specified: create_clock -name dclk -period [get_ports dclk] This constraint defines the frequency of CLK that is supplied to the transceivers. The example design uses a nominal 50 MHz clock. Specify the clocks as asynchronous: set_clock_groups -group [get_clocks dclk] -group [get_clocks RXOUTCLK_OUT] -asynchronous set_clock_groups -group [get_clocks TXOUTCLK_OUT] -group [get_clocks RXOUTCLK_OUT] -asynchronous set_clock_groups -group [get_clocks RXOUTCLK_OUT] -group [get_clocks TXOUTCLK_OUT] -asynchronous Clock Management The une Networks RXAU core has one clock domain: The refclk domain derived from the TXOUTCLK output of the GTX/GTH transceiver The Marvell core has two clock domains: The refclk domain derived from the TXOUTCLK output of the GTX/GTH transceiver The rxclk domain derived from a single recovered clock output of a transceiver LogiCORE RXAU v

78 Chapter 5: Constraining the Core Transceiver Placement 7 Series GTH Transceivers set_property LOC GTHE2_CHANNEL_X0Y0 [get_cells rxaui_block/gt_wrapper_i/ gt0_<componentname>_gt_wrapper_i/gthe2_i] set_property LOC GTHE2_CHANNEL_X0Y1 [get_cells rxaui_block/gt_wrapper_i/ gt1_<componentname>_gt_wrapper_i/gthe2_i] 7 Series GTX Transceivers set_property LOC GTXE2_CHANNEL_X0Y0 [get_cells rxaui_block/gt_wrapper_i/ gt0_<componentname>_gt_wrapper_i/gtxe2_i] set_property LOC GTXE2_CHANNEL_X0Y1 [get_cells rxaui_block/gt_wrapper_i/ gt1_<componentname>_gt_wrapper_i/gtxe2_i] These constraints lock down the placement of the transceivers. 7 Series GTP Transceivers set_property LOC GTPE2_CHANNEL_X0Y0 [get_cells rxaui_block/gt_wrapper_i/ gt0_<componentname>_gt_wrapper_i/gtpe2_i] set_property LOC GTPE2_CHANNEL_X1Y0 [get_cells rxaui_block/gt_wrapper_i/ gt1_<componentname>_gt_wrapper_i/gtpe2_i] MO f the MO interface is enabled, it should be constrained to 2.5 MHz. set_max_delay from [get_cells -hierarchical -filter {NAME =~ rxaui_block/rxaui_core/u0/rxaui_inst/xaui_i/*management_1/mdio_interface_1/*_reg*}] -to [get_cells -hierarchical -filter {NAME =~ rxaui_block/rxaui_core/u0/rxaui_inst/xaui_i/*management_1/*_reg*}] set_max_delay from [get_cells -hierarchical -filter {NAME =~ rxaui_block/rxaui_core/u0/rxaui_inst/xaui_i/*management_1/mdio_interface_1/*_reg*}] -to [get_cells -hierarchical -filter {NAME =~ rxaui_block/rxaui_core/u0/rxaui_inst/xaui_i/*management_1/mdio_interface_1/*_reg*}] LogiCORE RXAU v

79 Chapter 6 etailed Example esign This chapter provides detailed information about the example design, including a description of the files and the directory structure generated by the Xilinx Vivado esign Suite, the purpose and contents of the provided scripts, the contents of the example HL wrappers, and the operation of the demonstration test bench. Example esign Figure 6-1 illustrates the default configuration of the example design. X-Ref Target - Figure 6-1 Figure 6-1: RXAU Example esign and Test Bench: efault Configuration LogiCORE RXAU v

80 Chapter 6: etailed Example esign The RXAU example design consists of the following: Clock management logic and Clock Buffer nstances Re-timing registers on the parallel data interface, both on inputs and outputs An instance of the 'block' level module which contains the core, transceiver wrappers and associated logic. The RXAU esign Example has been tested with Xilinx Vivado esign Suite, Mentor Graphics ModelSim, Cadence ES, and Synopsys (the versions of these tools are available in the Xilinx esign Tools: Release Notes Guide. emonstration Test Bench n Figure 6-2, the demonstration test bench is a simple VHL or Verilog program to exercise the example design and the core itself. This test bench consists of transactor procedures or tasks that connect to the major ports of the example design, and a control program that pushes frames of varying length and content through the design and checks the values as they exit the core. The test bench is supplied as part of the Example Simulation output product group. X-Ref Target - Figure 6-2 Figure 6-2: emonstration Test Bench for RXAU LogiCORE RXAU v

81 Chapter 6: etailed Example esign mplementation To implement the example design, select Run mplementation in the Vivado Project Manager window. For further details on setting up the implementation, see the Vivado esign Suite User Guide, mplementation [Ref 6]. Simulation To simulate the example design, select Run Simulation in the Vivado Project Manager window. For further details on setting up the implementation, see the Vivado esign Suite User Guide, esigning with P [Ref 7]. LogiCORE RXAU v

82 SECTON : SE ESGN SUTE Customizing and Generating the Core Constraining the Core etailed Example esign LogiCORE RXAU v

83 Chapter 7 Customizing and Generating the Core This chapter includes information about using Xilinx tools to customize and generate the core in the SE esign Suite environment. GU Figure 7-1 displays the main screen for customizing the RXAU core. X-Ref Target - Figure 7-1 Figure 7-1: RXAU Main Screen For general help with starting and using the CORE Generator GU, see the documentation supplied with the SE esign Suite. LogiCORE RXAU v

84 Chapter 7: Customizing and Generating the Core Component Name The component name is used as the base name of the output files generated for the core. Names must begin with a letter and must be composed from the following characters: a through z, 0 through 9 and _ (underscore). RXAU Mode This option selects between the three different RXAU implementations that are supported. n une mode, deinterleaving is performed on the A A double character that is received. n 'Marvell' mode multiplexing of the lanes is done to preserve 8B/10B disparity on the XAU logical lanes. This means that the deinterleaving must be performed prior to any other processing. 8B/10B, deskew, and clock correction are all performed within the core. MO Management Select this option to implement the MO interface for managing the core. eselect the option to remove the MO interface and expose a simple bit vector to manage the core. The default is to implement the MO interface. Parameter Values in the XCO File XCO files contain parameterization information for an instance of a core; an XCO file is created when a core is generated and can be used to recreate a core. The text in an XCO file is case-insensitive. Table 7-1 shows the XCO file parameters and values, and summarizes the GU defaults. This is an example extract from an XCO file: SELECT RXAU family Xilinx,_nc. 2.4 CSET component_name = the_core CSET rxaui_mode = une CSET mdio_management = true GENERATE Table 7-1: XCO File Values and efaults Parameter XCO File Values efaults component_name ASC text starting with a letter and based upon the following character set: a...z, and _ rxaui_v2_4 mdio_management TRUE, FALSE TRUE rxaui_mode une and Marvell une LogiCORE RXAU v

85 Chapter 7: Customizing and Generating the Core Output Generation The output files generated from CORE Generator are placed in the project directory. The list of output files includes: The netlist files for the core XCO files Release notes and documentation An HL example design Scripts to synthesize, implement and simulate the example design. See the Chapter 6, etailed Example esign for a complete description of the CORE Generator output files and for details of the HL example design. Pre-implementation Simulation A unit delay gate-level model of the RXAU core netlist is provided as a CORE Generator output file. This can be used for simulation of the block in the design phase of a project. Using the Simulation Model For information about setting up your simulator to use the gate-level model, consult the Xilinx SE Synthesis and Simulation esign Guide [Ref 4], included in your Xilinx software installation. The unit delay gate-level model of the RXAU core can be found in the CORE Generator project directory. etails of the CORE Generator outputs can be found in the Chapter 10, etailed Example esign. VHL component_name.vhd Verilog component_name.v LogiCORE RXAU v

86 Chapter 8 Constraining the Core This chapter is applicable to the SE esign Suite environment. This chapter describes how to constrain a design containing the RXAU core. This is illustrated by the UCF delivered with the core at generation time. See Chapter 9, etailed Example esign, for a complete description of the CORE Generator output files. Caution! Not all constraints are relevant to specific implementations of the core; consult the UCF created with the core instance to see exactly what constraints are relevant. evice, Package, and Speed Grade Selections This line selects the part to be used in the implementation run. Change this line so that it matches the part intended for the final application. # Select the part to be used in the implementation run CONFG PART = xc6vlx240t-ff1156-2; The RXAU core can be implemented in all Virtex -6 LXT/SXT/HXT devices with a speed grade of -2 or higher and all Kintex -7 or Virtex-7 devices. LogiCORE RXAU v

87 Chapter 8: Constraining the Core Clock Frequencies The main clock frequencies for the design are specified as follows: Virtex-7, Kintex-7 and Virtex-6 FPGAs #################################################################### # Clock frequencies and clock management # #################################################################### NET "*txoutclk*" TNM_NET="clk156_top"; TMESPEC "TS_clk156_top" = PERO "clk156_top" MHz; Recovered Clock (Marvell Mode) NET "rxaui_block/rxclk" TNM_NET="rxclk312"; TMESPEC "TS_rxclk312" = PERO "rxclk312" MHz; General Clocking NET "dclk" TNM_NET=CLK_CLK; TMESPEC TS_CLK_CLK = PERO CLK_CLK 50 MHz; This constraint defines the frequency of CLK that is supplied to the Virtex-7, Kintex-7 and Virtex-6 FPGAs transceivers. The example design uses a nominal 50 MHz clock. Clock Management The une Networks RXAU core has one clock domain: The refclk domain derived from the TXOUTCLK output of the transceiver The Marvell core has two clock domains: The refclk domain derived from the TXOUTCLK output of the GTX/GTH transceiver The rxclk domain derived from the RXRECCLK output of the Virtex-6 FPGA GTX transceiver or the RXOUTCLK output of the 7 series transceivers LogiCORE RXAU v

88 Chapter 8: Constraining the Core Transceiver Placement Virtex-7 GTH Transceivers NST rxaui_block/gt_wrapper_i/gt0_<componentname>_gt_wrapper_i/ gthe2_i LOC=GTHE2_CHANNEL_X0Y0 NST rxaui_block/gt_wrapper_i/gt1_<componentname>_gt_wrapper_i/ gthe2_i LOC=GTHE2_CHANNEL_X0Y1 7 Series GTX Transceivers NST rxaui_block/gt_wrapper_i/gt0_<componentname>_gt_wrapper_i/ gtxe2_i LOC=GTXE2_CHANNEL_X0Y0 NST rxaui_block/gt_wrapper_i/gt1_<componentname>_gt_wrapper_i/ gtxe2_i LOC=GTXE2_CHANNEL_X0Y1 These constraints lock down the placement of the transceivers. 7 Series GTP Transceivers NST rxaui_block/gt_wrapper_i/gt0_<componentname>_gt_wrapper_i/ gtpe2_i LOC=GTPE2_CHANNEL_X0Y0 NST rxaui_block/gt_wrapper_i/gt1_<componentname>_gt_wrapper_i/ gtpe2_i LOC=GTPE2_CHANNEL_X1Y0 Virtex-6 LXT/SXT/HXT FPGAs NST rxaui_block/gtx_wrapper_i/gtx0_<componentname>_gtx_wrapper_i/ gtxe1_i LOC=GTXE1_X0Y0 NST rxaui_block/gtx_wrapper_i/gtx1_<componentname>_gtx_wrapper_i/ gtxe1_i LOC=GTXE1_X0Y1 MO ################################################################# # MO-related constraints # ################################################################# NET "*rxaui_core/bu2/u0/xaui_i/*management_1/mdc_rising*" TNM_NET = "rxaui_mdc_grp"; NST "*rxaui_core/bu2/u0/xaui_i/type_sel_reg_1" TNM = FFS "rxaui_mdc_grp"; TMESPEC "TS_RXAU_mdc" = FROM "rxaui_mdc_grp" to "rxaui_mdc_grp" 400 ns; These constraints set the correct attributes for the registers at the edge of the MO block. The TMESPEC constrains the MO interface to 2.5 MHz. f you wish to overclock the MO interface, you must alter this constraint. LogiCORE RXAU v

89 Chapter 9 etailed Example esign This chapter provides detailed information about the example design, including a description of the files and the directory structure generated by the Xilinx CORE Generator tool, the purpose and contents of the provided scripts, the contents of the example HL wrappers, and the operation of the demonstration test bench. irectory and File Contents top directory link - white text invisible <project directory>topdirectory Top-level project directory; name is user-defined. <project directory>/<component name> Core release notes file <component name>/example_design Verilog and VHL design files <component name>/implement mplementation script files implement/results Results directory, created after implementation scripts are run, and contains implement script results <component name>/simulation Simulation scripts simulation/functional Functional simulation files LogiCORE RXAU v

90 Chapter 9: etailed Example esign <project directory> The project directory contains all the CORE Generator project files. Table 9-1: Project irectory Name <project_dir> <component_name>.ngc <component_name>.v[hd] <component_name>.xco <component_name>_flist.txt <component_name>.{veo vho} Back to Top escription A binary Xilinx implementation netlist. escribes how the core is to be implemented. Used as an input to the Xilinx implementation tools. VHL or Verilog structural simulation model. File used to support functional simulation of a core. As an output file, the XCO file is a log file which records the settings used to generate a particular core. An XCO file is generated by CORE Generator for each core that it creates in the current project directory. An XCO file can also be used as an input to CORE Generator. List of files delivered with the core A VHL or Verilog template for the core. This can be copied into your design. <project directory>/<component name> The <component name> directory contains the release notes file provided with the core, which can include last-minute changes and updates. Table 9-2: rxaui_readme.txt Back to Top Component Name irectory Name <project_dir>/<component_name> Core release notes file escription top directory link - white text invisible LogiCORE RXAU v

91 Chapter 9: etailed Example esign <component name>/example_design The example design directory contains the example design files provided with the core. Table 9-3: Example esign irectory Name <component_name>_block.v[hd] <component_name>_example_design.v[hd] component_name>_example_design.ucf <component_name>_mod.v <component_name>_chanbond_monitor.v[hd] <project_dir>/<component_name>/example_design <component_name>_gt[x]_wrapper.v[hd] <component_name>_gt[x]_wrapper_gt[x].v[hd] Back to Top <component name>/implement escription Block entity containing the RXAU core and transceiver wrappers Top-level entity for the example design containing the block level design and clocking circuitry User constraints file for the core and example design Wrapper file for the RXAU core Transceiver Channel Bonding Monitor Wrappers for the transceivers This directory contains the support files necessary for implementation of the example design with the Xilinx tools. Execution of an implement script creates a results directory and an xst project directory. Table 9-4: implement.bat implement.sh xst.scr xst.prj Back to Top mplement irectory Name <project_dir>/<component_name>/implement escription Windows batch file that process the example design through the Xilinx tool flow Linux shell script that processes the example design through the Xilinx tool flow XST script file for the example design XST project file for the example design LogiCORE RXAU v

92 Chapter 9: etailed Example esign implement/results This directory is created by the implement scripts and is used to run the example design files and the <component_name>.ngc file through the Xilinx implementation tools. On completion of an implement script, this directory contains the following files for timing simulation. Output files from the Xilinx implementation tools can also be found in this directory. Table 9-5: Results irectory Name routed.v[hd] routed.sdf Back to Top <component name>/simulation The simulation directory and the subdirectories below it contain the files necessary to test a VHL or Verilog implementation of the example design. Table 9-6: simulation/functional escription <project_dir>/<component_name>/implement/results Simulation irectory Name demo_tb.v[hd] Back to Top The back-annotated SimPrim-based VHL or Verilog design. Used for timing simulation. Timing information for simulation escription <project_dir>/<component_name>/simulation The VHL or Verilog demonstration test bench for the RXAU core The functional directory contains functional simulation scripts provided with the core. Table 9-7: Functional irectory Name simulate_mti.do simulate_ncsim.sh simulate_vcs.sh (verilog only) escription <project_dir>/<component_name>/simulation/functional ModelSim macro file that compiles the example design sources, the structural simulation model and the demonstration test bench then runs the functional simulation to completion. Linux shell script that compiles the example design sources and the structural simulation model then runs the functional simulation to completion using the Cadence ES simulator. Linux shell script that compiles the example design sources and the structural simulation model then runs the functional simulation to completion using VCS. LogiCORE RXAU v

93 Chapter 9: etailed Example esign Table 9-7: ucli_commands.key (verilog only) vcs_session.tcl (verilog only) wave_mti.do wave_ncsim.sv Back to Top Functional irectory (Cont d) Name escription VCS command file. This file is called by the simulate_vcs.sh script. VCS VE tcl script that opens wave windows and adds interesting signals to it. This macro is used by the simulate_vcs.sh script. ModelSim macro file that opens a wave window and adds interesting signals to it. This macro is called by the simulate_mti.do macro file. The Cadence ES simulator macro file that opens a wave windows and adds interesting signals to it. This macro is called by the simulate_ncsim.sh script. Example esign Figure 9-1 illustrates the default configuration of the example design. X-Ref Target - Figure 9-1 Figure 9-1: RXAU Example esign: efault Configuration LogiCORE RXAU v

94 Chapter 9: etailed Example esign The RXAU example design consists of the following: A RXAU core netlist Transceiver wrappers A transceiver transmit initialization block Clock management logic and clock buffer instances Re-timing registers on the parallel data interface, both on inputs and outputs The RXAU esign Example has been tested with Xilinx SE esign Suite, Mentor Graphics ModelSim, Cadence ES, and Synopsys (the versions of these tools are available in the Xilinx esign Tools: Release Notes Guide). emonstration Test Bench n Figure 9-2, the demonstration test bench is a simple VHL or Verilog program to exercise the example design and the core itself. This test bench consists of transactor procedures or tasks that connect to the major ports of the example design, and a control program that pushes frames of varying length and content through the design and checks the values as they exit the core. X-Ref Target - Figure 9-2 Test Bench evice Under Test (UT) XGM-like Stimulus 64-bit /F RXAU RXAU Monitor XGM-like Monitor RXAU Stimulus Control and ata Stuctures Figure 9-2: emonstration Test Bench for RXAU LogiCORE RXAU v

95 Chapter 9: etailed Example esign Generating the Core To generate a RXAU core with default values using the CORE Generator tool perform the following steps: 1. Start CORE Generator. For help starting and using CORE Generator, see the documentation supplied with the SE esign Suite. 2. Choose File > New Project. 3. Type a directory name. 4. Perform these steps to set project options: a. From the Part tab, select a silicon family, part, speed grade, and package that supports the RXAU core, for example, Virtex -6 FPGAs. MPORTANT: f an unsupported silicon family is selected, the RXAU core does not appear in the taxonomy tree. b. From the Generation tab, select VHL or Verilog; for Vendor, select Other. c. On the Advanced tab, accept the default values. 5. After creating the project, locate the core in the taxonomy tree at the left side of the CORE Generator window. The RXAU core appears under these categories: Communications & Networking/Ethernet Communications & Networking/Networking Communications & Networking/Telecommunications 6. ouble-click the core to open it. 7. n the Component Name field, enter a name for the core instance. 8. Accept the remaining default options and click Finish to generate the core. The core and its supporting files, including the example design, are generated in the project directory. For a detailed description of the directory structure and files, see irectory and File Contents. LogiCORE RXAU v

96 Chapter 9: etailed Example esign X-Ref Target - Figure 9-3 Figure 9-3: RXAU Main Screen mplementation After the core is successfully generated, the netlist and example design HL wrapper can be processed through the Xilinx implementation tools. The generated outputs include several scripts to assist in processing. mplementation Script The implementation script is either a shell script or batch file that processes the example design through the Xilinx tool flow. The script is located at: Linux <project_dir>/<component_name>/implement/implement.sh Windows <project_dir>/<component_name>/implement/implement.bat LogiCORE RXAU v