Microsemi UG0687 PolarFire FPGA 1G Ethernet Solutions User Guide
- June 10, 2024
- Microsemi
Table of Contents
- Microsemi UG0687 PolarFire FPGA 1G Ethernet Solutions
- Product Information: PolarFire FPGA 1G Ethernet Solutions
- Product Usage Instructions:
- Contact Information:
- 1G Ethernet Overview
- PolarFire FPGA Evaluation Kit Ethernet Support
- Building Blocks for 1G Ethernet Solutions
- Implementing 1G Ethernet Solutions
- Appendix 1: MAC Layers in the OSI Reference Model and Standard Ethernet
- Appendix 2: Ethernet Frame Format
- Appendix 3: Glossary
- References
- Read User Manual Online (PDF format)
- Download This Manual (PDF format)
Microsemi UG0687 PolarFire FPGA 1G Ethernet Solutions
Product Information: PolarFire FPGA 1G Ethernet Solutions
The PolarFire FPGA 1G Ethernet Solutions is an evaluation kit for Microsemi’s FPGA product line. This solution provides a comprehensive 1G Ethernet solution that includes building blocks for soft processor IP, Ethernet MAC IP, Ethernet interface IP, transmit PLL, and IP licensing. These building blocks can be used to implement different 1000BASE-T solutions such as GMII-based and SGMII- based designs.
The kit also includes support for PolarFire FPGA evaluation, which provides Ethernet support for the kit. The kit can be used to implement different 1G Ethernet solutions based on GMII and SGMII interfaces.
Product Usage Instructions:
- Download and read the user manual for the PolarFire FPGA 1G Ethernet Solutions.
- Install the evaluation kit and follow the instructions provided in the kit’s user manual.
- Depending on the design requirements, choose the appropriate building blocks such as soft processor IP, Ethernet MAC IP, Ethernet interface IP, transmit PLL, and IP licensing.
- Implement the 1G Ethernet solution based on GMII or SGMII interfaces using the appropriate building blocks.
- Test the implemented solution to ensure that it meets the design requirements and specifications.
Contact Information:
For more information about the PolarFire FPGA 1G Ethernet
Solutions, please contact Microsemi at:
- Microsemi 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
- Email: sales.support@microsemi.com
- Website: www.microsemi.com
©2018 Microsemi, a wholly owned subsidiary of Microchip Technology Inc. All rights reserved. Microsemi and the Microsemi logo are registered trademarks of Microsemi Corporation. All other trademarks and service marks are the property of their respective owners.
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.
About Microsemi
Microsemi, a wholly owned subsidiary of Microchip Technology Inc. (Nasdaq:
MCHP), offers a comprehensive portfolio of semiconductor and system solutions
for aerospace & defense, communications, data center 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; enterprise storage and communication solutions, security
technologies and scalable anti-tamper products; Ethernet solutions; Power-
over-Ethernet ICs and midspans; as well as custom design capabilities and
services. Learn more at www.microsemi.com.
Revision History
The revision history describes the changes that were implemented in the
document.
The changes are listed by revision, starting with the current publication.
-
Revision 5.0
The following is a summary of the changes made in this revision of document.- Updated the document for Libero SoC v2021.1.
- Replaced Figure 9, page 9.
- Replaced Figure 16, page 14.
- Added SGMII Based Designs Using IOD-CDR, page 15.
-
Revision 4.0
Updated the document for Libero SoC PolarFire v2.2. -
Revision 3.0
The following is a summary of the changes made in this revision of document.- Block diagrams of RJ45 connections for SGMII-based AMBA AHB designs and non-AMBA AHB designs were updated. For more information, see Figure 7, page 8 and Figure 13, .
- A note about SyncE support in Libero SoC PolarFire v2.0 was added. For more information, see Synchronous Ethernet (SyncE) Support, .
-
Revision 2.0
The following is a summary of the changes made in this revision of document.- Information about the SyncE feature was added. For more information, see Synchronous Ethernet (SyncE) Support, page 15.
- Clocking information for SGMII-based designs was updated. For more information, see Clocking Requirements, page 13.
-
Revision 1.0
The first publication of this document.
1G Ethernet Overview
Ethernet is a family of networking interface standards used in systems and applications across multiple industries. Implementation of Ethernet solutions in FPGAs requires IP and design flows that reduce development time and utilize minimal device resources, thereby helping meet performance, power, and cost goals. Microsemi PolarFire® devices support Ethernet data transfer rates ranging from 10 Mbps to 10 Gbps on a single interface.
Microsemi PolarFire devices provide a complete range of solutions for implementing IEEE 802.3 standard-compliant Ethernet interfaces for chip-to- chip, board-to-board, and backplane interconnects. The high-speed serial interface and soft IP blocks available in PolarFire devices enable designers to build Ethernet solutions for use in embedded systems and systems connected over copper or optical cabling.
PolarFire FPGA 1G Ethernet support is compliant with the IEEE 802.3-2008 standard that supports data transfer rates of up to 1 Gbps. Advantages offered by PolarFire FPGAs for building 1G Ethernet solutions include the use of low- power transceivers, low-power FPGA fabric, low-power IOD
CDR, synchronous Ethernet (SyncE)-compliant jitter attenuation, and on-board
Microsemi VSC8575 PHY.
In PolarFire devices, 10/100/1000 Mbps (1G) Ethernet is implemented using the
CoreTSE soft IP media access control (MAC) core. This IP supports standard
Ethernet interfaces such as the following.
- Gigabit media-independent interface (GMII)
- Reduced gigabit media-independent interface (RGMII)
- Serial gigabit media-independent interface (SGMII)
- Quad serial gigabit media-independent interface (QSGMII)
A typical Ethernet application, such as a switch or a router, requires an Ethernet MAC sublayer (commonly referred to as the MAC) that supports standard Ethernet interfaces, an Ethernet physical layer (PHY), and a physical connector, such as an RJ45 or SFP connector. The following illustration shows a sample Ethernet application.
Note: The LVDS25 IO standard is used in all the IO based SGMII designs.
Figure 1 • Sample Ethernet Application
For more information about the Ethernet MAC, including standard Ethernet interfaces, see Appendix 1: MAC Layers in the OSI Reference Model and Standard Ethernet Interfaces, .
PolarFire FPGA Evaluation Kit Ethernet Support
The PolarFire FPGA Evaluation Kit supports the 1000BASE-T standard (applicable to copper interfaces), as well as the 1000BASE-X standard (applicable to optical interfaces). The kit supports both the GMII and TBI/SGMII Ethernet interfaces.
The PolarFire FPGA Evaluation Kit includes the following 1G Ethernet hardware components.
- Two RJ45 ports
- Microsemi VSC8575 Ethernet PHY, which supports 10/100/1000 Mbps Ethernet speeds
- I/O digital logic block with clock and data recovery circuitry (IOD CDR) to support TBI/SGMII applications
- SFP module supporting 1G and 10G Ethernet speeds that is connected to a transceiver lane
- FPGA mezzanine card (FMC) high-pin count (HPC) connector that connects the MAC to an external GMII Ethernet PHY over I/O
- SubMiniature version A (SMA) connectors that connect the MAC to an external SFP module
The following illustration shows the hardware on the PolarFire FPGA Evaluation Board. Highlighted in red are the hardware components used for implementing 1G Ethernet solutions.
Figure 2 • PolarFire FPGA Evaluation Board Hardware Block Diagram
Building Blocks for 1G Ethernet Solutions
Microsemi offers pre-designed and verified IP for all key markets and applications. A complete 1G Ethernet solution requires the following IP:
- Soft processor to implement control plane features, initialize the Ethernet MAC, and perform autonegotiation
- Ethernet MAC to process Ethernet packets
- Ethernet interface to connect the Ethernet MAC with an external PHY
- Transceiver interface to send and receive serialized/deserialized data
- Transmit PLL to provide the clocks required for the transceiver
- Transceiver reference clock to provide input to the transmit PLL and the transceiver interface
The following illustration shows a sample Ethernet application developed using Microsemi IP cores.
Figure 3 • Sample Ethernet Application Using Microsemi IP Cores
For comprehensive information about all Microsemi IP, see www.microsemi.com/products/fpga-soc/design-resources/ip- cores.
Soft Processor IP
CoreRISCV_AXI4 or Cortex-M1: A 32-bit soft processor core such as
CoreRISCV_AXI4 or Cortex-M1 can be used to develop processor-based Ethernet
solutions. The soft processor initializes the Ethernet MAC and runs real-time
operating systems such as FreeRTOS. A complete Ethernet solution consisting of
an application layer, a network layer (TCP/IP), and a data link layer (MAC)
such as a web server can be implemented using RISC-V. For more information
about CoreRISCV_AXI4, see the CoreRISCV_AXI4 Handbook. For more information
about Cortex-M1, see the CoreCortexM1 Handbook.
CoreABC: CoreABC is a simple, configurable, low gate-count controller primarily targeted at implementing Advanced Microcontroller Bus Architecture Advanced Peripheral Bus (AMBA APB)-based designs. In an Ethernet-based application, this core is used only for configuring the Ethernet MAC. For more information about CoreABC, see the CoreABC Handbook.
Ethernet MAC IP (CoreTSE)
The CoreTSE soft IP core provides a 10/100/1000 Mbps Ethernet MAC
functionality with GMII or TBI/SGMII to support 1000BASE-T and 1000BASE-X
standards. CoreTSE supports full-duplex communication at 10, 100, and 1000
Mbps speeds and half-duplex communication at 10 and 100 Mbps speeds. The
management data input/output (MDIO) interface of the MAC performs read/write
operations to the Ethernet PHY registers. CoreTSE also maintains frame
statistics counters that count the number of data packets transmitted and
received over the Ethernet link. The MAC station address logic provides the
address-filtering capability.
The CoreTSE IP is available in two versions:
- CoreTSE_AHB: Designed for AMBA AHB applications, uses the AHB interface for both transmit and receive paths
- CoreTSE: Designed for wire-speed store-and-forward throughput (non-AMBA AHB applications), uses direct access to the MAC with a streaming packet interface
For more information, see the CoreTSE Handbook and CoreTSE_AHB Handbook.
Ethernet Interface IP
PF_XCVR: The PolarFire FPGA Transceiver Interface (PF_XCVR) provides the
physical media attachment (PMA) for high-speed serial interfaces. The
transceiver has a multi-lane architecture with each lane natively supporting
serial data transfer rates ranging from 250 Mbps to 12.7 Gbps. For more
information, see UG0677: PolarFire FPGA Transceiver User Guide.
PF_IOD_CDR: The PolarFire FPGA IOD CDR (PF_IOD_CDR), available in every GPIO bank lane of the device, provides clock and data recovery for 1 GbE data transfer rates. Each side of the device can have multiple IOD CDRs sharing high-speed signals from a PLL located at the corner of the FPGA fabric. For more information, see UG0686: PolarFire FPGA User I/O
User Guide.
CoreSGMII: The CoreSGMII PCS core provides a ten-bit interface (TBI) for GMII-
based designs. It is a subset of the CoreTSE IP that only provides the PHY
layer to connect to the GMII interface. When transmitting Ethernet packets,
CoreSGMII encodes the GMII data stream into 10-bit symbols. When receiving the
Ethernet packets, it decodes and converts the 10-bit symbols into the receive
GMII signal set. CoreSGMII is designed to work with both the PolarFire FPGA
transceiver and the PolarFire FPGA IOD CDR. For more information about
CoreSGMII, see the CoreSGMII Handbook.
Transmit PLL
The PolarFire FPGA transmit PLL (PF_TX_PLL) provides the high-speed clock for
the PolarFire FPGA transceiver. When used with the transceiver, the transmit
PLL supports jitter attenuation for loop-timing applications where recovered
clocks are used as transmit reference clocks. The jitter attenuation feature
controls low-speed wander, ensuring compliance with SyncE specifications. For
more information, see UG0677: PolarFire FPGA Transceiver User Guide.
IP Licensing
The Libero® System-on-chip (SoC) PolarFire software provides free access to
several Microsemi IP, but some IP require purchasing a separate license.
Contact Customer Service for information about how to purchase licenses.
The following table lists license information for each Ethernet-based IP.
Table 1 • License Information for Microsemi 1G Ethernet-Based IP
IP Core / License Information
- CoreRISCV_AXI4 Available with the Libero SoC PolarFire license
- CoreCortexM1 Available with clickthrough license1
- CoreABC Available with the Libero SoC PolarFire license
- CoreTSE Must be purchased separately
- CoreTSE_AHB Must be purchased separately
- CoreSGMII Must be purchased separately
- CoreRGMII Must be purchased separately
- PF_XCVR (transceiver interface)
- Available with the Libero SoC PolarFire license
- PF_IOD_CDR Available with the Libero SoC PolarFire license
- PF_TX_PLL Available with the Libero SoC PolarFire license
- PF_XCVR_REF_CLK Available with the Libero SoC PolarFire license
- This IP is listed in the Libero SoC IP catalog but can be used only after signing the end-user license agreement (EULA).
Implementing 1G Ethernet Solutions
In PolarFire devices, 1G Ethernet solutions can be implemented using the CoreTSE or CoreTSE_AHB MAC IP. Both of these IP support the SGMII, 1000BASE-T, and 1000BASE-X standards. The IP must be initialized and configured using a soft processor, a state machine hosted in the fabric, or the CoreABC IP.
For GMII/RGMII-based designs, GPIOs and HSIOs connect the Ethernet MAC to the external Ethernet PHY. PolarFire FPGA I/O lanes have built-in logic that allows them to support multiple RGMII interfaces with a shared DLL.
Both the transceiver and IOD CDR provide a TBI bridge to the serial data from the MAC. Use the following guidelines to choose the physical layer interface for the design.
- The transceiver supports jitter attenuation for applications such as those that require the Synce feature. For such applications, and for applications that use the transceiver hard IP block, use the transceiver interface.
- The IOD CDR allows several SGMII ports to be connected using a single PLL. PLL sharing minimizes power consumption and is useful when multiple interfaces are required on the device. If minimal power is the priority, use the IOD CDR.
The following sections describe how the MAC interfaces with the PHY in PolarFire devices for various Ethernet interfaces. For more information about Ethernet interfaces, see Appendix 1: MAC Layers in the OSI Reference Model and Standard Ethernet Interfaces, .
1000BASE-T Solutions Using CoreTSE_AHB
1000BASE-T solutions are implemented by connecting the CoreTSE_AHB MAC to an
external PHY through a media interface (GMII or SGMII) either using a
PolarFire FPGA IOD CDR or a PolarFire FPGA transceiver.
For all CoreTSE_AHB-based connections, the IP is connected to a soft processor
using the CoreAHBLite bus interface.
GMII-Based Designs
For GMII-based designs, CoreTSE_AHB is configured in GMII mode and then
connected to a compatible 1000BASE-T Ethernet PHY through GPIO or HSIO, as
shown in the following illustration.
Figure 4 • RJ45 Connections for GMII-Based Designs (AMBA AHB)
Clocking Requirements
The following clocks are required for 1000BASE-T, GMII/RGMII-based, AMBA
AHB designs.
- GTXCLK: 125-MHz global transmit clock for 1000 Mbps, driven from the MAC to the Ethernet PHY
- TXCLK: 125-MHz, 25-MHz, or 2.5-MHz regional transmit clock (for 1000 Mbps, 100 Mbps and 10 Mbps, respectively), driven from the MAC to the Ethernet PHY
- RXCLK: 125-MHz, 25-MHz, or 2.5-MHz regional receive clock (for 1000 Mbps, 100 Mbps, and 10 Mbps, respectively), driven from the Ethernet PHY to the MAC
RGMII-Based Designs
For RGMII-based designs, the PF_IOD_GENERIC_TX Configurator converts GMII
signals (MAC side) to RGMII signals (PHY side), and the PF_IOD_GENERIC_RX
Configurator converts the RGMII signals into GMII signals. CoreTSE_AHB is
configured in GMII mode and connected to an RGMII-compatible 1000BASE-T
Ethernet PHY through GPIO or HSIO, as shown in the following illustration.
Figure 5 • RJ45 Connections for RGMII-Based Designs (AMBA AHB)
Configuring IP Using Libero SoC PolarFire
The CoreTSE_AHB MAC IP is available in the Libero SoC PolarFire IP catalog.
The following figure shows CoreTSE_AHB configured in GMII mode.
Figure 6 • CoreTSE_AHB Configuration in GMII Mode
SGMII-Based Designs
For SGMII-based designs, CoreTSE_AHB is configured in TBI/SGMII mode and
connected to the SGMII-compatible VSC8575 Ethernet PHY through the IOD CDR
circuitry, as shown in the following illustration.
Figure 7 • RJ45 Connections for SGMII-Based Designs (AMBA AHB)
Clocking Requirements
The following clocks are required for 1000BASE-T, SGMII-based, AMBA AHB
designs.
- RX_CLK_R: 125-MHz receive clock connected to TBI_RX_CLK
- TX_CLK_G: 125-MHz transmit clock connected to TBI_TX_CLK
GMII Connections Using CoreSGMII
For GMII-based designs that use TBI, CoreTSE_AHB is configured in GMII mode
and connected to CoreSGMII, an IP designed for applications that use TBI.
CoreSGMII is then interfaced to the VSC8575 Ethernet PHY using an IOD CDR or a
transceiver connected to an SFP module.
Configuring IP and IOD CDR Using Libero SoC PolarFire
To implement SGMII-based designs, configure the following settings in Libero
SoC PolarFire.
- Configure CoreTSE_AHB in TBI/SGMII mode, as shown in the following figure.
Figure 8 • CoreTSE_AHB Configuration in SGMII Mode
- Configure the IOD CDR selecting the data transfer rate of 1250 Mbps (required for SGMII mode), as shown in the following figure.
Figure 9 • IOD CDR Configuration with SGMII Mode Data Transfer Rate
1000BASE-T Solutions Using CoreTSE (Non-AMBA AHB)
For non-AMBA AHB designs, 1000BASE-T solutions are implemented by connecting
the CoreTSE MAC to an external PHY through a media interface (GMII or SGMII)
either using a PolarFire FPGA IOD CDR or a PolarFire FPGA transceiver.
For all CoreTSE-based connections, the IP is connected to a soft processor
using the AHBtoAPB bus interface
GMII-Based Designs
For GMII-based designs, CoreTSE is configured in GMII mode and connected to a
GMII-compatible 1000BASE-T Ethernet PHY through GPIO, as shown in the
following illustration.
Figure 10 • RJ45 Connections for GMII-Based Designs (Non-AMBA AHB)
Clocking Requirements
The clocks required for 1000BASE-T, GMII/RGMII-based, non-AMBA AHB designs are
the same as those required for corresponding AMBA AHB designs:
- GTXCLK: 125-MHz global transmit clock for 1000 Mbps, driven from the MAC to the Ethernet PHY
- TXCLK: 125-MHz, 25-MHz or 2.5-MHz regional transmit clock (for 1000 Mbps, 100 Mbps and 10 Mbps, respectively), driven from the MAC to the Ethernet PHY
- RXCLK: 125-MHz, 25-MHz, or 2.5-MHz regional receive clock (for 1000 Mbps, 100 Mbps, and 10 Mbps, respectively), driven from the Ethernet PHY, driven from the Ethernet PHY to the MAC
RGMII-Based Designs
For RGMII-based designs, the PF_IOD_GENERIC_TX Configurator converts GMII
signals (MAC side) to RGMII signals (PHY side), and the PF_IOD_GENERIC_RX
Configurator converts RGMII signals into GMII signals. Cortes is configured in
GMII mode and connected to an RGMII-compatible 1000BASE-T Ethernet PHY through
GPIO or HSIO, as shown in the following illustration.
Figure 11 • RJ45 Connections for RGMII-Based Designs (Non-AMBA AHB)
Configuring IP Using Libero SoC PolarFire
The CoreTSE MAC IP is available in the Libero SoC PolarFire IP catalog. The
following figure shows CoreTSE configured in GMII mode.
Figure 12 • CoreTSE Configuration in GMII Mode
SGMII-Based Designs
For SGMII-based designs, CoreTSE is configured in TBI/SGMII mode and connected
to the SGMII-compatible VSC8575 Ethernet PHY through IOD CDR circuitry, as
shown in the following illustration.
Figure 13 • RJ45 Connections for SGMII-Based Designs (Non-AMBA AHB)
Clocking Requirements
The clocks required for 1000BASE-T, SGMII-based, non-AMBA AHB designs are the
same as those required for corresponding AMBA AHB designs:
- RX_CLK_R: 125-MHz receive clock connected to TBI_RX_CLK
- TX_CLK_G: 125-MHz transmit clock connected to TBI_TX_CLK
GMII Connections Using CoreSGMII
For GMII-based designs that use TBI, CoreTSE is configured in GMII mode and
connected to CoreSGMII, which, in turn, is interfaced to the VSC8575 Ethernet
PHY using a IOD CDR or a transceiver connected to an SFP module.
Configuring IP and IOD CDR Using Libero SoC PolarFire
To implement RJ45 connections for SGMII-based designs, configure the following
settings in Libero SoC PolarFire.
- Configure CoreTSE in TBI/SGMII mode, as shown in the following figure.
Figure 14 • CoreTSE Configuration in SGMII Mode
- Configure the IOD CDR selecting the data transfer rate of 1250 Mbps (required for SGMII mode), as shown in Figure 9, .
1000BASE-X Solutions Using CoreTSE (Non-AMBA AHB)
1000Base-X solutions are implemented by connecting the CoreTSE MAC to an
external PHY compatible with the Ethernet interface used in the design. The
MAC is connected to optical-to-electrical (O/E) converters through the
transceiver.
SGMII-Based Designs
For SGMII-based designs, CoreTSE is configured in TBI/SGMII mode and connected
to a 1G SFP using the transceiver. One of the transceiver lanes is connected
to the SFP module cage on the PolarFire device, as shown in the following
illustration.
Figure 15 • SFP Connections for SGMII-Based Designs (Non-AMBA AHB)
Clocking Requirements
The clocks required for 1000BASE-X, SGMII-based, non-AMBA AHB designs are the
same as those required for corresponding AMBA AHB designs:
- TBI_RX_CLK: 125-MHz TBI transmit clock driven from the transceiver or sourced by the local reference clock oscillator
- TBI_TX_CLK: 125-MHz TBI receive clock driven from the transceiver
- TXCLK: 2.5-MHz, 25-MHz, or 125-MHz transmit clock (for 10 Mbps, 100 Mbps, and 1000 Mbps, respectively)
- RXCLK: 2.5-MHz, 25-MHz, or 125-MHz receive clock (for 10 Mbps, 100 Mbps, and 1000 Mbps, respectively)
- CLKS_FROM_TXPLL_0: Clocks from the transmit PLL bus interface port with the following underlying signals common to all lanes instantiated in the transceiver interface IP core:
- TX_BIT_CLK_0
- TX_PLL_LOCK_0
- TX_PLL_REF_CLK_0
- CDR_REF_CLK: Reference for the lane CDR, sourced from the receiver reference clock IP
Configuring IP and Transceiver Interface Using Libero SoC PolarFire
To implement SFP connections for SGMII-based designs, use the following
settings in Libero SoC PolarFire.
- Configure CoreTSE in TBI/SGMII mode.
- Configure the transceiver in SGMII mode, as shown in the following figure.
Figure 16 • Transceiver Interface Configuration in SGMII Mode
When configuring the transceiver, the transceiver data rate must be set to 1250 Mbps to match the SGMII/1000BASE-X data transfer rate, as shown in the preceding figure.
The TX clock division factor allows the transceiver lane high-speed bit clock from the TX PLL to be divided, which allows the user to share a higher rate TX PLL and locally divide the clock to match the 1250 Mbps. The default value for this field is 1.
The PCS-Fabric interface width must be set to 10 bits to match the TBI required by the CoreTSE/CoreTSE_AHB/CoreSGMII IP blocks.
Because the CoreTSE, CoreTSE_AHB, and CoreSGMII IP have built-in PCS functionality, PMA mode must be selected to allow the transceiver to transmit and receive serial data.
SGMII Based Designs Using IOD-CDR
For SGMII-based designs, CoreTSE is configured in TBI/SGMII mode and connected
to a 1G SFP using the IOD-CDRs, as shown in the following illustration.
For more information related to Clocking requirements, refer to Clocking
Requirements, .
For more information related to Configuring IP and IOD CDR Using Libero SoC
PolarFire, refer to Configuring IP and IOD CDR Using Libero SoC PolarFire, .
Figure 17 • SFP Connections for SGMII-Based Designs (for IOD-CDR)
Synchronous Ethernet (SyncE) Support
The SyncE technology is commonly used for frequency synchronization in
networks. SyncE-enabled Ethernet switches can extend frequency from one side
of the network to the other. The transmit PLL in PolarFire devices supports
jitter attenuation at both 1 Gbps and 10 Gbps data transfer rates.
Firmware Support
The CoreTSE IP driver is distributed through the Microsemi SoC firmware
catalog. This catalog provides access to the documentation for the driver,
generates application projects from source files, and generates sample
projects that illustrate how to use the driver.
The firmware catalog is available at:
www.microsemi.com/soc/products/software/firmwarecat/default.aspx.
The CoreTSE driver supports the following features.
- Initialization and configuration
- Transmit operations
- Receive operations
- Reading link status and statistics
- Address-based frame filtering
- Wake-up on LAN (WoL) with unicast match and AMD magic packet detection
- Jumbo frames
Note: The CoreTSE IP does not have an AHB interface for packet transmission and reception, so transmit and receive operations are only supported for CoreTSE_AHB. All other features supported by the driver are applicable to both CoreTSE_AHB and CoreTSE.
For more information about the CoreTSE driver, see the CoreTSE Driver User Guide (accessible from the CoreTSE Configurator in the Libero SoC PolarFire software).
Appendix 1: MAC Layers in the OSI Reference Model and Standard Ethernet
Interfaces
This section discusses how Ethernet MAC layers fit into the open systems interconnection (OSI) reference model and provides information about the standard interfaces used for Ethernet connections.
MAC Layers
The OSI reference model is a standard framework for data communication between
networked systems. The following illustration shows the relationship between
the OSI reference model and the Ethernet MAC as defined in the IEEE 802.3-2012
standard. It also illustrates where the supported physical interfaces (PCS,
PMA, and PMD) fit into the archite
cture. The MAC and MAC control sublayers shown are handled by the Ethernet MAC.
Figure 18 • IEEE Standard 802.3-2012 Ethernet Model
The data link and physical layers in the OSI model are explained as follows.
LLC
The logical layer control (LLC) sublayer acts as an interface between the MAC
and the network layer. It provides frame synchronization, flow control, and
error checking mechanisms. It also offers multiplexing mechanisms to allow
several network protocols to exist simultaneously in a multi-point network and
share the same network medium for transmitting and receiving Ethernet packets.
MAC Sublayer
The MAC sublayer, referred to as the MAC, is defined in IEEE 802.3-2012,
clauses 2, 3, and 4. The MAC is the second sublayer of the data link layer in
the seven-layer OSI model. It provides addressing and channel access control
mechanisms that allow terminals and network nodes in a multiple access network
using a shared medium, such as an Ethernet network, to communicate with each
other. The MAC is responsible for the transmission of data packets to and from
the network-interface card. It is independent of the physical layer and can
connect to any type of physical layer device.
MAC Control Sublayer
The MAC control sublayer, defined in IEEE 802.3-2012, clause 31 provides real-
time flow control manipulation for the MAC. MAC and MAC control sublayer
functions are performed by the Ethernet MAC in all modes of operation.
Reconciliation Sublayer
The reconciliation sublayer maps the signals between the physical medium
interface and the MAC layer.
Physical Sublayers (PCS, PMA, and PMD)
The Ethernet physical layer consists of the following three sublayers:
- Physical coding sublayer (PCS)—performs autonegotiation and coding operations such as 8b/10b encoding
- Physical medium attachment sublayer (PMA)—performs data serialization and clock recovery necessary to move serial data in and out of the device
- Physical medium-dependent sublayer (PMD)—hosts the transceiver that receives and transmits data through the physical medium
The MAC does not have the PHY functionality to allow it to directly connect to the physical medium. The following are the two PHY standards that connect the MAC to the physical medium:
- BASE-T PHYs connect the MAC with copper media through GMII, RGMII, SGMII, or 1000BASE-T interfaces.
- BASE-X PHYs connect the MAC with fiber-optic media through the SGMII or 1000BASE-X interface.
Standard Ethernet MAC Interfaces
This section describes standard interfaces used to connect the Ethernet MAC to
the PHY and the signals associated with each interface.
Note: The direction of signals as described in this section is with reference to the MAC, not the PHY.
Gigabit Media-Independent Interface (GMII)
GMII connects a 10/100/1000 Mbps-capable MAC to the PHY.
The following table lists the GMII interface signals.
Table 2 • GMII Interface Signals
Signal | Direction | Description |
---|---|---|
TXD[7:0] | Output | GMII transmit data signals for the MAC to supply byte- |
aligned data to the PHY.
TX_EN| Output| GMII transmit data enable. Indicates to the PHY that data is
available on the GMII for transmission.
TX_ER| Output| GMII transmit data error.
RXD[7:0]| Input| GMII receive data signals for the PHY to transmit byte-
aligned data to the MAC.
RX_ER| Input| GMII receive data error.
RX_DV| Input| Indicates GMII receive data valid.
CRS| Input| Asynchronous carrier sense signal. Indicates at least one physical
device is transmitting on the physical medium.
COL| Input| Asynchronous collision signal. Indicates more than one physical
device is transmitting simultaneously on the medium.
Signal| Direction| Description
---|---|---
RX_CLK| Input| GMII receive clock. 125 MHz for the 1000 Mbps mode, 25 MHz for
the 100 Mbps mode, and 2.5 MHz for the 10 Mbps mode.
TX_CLK| Input| GMII transmit clock. 25 MHz for the 100 Mbps mode and 2.5 MHz
for the 10 Mbps mode. TXD, TX_EN, and TX_ER signals are synchronized to
TX_CLK.
GTX_CLK| Input| Gigabit 125-MHz transmit clock for the 1000 Mbps mode. TXD,
TX_EN, and TX_ER signals are synchronized to GTX_CLK.
MDC| Output| GMII management data clock.
MDC_EN| Output| GMII management data enable.
MDO| Output| GMII management data out.
MDI| Input| GMII management data.
Reduced Gigabit Media Independent Interface (RGMII)
RGMII was developed to reduce number of signals required to connect a
10/100/1000 Mbps-capable MAC to a PHY compared to GMII.
The following table lists the RGMII interface signals.
Table 3 • RGMII Interface Signals
Signal | Direction | Description |
---|---|---|
TXD[3:0] | Output | RGMII transmit data signals for the MAC to supply byte- |
aligned data to the PHY.
RXD[3:0]| Input| RGMII receive data signals for the PHY to transmit byte-
aligned data to the MAC.
CLK_RX| Input| Receive reference clock. 125 MHz for the 1000 Mbps mode, 25 MHz
for the 100 Mbps mode, and 2.5 MHz for the 10 Mbps mode.
CLK_TX| Output| Transmit reference clock. 125 MHz for the 1000 Mbps mode, 25
MHz for the 100 Mbps mode, and 2.5 MHz for the 10 Mbps mode.
TX_CTL| Output| Transmit control.
RX_CTL| Input| Receive control.
Ten-Bit Interface (TBI)
TBI is a parallel interface equivalent to SGMII which connects the PCS to the
PMA. TBI connects to a serial interface such as a transceiver or an IOD CDR.
The following table lists the TBI interface signals.
Table 4 • TBI Interface Signals
Signal | Direction | Description |
---|---|---|
TBI_RX_CLK | Input | 125-MHz recovered clock generated from serial data |
TBI_TX_CLK | Input | 125-MHz transmit clock generated from a transceiver or |
sourced by the local reference clock oscillator
RCG| Input| 10-bit receive code group
TCG| Output| 10-bit transmit code group
MDI| Input| MDIO management data input from pad
MDC| Output| MDIO management data clock
MDO| Output| MDIO management data output
MDOEN| Output| MDIO management data output enable
Appendix 2: Ethernet Frame Format
Ethernet data is encapsulated in frames consisting of a preamble, a start-of- frame delimiter (SFD), and the actual frame starting from the destination address and ending with the frame check sequence (FCS) field. The bytes within each field in an Ethernet frame are transmitted from left to right, going from the least significant bit to the most significant bit. A typical Ethernet frame’s data length is between 0 bytes to 1500 bytes. Frames with data lengths greater than 1500 bytes are called jumbo Ethernet frames. The actual Ethernet frame begins after the SFD. The following illustration shows the format of a standard Ethernet frame.
Figure 19 • Standard Ethernet Frame Format
The Ethernet MAC also accepts virtual local area network (VLAN) frames. VLANs are specified in the IEEE 802.1Q. A virtual, bridged LAN logically groups the network devices that share the same physical network. This way, the network traffic in a VLAN group is only visible to those devices that are members of that network group. For VLAN-type frames, the Ethernet MAC accepts four bytes more than a standard Ethernet frame. The following illustration shows the format of an Ethernet VLAN frame.
Figure 20 • Ethernet VLAN Frame Format
The following sections describe the individual fields in an Ethernet frame.
Preamble
The preamble field synchronizes receiver clocks within a network and contains
seven bytes, with the pattern 0x55, transmitted from left to right. During
transmission on the physical interface, this field is automatically inserted
by the Ethernet MAC. On reception, it is stripped from the incoming frame
before the data is passed to the MAC client. The MAC can receive Ethernet
frames even if the preamble does not exist, as long as a valid SFD is
available.
SFD
The SFD field marks the start of the Ethernet frame and must follow the
pattern 0xD5. For transmission, this field is automatically inserted by the
Ethernet MAC. On reception, it is stripped from the incoming frame before the
data is passed to the MAC client.
MAC Address Fields
The MAC address is a unique identifier assigned to PHY interfaces to allow
devices to communicate over the network. A MAC address can either be a source
address or a destination address, depending on whether it is transmitting the
frame or receiving it:
- Destination address—the MAC address of the frame’s intended recipient on the network. It is the first field in an Ethernet frame that is transmitted and received between stations.
- Source address—the MAC address of the frame’s initiator on the network. It is the second field in an Ethernet frame.
The least significant bit of a MAC address determines if a MAC address is an individual (unicast) address, a group (multicast) address, or a broadcast address.
- An individual address, also known as a unicast address, is specific to a station (device) on the network. For this address type, the destination address ends with 0.
- A group address, also known as a multicast address, is used to group logically-related stations. For this address type, the destination address ends with 1.
- A broadcast address is a multicast address used to group all stations on the LAN. For this address type, the destination address field has all 1s.
The Ethernet MAC supports transmission and reception of unicast, multicast, and broadcast packets. During transmission, the bit representing the individual or group (multicast) address is the first bit to appear in the address field of an Ethernet frame.
VLAN Tag (for VLAN Frames Only)
A VLAN tag field consists of the VLAN ID inserted into a packet header to
identify the VLAN the packet belongs to. Based on the VLAN ID, switches
determine the port or interface to which the broadcast packet needs to be
sent.
Length/Type
The value of this field determines if it is interpreted as a length field or a
type field as defined by
IEEE 802.3-2012. The MAC interprets a value of 1500 bytes or less as a length
field, and a value of 1536 bytes or more as a type field. A length field
represents the number of bytes in the following data field. This value
excludes any bytes inserted in the pad field following the data field. A
length/type field value of 0x8100 indicates a VLAN frame, and a value of
0x8808 indicates a PAUSE MAC control frame.
During transmission, the Ethernet MAC does not process the length/type field. On reception, if this field is a length field, the Ethernet MAC’s receive engine interprets this value and removes any padding that may be displayed in the pad field.
If the field is a length field and length/type checking is enabled in the Ethernet MAC, the MAC compares the length against the actual data field length and flags an error if a mismatch occurs. If the field is a type field, the Ethernet MAC ignores the value and simply passes it along with the packet data with no further processing. The length/type field is retained in the receive packet data.
Data
For a normal frame, the data field can vary from 0 to 1,500 bytes in length.
The Ethernet MAC can handle jumbo frames of any length. This field is provided
in the packet data for transmissions and retained in the receive packet data.
Pad
The pad field ensures that the Ethernet frame is at least 64 bytes in length.
This is the minimum length required for successful CSMA/CD operation. The
field can vary from 0 to 46 bytes in length.
Appendix 3: Glossary
This section defines common terms associated with Ethernet architecture used
in this document.
Note: This section does not define MAC sublayers, standard Ethernet
interfaces, and Ethernet frame fields, which are described in previous
sections.
Table 5 • Common Ethernet Terms
Term / Definition
- 10/100/1000BASE-T
- 10BASE-T, 100BASE-T, and 1000BASE-T are networking standards that support data transfer rates of up to 10 Mbps, 100 Mbps, and 1000 Mbps respectively over twisted-pair Ethernet cables.
- 1000BASE-X
- 1000BASE-X is a group of Ethernet physical layer standards used for gigabit Ethernet connections that transmit data, typically over fiber-optic cables and sometimes over copper-shielded cables.
- HPC connector
- A high pin count (HPC) connector is an FMC connector that allows the board to be connected to an external PHY.
- Physical layer (PHY)
- The PHY is the physical layer of the MAC, which, when instantiated, connects a link layer device (often called a MAC) to a physical medium such as an optical fiber or a copper cable.
- RJ45
- RJ45 is a type of connector commonly used in Ethernet networks to transmit and receive data from the Ethernet PHY over an Ethernet cable.
- SFP
- A small form factor pluggable (SFP) connector, commonly known as an SFP, is a compact, hot-pluggable transceiver (transmitter and receiver in a single package) used for carrying data over optical or copper wires.
- Transceiver
- A transceiver is a pair of functional blocks that converts serial data to parallel data and vice versa. The primary use of a transceiver is to provide data transmission over a single or differential line, thereby minimizing the number of I/O pins and interconnects required for the design.
- IOD CDR
- An IOD CDR is an I/O digital logic block with clock and data recovery. Each PolarFire FPGA I/O is composed of an analog I/O buffer (referred to as IOA) and a digital logic block (referred to as IOD). The IOD block interfaces with the FPGA fabric on one side and the IOA buffers on the other side and handles gearing (serial-to-parallel and parallel-to-serial conversion) of multiple FPGA fabric data bits to and from a single device I/O, allowing the clock frequency to be divided between the I/O and the fabric.
Microsemi Proprietary UG0687 Revision 5.0
References
- Microsemi | Semiconductor & System Solutions | Power Matters
- Microsemi | Semiconductor & System Solutions | Power Matters
- Microsemi | Semiconductor & System Solutions | Power Matters
- microsemi.com/index.php?option=com_docman&task=doc_download&gid=136531
- microsemi.com/index.php?option=com_docman&task=doc_download&gid=136535
- Microsemi | Semiconductor & System Solutions | Power Matters
- IP Core Tools | Microchip Technology
- Libero® SoC Design Suite Versions 2022.3 to 12.0 | Microchip Technology
- Microsemi | Microsemi
Read User Manual Online (PDF format)
Read User Manual Online (PDF format) >>