CoreRGMII v2.0. Handbook

CoreRGMII v2.0 Handbook

CoreRGMII v2.0 Handbook Table of Contents Introduction... 3 Core Overview... 3 Core Version... 3 Supported Families... 3 Key Features... 3 Utilization and Performance... 3 Functional Block Description... 4 Management Interface Block... 4 Conversion Block... 5 Protocol Boundaries... 5 Tool Flows... 6 Licensing... 6 SmartDesign... 6 RXC and TXC Clocks... 8 Simulation Flows... 8 Synthesis in Libero SoC... 8 Place-and-Route in Libero SoC... 8 Timing Closure Using SmartTime... 9 Core Interfaces... 16 Core Parameters... 17 Register Map and Descriptions... 18 Appendix 1 - SmartTime Constraints... 19 Ordering Information... 20 Ordering Codes... 20 List of Changes... 21 Product Support... 22 Customer Service... 22 Customer Technical Support Center... 22 Technical Support... 22 Website... 22 Contacting the Customer Technical Support Center... 22 ITAR Technical Support... 23 CoreRGMII v2.0 Handbook 2

Introduction Core Overview Reduced gigabit media independent interface (RGMII) is a standard interface, which helps in reducing the number of signals required to connect a PHY to a MAC. CoreRGMII is responsible for providing the interface between a standard gigabit media independent interface (GMII) to RGMII conversion. The fifteen-signal GMII interface is converted into six-signal RGMII interface by using both edges of the clock. The IP core is compatible with the RGMII specification v2.0 that is designed to support the SmartFusion 2 systemon-chip (SoC) field programmable gate array (FPGA) device family. The SmartFusion2 Ethernet MAC (EMAC) supports IEEE 802.3 10/100/1000 Mbps Ethernet operation. Various configuration parameters or generics are applied to CoreRGMII core. Core Version This handbook supports the CoreRGMII version 2.0. Supported Families Key Features SmartFusion2 CoreRGMII is a configurable core and has the following features: Provides reduced pin-count interface for Ethernet PHYs Provides GMII interface towards the microcontroller subsystem (MSS)-side and RGMII interface on the PHY-side Supports 10/100/1000 Mbps mode operation Configurable parameter to select the default-on-reset line rate 10/100/1000 Mbps Configurable parameter for Core Management Interface Address Supports full-duplex operation at 10/100/1000 and half-duplex at 10/100 Supports "Broadcast" 00000 address capability Utilization and Performance Table 1 provides the utilization and performance data for the SmartFusion2 (M2S050T) device family. The provided data is only indicative. The overall device utilization and performance of the core is system dependent. Table 1 CoreRGMII Device Utilization and Performance Family TRANSFER_SPEED Sequential Logic Elements Combinatorial Total % Performance (MHz) SmartFusion2 (M2S050T) 10/100/1000 123 83 206 0.37 REFCLK = 125 Note: The data in this table was achieved using typical synthesis and layout settings. Frequency (in MHz) was set to 125 and speed grade of -1. CoreRGMII v2.0 Handbook 3

Functional Block Description CoreRGMII consists of two functional blocks the Conversion block and the Management Interface (MI) block, refer to Figure 1. The IP core selects 1000 Mbps, 100 Mbps, or 10 Mbps as default based on the configurable parameter DEF_SPD and subsequently adapts through firmware to the link line speed. RESET_IN_N CLK_RX CLK_TX MAC_GMII_TX_EN MAC_GMII_TX_ER MAC_GMII_RX_ER MAC_GMII_RX_DV MAC_GMII_CRS MAC_GMII_COL Conversion Block TX_CTL TD RX_CTL RD RESETN MAC_GMII_TXD MAC_GMII_RXD GMII_Interface RGMII_Interface MDIO MAC_GMII_MDC MAC_GMII_MDO_EN MAC_GMII_MDO MAC_GMII_MDI MI Block MDI_SPD Management Interface Block Figure 1 CoreRGMII Block Diagram The MI block decodes the MAC <-> CORE MDIO transactions and is used to select an appropriate clock conditioning circuitry (CCC) output for the negotiated line speed. The Core has a default address of 28(0x1C), but can be set from 0 to 31. Note: The use of the management interface block is only required if the link speed is not fixed to a constant value. CoreRGMII v2.0 Handbook 4

Conversion Block Conversion Block The conversion block converts GMII into RGMII using DDRIO and must connect to FPGA ports at the top-level. Protocol Boundaries The MSS Ethernet MAC operates in GMII mode and the PHY operates in RGMII mode. Hence, MAC_GMII_TX_CLK does not get generated by the PHY, but gets generated by Core controlled clock conditioning circuit. MAC_GMII_TX_CLK and MAC_GMII_GTX_CLK are supplied to the MSS by the same clock generated by the CCC. CoreRGMII v2.0 Handbook 5

Tool Flows Licensing CoreRGMII is license free. RTL Complete RTL source code is provided for the core. SmartDesign CoreRGMII is pre-installed in the SmartDesign IP deployment design environment or downloaded from the online repository. Figure 2 shows an example instantiated. The core can be configured using the configuration GUI within SmartDesign, as shown in Figure 3. For more information on using SmartDesign to instantiate and generate cores, refer to the Using DirectCore in Libero System-on-Chip (SoC) User Guide. Figure 2 SmartDesign CoreRGMII Instance View Figure 3 CoreRGMII Configurator CoreRGMII v2.0 Handbook 6

SmartDesign For RGMII, the PHY supplies the receive clock and the MAC supplies the transmit clock. A correctly configured CCC needs to support three line speeds. The core switches between 10, 100, and 1000 Mbps (2.5 MHz, 25 MHz, and 125 MHz respectively) and allows for glitchless clock switching. The CCC is configured as shown in Figure 4 and connected at instantiation hierarchy level as shown in Figure 5. This arrangement is used to minimize delay on the fastest clock speed. Figure 4 CCC Configuration Figure 5 CCC Instantiation Level Wiring In Figure 5: GL2 is fed back into the CLK0 input of the CCC GL0 drives CLK_TX on the core instantiation NGMUX?_ARST_N are connected to system reset NGMUX?_HOLD_N are tied high CoreRGMII v2.0 Handbook 7

Tool Flows The core contains a single RW register to control line speed, which is written by the firmware after the PHY completes auto-negotiation to maintain the correct clock speed selection. Signal MDI[0] (Reflects Configuration Register Bit 13) selects between 25 MHz and 2.5 MHz Connected to NGMUX2_SEL in Figure 5 Signal MDI[1] (which reflects Configuration Register Bit 6) selects between 125 MHz and either [25 MHz 2.5 MHz] Connected to NGMUX0_SEL in Figure 5 MAC_GMII_MDO, MAC_GMII_MDI, MAC_GMII_MDO_EN, and MAC_GMII_MDC connect directly to MSS ports of the same name. MAC_GMII_MDC and MDIO connect to the user PHY. RXC and TXC Clocks To capture the received data from the PHY, ensure that there is a 2 ns delay on the relevant clock. For RXC, this can be achieved using a combination of SmartFusion2 features. The programmable input delay can be used to delay RXC or a GCLKINT can be instantiated to distribute RXC. For the TX path, this can be achieved with the PHY local clock shifting. If this is not available on the user PHY, a second CCC can be used to generate the clock with 2 ns shift for driving the PHY. Simulation Flows There is currently no simulation flow for CoreRGMII. Synthesis in Libero SoC Figure 6 Programmable Input Delay By clicking Synthesis in Libero System-on-Chip (SoC), the Synthesis window displays the Synplicity project. Synplicity must be set for using the Verilog 2001 standard, if Verilog is used. Run must be selected to run Synthesis. Place-and-Route in Libero SoC To invoke Designer, Layout must be selected in the Libero SoC software. CoreRGMII must be run with the following place-and-route settings, refer to Figure 7: Timing Driven High Effort 8 CoreRGMII v2.0 Handbook

Timing Closure Using SmartTime Figure 7 Configuring Place-and-Route Timing Closure Using SmartTime Right-click Verify Timing in the Libero flow and select Open Interactively to invoke SmartTime. Setup and evaluate different timing parameters by using SmartTime interactively. To close the source synchronous timing of CoreRGMII, enable cross clock domain analysis. Refer to Figure 8 and Figure 9. Figure 8 Selecting Options from SmartTime Window CoreRGMII v2.0 Handbook 9

Tool Flows Receive Transmit The receive timing path consists of: PHY clock-to-out timing PCB traces FPGA package and wiring delays Figure 9 Enabling Cross Clock Domain Analysis Receive timing is done with respect to RXC, which is generated by the PHY. Typically, the RD and RX_CTL signals are matched to RXC in PCB traces. However, PHYs might generate these signals within a specified skew tolerance relative to RXC, PCB traces might not be exactly matched and the user might add a manufacturer determined delay to RXC through a PHY register. Therefore, the relative timing of RD and RX_CTL need to be determined with respect to RXC signals as generated by the PHY at the FPGA, prior to using the core, to set the input design constraints. Maximum delay value = maximum data trace delay - minimum clock trace delay + Tskew(PHY) Minimum delay value = maximum clock trace delay - minimum data trace delay -Tskew(PHY) The Transmit timing path consists of: FPGA Clock-to-out timing PCB traces To generate reports to assess timing of the external PHY, the clock needs to be propagated to the device pins using a generated clock, refer to Figure 14. Note: The reference clock in this example design is 50MHz, resulting in the displayed multiplier and divider factors. TD and TX_CTL path differences with respect to TXC and PHY setup and hold time must be accounted for the timing budget through the SmartTime constraints. (SETUP)Output maximum delay value = t SU (PHY) - minimum clock trace + maximum data trace (HOLD)Output minimum delay value = t H (PHY) +minimum data trace - maximum clock trace 10 CoreRGMII v2.0 Handbook

Timing Closure Using SmartTime Timing Constraints Timing constraints are required to allow SmartTime determine if the timing requirements to clocked components external to the FPGA for +ve and ve clocks are met. If constraints are not set, no violations will be reported. The constraints are presented separately in each section, but are gathered together in the appendix for convenience. The relevant section of the SmartTime Constraints Editor GUI is also presented. However, this tool can be accessed after the COMPILE step. For the initial run, Libero can be directed to use a file which includes these constraints. Note: Examples refer to the webserver demo must be modified as per the design hierarchy and signals. Max Delay and Min Delay Clock Generated Clock Input Delay Output Delay Clock Source Latency Max Delay and Min Delay SmartTime uses the current edge for Hold time analyses and the subsequent edge for Setup time analyses, by default. For CoreRGMII, advance the timing by one clock cycle to have the correct edges used for timing analysis, refer to Figure 10. Figure 10 Edges Used for Analysis This is achieved using set_min_delay and set_max_delay. These delay constraints advance the analyzed edge by one clock cycle to ensure that the correct edge is used for analyzing timing. set_min_delay -8.000 -from [get_ports { RD RX_CTL }] set_min_delay -8.000 -to [get_ports { TD TX_CTL }] CoreRGMII v2.0 Handbook 11

Tool Flows Figure 11 Setting Minimum Delay Constraint with SmartTime Constraint Editor set_max_delay 0.000 -from [get_ports { RD RX_CTL }] set_max_delay 0.000 -to [get_ports { TD TX_CTL }] Figure 12 Setting Maximum Delay Constraint with SmartTime Constraint Editor Clock The following clocks need to be created: create_clock -name { RXC } -period 8.000 -waveform { 0.000 4.000 } { RXC } create_clock -name { MDC } -period 40.000 -waveform { 0.000 20.000 } [get_pins { \ Webserver_TCP_0/Webserver_TCP_MSS_0/MSS_ADLIB_INST/INST_MSS_050_IP:MDCF }] Define the source_clock used to drive the CCC: create_clock -name { source_clock } -period 20.000 -waveform { 0.000 10.000 } { source_clock } 12 CoreRGMII v2.0 Handbook

Timing Closure Using SmartTime Figure 13 Setting RXC Clock with SmartTime Constraint Editor Generated Clock The generated clocks are derived from the source clocks and must be defined to allow SmartTime analyze the timing of the paths they clock. create_generated_clock -name { Webserver_TCP_0/CCC_0/CCC_INST/INST_CCC_IP:GL0 } \ -divide_by 2 -multiply_by 5 \ -source { Webserver_TCP_0/CCC_0/CCC_INST/INST_CCC_IP:CLK0_PAD } \ { Webserver_TCP_0/CCC_0/CCC_INST/INST_CCC_IP:GL0 } The generated clock for TXC is important as it allows SmartTime to analyze the paths to the external PHY and determine, if the PHY setup and hold time are met. create_generated_clock -name { output_clock } \ -divide_by 1 \ -source { Webserver_TCP_0/CCC_0/CCC_INST/INST_CCC_IP:GL0 } \ { TXC } Figure 14 Setting TXC Generated Clock Constraint with SmartTime Constraint Editor CoreRGMII v2.0 Handbook 13

Tool Flows Input Delay The input delay specifies the delay of the longest and shortest paths arriving at the specified input. In the following example, they are given by the skew of RD relative to RXC Figure 15 Setting Input Delay Constraints using SmartTime Constraint Editor set_input_delay -max -clock_fall 0.500 -clock { RXC } [get_ports { RD RX_CTL }] set_input_delay -min -clock_fall -0.500 -clock { RXC } [get_ports { RD RX_CTL }] set_input_delay -max 0.500 -clock { RXC } [get_ports { RD RX_CTL }] set_input_delay -min -0.500 -clock { RXC } [get_ports { RD RX_CTL }] Output Delay The output delay specifies the delay for the longest and shortest path from the specified output to the captured edge. This represents a combinational path delay to a register outside the current design plus the library setup and hold time. When the data and clock paths are matched, then the delays are simply the setup and hold time of the PHY. In the following example, the PHY locally shifted clock is used, resulting in the apparent conflict. set_output_delay -max -0.900 -clock { output_clock } [get_ports { TD TX_CTL }] set_output_delay -min 2.700 -clock { output_clock } [get_ports { TD TX_CTL }] set_output_delay -max -clock_fall -0.900 -clock { output_clock } [get_ports { TD TX_CTL }] set_output_delay -min -clock_fall 2.700 -clock { output_clock } [get_ports { TD TX_CTL }] 14 CoreRGMII v2.0 Handbook

Timing Closure Using SmartTime Figure 16 Setting Output Delay Constraints using SmartTime Constraint Editor Clock Source Latency This is used to incorporate the jitter on the transmit and receive clocks: set_clock_latency -source -early -rise 0.080 { Webserver_TCP_0/CCC_0/CCC_INST/INST_CCC_IP:GL0 } set_clock_latency -source -early -fall 0.080 { Webserver_TCP_0/CCC_0/CCC_INST/INST_CCC_IP:GL0 } set_clock_latency -source -late -rise 0.080 { Webserver_TCP_0/CCC_0/CCC_INST/INST_CCC_IP:GL0 } set_clock_latency -source -late -fall 0.080 { Webserver_TCP_0/CCC_0/CCC_INST/INST_CCC_IP:GL0 } set_clock_latency -source -early -rise 0.080 { RXC } set_clock_latency -source -early -fall 0.080 { RXC } set_clock_latency -source -late -rise 0.080 { RXC } set_clock_latency -source -late -fall 0.080 { RXC } Correcting Timing Failures Once the SmartTime timing constraints are set, minimum or maximum delay analysis can be run to determine whether or not the timing constraints are met. For the RX path, timing failures can be remedied using the SmartFusion2 programmable input delays, adjusting the delay between RD/RX_CTL and RXC until the timing is met. However, this requires multiple re-compiling of the design, so the I/O delay is updated in the timing tools. An alternative approach is to note the existing input delays, modify the input delay in SmartTime until timing constraints are met, then implement this delay in the programmable input delay given that one step is nominally ~100 ps, and finally revert the timing constraints back to their correct value and re-compiling. For the TX path, if second CCC is used to generate a shifted TXC clock for the PHY, the delay of the output clock can be adjusted. CoreRGMII v2.0 Handbook 15

Core Interfaces Signal descriptions for CoreRGMII are provided in Table 2. Table 2 CoreRGMII I/O Signals Name Direction Description Clock and Reset Signals CLK_RX Input RGMII Receive Clock from PHY From PHY to Core CLK_TX Input RGMII Transmit Clock From CCC to Core RESET_IN_N Input System reset. Active low asynchronous reset System Level Reset MSS Interface MAC_GMII_TXD [7:0] Input GMII transmit data From MSS to Core MAC_GMII_TX_EN Input Transmit enable From MSS to Core MAC_GMII_TX_ER Input Transmit Error From MSS to Core MAC_GMII_RXD[7:0] Output MII Receive data From Core to MSS MAC_GMII_RX_DV Output Receive data valid From Core to MSS MAC_GMII_RX_ER Output Receive error From Core to MSS MAC_GMII_COL Output Collision, considered asynchronous From Core to MSS MAC_GMII_CRS Output Carrier Sense, considered asynchronous From Core to MSS PHY Interface TD[3:0] Output Transmit Data to PHY From Core to PHY TX_CTL Output Transmit Control To PHY. The TX_CTL signal carries: MAC_GMII_TX_EN on the rising edge (MAC_GMII_TX_EN xor MAC_GMII_TX_ER) on the falling edge From Core to PHY RD[3:0] Input Receive Data from PHY From PHY to Core RX_CTL Input Receive Control from PHY. The RX_CTL signal carries: mac_gmii_rx_dv (data valid) on the rising edge (mac_gmii_rx_dv xor mac_gmii_rx_er ) on the falling edge From PHY to Core RESETN Output Reset Output to PHY From Core to PHY MDIO Inout Management Interface Between Core and PHY MSS GMII Interface MDI_SPD[1:0] Output CCC Clock Speed selection signals From Core to CCC MAC_GMII_MDC Input MII Clock From MSS to Core and PHY MAC_GMII_MDO_EN Input MII Output enable for Tristating BIBUF From MSS to Core MAC_GMII_MDO Input MII Data from MSS to Core/PHY From MSS to Core and PHY MAC_GMII_MDI Output MII Data(muxed between PHY & Core) From Core to MSS CoreRGMII v2.0 Handbook 16

Core Parameters Core Parameters CoreRGMII Configurable Options CoreRGMII configuration options are listed in Table 3. Use Configuration dialog box in SmartDesign to configure CoreRGMII. Table 3 CoreRMII Configuration Options Name Valid Range Default Description FAMILY 19 Must be set to the required FPGA family: 19: SmartFusion2 DEF_SPD 0-2 0 0: Select 10 Mbps mode as default 1: Select 100 Mbps mode as default 2: Select 1000 Mbps mode as default COR_ADDR 0-31 28 Address of the core on the management interface. CoreRGMII v2.0 Handbook 17

Register Map and Descriptions CoreRGMII has one RW register at address 0 accessed through the management interface. Bit 13 controls the selection between 25 MHz and 2.5 MHz Bit 6 controls the selection between 125 MHz and either 25 MHz or 2.5 MHz Default reset speed is set at core instantiation; otherwise the speed is set as listed in Table 4. Table 4 Speed Settings for Register Bit 6 and Bit 13 Bit 6 Bit 13 Description 1 1 Reserved 1 0 1000 Mbps 0 1 100 Mbps 0 0 10 Mbps CoreRGMII v2.0 Handbook 18

Appendix 1 - SmartTime Constraints create_clock -name { RXC } -period 8.000 -waveform { 0.000 4.000 } { RXC } create_clock -name { CLK0_PAD } -period 20.000 -waveform { 0.000 10.000 } { CLK0_PAD } create_clock -name { MDC } -period 40.000 -waveform { 0.000 20.000 } [get_pins { \ Webserver_TCP_0/Webserver_TCP_MSS_0/MSS_ADLIB_INST/INST_MSS_050_IP:MDCF }] create_generated_clock -name { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:gl0 } \ -divide_by 2 -multiply_by 5 \ -source { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:clk0_pad } \ { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:gl0 } create_generated_clock -name { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:gl2 } \ -divide_by 10 -multiply_by 5 \ -source { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:clk0_pad } \ { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:gl2 } create_generated_clock -name { output_clock } -divide_by 1 \ -source { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:gl0 } { TXC } set_input_delay -max -clock_fall 0.500 -clock { RXC } [get_ports { RD RX_CTL }] set_input_delay -min -clock_fall -0.500 -clock { RXC } [get_ports { RD RX_CTL }] set_input_delay -max 0.500 -clock { RXC } [get_ports { RD RX_CTL }] set_input_delay -min -0.500 -clock { RXC } [get_ports { RD RX_CTL }] set_output_delay -max -clock_fall -0.900 -clock { output_clock } [get_ports { TD TX_CTL }] set_output_delay -min -clock_fall 2.700 -clock { output_clock } [get_ports { TD TX_CTL }] set_output_delay -max -0.900 -clock { output_clock } [get_ports { TD TX_CTL }] set_output_delay -min 2.700 -clock { output_clock } [get_ports { TD TX_CTL }] set_max_delay 0.000 -from [get_ports { RD RX_CTL }] set_max_delay 0.000 -to [get_ports { TD TX_CTL }] set_min_delay -8.000 -from [get_ports { RD RX_CTL }] set_min_delay -8.000 -to [get_ports { TD TX_CTL }] set_clock_latency -source -early -rise 0.080 { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:gl0 } set_clock_latency -source -early -fall 0.080 { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:gl0 } set_clock_latency -source -late -rise 0.080 { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:gl0 } set_clock_latency -source -late -fall 0.080 { <design_name>/ccc_0/ccc_inst/inst_ccc_ip:gl0 } set_clock_latency -source -early -rise 0.080 { RXC } set_clock_latency -source -early -fall 0.080 { RXC } set_clock_latency -source -late -rise 0.080 { RXC } set_clock_latency -source -late -fall 0.080 { RXC } CoreRGMII v2.0 Handbook 19

Ordering Information Ordering Codes CoreRGMII can be ordered through the local Sales Representative. It must be ordered using the following number scheme: CoreRGMII-XX, where XX is listed in Table 5. Table 5 Ordering Codes XX RM RTL source multi-use multi-site license. Note: CoreRGMII is license free. Description CoreRGMII v2.0 Handbook 20

List of Changes The following table lists critical changes that were made in each revision of the document. Date Change Page December 2014 Initial release. NA Note: The revision number is located in the part number after the hyphen. The part number is displayed at the bottom of the last page of the document. The digits following the slash indicate the month and year of publication. CoreRGMII v2.0 Handbook 21

Product Support Microsemi SoC Products Group backs its products with various support services, including Customer Service, Customer Technical Support Center, a website, electronic mail, and worldwide sales offices. This appendix contains information about contacting Microsemi SoC Products Group and using these support services. Customer Service Contact Customer Service for non-technical product support, such as product pricing, product upgrades, update information, order status, and authorization. From North America, call 800.262.1060 From the rest of the world, call 650.318.4460 Fax, from anywhere in the world 650. 318.8044 Customer Technical Support Center Microsemi SoC Products Group staffs its Customer Technical Support Center with highly skilled engineers who can help answer your hardware, software, and design questions about Microsemi SoC Products. The Customer Technical Support Center spends a great deal of time creating application notes, answers to common design cycle questions, documentation of known issues and various FAQs. So, before you contact us, visit our online resources. It is very likely we have already answered your questions. Technical Support Website For Microsemi SoC Products Support, visit http://www.microsemi.com/products/fpga-soc/design-support/fpga-socsupport. You can browse a variety of technical and non-technical information on the Microsemi SoC Products Group home page, at http://www.microsemi.com/soc/. Contacting the Customer Technical Support Center Highly skilled engineers staff the Technical Support Center. The Technical Support Center can be contacted by email or through the Microsemi SoC Products Group website. Email You can communicate your technical questions to our email address and receive answers back by email, fax, or phone. Also, if you have design problems, you can email your design files to receive assistance. We constantly monitor the email account throughout the day. When sending your request to us, please be sure to include your full name, company name, and your contact information for efficient processing of your request. The technical support email address is soc_tech@microsemi.com. My Cases Microsemi SoC Products Group customers may submit and track technical cases online by going to My Cases. CoreRGMII v2.0 Handbook 22

ITAR Technical Support Outside the U.S. Customers needing assistance outside the US time zones can either contact technical support via email (soc_tech@microsemi.com) or contact a local sales office. Sales office listings can be found at www.microsemi.com/soc/company/contact/default.aspx. ITAR Technical Support For technical support on RH and RT FPGAs that are regulated by International Traffic in Arms Regulations (ITAR), contact us via soc_tech_itar@microsemi.com. Alternatively, within My Cases, select Yes in the ITAR drop-down list. For a complete list of ITAR-regulated Microsemi FPGAs, visit the ITAR web page. CoreRGMII v2.0 Handbook 23

Microsemi Corporate Headquarters One Enterprise, Aliso Viejo, CA 92656 USA Within the USA: +1 (800) 713-4113 Outside the USA: +1 (949) 380-6100 Sales: +1 (949) 380-6136 Fax: +1 (949) 215-4996 E-mail: sales.support@microsemi.com 2014 Microsemi Corporation. All rights reserved. Microsemi and the Microsemi logo are trademarks of Microsemi Corporation. All other trademarks and service marks are the property of their respective owners. Microsemi Corporation (Nasdaq: MSCC) offers a comprehensive portfolio of semiconductor and system solutions for communications, defense & security, aerospace and industrial markets. Products include high-performance and radiation-hardened analog mixed-signal integrated circuits, FPGAs, SoCs and ASICs; power management products; timing and synchronization devices and precise time solutions, setting the world s standard for time; voice processing devices; RF solutions; discrete components; security technologies and scalable anti-tamper products; Power-over-Ethernet ICs and midspans; as well as custom design capabilities and services. Microsemi is headquartered in Aliso Viejo, Calif., and has approximately 3,400 employees globally. Learn more at www.microsemi.com. Microsemi makes no warranty, representation, or guarantee regarding the information contained herein or the suitability of its products and services for any particular purpose, nor does Microsemi assume any liability whatsoever arising out of the application or use of any product or circuit. The products sold hereunder and any other products sold by Microsemi have been subject to limited testing and should not be used in conjunction with mission-critical equipment or applications. Any performance specifications are believed to be reliable but are not verified, and Buyer must conduct and complete all performance and other testing of the products, alone and together with, or installed in, any end-products. Buyer shall not rely on any data and performance specifications or parameters provided by Microsemi. It is the Buyer s responsibility to independently determine suitability of any products and to test and verify the same. The information provided by Microsemi hereunder is provided as is, where is and with all faults, and the entire risk associated with such information is entirely with the Buyer. Microsemi does not grant, explicitly or implicitly, to any party any patent rights, licenses, or any other IP rights, whether with regard to such information itself or anything described by such information. Information provided in this document is proprietary to Microsemi, and Microsemi reserves the right to make any changes to the information in this document or to any products and services at any time without notice. 50200569-1/12.14