Low Latency 40- and 100-Gbps Ethernet MAC and PHY MegaCore Function User Guide
About the Low Latency 40- and 100-Gbps Ethernet MAC and PHY IP Core
The Altera® Low Latency 40- and 100-Gbps Ethernet (40GbE and 100GbE) media access controller (MAC) and PHY MegaCore® functions offer the lowest round-trip latency and smallest size to implement the IEEE 802.3ba 40G and 100G Ethernet Standard with an option to support the IEEE 802.3ap-2007 Backplane Ethernet Standard.
The version of this product that supports Arria® 10 devices is included in the Altera MegaCore® IP Library and available from the Quartus® Prime IP Catalog.
As illustrated, on the MAC client side you can choose a wide, standard Avalon® Streaming (Avalon-ST) interface, or a narrower, custom streaming interface. Depending on the variant you choose, the MAC client side Avalon Streaming (Avalon-ST) interface is either 256 or 512 bits of data mapped to either four or ten 10.3125 Gbps transceiver PHY links, depending on data rate, or to four 25.78125 Gbps transceiver PHY links.
The 40GbE (XLAUI) interface has 4x10.3125 Gbps links. The 100GbE (CAUI) interface has 10x10.3125 Gbps links. For Arria 10 devices only, you can configure a 40GbE 40GBASE-KR4 variation to support Backplane Ethernet. For Arria 10 GT devices only, you can configure a 100GbE CAUI-4 option, with 4x25.78125 Gbps links.
The FPGA serial transceivers are compliant with the IEEE 802.3ba standard XLAUI, CAUI, and CAUI-4 specifications. The IP core configures the transceivers to implement the relevant specification for your IP core variation. You can connect the transceiver interfaces directly to an external physical medium dependent (PMD) optical module or to another device.
The IP core provides standard MAC and physical coding sublayer (PCS) functions with a variety of configuration and status registers. You can exclude the statistics registers. If you exclude these registers, you can monitor the statistics counter increment vectors that the IP core provides at the client side interface and maintain your own counters.
Low Latency 40- and 100-Gbps Ethernet MAC and PHY IP Core Supported Features
All LL 40-100GbE IP core variations include both a MAC and a PHY, and all variations are in full-duplex mode. These IP core variations offer the following features:
- Designed to the IEEE 802.3ba-2010 High Speed Ethernet Standard available on the IEEE website (www.ieee.org).
- Soft PCS logic that interfaces seamlessly to Altera 10.3125 Gbps and 25.78125 Gbps serial transceivers.
- Standard XLAUI or CAUI external interface consisting of FPGA hard serial transceiver lanes operating at 10.3125 Gbps , or the CAUI-4 external interface consisting of four FPGA hard serial transceiver lanes operating at 25.78125 Gbps.
- Supports 40GBASE-KR4 PHY based on 64B/66B encoding with data striping and alignment markers to align data from multiple lanes.
- Supports 40GBASE-KR4 PHY and forward error correction (FEC) option for interfacing to backplanes.
- Supports Synchronous Ethernet (Sync-E) by providing an optional CDR recovered clock output signal to the device fabric.
- Avalon Memory-Mapped (Avalon-MM) management interface to access the IP core control and status registers.
- Avalon-ST data path interface connects to client logic with the start of frame in the most significant byte (MSB) when optional adapters are used. Interface has data width 256 or 512 bits depending on the data rate.
- Optional custom streaming data path interface with narrower bus width and a start frame possible on 64‑bit word boundaries without the optional adapters. Interface has data width 128 or 256 bits depending on the data rate.
- Support for jumbo packets.
- TX and RX CRC pass-through control.
- Optional TX CRC generation and insertion.
- RX CRC checking and error reporting.
- TX error insertion capability supports test and debug.
- RX and TX preamble pass-through options for applications that require proprietary user management information transfer.
- TX automatic frame padding to meet the 64-byte minimum Ethernet frame length at the LL 40-100GbE Ethernet connection.
- Hardware and software reset control.
- Pause frame filtering control.
- Received control frame type indication.
- MAC provides cut-through frame processing.
- Optional deficit idle counter (DIC) options to maintain a finely controlled 8-byte or 12-byte inter-packet gap (IPG) minimum average.
- Optional IEEE 802.3 Clause 31 Ethernet flow control operation using the pause registers or pause interface.
- Optional priority-based flow control that complies with the IEEE Standard 802.1Qbb-2011—Amendment 17: Priority-based Flow Control, using the pause registers for fine control.
- RX PCS lane skew tolerance that exceeds the IEEE 802.3-2012 Ethernet standard clause 82.2.12 requirements: 1900 bits RX lane skew tolerance for LL 40GbE IP cores and 1000 bits RX lane skew tolerance for LL 100GbE IP cores.
- Optional support for the IEEE Standard 1588-2008 Precision Clock Synchronization Protocol (1588 PTP).
- Optional statistics counters.
- Optional f ault signaling: detects and reports local fault and generates remote fault, with IEEE 802.3ba-2012 Ethernet Standard Clause 66 support.
- Optional serial PMA loopback (TX to RX) at the serial transceiver for self-diagnostic testing.
- Optional access to Altera Debug Master Endpoint (ADME) for debugging or monitoring PHY signal integrity.
The LL 40-100GbE IP core can support full wire line speed with a 64-byte frame length and back-to-back or mixed length traffic with no dropped packets.
For a detailed specification of the Ethernet protocol refer to the IEEE 802.3ba-2010 High Speed Ethernet Standard.
Low Latency 40-100GbE IP Core Device Family and Speed Grade Support
The following sections list the device family and device speed grade support offered by the Low Latency 40‑100GbE IP core:
Device Family Support
Device Support Level |
Definition |
---|---|
Preliminary |
The IP core is verified with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. It can be used in production designs with caution. |
Final |
The IP core is verified with final timing models for this device family. The IP core meets all functional and timing requirements for the device family and can be used in production designs. |
Device Family |
Support |
---|---|
Stratix® V (GX, GT, and GS) |
Final |
Arria 10 (GX, GT, and GS) |
Refer to What's New in IP webpage |
Other device families |
Not supported |
Low Latency 40-100GbE IP Core Device Speed Grade Support
MegaCore Function |
Device Family |
Supported Speed Grades |
---|---|---|
40GbE |
Stratix V (GX) |
I3, C3 |
Stratix V (GT) |
I3, C2 |
|
Stratix V (GS) |
I3, C3 |
|
Arria 10 (GX, GT, GS) |
I2, C2 |
|
40GbE (40GBASE-KR4 option) |
Arria 10 (GX, GT, GS) |
I2, C2 |
100GbE |
Stratix V (GX) |
I2, C2 |
Stratix V (GT) |
I2, C2 |
|
Stratix V (GS) |
I2, C2 |
|
Arria 10 (GX, GT, GS) |
I2, C2 |
|
100GbE (CAUI–4 option) |
Arria 10 GT |
I2, C2 |
IP Core Verification
To ensure functional correctness of the Low Latency 40‑100GbE IP core, Altera performs extensive validation through both simulation and hardware testing. Before releasing a version of the Low Latency 40- and 100-Gbps Ethernet MAC and PHY IP core, Altera runs comprehensive regression tests in the current or associated version of the Quartus® Prime software.
Simulation Environment
Altera performs the following tests on the Low Latency 40-100GbE MAC and PHY IP core in the simulation environment using internal and third party standard bus functional models (BFM):
- Constrained random tests that cover randomized frame size and contents
- Randomized error injection tests that inject Frame Check Sequence (FCS) field errors, runt packets, and corrupt control characters, and then check for the proper response from the IP core
- Assertion based tests to confirm proper behavior of the IP core with respect to the specification
- Extensive coverage of our runtime configuration space and proper behavior in all possible modes of operation
Compilation Checking
Altera performs compilation testing on an extensive set of Low Latency 40-100GbE MAC and PHY IP core variations and designs that target different devices, to ensure the Quartus Prime software places and routes the IP core ports correctly.
Hardware Testing
Altera performs hardware testing of the key functions of the Low Latency 40-100GbE MAC and PHY IP core using standard 40-100Gbps Ethernet network test equipment and optical modules. The Altera hardware tests of the Low Latency 40‑100GbE IP core also ensure reliable solution coverage for hardware related areas such as performance, link synchronization, and reset recovery. The IP core is tested with Stratix V devices.
Performance and Resource Utilization
The following sections provide performance and resource utilization data for the Low Latency 40GbE and 100GbE IP cores.
IP Core Variation | A | B | C | D | E | F |
---|---|---|---|---|---|---|
Parameter | ||||||
Data interface | Custom-ST | Avalon-ST | Avalon-ST | Avalon-ST | Avalon-ST | Avalon-ST |
Flow control mode | No flow control | No flow control | Standard flow control | Standard flow control | No flow control | No flow control |
Average interpacket gap | 12 | 12 | 12 | 12 | 12 | 12 |
Enable 1588 PTP | — | — | — | On | — | — |
Enable link fault generation | — | — | On | On | — | — |
Enable TX CRC insertion | — | On | On | On | On | On |
Enable preamble passthrough | — | — | On | On | — | — |
Enable alignment EOP on FCS word | — | On | On | On | On | On |
Enable TX statistics | — | On | On | On | On | On |
Enable RX statistics | — | On | On | On | On | On |
Enable KR4 | — | — | — | — | On | On |
Include FEC sublayer | — | — | — | — | — | On |
Stratix V Resource Utilization for Low Latency 40-100GbE IP Cores
Resource utilization changes depending on the parameter settings you specify in the Low Latency 40-100GbE parameter editor. For example, if you turn on pause functionality or statistics counters in the LL 40-100GbE parameter editor, the IP core requires additional resources to implement the additional functionality.
40GbE Variation |
ALMs |
Dedicated Logic Registers |
Memory M20K |
---|---|---|---|
40GbE variation A |
5300 |
12800 |
13 |
40GbE variation B |
9900 |
21500 |
13 |
40GbE variation C | 10900 | 24100 | 13 |
40GbE variation D |
14000 |
31000 |
17 |
100GbE Variation |
ALMs |
Dedicated Logic Registers |
Memory M20K |
100GbE variation A |
9500 | 23000 | 29 |
100GbE variation B |
20900 | 48400 | 61 |
100GbE variation C | 22100 | 52500 | 61 |
100GbE variation D |
26900 | 63700 | 65 |
Arria 10 Resource Utilization for Low Latency 40-100GbE IP Cores
Resource utilization changes depending on the parameter settings you specify in the Low Latency 40-100GbE parameter editor. For example, if you turn on pause functionality or statistics counters in the LL 40-100GbE parameter editor, the IP core requires additional resources to implement the additional functionality.
40GbE Variation |
ALMs |
Dedicated Logic Registers |
Memory M20K |
---|---|---|---|
40GbE variation A |
5400 | 12800 | 13 |
40GbE variation B |
10100 | 21200 | 13 |
40GbE variation C | 11000 | 24100 | 13 |
40GbE variation D |
14200 | 31100 | 17 |
40GbE variation E |
14400 | 28200 | 26 |
40GbE variation F | 16300 | 29300 | 26 |
100GbE Variation |
ALMs |
Dedicated Logic Registers |
Memory M20K |
100GbE variation A |
13100 | 29000 | 29 |
100GbE variation B |
21200 | 47600 | 61 |
100GbE variation C | 22500 | 51800 | 61 |
100GbE variation D |
27000 | 63200 | 65 |
CAUI-4 Variation |
ALMs |
Dedicated Logic Registers |
Memory M20K |
CAUI-4 variation B |
22700 | 51300 | 61 |
Release Information
Item |
Description |
|
---|---|---|
Version |
16.0 |
|
Release Date |
2016.05.02 |
|
Ordering Codes |
Low Latency 40G Ethernet MAC and PHY: IP-40GEUMACPHY Low Latency 40G Ethernet MAC and PHY with 1588: IP-40GEUMACPHYF Low Latency 100G Ethernet MAC and PHY: IP-100GEUMACPHY Low Latency 100G Ethernet MAC and PHY with 1588: IP-100GEUMACPHYF Low Latency 40G Ethernet MAC and 40GBASE-KR4 PHY with FEC: IP-40GBASEKR4PHY |
|
Product ID |
Low Latency 40G Ethernet MAC and PHY: 011B Low Latency 40G Ethernet MAC and PHY with 1588: 011C Low Latency 100G Ethernet MAC and PHY: 011A Low Latency 100G Ethernet MAC and PHY with 1588: 011D Low Latency 40G Ethernet MAC and 40GBASE-KR4 PHY with FEC: 0113 |
|
Vendor ID |
6AF7 |
Getting Started
The following sections explain how to install, parameterize, simulate, and initialize the Low Latency 40‑100GbE IP core:
- Installation and Licensing for LL 40-100GbE IP Core for Stratix V Devices
The Low Latency 40-100GbE IP core that targets a Stratix V device is an extended IP core which is not included with the Quartus Prime release. This section provides a general overview of the Altera extended IP core installation process to help you quickly get started with any Altera extended IP core. - Licensing IP Cores
The Low Latency 40-100GbE IP core that targets an Arria 10 device is a standard Altera IP core in the Altera IP Library. - Specifying the Low Latency 40-100GbE IP Core Parameters and Options
The LL 40-100GbE IP core for Arria 10 devices supports a standard customization and generation process from the Quartus Prime IP Catalog. After you install and integrate the extended IP core in the ACDS release, the LL 40-100GbE IP core for Stratix V devices also supports the standard customization and generation process. The Low Latency 40-100GbE IP core is not supported in Qsys. - IP Core Parameters
The Low Latency 40-100GbE parameter editor provides the parameters you can set to configure the Low Latency 40-100GbE IP core and simulation and hardware design examples. - Files Generated for Stratix V Variations
The Quartus Prime software generates the following output for your Stratix V LL 40-100GbE IP core. - Files Generated for Arria 10 Variations
The Quartus Prime software generates the following IP core output file structure when targeting Arria 10 devices. - Integrating Your IP Core in Your Design
- Low Latency 40-100GbE IP Core Testbenches
Altera provides a testbench , a hardware design example, and a compilation-only example design with most variations of the Low Latency 40-100GbE IP core. The testbench is available for simulation of your IP core, and the hardware design example can be run on hardware. You can run the testbench to observe the IP core behavior on the various interfaces in simulation. - Simulating the Low Latency 40‑100GbE IP Core With the Testbenches
- Compiling the Full Design and Programming the FPGA
- Initializing the IP Core
Installation and Licensing for LL 40-100GbE IP Core for Stratix V Devices
The Low Latency 40-100GbE IP core that targets the Stratix V device family is an extended IP core which is not included with the Quartus Prime release. This section provides a general overview of the Altera extended IP core installation process to help you quickly get started with any Altera extended IP core.
The Altera extended IP cores are available from the Altera Self-Service Licensing Center (SSLC). Refer to Related Links below for the correct link for this IP core.
You can evaluate an IP core in simulation and in hardware until you are satisfied with its functionality and performance. You must purchase a license for the IP core when you want to take your design to production. After you purchase a license for an Altera IP core, you can request a license file from the Altera Licensing page of the Altera website and install the license on your computer.
Licensing IP Cores
OpenCore Plus IP Evaluation
- Simulate the behavior of a licensed IP core in your system.
- Verify the functionality, size, and speed of the IP core quickly and easily.
- Generate time-limited device programming files for designs that include IP cores.
- Program a device with your IP core and verify your design in hardware.
OpenCore Plus evaluation supports the following two operation modes:
- Untethered—run the design containing the licensed IP for a limited time.
- Tethered—run the design containing the licensed IP for a longer time or indefinitely. This requires a connection between your board and the host computer.
Specifying the Low Latency 40-100GbE IP Core Parameters and Options
- In the IP Catalog (Tools > IP Catalog), select a target device family.
- In the IP Catalog, locate and double-click the name of the IP core to customize. The New IP Variation window appears.
- Specify a top-level name for your custom IP variation. The parameter editor saves the IP variation settings in a file named <your_ip> .qsys (for Arria 10 variations) or <your_ip> .qip (for Stratix V variations).
- If your IP core targets the Arria 10 device family, you must select a specific device in the Device field or maintain the default device the Quartus Prime software lists. If you target a specific Altera development kit, the hardware design example overwrites the selection with the device on the target board.
- Click OK. The parameter editor appears.
-
Specify the
parameters and options for your IP variation in the parameter editor, including
one or more of the following. Refer to your IP core user guide for information
about specific IP core parameters.
- Specify parameters defining the IP core functionality, port configurations, and device-specific features.
- Specify options for processing the IP core files in other EDA tools.
-
For Arria 10 variations, follow these steps:
- Optionally, to generate a simulation testbench or example project, follow the instructions in Generating the Low Latency 40-100GbE Testbench.
- Click Generate HDL. The Generation dialog box appears.
- Specify output file generation options, and then click Generate. The IP variation files generate according to your specifications.
- Click Finish. The parameter editor adds the top-level .qsys file to the current project automatically. If you are prompted to manually add the .qsys file to the project, click Project > Add/Remove Files in Project to add the file.
-
For Stratix V
variations, follow these steps:
- Click Finish.
-
Optionally, to generate a
simulation testbench or example project, follow the instructions in
Generating the Low Latency 40-100GbE Testbench.
After you click Finish and optionally follow the additional step to generate a simulation testbench and example project, if available for your IP core variation, the parameter editor adds the top-level .qsys file or top-level .qip file to the current project automatically. If you are prompted to manually add the .qip file to the project, click Project > Add/Remove Files in Project to add the file.
- After generating and instantiating your IP variation, make appropriate pin assignments to connect ports.
IP Core Parameters
The Low Latency 40-100GbE parameter editor provides the parameters you can set to configure the Low Latency 40-100GbE IP core and simulation and hardware design examples.
LL 40-100GbE IP core variations that target an Arria 10 device include an Example Design tab.
Parameter |
Type |
Range |
Default Setting |
Parameter Description |
---|---|---|---|---|
General Options |
||||
Device family |
String |
|
According to the setting in the project or IP Catalog settings. |
Selects the device family. |
Protocol speed |
String |
|
100 GbE |
Selects the MAC datapath width. |
Data interface |
String |
|
Avalon–ST |
Selects the Avalon–ST interface or the narrower, custom streaming client interface to the MAC. If you select the custom streaming client interface, the Flow control mode and Enable 1588 PTP parameters are not available. |
PCS/PMA Options |
||||
Boolean |
|
False |
If turned on, the IP core is a 100GbE CAUI-4 variation, with four 25.78125 Gbps transceiver PHY links. |
|
Enable SyncE |
Boolean |
|
False |
Exposes the RX recovered clock as an output signal. This feature supports the Synchronous Ethernet standard described in the ITU-T G.8261, G.8262, and G.8264 recommendations. This parameter is available only in variations that target an Arria 10 device. |
PHY reference frequency |
Integer (encoding) |
|
644.53125 MHz |
Sets the expected incoming PHY clk_ref reference frequency. The input clock frequency must match the frequency you specify for this parameter (± 100ppm). |
Use external TX MAC PLL | Boolean |
|
False | If you turn this option on, the IP core is configured to expect an input clock to drive the TX MAC. The input clock signal is clk_txmac_in. |
Flow Control Options |
||||
Flow control mode |
String |
|
No flow control |
Configures the flow control mechanism the IP core implements. Standard flow control is Ethernet standard flow control. If you select the custom streaming client interface, the IP core must be configured with no flow control, and this parameter is not available. |
Number of PFC queues |
Integer |
1–8 |
8 |
Number of distinct priority queues for priority-based flow control. This parameter is available only if you set Flow control mode to Priority-based flow control. |
Average interpacket gap |
String |
|
12 |
If you set the value of this parameter to 8 or to 12, the IP core includes a deficit idle counter (DIC), which maintains an average interpacket gap (IPG) of 8 or 12, as you specify. If you set the value of this parameter to Disable deficit idle counter, the IP core is configured without the DIC, and does not maintain the required minimum average IPG. The Ethernet standard requires a minimum average IPG of 12. Turning off Average interpacket gap increases bandwidth. |
MAC Options |
||||
Enable 1588 PTP |
Boolean |
|
False |
If turned on, the IP core supports the IEEE Standard 1588-2008 Precision Clock Synchronization Protocol, by providing the hooks to implement the Precise Timing Protocol (PTP). If you select the custom streaming client interface, the IP core must be configured without 1588 support, and this parameter is not available. |
Enable 96b Time of Day Format | Boolean |
|
True | Include the 96-bit interface to
the TOD module. If you turn on this parameter, the TOD module that
is generated with the IP core has a matching 96-bit timestamp
interface.
If Enable 1588 PTP is turned on, you must turn on at least one of Enable 96b Time of Day Format and Enable 64b Time of Day Format. You can turn on both Enable 96b Time of Day Format and Enable 64b Time of Day Format to generate a TOD interface for each format. This parameter is available only in variations with Enable 1588 PTP turned on. |
Enable 64b Time of Day Format | Boolean |
|
False | Include the 64-bit interface to
the TOD module. If you turn on this parameter, the TOD module that
is generated with the IP core has a matching 64-bit timestamp
interface.
If Enable 1588 PTP is turned on, you must turn on at least one of Enable 96b Time of Day Format and Enable 64b Time of Day Format. You can turn on both Enable 96b Time of Day Format and Enable 64b Time of Day Format to generate a TOD interface for each format. This parameter is available only in variations with Enable 1588 PTP turned on. |
Timestamp fingerprint width | Integer | 1–16 | 1 | Specifies the number of bits in
the fingerprint that the IP core handles.
This parameter is available only in variations with Enable 1588 PTP turned on. |
Enable link fault generation |
Boolean |
|
False |
If turned on, the IP core includes the link fault signaling modules and relevant signals. If turned off, the IP core is configured without these modules and without these signals. Turning on link fault signaling provides your design a tool to improve reliability, but increases resource utilization. |
Enable TX CRC insertion |
Boolean |
|
True |
If turned on, the IP core inserts a 32-bit Frame Check Sequence (FCS), which is a CRC-32 checksum, in outgoing Ethernet frames. If turned off, the IP core does not insert the CRC-32 sequence in outgoing Ethernet communication. Turning on TX CRC insertion improves reliability but increases resource utilization and latency through the IP core. If you turn on flow control, the IP core must be configured with TX CRC insertion, and this parameter is not available. |
Enable preamble passthrough |
Boolean |
|
False |
If turned on, the IP core is in RX and TX preamble pass-through mode. In RX preamble pass-through mode, the IP core passes the preamble and SFD to the client instead of stripping them out of the Ethernet packet. In TX preamble pass-through mode, the client specifies the preamble to be sent in the Ethernet frame. |
Enable alignment EOP on FCS word |
Boolean |
|
True |
If turned on, the IP core aligns the 32-bit Frame Check Sequence (FCS) error signal with the assertion of the EOP by delaying the RX data bus to match the latency of the FCS computation. If turned off, the IP core does not delay the RX data bus to match the latency of the FCS computation. If the parameter is turned off, the FCS error signal, in the case of an FCS error, is asserted in a later clock cycle than the relevant assertion of the EOP signal. Altera recommends that you turn on this option. Otherwise, the latency between the EOP indication and assertion of the FCS error signal is non-deterministic. You must turn on this parameter if your design relies on the rx_inc_octetsOK signal.. |
Enable TX statistics |
Boolean |
|
True |
If turned on, the IP core includes built–in TX statistics counters. If turned off, the IP core is configured without TX statistics counters. In any case, the IP core is configured with TX statistics counter increment output vectors. |
Enable RX statistics |
Boolean |
|
True |
If turned on, the IP core includes built–in RX statistics counters. If turned off, the IP core is configured without RX statistics counters. In any case, the IP core is configured with RX statistics counter increment output vectors. |
Configuration, Debug and Extension Options |
||||
Enable Altera Debug Master Endpoint (ADME) |
Boolean |
|
False |
If turned on, the IP core turns on the following features in the Arria 10 PHY IP core that is included in the LL 40-100GbE IP core:
If turned off, the IP core is configured without these features. This parameter is available only in variations that target an Arria 10 device. For information about these Arria 10 features, refer to the Arria 10 Transceiver PHY User Guide. |
Parameter |
Type |
Range |
Default Setting |
Parameter Description |
---|---|---|---|---|
KR4 General Options |
||||
Enable KR4 |
Boolean |
|
False |
If this parameter is turned on, the IP core is a 40GBASE-KR4 variation. If this parameter is turned off, the IP core is not a 40GBASE-KR4 variation, and the other parameters on this tab are not available. |
Status clock rate | Frequency range | 100–125 MHz | 100 MHz | Sets the expected incoming
clk_status frequency. The
input clock frequency must match the frequency you specify for this
parameter.
The IP core is configured with this information:
This parameter determines the PHY Management clock (MGMT_CLK) frequency in MHz parameter of the underlying 10GBASE-KR PHY IP core. However, the default value of the Status clock rate parameter is not identical to the default value of the PHY IP core PHY Management clock (MGMT_CLK) frequency in MHz parameter. |
Auto-Negotiation |
||||
Enable Auto-Negotiation |
Boolean |
|
True |
If this parameter is turned on, the IP core includes logic to implement auto-negotiation as defined in Clause 73 of IEEE Std 802.3ap–2007. If this parameter is turned off, the IP core does not include auto-negotiation logic and cannot perform auto-negotiation. Currently the IP core can only negotiate to KR4 mode. |
Link fail inhibit time for 40Gb Ethernet |
Integer (Unit: ms) |
500–510 ms |
504 ms |
Specifies the time before link status is set to FAIL or OK. A link fails if the time duration specified by this parameter expires before link status is set to OK. For more information, refer to Clause 73 Auto-Negotiation for Backplane Ethernet in IEEE Standard 802.3ap–2007. The 40GBASE-KR4 IP core asserts the rx_pcs_ready signal to indicate link status is OK. |
Auto-Negotiation Master |
String |
|
Lane 0 |
Selects the master channel for auto-negotiation. |
Pause ability–C0 |
Boolean |
|
True |
If this parameter is turned on, the IP core indicates on the Ethernet link that it supports symmetric pauses as defined in Annex 28B of Section 2 of IEEE Std 802.3–2008. |
Pause ability–C1 |
Boolean |
|
True |
If this parameter is turned on, the IP core indicates on the Ethernet link that it supports asymmetric pauses as defined in Annex 28B of Section 2 of IEEE Std 802.3–2008. |
Link Training: PMA Parameters |
||||
VMAXRULE |
Integer |
0–31 | 30 |
Specifies the maximum VOD. The default value, 60, represents 1200 mV. |
VMINRULE |
Integer |
0–31 | 6 |
Specifies the minimum VOD. The default value, 9, represents 165 mV. |
VODMINRULE |
Integer |
0–31 | 14 |
Specifies the minimum VOD for the first tap. The default value, 24, represents 440 mV. |
VPOSTRULE |
Integer |
0–25 | 25 |
Specifies the maximum value that the internal algorithm for pre-emphasis will ever test in determining the optimum post-tap setting. |
VPRERULE |
Integer |
0–16 | 16 |
Specifies the maximum value that the internal algorithm for pre-emphasis will ever test in determining the optimum pre-tap setting. |
PREMAINVAL |
Integer |
0–31 | 30 |
Specifies the Preset VOD value. This value is set by the Preset command of the link training protocol, defined in Clause 72.6.10.2.3.1 of IEEE Std 802.3ap–2007. |
PREPOSTVAL |
Integer |
0–25 | 0 |
Specifies the preset Post-tap value. |
PREPREVAL |
Integer |
0–16 | 0 |
Specifies the preset Pre-tap value. |
INITMAINVAL |
Integer |
0–31 | 25 |
Specifies the initial VOD value. This value is set by the Initialize command of the link training protocol, defined in Clause 72.6.10.2.3.2 of IEEE Std 802.3ap–2007. |
INITPOSTVAL |
Integer |
0–25 | 13 |
Specifies the initial Post-tap value. |
INITPREVAL |
Integer |
0–16 | 3 |
Specifies the initial Pre-tap value. |
Link Training: General |
||||
Enable Link Training |
Boolean |
|
True |
If this parameter is turned on, the IP core includes the link training module, which configures the remote link partner TX PMD for the lowest Bit Error Rate (BER). LT is defined in Clause 72 of IEEE Std 802.3ap–2007. |
Maximum bit error count |
Integer |
2n – 1 for n an integer in the range 4–10. | 511 |
Specifies the maximum number of errors on a lane before the Link Training Error bit (40GBASE-KR4 register offset 0xD2, bit 4, 12, 20, or 28, depending on the lane) is set, indicating an unacceptable bit error rate. n is the width of the Bit Error Counter that is configured in the IP core. The value to which you set this parameter determines n, and thus the width of the Bit Error Counter. Because the default value of this parameter is 511, the default width of the Bit Error Counter is 10 bits. You can use this parameter to tune PMA settings. For example, if you see no difference in error rates between two different sets of PMA settings, you can increase the width of the bit error counter to determine if a larger counter enables you to distinguish between PMA settings. |
Number of frames to send before sending actual data |
Integer |
|
127 |
Specifies the number of additional training frames the local link partner delivers to ensure that the link partner can correctly detect the local receiver state. |
FEC Options |
||||
Include FEC sublayer |
Boolean |
|
False |
If this parameter is turned on, the IP core includes logic to implement FEC |
Set FEC_Ability bit on power up or reset |
Boolean |
|
True |
If this parameter is turned on, the IP core
sets the FEC ability bit (40GBASE-KR4 register offset 0xB0, bit 16:
KR FEC enable) on power up
and reset.
This parameter is available if you turn on Include FEC sublayer. |
Set FEC_Enable bit on power up or reset |
Boolean |
|
True |
If this parameter is turned on, the IP core
sets the FEC enable bit (40GBASE-KR4 register offset 0xB0, bit 18:
KR FEC request) on power up
and reset. If you turn on this parameter but do not turn on
Set FEC_ability bit on power up or
reset, this parameter has no effect: the IP core
cannot specify the value of 1 for FEC Requested without specifying
the value of 1 for FEC Ability.
This parameter is available if you turn on Include FEC sublayer. |
Parameter |
40GbE Value 40GBASE-KR4 Value |
100GbE Value |
100GbE at CAUI–4 |
---|---|---|---|
Lanes |
4 |
10 |
4 |
Data rate per lane |
10312.5 Mbps |
10312.5 Mbps |
25781.25 Mbps |
Available PHY reference clock frequencies |
322.265625 MHz 644.53125 MHz |
322.265625 MHz 644.53125 MHz |
322.265625 MHz 644.53125 MHz |
Files Generated for Stratix V Variations
Files Generated for Arria 10 Variations
File Name |
Description |
---|---|
<my_ip>.qsys |
The Qsys system or top-level IP variation file. <my_ip> is the name that you give your IP variation. |
<system>.sopcinfo |
Describes the connections and IP component parameterizations in your Qsys system. You can parse its contents to get requirements when you develop software drivers for IP components. Downstream tools such as the Nios II tool chain use this file. The .sopcinfo file and the system.h file generated for the Nios II tool chain include address map information for each slave relative to each master that accesses the slave. Different masters may have a different address map to access a particular slave component. |
<my_ip>.cmp | The VHDL Component Declaration (.cmp) file is a text file that contains local generic and port definitions that you can use in VHDL design files. |
<my_ip>.html |
A report that contains connection information, a memory map showing the address of each slave with respect to each master to which it is connected, and parameter assignments. |
<my_ip>_generation.rpt | IP or Qsys generation log file. A summary of the messages during IP generation. |
<my_ip>.debuginfo | Contains post-generation information. Used to pass System Console and Bus Analyzer Toolkit information about the Qsys interconnect. The Bus Analysis Toolkit uses this file to identify debug components in the Qsys interconnect. |
<my_ip>.qip |
Contains all the required information about the IP component to integrate and compile the IP component in the Quartus Prime software. |
<my_ip>.csv | Contains information about the upgrade status of the IP component. |
<my_ip>.bsf |
A Block Symbol File (.bsf) representation of the IP variation for use in Quartus Prime Block Diagram Files (.bdf). |
<my_ip>.spd |
Required input file for ip-make-simscript to generate simulation scripts for supported simulators. The .spd file contains a list of files generated for simulation, along with information about memories that you can initialize. |
<my_ip>.ppf | The Pin Planner File (.ppf) stores the port and node assignments for IP components created for use with the Pin Planner. |
<my_ip>_bb.v | You can use the Verilog black-box (_bb.v) file as an empty module declaration for use as a black box. |
<my_ip>.sip | Contains information required for NativeLink simulation of IP components. You must add the .sip file to your Quartus Prime project. |
<my_ip>_inst.v or _inst.vhd | HDL example instantiation template. You can copy and paste the contents of this file into your HDL file to instantiate the IP variation. |
<my_ip>.regmap | If IP contains register information, .regmap file generates. The .regmap file describes the register map information of master and slave interfaces. This file complements the .sopcinfo file by providing more detailed register information about the system. This enables register display views and user customizable statistics in the System Console. |
<my_ip>.svd |
Allows HPS System Debug tools to view the register maps of peripherals connected to HPS within a Qsys system. During synthesis, the .svd files for slave interfaces visible to System Console masters are stored in the .sof file in the debug section. System Console reads this section, which Qsys can query for register map information. For system slaves, Qsys can access the registers by name. |
<my_ip>.v
or <my_ip>.vhd |
HDL files that instantiate each submodule or child IP core for synthesis or simulation. |
mentor/ |
Contains a ModelSim® script msim_setup.tcl to set up and run a simulation. |
aldec/ |
Contains a Riviera-PRO script rivierapro_setup.tcl to setup and run a simulation. |
/synopsys/vcs /synopsys/vcsmx |
Contains a shell script vcs_setup.sh to set up and run a VCS® simulation. Contains a shell script vcsmx_setup.sh and synopsys_ sim.setup file to set up and run a VCS MX® simulation. |
/cadence |
Contains a shell script ncsim_setup.sh and other setup files to set up and run an NCSIM simulation. |
/submodules | Contains HDL files for the IP core submodule. |
<child IP cores>/ | For each generated child IP core directory, Qsys generates /synth and /sim sub-directories. |
Integrating Your IP Core in Your Design
When you integrate your IP core instance in your design, you must pay attention to the following items:
- Pin Assignments
- External Transceiver Reconfiguration Controller Required in Stratix V Designs
- Transceiver PLL Required in Arria 10 Designs
- External Time-of-Day Module for Variations with 1588 PTP Feature
- Clock Requirements for 40GBASE-KR4 Variations
- External TX MAC PLL
- Placement Settings for the Low Latency 40-100GbE IP Core
Pin Assignments
When you integrate your Low Latency 40-100GbE IP core instance in your design, you must make appropriate pin assignments. You can create a virtual pin to avoid making specific pin assignments for top-level signals while you are simulating and not ready to map the design to hardware.
For the Arria 10 device family, you must configure a transceiver PLL that is external to the 40-100GbE IP core. The transceiver PLLs you configure are physically present in the device transceivers, but the LL 40-100GbE IP core does not configure and connect them. The required number of transceiver PLLs depends on the distribution of your Ethernet data pins in the different Arria 10 transceiver blocks.
External Transceiver Reconfiguration Controller Required in Stratix V Designs
You can use the IP Catalog to generate an Altera Transceiver Reconfiguration Controller .
When you configure the Altera Transceiver Reconfiguration Controller, you must specify the number of reconfiguration interfaces. The number of reconfiguration interfaces required for the Low Latency 40GbE and 100GbE IP cores depends on the IP core variation.
PHY Configuration |
Number of Reconfiguration Interfaces |
---|---|
LL 40GbE (4x10.3125 lanes) |
8 |
LL 100GbE (10x10.3125 lanes) |
20 |
You can configure your reconfiguration controller with additional interfaces if your design connects with multiple transceiver IP cores. You can leave other options at the default settings or modify them for your preference.
You should connect the reconfig_to_xcvr, reconfig_from_xcvr, and reconfig_busy ports of the Low Latency 40-100GbE IP core to the corresponding ports of the reconfiguration controller.
You must also connect the mgmt_clk_clk and mgmt_rst_reset ports of the Altera Transceiver Reconfiguration Controller. The mgmt_clk_clk port must have a clock setting in the range of 100–125MHz; this setting can be shared with the Low Latency 40-100GbE IP core clk_status port. The mgmt_rst_reset port must be deasserted before, or deasserted simultaneously with, the Low Latency 40-100GbE IP core reset_async port.
Refer to the example project for RTL that connects the Altera transceiver reconfiguration controller to the IP core..
Signal Name |
Direction |
Description |
---|---|---|
reconfig_to_xcvr[559:0](40GbE) reconfig_to_xcvr[1399:0](100GbE) |
Input |
The Low Latency 40-100GbE IP core reconfiguration controller to transceiver port in Stratix V devices. |
reconfig_from_xcvr[367:0](40GbE) reconfig_from_xcvr[919:0](100GbE) |
Output |
The Low Latency 40-100GbE IP core reconfiguration controller from transceiver port in Stratix V devices. |
reconfig_busy |
Input |
Indicates the reconfiguration controller is still in the process of reconfiguring the transceiver. |
Transceiver PLL Required in Arria 10 Designs
Low Latency 40-100GbE IP cores that target Arria 10 devices require an external TX transceiver PLL to compile and to function correctly in hardware.
In this example, Use external TX MAC PLL is turned off. Therefore, the TX MAC PLL is in the IP core. If you turn on the Use external TX MAC PLL parameter you must also instantiate and connect a TX MAC PLL outside the LL 40-100GbE IP core.
You can use the IP Catalog to create a transceiver PLL.
- Select Arria 10 Transceiver ATX PLL or Arria 10 Transceiver CMU PLL.
- In the parameter editor,
set the following parameter values:
- PLL output frequency to 5156.25 MHz for standard LL 40-100GbE IP core variations or to 12890.625 MHz for CAUI-4 variations. The transceiver performs dual edge clocking, using both the rising and falling edges of the input clock from the PLL. Therefore, this PLL output frequency setting supports a 10.3125 or 25.78125 Gbps data rate through the transceiver.
- PLL reference clock frequency to the value you specified for the PHY reference frequency parameter.
When you generate a Low Latency 40-100GbE IP core, the software also generates the HDL code for an ATX PLL, in the file <variation_name> /arria10_atx_pll.v. However, the HDL code for the Low Latency 40-100GbE IP core does not instantiate the ATX PLL. If you choose to use the ATX PLL provided with the Low Latency 40-100GbE IP core, you must instantiate and connect the instances of the ATX PLL with the LL 40-100GbE IP core in user logic.
The number of external PLLs you must generate or instantiate depends on the distribution of your Ethernet TX serial lines across physical transceiver channels and banks. You specify the clock network to which each PLL output connects by setting the clock network in the PLL parameter editor. The example project demonstrates one possible choice, which is compatible with the ATX PLL provided with the LL 40-100GbE IP core.
You must connect the tx_serial_clk input pin for each Low Latency 40-100GbE IP core PHY link to the output port of the same name in the corresponding external PLL. You must connect the pll_locked input pin of the Low Latency 40-100GbE IP core to the logical AND of the pll_locked output signals of the external PLLs for all of the PHY links.
User logic must provide the AND function and connections. Refer to the example project for example working user logic including one correct method to instantiate and connect an external PLL.
External Time-of-Day Module for Variations with 1588 PTP Feature
Low Latency 40-100GbE IP cores that include the 1588 PTP module require an external time-of-day (TOD) module to provide a continuous flow of current time-of-day information. The TOD module must update the time-of-day output value on every clock cycle, and must provide the TOD value in the V2 format (96 bits) or the 64-bit TOD format, or both..
The example project you can generate for your IP core PTP variation includes a TOD module, implemented as two distinct, simple TOD modules, one connected to the TX MAC and one connected to the RX MAC.
TOD Module Signal | LL 40-100GbE IP Core Signal |
---|---|
rst_txmac (input) | Drive this signal from the same source as the reset_async input signal to the LL 40-100GbE IP core. |
rst_rxmac (input) | Drive this signal from the same source as the reset_async input signal to the LL 40-100GbE IP core. |
tod_txmclk_96b[95:0] (output) | tx_time_of_day_96b_data[95:0] (input) |
tod_txmclk_64b[63:0] (output) | tx_time_of_day_64b_data[63:0] (input) |
tod_rxmclk_96b[95:0] (output) | rx_time_of_day_96b_data[95:0] (input) |
tod_rxmclk_64b[63:0] (output) | rx_time_of_day_64b_data[63:0] (input) |
clk_txmac (input) | clk_txmac (output) |
clk_rxmac (input) | clk_rxmac (output) |
Clock Requirements for 40GBASE-KR4 Variations
In 40GBASE-KR4 IP core designs, you must drive the clocks for the two IP core register interfaces (reconfig_clk and clk_status) from the same clock source.
External TX MAC PLL
If you turn on Use external TX MAC PLL in the LL 40-100GbE parameter editor, you must connect the clk_txmac_in input port to a clock source, usually a PLL on the device.
The clk_txmac_in signal drives the clk_txmac clock in the IP core TX MAC and PHY. If you turn off this parameter, the clk_txmac_in input clock signal is not available.
The required TX MAC clock frequency is 312.5 MHz for 40GbE variations, and 390.625 MHz for 100GbE variations. User logic must drive clk_txmac_in from a PLL whose input is the PHY reference clock, clk_ref.
Placement Settings for the Low Latency 40-100GbE IP Core
The Quartus Prime software provides the options to specify design partitions and LogicLock™ regions for incremental compilation, to control placement on the device. To achieve timing closure for your design, you might need to provide floorplan guidelines using one or both of these features.
The appropriate floorplan is always design-specific, and depends on your full design.
Low Latency 40-100GbE IP Core Testbenches
Altera provides a testbench , a hardware design example, and a compilation-only example design with most variations of the Low Latency 40-100GbE IP core. The testbench is available for simulation of your IP core, and the hardware design example can be run on hardware. You can run the testbench to observe the IP core behavior on the various interfaces in simulation.
Altera offers testbenches for all Avalon-ST client interface variations that generate their own TX MAC clock(Use external TX MAC PLL is turned off).
Currently, the IP core can generate a testbench and example project for variations that use an external TX MAC PLL, but these testbenches and example projects do not function correctly. Non-functional testbenches and example projects provide an example of the connections you must create in your design to ensure the LL 40-100GbE IP core functions correctly. However, you cannot simulate them nor run them in hardware.
To generate the testbench, in the Low Latency 40-100GbE parameter editor, you must first set the parameter values for the IP core variation you intend to generate. If you do not set the parameter values identically, the testbench you generate might not exercise the IP core variation you generate. If your IP core variation does not meet the criteria for a testbench, the generation process does not create a testbench (with the exception of the non-functional testbench generated if an IP core requires an external TX MAC clock signal).
You can simulate the testbench that you generate with your IP core variation. The testbench illustrates packet traffic, in addition to providing information regarding the transceiver PHY. The 40GBASE-KR4 testbench exercises auto-negotiation and link training, in addition to generating and checking packet traffic.
Low Latency 40-100GbE IP Core Testbench Overview
The non-40GBASE-KR4 testbenches send traffic through the IP core in transmit-to-receive loopback mode, exercising the transmit side and receive side of the IP core in the same data flow. These testbenches send traffic to allow the Ethernet lanes to lock, and then send packets to the transmit client data interface and check the data as it returns through the receive client data interface.
File Names |
Description |
---|---|
Testbench and Simulation Files |
|
basic_avl_tb_top.v | Top-level testbench file for non-40GBASE-KR4 variations. The testbench instantiates the DUT and runs Verilog HDL tasks to generate and accept packets. |
alt_e40_avalon_kr4_tb.sv | Top-level testbench file for 40GBASE-KR4 variations. |
alt_e40_avalon_tb_packet_gen.v, alt_e40_avalon_tb_packet_gen_sanity_check.v, alt_e40_stat_cntr_1port.v | Packet generator and checkers for 40GBASE-KR4 variations. |
Testbench Scripts |
|
run_vsim.do |
The ModelSim script to run the testbench. |
run_vcs.sh |
The Synopsys VCS script to run the testbench. |
run_ncsim.sh |
The Cadence NCSim script to run the testbench. |
The markers in the figure show the following sequence of events:
- At marker 1, the application asserts l4_tx_startofpacket, indicating the beginning of a TX packet.
- At marker 2, the application asserts l4_tx_endofpacket, indicating the end of the TX packet. The value on l4_tx_empty[4:0] indicates that the 2 least significant bytes of the last data cycle are empty.
- At marker 3, the IP core asserts l4_rx_startofpacket, indicating the beginning of an RX packet. A second transfer has already started on the TX bus.
- At marker 4, the 40GbE IP core deasserts l4_rx_valid, indicating that the IP core does not have new valid data to send to the client on l4_rx_data[255:0]. l4_rx_data[255:0] remains unchanged for a second cycle, but because the l4_rx_valid signal is deasserted, the client should ignore the value on the RX signals.
- A marker 5, the 40GbE IP core asserts l4_rx_valid, indicating that it has valid data to send to the client on l4_rx_data[255:0].
- At marker 6, the 40GbE IP core deasserts l4_rx_valid, indicating that it does not have new valid data to send to the client on l4_rx_data[255:0]. l4_rx_data[255:0] remains unchanged for a second cycle.
- At marker 7, the 40GbE IP core asserts l4_rx_valid, indicating that it has valid data to send to the client on l4_rx_data[255:0].
- At marker 8, the 40GbE IP core deasserts l4_rx_valid, indicating that the 40GbE IP core does not have new valid data to send to the client on l4_rx_data[255:0]. l4_rx_data[255:0] remains unchanged for a second cycle.
- At marker 9, the IP core asserts l4_rx_endofpacket, indicating the end of the RX packet. l4_rx_empty[4:0] has a value of 0x1D, indicating that 29 least significant bytes of the last cycle of the RX packet empty.
Understanding the Testbench Behavior
The non-40GBASE-KR4 testbenches send traffic through the IP core in transmit-to-receive loopback mode, exercising the transmit side and receive side of the IP core in the same data flow. These testbenches send traffic to allow the Ethernet lanes to lock, and then send packets to the transmit client data interface and check the data as it returns through the receive client data interface.
The 40GBASE-KR4 testbench sends traffic through the two IP cores in each direction, exercising the receive and transmit sides of both IP cores. This testbench exercises auto-negotiation and link training, and then sends and checks packets in data mode.
The Low Latency 40-100GbE IP core implements virtual lanes as defined in theIEEE 802.3ba-2010 40G and 100G Ethernet Standard. The 40GbE IP cores are fixed at four virtual lanes and each lane is sent over a 10 Gbps physical lane. The 100GbE IP cores are fixed at 20 virtual lanes; the 20 virtual lanes are typically bit-interleaved over ten 10-Gbps physical lanes. When the lanes arrive at the receiver the lane streams are in an undefined order. Each lane carries a periodic PCS-VLANE alignment tag to restore the original ordering. The simulation establishes a random permutation of the physical lanes that is used for the remainder of the simulation.
Within each virtual lane stream, the data is 64B/66B encoded. Each word has two framing bits which are always either 01 or 10, never 00 or 11. The RX logic uses this pattern to lock onto the correct word boundaries in each serial stream. The process is probabilistic due to false locks on the pseudo-random scrambled stream. To reduce hardware costs, the receiver does not test alignments in parallel; consequently, the process can be somewhat time-consuming in simulation.
In the 40GBASE-KR4 testbench, some register values are set to produce a shorter runtime. For example, timeout counters and the number of steps used in link training are set to smaller values than would be prudent in hardware. To override this behavior and use the normal settings in simulation, add the following line to your IP core variation top-level file or to the testbench top-level file, alt_e40_avalon_kr4_tb.sv:
`define ALTERA_RESERVED_XCVR_FULL_KR_TIMERS
Both the word lock and the alignment marker lock implement hysteresis as defined in the IEEE 802.3ba-2010 40G and 100G Ethernet Standard. Multiple successes are required to acquire lock and multiple failures are required to lose lock. The “fully locked” messages in the simulation log indicate the point at which a physical lane has successfully identified the word boundary and virtual lane assignment.
In the event of a catastrophic error, the RX PCS automatically attempts to reacquire alignment. The MAC properly identifies errors in the datastream.
Simulating the Low Latency 40‑100GbE IP Core With the Testbenches
You can simulate the Low Latency 40‑100GbE IP core using the Altera-supported versions of the Mentor Graphics ModelSim® SE, Cadence NCSim, and Synopsys VCS simulators for the current version of the Quartus Prime software. The ModelSim-AE simulator does not have the capacity to simulate this IP core.
The example testbenches simulate packet traffic at the digital level. The testbenches do not require special SystemVerilog class libraries.
The top-level testbench file for non-40GBASE-KR4 variations consists of a simple packet generator and checker and one IP core in a loopback configuration.
The top-level testbench file for 40GBASE-KR4 variations consists of a symmetric arrangement with two IP cores and traffic between them. For each IP core there is a packet generator to send traffic on the TX side of the IP core and a packet checker to check the packets it receives from the other IP core. The two IP cores communicate with each other through their Ethernet link, in which the testbench injects random skew. The 40GBASE-KR4 testbench connects each IP core to a transceiver TX PLL, and exercises auto-negotiation, link training, and data mode.
The example testbenches contain the test files and run scripts for the ModelSim, Cadence, and Synopsys simulators. The run scripts use the file lists in the wrapper files. When you launch a simulation from the original directory, the relative filenames in the wrapper files allow the run script to locate the files correctly. When you generate the testbench for a Low Latency 40-100GbE IP core that targets an Arria 10 device, the software generates a copy of the IP core variation with a specific relative path from the testbench scripts.
The following sections provide directions for generating the testbench and running tests with the ModelSim, Cadence, and Synopsys simulators.
- Generating the Low Latency 40-100GbE Testbench
- Optimizing the Low Latency 40‑100GbE IP Core Simulation With the Testbenches
- Simulating with the Modelsim Simulator
- Simulating with the NCSim Simulator
- Simulating with the VCS Simulator
- Testbench Output Example: Low Latency 40-100GbE IP Core
Generating the Low Latency 40-100GbE Testbench
A single procedure generates both the testbench and the example project. The procedure varies depending on your target device. To generate the testbench and example project:
- Follow the steps in Specifying the Low Latency 40-100GbE IP Core Parameters and Options to parameterize your IP core.
- If your IP core variation targets a Stratix V device, go to step 4.
- If your IP core variation targets an Arria 10
device, in the Low Latency 40-100GbE parameter editor, click the Generate
Example Design button to generate the
testbench and example project for the IP core variation you intend to generate.
Tip: You are prompted to locate the new testbench and example project in the directory <working directory>/alt_eth_ultra_0_example_design. You can accept the default path or modify the path to the new testbench and example project.
- Generate the IP core by
clicking Generate HDL for Arria 10
variations or Generate for Stratix V
variations.
Note: If your IP core variation targets a Stratix V device, when prompted at the start of generation, you must turn on Generate example design. Turning on Generate example design is the only process that generates a functional testbench and a functional example project for Stratix V variations.
When the IP core is generated in <working directory>, the testbench and example project are generated in different locations depending on the device family your IP core variation targets.
- For Stratix V variations, the testbench and example project are generated in <working directory>/<IP core variation>_example_design/alt_eth_ultra.
- For Arria 10 variations, the testench and the compilation-only and hardware design examples are generated in the directory you specify in Step 2. If you do not modify the location text at the prompt, they are generated in <working directory>/alt_eth_ultra_0_example_design.
The directory with the testbench and design example has four subdirectories for Arria 10 variations and three subdirectories for Stratix V variations:
- example_testbench
- compilation_test_design
- hardware_test_design
- ex_40g, ex_100g, or ex_100g_caui4, for Arria 10 variations only
The ex_40g, ex_100g, or ex_100g_caui4 directory contains a copy of the IP core variation. The testbench and design examples (compilation-only and hardware design example) for your Arria 10 IP core variation connect to the copy in this directory rather than to the copy you generate in <working directory>.
Optimizing the Low Latency 40‑100GbE IP Core Simulation With the Testbenches
In the testbench file for non-40GBASE-KR4 variations, you can set the FASTSIM parameter and force values in the RO_SELS, BPOS, and WPOS parameters to enable simulation optimization. The testbench also specifies another IP core simulation optimization setting that you might need to modify for simulation in your own environment: AM_CNT_BITS.
To derive the values to which to force the RO_SELS, BPOS, and WPOS parameters, you must run your first simulation with some additional testbench code to display the simulation-derived values. For subsequent simulation runs with the same hardware design and simulator, you can force the values to these simulation-derived values to avoid the lengthy simulation required to achieve lane alignment. The process is particularly slow for this IP core because the IP core includes a soft processor that drives the lane alignment process. Forcing the parameters to the correct values for your design and simulator bypasses this process, increasing simulation efficiency.
The testbench file generated with the Low Latency 40-100GbE IP core includes an initial block that displays the required force values. You can view the appropriate initial block for your IP core variation in the top-level testbench file you generate with your example design.
When you run simulation, this initial block prints values for the three parameters after lane alignment. Copy the values from standard output or from your log file and add the following lines to the testbench file, overwriting other forced values for these parameters if necessary:
defparam dut.top_inst.FASTSIM = 1; defparam dut.<variation_name>_inst.FORCE_BPOS = <required BPOS value>; defparam dut.<variation_name>_inst.FORC_WPOS = <required WPOS value>; defparam dut.<variation_name>_inst.FORCE_RO_SELS = <required RO_SELS value>;
The AM_CNT_BITS parameter specifies the interval between expected alignment markers. The default value of this parameter is 14; this value specifies that alignment markers are inserted every 214 blocks, in compliance with the Ethernet specification. However, the testbench sets this parameter to the value of 6, to speed up simulation. In your own simulation environment, you must set this parameter to match the interval between incoming alignment markers to the IP core.
Simulating with the Modelsim Simulator
To run the simulation in the supported versions of the ModelSim simulation tool, follow these steps:
- Change directory to the <example_design_install_dir>/example_testbench directory.
- In the command line, type: vsim -c -do run_vsim.do
The example testbench will run and pass.
The ModelSim-AE simulator does not have the capacity to simulate this IP core.
Simulating with the NCSim Simulator
To run the simulation in the supported versions of the NCSim simulation tool, follow these steps:
- Change directory to the <example_design_install_dir>/example_testbench directory.
- In the command line, type:
sh run_ncsim.sh
The example testbench will run and pass.
Simulating with the VCS Simulator
To run the simulation in the supported versions of the VCS simulation tool, follow these steps:
- Change directory to the <example_design_install_dir>/example_testbench directory.
- In the command line, type: sh run_vcs.sh
The example testbench will run and pass.
Testbench Output Example: Low Latency 40-100GbE IP Core
This section shows successful simulation using the Low Latency 40-100GbE IP core testbench ( <variation_name> _example_design/alt_eth_ultra/example_testbench/basic_avl_tb_top.v for Stratix V variations, or <example_design_directory> /example_testbench/basic_avl_tb_top.v for Arria 10 variations). The testbench connects the Ethernet TX lanes to the Ethernet RX lanes, so that the IP core is in an external loopback configuration. In simulation, the testbench resets the IP core and waits for lane alignment and deskew to complete successfully. The packet generator sends ten packets on the Ethernet TX lanes and the packet checker checks the packets when the IP core receives them on the Ethernet RX lanes.
The successful testbench run displays the following output:
# ***************************************** # ** Starting TX traffic... # ** # ** # ** Sending Packet 1... # ** Sending Packet 2... # ** Sending Packet 3... # ** Sending Packet 4... # ** Sending Packet 5... # ** Sending Packet 6... # ** Sending Packet 7... # ** Sending Packet 8... # ** Sending Packet 9... # ** Sending Packet 10... # ** Received Packet 1... # ** Received Packet 2... # ** Received Packet 3... # ** Received Packet 4... # ** Received Packet 5... # ** Received Packet 6... # ** Received Packet 7... # ** Received Packet 8... # ** Received Packet 9... # ** Received Packet 10... # ** # ** Testbench complete. # ** # *****************************************
Compiling the Full Design and Programming the FPGA
You can use the Start Compilation command on the Processing menu in the Quartus® Prime software to compile your design. After successfully compiling your design, program the targeted Altera device with the Programmer and verify the design in hardware.
Initializing the IP Core
The testbench initializes the IP core. However, when you simulate or run your own design in hardware, you must implement the initialization steps yourself.
To initialize the 40-100GbE IP core in your own design, follow these steps:
- Drive the clock ports.
- Reset the IP core.
Functional Description
This chapter provides a detailed description of the Low Latency 40‑100GbE IP core. The chapter begins with a high-level overview of typical Ethernet systems and then provides detailed descriptions of the MAC, transmit (TX) and receive (RX) datapaths, signals, register descriptions, and an Ethernet glossary. This chapter includes the following sections:
High Level System Overview
Low Latency 40-100GbE MAC and PHY Functional Description
The Altera Low Latency 40‑100GbE IP core implements the 40‑100GbE Ethernet MAC in accordance with the IEEE 802.3ba 2010 40G and 100G Ethernet Standard. This IP core handles the frame encapsulation and flow of data between a client logic and Ethernet network via a 40‑100GbE Ethernet PCS and PMA (PHY).
In the transmit direction, the MAC accepts client frames, and inserts inter-packet gap (IPG), preamble, start of frame delimiter (SFD), padding, and CRC bits before passing them to the PHY. The PHY encodes the MAC frame as required for reliable transmission over the media to the remote end.
In the receive direction, the PHY passes frames to the MAC. The MAC accepts frames from the PHY, performs checks, updates statistics counters, strips out the CRC, preamble, and SFD, and passes the rest of the frame to the client. In RX preamble pass-through mode, the MAC passes on the preamble and SFD to the client instead of stripping them out. In RX CRC pass-through mode (bit 1 of the CRC_CONFIG register has the value of 1), the MAC passes on the CRC bytes to the client and asserts the EOP signal in the same clock cycle with the final CRC byte.
The Low Latency 40-100GbE IP core includes the following interfaces:
- Datapath
client-interface–The following options are available:
- 40GbE with adapters—Avalon‑ST, 256 bits
- 40GbE—Custom streaming, 128 bits
- 100GbE with adapters—Avalon‑ST, 512 bits
- 100GbE—Custom streaming, 256 bits
- Management interface—Avalon-MM host slave interface for MAC management. This interface has a data width of 32 bits and an address width of 16 bits.
- Datapath Ethernet
interface–The following options are available:
- 40GbE—Four 10.3125 Gbps serial links
- 100GbE—Ten 10.3125 Gbps serial links
- 100GbE CAUI–4—Four 25.78125 Gbps serial links
- In Arria 10 variations, an Arria 10 dynamic reconfiguration interface—an Avalon-MM interface to read and write the Arria 10 Native PHY IP core registers. This interface supports dynamic reconfiguration of the transceiver. Low Latency 40-100GbE IP cores that target an Arria 10 device use the Arria 10 Native PHY IP core to configure the Ethernet link serial transceivers on the device. This interface has a data width of 32 bits. This interface has an address width of 12 bits for 40GbE and 100GbE CAUI-4 variations, and an address width of 14 bits for standard 100GbE variations.
Low Latency 40-100GbE IP Core TX Datapath
The TX MAC module receives the client payload data with the destination and source addresses and then adds, appends, or updates various header fields in accordance with the configuration specified. The MAC does not modify the destination address, the source address, or the payload received from the client. However, the TX MAC module adds a preamble (if the IP core is not configured to receive the preamble from user logic), pads the payload of frames greater than eight bytes to satisfy the minimum Ethernet frame payload of 46 bytes, and if you set Enable TX CRC insertion or turn on flow control, calculates the CRC over the entire MAC frame. (If padding is added, it is also included in the CRC calculation. If you turn off Enable TX CRC insertion, the client must provide the CRC bytes and must provide frames that have a minimum size of 64 bytes and therefore do not require padding). If you set Average interpacket gap to 8 or 12, the TX MAC module inserts IDLE bytes to maintain an average IPG. In addition, the TX MAC inserts an error in the Ethernet frame if the client requests to insert an error.
The Low Latency 40-100GbE IP core does not process incoming frames of less than nine bytes correctly. You must ensure such frames do not reach the TX client interface.
- <p> = payload size, which is arbitrarily large.
- <s> = padding bytes = 0–46 bytes.
- <l> = number of IPG bytes
The following sections describe the functions that the TX module performs:
Preamble, Start, and SFD Insertion
In the TX datapath the MAC appends an eight-byte preamble that begins with a Start byte (0xFB) to the client frame. If you turn on Enable link fault generation, this MAC module also incorporates the functions of the reconciliation sublayer.
The source of the preamble depends on whether you turn on the preamble pass-through feature by turning on Enable preamble passthrough in the Low Latency 40-100GbE parameter editor.
If the preamble pass-through feature is turned on, the client provides the eight-byte preamble (including Start byte) on the data bus. The client is responsible for providing the correct Start byte .
Address Insertion
The client provides the destination MAC address and the source address of the local MAC.
Length/Type Field Processing
This two-byte header represents either the length of the payload or the type of MAC frame. When the value of this field is equal to or greater than 1536 (0x600) it indicates a type field. Otherwise, this field provides the length of the payload data that ranges from 0–1500 bytes. The TX MAC does not modify this field before forwarding it to the network.
Frame Padding
When the length of client frame is less than 64 bytes (meaning the payload is less than 46 bytes) and greater than eight bytes, the TX MAC module inserts pad bytes (0x00) after the payload to create a frame length equal to the minimum size of 64 bytes.
Frame Check Sequence (CRC-32) Insertion
The TX MAC computes and inserts a CRC32 checksum in the transmitted MAC frame. The frame check sequence (FCS) field contains a 32-bit CRC value. The MAC computes the CRC32 over the frame bytes that include the source address, destination address, length, data, and pad (if applicable). The CRC checksum computation excludes the preamble, SFD, and FCS. The encoding is defined by the following generating polynomial:
FCS(X) = X32 +X26 +X23 +X22 +X16 +X12 +X11 +X10 +X8 +X7 +X5 +X4 +X2 +X1 +1
CRC bits are transmitted with MSB (X32) first.
If you configure your Low Latency 40-100GbE IP core with no flow control, you can configure your IP core TX MAC to implement TX CRC insertion or not, by turning Enable TX CRC insertion on or off in the Low Latency 40-100GbE parameter editor. By default, the CRC insertion feature is enabled. In variations with flow control, CRC insertion is enabled.
Inter‑Packet Gap Generation and Insertion
If you set Average interpacket gap to 12 in the Low Latency 40-100GbE parameter editor, t he TX MAC maintains the minimum inter‑packet gap (IPG) between transmitted frames required by the IEEE 802.3 Ethernet standard. The standard requires an average minimum IPG of 96 bit times (or 12 byte times). The deficit idle counter maintains the average IPG of 12 bytes.
If you set Average interpacket gap to 8, the TX MAC maintains a minimum average IPG of 8 bytes. This option is provided as an intermediate option to allow you to enforce an IPG that does not conform to the Ethernet standard, but which increases the throughput of your IP core.
If you set Average interpacket gap to Disable deficit idle counter, the IP core transmits Ethernet packets as soon as the data is available, without maintaining the 12-byte IPG. In this case the IP core maintains only a minimum 1-byte IPG. If you select this parameter value, you optimize the IP core throughput.
Error Insertion Test and Debug Feature
The client can specify the insertion of a TX error in a specific packet. If the client specifies the insertion of a TX error, the LL 40-100GbE IP core inserts an error in the frame it transmits on the Ethernet link. The error appears as a 66-bit error block that consists of eight /E/ characters (EBLOCK_T) in the Ethernet frame.
To direct the IP core to insert a TX error in a packet, the client should assert the TX error insertion signal as follows, depending on the TX client interface:
- On the Avalon-ST TX client interface, assert the l<n>_tx_error signal in the EOP cycle of the packet.
- On the custom streaming TX client interface, assert bit N of the tx_error[<w>-1:0] signal in the same cycle in which bit N of din_eop[<w>-1:0] is asserted.
The IP core overwrites Ethernet frame data with an EBLOCK_T error block when it transmits the Ethernet frame that corresponds to the packet EOP.
This feature supports test and debug of your IP core. In loopback mode, when the IP core receives a deliberately errored packet on the Ethernet link, the IP core recognizes it as a malformed packet.
Low Latency 40-100GbE IP Core TX Data Bus Interfaces
This section describes the TX data bus at the user interface and includes the following topics:
Low Latency 40-100GbE IP Core TX Data Bus with Adapters (Avalon-ST Interface)
The Low Latency 40-100GbE IP core TX datapath with adapters employs the Avalon-ST protocol. The Avalon-ST protocol is a synchronous point-to-point, unidirectional interface that connects the producer of a data stream (source) to a consumer of data (sink). The key properties of this interface include:
- Start of packet (SOP) and end of packet (EOP) signals delimit frame transfers.
- A valid signal qualifies signals from source to sink.
- The sink applies backpressure to the source by using the ready signal. The source typically responds to the deassertion of the ready signal from the sink by driving the same data until the sink can accept it. The readyLatency defines the relationship between assertion and deassertion of the ready signal, and cycles which are considered to be ready for data transfer.The readyLatency on the TX client interface is zero cycles.
Altera provides an Avalon-ST interface with adapters for both the LL 40GbE and LL 100GbE IP cores. The Avalon-ST interface requires that the start of packet (SOP) always be in the MSB, simplifying the interpretation and processing of incoming data.
In the LL 40GbE IP core, the interface width is 256 bits, and in the LL 100GbE IP core, the interface width is 512 bits. The LL 40GbE Avalon-ST interface operates at 312.5 MHz and the LL 100GbE Avalon-ST interface operates at 390.625 MHz.
The client acts as a source and the TX MAC acts as a sink in the transmit direction.
Signal Name |
Direction |
Description |
---|---|---|
l<n>_tx_data[<n>*64-1:0] |
Input |
TX data. If the preamble pass-through feature is enabled, data begins with the preamble. The Low Latency 40-100GbE IP core does not process incoming frames of less than nine bytes correctly. You must ensure such frames do not reach the TX client interface. You must send each TX data packet without intermediate idle cycles. Therefore, you must ensure your application can provide the data for a single packet in consecutive clock cycles. If data might not be available otherwise, you must buffer the data in your design and wait to assert l<n>_tx_startofpacket when you are assured the packet data to send on l<n>_tx_data[<n>*64-1:0] is available or will be available on time. |
l<n>_tx_empty[<l>-1:0] |
Input |
Indicates the number of empty bytes on l<n>_tx_data when l<n>_tx_endofpacket is asserted. |
l<n>_tx_startofpacket |
Input |
When asserted, indicates the start of a packet. The packet starts on the MSB. |
l<n>_tx_endofpacket |
Input |
When asserted, indicates the end of packet. |
l<n>_tx_ready |
Output |
When asserted, the MAC is ready to receive data. The l<n>_tx_ready signal acts as an acknowledge. The source drives l<n>_tx_valid and l<n>_tx_data[<n>*64-1:0], then waits for the sink to assert l<n>_tx_ready. The readyLatency is zero cycles, so that the IP core accepts valid data in the same cycle in which it asserts l<n>_tx_ready. The l<n>_tx_ready signal indicates the MAC is ready to receive data in normal operational model. However, the l<n>_tx_ready signal might not be an adequate indication following reset. To avoid sending packets before the Ethernet link is able to transmit them reliably, you should ensure that the application does not send packets on the TX client interface until after the tx_lanes_stable signal is asserted. |
l<n>_tx_valid |
Input |
When asserted l<n>_tx_data is valid. This signal must be continuously asserted between the assertions of l<n>_tx_startofpacket and l<n>_tx_endofpacket for the same packet. |
l<n>_tx_error | Input | When asserted in an EOP cycle (while l<n>_tx_endofpacket is
asserted), directs the IP core to insert an error in the packet
before sending it on the Ethernet link.
This signal is a test and debug feature. In loopback mode, the IP core recognizes the packet upon return as a malformed packet. |
Low Latency 40-100GbE IP Core TX Data Bus Without Adapters (Custom Streaming Interface)
When no adapters are used, the LL 40GbE custom interface bus width is 2 words (128 bits) and the LL 100GbE custom interface bus width is 4 words (256 bits). The LL 40GbE custom interface operates at 312.5 MHz and the LL 100GbE custom interface operates at 390.625 MHz.
Signal Name |
Direction |
Description |
---|---|---|
din[<w>*64-1:0] |
Input |
Data bytes to send in big-endian mode. Most significant 64-bit word is in the higher-order bits. In 40GbE variations, the most significant word is in bits [127:64] and in 100GbE variations, the most significant word is in bits [255:192]. The Low Latency 40-100GbE IP core does not process incoming frames of less than nine bytes correctly. You must ensure such frames do not reach the TX client interface. |
din_sop[<w>-1:0] |
Input |
Start of packet (SOP) location in the TX data bus. Only the most significant byte of each 64‑bit word may be a start of packet. Bit 63 or 127 are possible for the 40GbE and bits 255, 191, 127, or 63 are possible for 100 GbE. Bit 0 of din_sop corresponds to the data word in din[63:0]. |
din_eop[<w>-1:0] |
Input |
End of packet location in the TX data bus. Indicates the 64-bit word that holds the end-of-packet byte. Any byte may be the last byte in a packet. Bit 0 of din_eop corresponds to the data word in din[63:0]. |
din_eop_empty[<w>*3-1:0] |
Input |
Indicates the number of empty (invalid) bytes in the end-of-packet byte in the word indicated by din_eop. If din_eop[z] has the value of 0, then the value of din_eop_empty[(z+2):z] does not matter. However, if din_eop[z] has the value of 1, then you must set the value of din_eop_empty[(z+2):z] to the number of empty (invalid) bytes in the end-of-packet word z. For example, if you have a 100GbE IP core and want to indicate that in the current clk_txmac clock cycle, byte 6 in word 2 of din is an end-of-packet byte, and no other words hold an end-of-packet byte in the current clock cycle, you must set the value of din_eop to 4'b0100 and the value of din_eop_empty to 12'b000_110_000_000. |
din_idle[<w>-1:0] |
Input |
Indicates the words in din that hold Idle bytes or control information rather than Ethernet data. One-hot encoded. |
din_req |
Output |
Indicates that input data was accepted by the IP core. |
tx_error[<w>-1:0] | Input | When asserted in an EOP cycle (while din_eop[<w>-1:0] is non-zero), directs the IP
core to insert an error in the corresponding packet before sending
it on the Ethernet link.
This signal is a test and debug feature. In loopback mode, the IP core recognizes the packet upon return as a malformed packet. |
clk_txmac |
Output |
TX MAC clock. The clock frequency should be 312.5 MHz in LL 40GbE IP cores, and 390.625 MHz in LL 100GbE IP cores. The clk_txmac clock and the clk_rxmac clock (which clocks the RX datapath) are assumed to have the same frequency. |
The IP core reads the bytes in big endian order. A packet may start in the most significant byte of any word. A packet may end on any byte.
Bus Quantization Effects With Adapters
The TX custom streaming interface allows a packet to start at any of two or four positions to maximize utilization of the link bandwidth. The TX Avalon-ST interface only allows start of packet (SOP) to be placed at the most significant position. If the SOP were restricted to the most significant position in the client logic data bus in the custom streaming interface, bus bandwidth would be reduced.
The example shows a nine-word packet, which is the worst case for bandwidth utilization. Assuming another packet is waiting for transmission, the effective ingress bandwidth is reduced by 25%. Running the MAC portion of the logic slightly faster than is required can mitigate this loss of bandwidth. Additional increases in the MAC frequency can provide further mitigation, although increases in frequency make timing closure more difficult. The wider data bus for the Avalon-ST interface also helps to compensate for the Avalon-ST left‑aligned SOP requirement.
User Interface to Ethernet Transmission
The IP core reverses the bit stream for transmission per Ethernet requirements. The transmitter handles the insertion of the inter‑packet gap, frame delimiters, and padding with zeros as necessary. The transmitter also handles FCS computation and insertion.
The Ethernet MAC and PHY transmit complete packets. After transmission begins, it must complete with no IDLE insertions. Between the end of one packet and the beginning of the next packet, the data input is not considered and the transmitter sends IDLE characters. An unbounded number of IDLE characters can be sent between packets.
Order of Transmission
The IP core transmits bytes on the Ethernet link starting with the preamble and ending with the FCS in accordance with the IEEE 802.3 standard. Transmit frames the IP core receives on the client interface are big‑endian. Frames the MAC sends to the PHY on the XGMII/CGMII between the MAC and the PHY are little‑endian; the MAC TX transmits frames on this interface beginning with the least significant byte.
For example, the destination MAC address includes the following six octets AC-DE-48-00-00-80. The first octet transmitted (octet 0 of the MAC address described in the 802.3 standard) is AC and the last octet transmitted (octet 7 of the MAC address) is 80. The first bit transmitted is the low-order bit of AC, a zero. The last bit transmitted is the high order bit of 80, a one.
The preceding table and the following figure show that in this example, 0xAC is driven on DA5 (DA[47:40]) and 0x80 is driven on DA0 (DA[7:0]).
Destination Address[40] is the broadcast/multicast bit (a type bit), and Destination Address[41] is a locally administered address bit.
The destination address and source address bytes follow the preamble pass-through in the same order as in the case without preamble pass-through.
Low Latency 40-100GbE IP Core RX Datapath
The Low Latency 40-100GbE RX MAC receives Ethernet frames from the PHY and forwards the payload with relevant header bytes to the client after performing some MAC functions on header bytes.
The following sections describe the functions performed by the RX MAC:
Low Latency 40-100GbE IP Core RX Filtering
The Low Latency 40-100GbE IP core processes all incoming valid frames. However, the IP core does not forward pause frames to the Avalon-ST RX client interface by default.
If you set the cfg_fwd_ctrl bit of the RX_PAUSE_FWD register to the value of 1, the IP core forwards pause frames to the Avalon-ST RX client interface.
40-100GbE IP Core Preamble Processing
The preamble sequence is Start, six preamble bytes, and SFD. If this sequence is incorrect the frame is ignored. The Start byte must be on receive lane 0 (most significant byte). The IP core uses the SFD byte (0xD5) to identify the last byte of the preamble. The MAC RX looks for the Start, six preamble bytes and SFD.
By default, the MAC RX removes all Start, SFD, preamble, and IPG bytes from accepted frames. However, if you turn on Enable preamble passthrough in the Low Latency 40-100GbE parameter editor, the MAC RX does not remove the eight-byte preamble sequence.
40-100GbE IP Core FCS (CRC-32) Removal
Independent user configuration register bits control FCS CRC removal at runtime. CRC removal supports both narrow and wide bus options. Bit 0 of the MAC_CRC_CONFIG register enables and disables CRC removal; by default, CRC removal is enabled.
In the user interface, the EOP signal (l<n>_rx_endofpacket or dout_eop ) indicates the end of CRC bytes if CRC is not removed. When CRC is removed, the EOP signal indicates the final byte of payload.
The IP core signals an FCS error by asserting the FCS error output signal l<n>_rx_fcs_error and the l<n>_rx_fcs_valid (or rx_fcs_error and the rx_fcs_valid) output signals in the same clock cycle. The l<n>_rx_error[1] or rx_error[1] also signals an FCS error.
If you turn on Enable alignment EOP on FCS word in the parameter editor, the IP core asserts l<n>_rx_fcs_error (or rx_fcs_error) and the EOP signal on the same clock cycle if the current frame has an FCS error. However, if you turn off Enable alignment EOP on FCS word , the IP core asserts l<n>_rx_fcs_error in a later clock cycle than the EOP signal.
40-100GbE IP Core CRC Checking
The 32-bit CRC field is received in the order: X32, X30, . . . X1, and X0 , where X32 is the most significant bit of the FCS field and occupies the least significant bit position in the first FCS byte.
If a CRC32 error is detected, the RX MAC marks the frame invalid by asserting the l<n>_rx_fcs_error and l<n>_rx_fcs_valid (or rx_fcs_error and rx_fcs_valid) signals, as well as the l<n>_rx_error[1] (or rx_error[1]) signal.
LL 40-100GbE IP Core Malformed Packet Handling
While receiving an incoming packet from the Ethernet link, the LL 40-100GbE IP core expects to detect a terminate character at the end of the packet. When it detects an expected terminate character, the IP core generates an EOP on the client interface. However, sometimes the IP core detects an unexpected control character when it expects a terminate character. The Low Latency 40-100GbE IP core detects and handles the following forms of malformed packets:
- If the IP core detects an Error character, it generates an EOP, asserts a malformed packet error (rx_error[0] or l<n>_rx_error[0]), and asserts an FCS error (rx_fcs_error (l<n>_rx_fcs_error) and rx_error[1] (l<n>_rx_error[1]). If the IP core subsequently detects a terminate character, it does not generate another EOP indication.
- If the IP core detects any other control character when it is waiting for an EOP indication (terminate character), the IP core generates an EOP indication (for example, an IDLE or Start character), asserts a malformed packet error (rx_error[0] or l<n>_rx_error[0]), and asserts an FCS error (rx_fcs_error (l<n>_rx_fcs_error) and rx_error[1] (l<n>_rx_error[1]). If the IP core subsequently detects a terminate character, it does not generate another EOP indication.
The IP core ignores a Start control character it receives on any lane other than Lane 0.
When the IP core receives a packet that contains an error deliberately introduced on the Ethernet link using the LL 40-100GbE TX error insertion feature, the IP core identifies it as a malformed packet.
RX CRC Forwarding
The CRC-32 field is forwarded to the client interface after the final byte of data, if the CRC removal option is not enabled.
Inter-Packet Gap
The MAC RX removes all IPG octets received, and does not forward them to the Avalon-ST client interface. If you configure your IP core with a custom streaming client interface, the MAC RX does not remove IPG octets. The MAC RX fowards all received IPG octets to the custom client interface.
Pause Ignore
If you turn on flow control by setting Flow control mode to the value of Standard flow control or Priority-based flow control in the Low Latency 40-100GbE parameter editor, the IP core processes incoming pause frames by default. However, w hen the pause frame receive enable bit (for standard flow control) or bits (for priority-based flow control) is or are not set, the IP core does not process incoming pause frames. In this case, the MAC TX traffic is not affected by the valid pause frames.
If you turn off flow control by setting Flow control mode to the value of No flow control in the LL 40-100GbE parameter editor, the IP core does not process incoming pause frames.
Control Frame Identification
The mechanisms to process flow control frames from the Ethernet link are specific to the flow control mode of the LL 40-100GbE IP core. Therefore, control frames that are inappropriate to the IP core mode, simply pass through the RX MAC to the RX client interface.
If you turn off flow control by setting Flow control mode to the value of No flow control in the LL 40-100GbE parameter editor, the IP core might nevertheless receive a flow control request on the Ethernet link. Similarly, if you set Flow control mode to Standard flow control, the IP core might nevertheless receive a priority-based flow control request on the Ethernet link, and if you set Flow control mode to Priority-based flow control, the IP core might nevertheless receive a standard flow control request.
The IP core provides a three-bit RX status flag that identifies the control frames that appear on the RX client interface. The flag is one-hot encoded to identify whether the control frame is a standard flow control frame, a priority-based flow control frame, or a different type of control frame. If the flag has the value of 3'b000, the current packet on the RX client interface is not a control frame. You can use this flag to identify control frames on the RX client interface that the client prefers to ignore.
Low Latency 40-100GbE IP Core RX Data Bus Interface
This section describes the RX data bus at the user interface and includes the following topics:
Low Latency 40-100GbE IP Core User Interface Data Bus
Client Interface |
Data Bus Width (Bits) |
|
---|---|---|
LL 40GbE IP Core |
LL 100GbE IP Core |
|
Custom streaming interface (no adapters) |
128 |
256 |
Avalon-ST interface (with adapters) |
256 |
512 |
Low Latency 40-100GbE IP Core RX Data Bus
The Low Latency 40-100GbE IP core RX datapath employs the Avalon-ST protocol. The Avalon-ST protocol is a synchronous point-to-point, unidirectional interface that connects the producer of a data stream (source) to a consumer of data (sink). The key properties of this interface include:
- Start of packet (SOP) and end of packet (EOP) signals delimit frame transfers.
- A valid signal qualifies signals from source to sink.
Altera provides an Avalon-ST interface for both the LL 40GbE and LL 100GbE IP cores. In the 40GbE IP core, the interface width is 256 bits, and in the 100GbE IP core, the interface width is 512 bits. In the LL 40GbE IP core, the client interface operates at a frequency of 312.5 MHz, and in the LL 100GbE IP core, the client interface operates at a frequency of 390.625 MHz. The Avalon-ST interface requires that the start of packet (SOP) always be in the MSB.
The RX MAC acts as a source and the client acts as a sink in the receive direction.
Name |
Direction |
Description |
---|---|---|
l<n>_rx_data[<n>*64-1:0] |
Output |
RX data. |
l<n>_rx_empty[<l>-1:0] |
Output |
Indicates the number of empty bytes on l<n>_rx_data when l<n>_rx_endofpacket is asserted, starting from the least significant byte (LSB). |
l<n>_rx_startofpacket |
Output |
When asserted, indicates the start of a packet. The packet starts on the MSB. |
l<n>_rx_endofpacket |
Output |
When asserted, indicates the end of packet. |
l<n>_rx_error[5:0] | Output | Reports certain types of errors in the Ethernet
frame whose contents are currently being transmitted on the client
interface. This signal is valid in EOP cycles only. To ensure you
can identify the corresponding packet, you must turn on
Enable alignment EOP on FCS word
in the LL 40-100GbE parameter editor.
The individual bits report different types of errors:
|
l<n>_rx_valid |
Output |
When asserted, indicates that RX data is valid. Only valid between the l<n>_rx_startofpacket and l<n>_rx_endofpacket signals. |
l<n>_rx_fcs_valid |
Output |
When asserted, indicates that FCS is valid. |
l<n>_rx_fcs_error |
Output |
When asserted, indicates an FCS error condition. The IP core asserts the l<n>_rx_fcs_error signal only when it asserts the l<n>_rx_fcs valid signal. Runt frames always force an FCS error condition. However, if a packet is eight bytes or smaller, it is considered a decoding error and not a runt frame, and the IP core does not flag it as a runt. |
l<n>_rx_status[2:0] | Output | Indicates the IP core received a control frame
on the Ethernet link. This signal identifies the type of control
frame the IP core is passing through to the client interface.
This signal is valid in EOP cycles only. To ensure you can identify the corresponding packet, you must turn on Enable alignment EOP on FCS word in the LL 40-100GbE parameter editor. The individual bits report different types of received control frames:
|
Low Latency 40-100GbE IP Core RX Data Bus Without Adapters (Custom Streaming Interface)
The RX bus without adapters consists of four 8-byte words, or 256 bits, operating at a frequency of 390.625. for the 100GbE IP core or two 8‑byte words, or 128 bits, for the 40GbE IP core, nominally at 312.5 MHz. This bus drives data from the RX MAC to the RX client.
Signal Name |
Direction |
Description |
---|---|---|
dout_d[<w>*64-1:0] |
Output |
Received data and Idle bytes. In RX preamble pass-through mode, this bus also carries the preamble. |
dout_c[<w>*8-1:0] |
Output |
Indicates control bytes on the data bus. Each bit of dout_c indicates whether the corresponding byte of dout_d is a control byte. A bit is asserted high if the corresponding byte on dout_d is an Idle byte or the Start byte, and has the value of zero if the corresponding byte is a data byte or, in preamble pass-through mode, a preamble or SFD byte. |
dout_sop[<w>-1:0] |
Output |
Indicates the first data word of a frame, in the current clk_rxmac cycle. In RX preamble pass-through mode, the first data word is the word that contains the preamble. When the RX preamble pass-through feature is turned off, the first data word is the first word of Ethernet data that follows the preamble. This signal is one-hot encoded. |
dout_eop[<w>–1:0] |
Output |
Indicates the final word of a frame in the current clk_rxmac cycle. If CRC removal is disabled, this signal indicates the word with the final CRC byte. If CRC removal is enabled, this signal indicates the final word with data. This signal is one-hot encoded. |
dout_eop_empty[<w>*3-1:0] | Output |
Indicates the number of empty (invalid) bytes in the end-of-packet byte in the word indicated by dout_eop. If dout_eop[z] has the value of 0, then the IP core sets the value of dout_eop_empty[(z+2):z] to 0. However, if dout_eop[z] has the value of 1, then you must use the value of dout_eop_empty[(z+2):z] to determine the number of empty (invalid) bytes in the end-of-packet word (and therefore, the end-of-packet byte). For example, if you have a 100GbE IP core and you observe that in the current clk_rxmac clock cycle, dout_eop has the value of 4'b0100 and dout_eop_empty has the value of 12'b000_110_000_000, you can conclude that byte 6 in word 2 of dout_d is an end-of-packet byte. |
dout_idle[<w>-1:0] | Output |
Indicates the words in dout_d that hold Idle bytes or control information rather than Ethernet data. This signal is one-hot encoded. |
rx_error[5:0] | Output | Reports certain types of errors in the Ethernet
frame whose contents are currently being transmitted on the client
interface. This signal is valid in EOP cycles only. To ensure you
can identify the corresponding packet, you must turn on
Enable alignment EOP on FCS word
in the LL 40-100GbE parameter editor.
The individual bits report different types of errors:
|
rx_fcs_error |
Output |
The current or most recent EOP byte is part of a frame with an incorrect FCS (CRC-32) value. By default, the IP core asserts rx_fcs_error in the same cycle as the dout_eop signal. However, if you turn off Enable alignment EOP on FCS word in the LL 40-100GbE parameter editor, the rx_fcs_error signal might lag the dout_eop signal for the frame. Runt frames always force an FCS error condition. However, if a packet is eight bytes or smaller, it is considered a decoding error and not a runt frame, and the IP core does not flag it as a runt. |
rx_fcs_valid |
Output |
When set, indicates that rx_fcs_error has a valid value in the current clock cycle.. |
rx_status[2:0] | Output | Indicates the IP core received a control frame
on the Ethernet link. This signal identifies the type of control
frame the IP core is passing through to the client interface.
This signal is valid in EOP cycles only. To ensure you can identify the corresponding packet, you must turn on Enable alignment EOP on FCS word in the LL 40-100GbE parameter editor. The individual bits report different types of received control frames:
|
dout_valid |
Output |
The dout_d bus contents are valid. This signal is occasionally deasserted due to clock crossing. |
clk_rxmac |
Output |
RX MAC clock. The clock frequency should be 312.5 MHz in LL 40GbE IP cores, and 390.625 MHz in LL 100GbE IP cores. The clk_rxmac clock is derived from the recovered CDR clock. |
The data bytes use 100 Gigabit Media Independent Interface (CGMII-like) encoding. For packet payload bytes, the dout_c bit is set to 0 and the dout_d byte is the packet data. You can use this information to transmit out-of-spec data such as customized preambles when implementing non-standard variants of the IEEE 802.3ba-2010 100G Ethernet Standard.
In RX preamble pass-through mode, dout_c has the value of 1 while the start byte of the preamble is presented on the RX interface, and dout_c has the value of 0 while the remainder of the preamble sequence (six-byte preamble plus SFD byte) is presented on the RX interface.
Low Latency 100GbE CAUI–4 PHY
The Low Latency 100GbE PHY IP core configured in an Arria 10 GT device supports CAUI-4 PCS and PMA at 4 x 25.78125 Gbps.
External Reconfiguration Controller
Low Latency 40GbE and 100GbE IP cores that target a Stratix V device require an external reconfiguration controller.
Altera recommends that you configure an Altera Transceiver Reconfiguration Controller for your Stratix V 40-100GbE IP core.
External Transceiver PLL
Low Latency 40GbE and 100GbE IP cores that target an Arria 10 device require an external transceiver PLL. The number and type of transceiver PLLs your design requires depends on the transceiver channels and available clock networks.
External TX MAC PLL
If you turn on Use external TX MAC PLL in the LL 40-100GbE parameter editor, the IP core has an extra input port, clk_txmac_in, which drives the TX MAC clock. You must connect this input port to a clock source, usually a PLL on the device.
The port is expected to receive the clock from the external TX MAC PLL and drives the internal clock clk_txmac. The required TX MAC clock frequency is 312.5 MHz for 40GbE variations, and 390.625 MHz for 100GbE variations. User logic must drive clk_txmac_in from a PLL whose input is the PHY reference clock, clk_ref.
Congestion and Flow Control Using Pause Frames
If you turn on flow control by setting Flow control mode to the value of Standard flow control or Priority-based flow control in the Low Latency 40-100GbE parameter editor, t he Low Latency 40-100GbE IP core provides flow control to reduce congestion at the local or remote link partner. When either link partner experiences congestion, the respective transmit control sends pause frames. The pause frame instructs the remote transmitter to stop sending data for the duration that the congested receiver specified in an incoming XOFF frame. In the case of priority-based flow control, the pause frame applies to only the indicated priority class.
When the IP core receives the XOFF pause control frame, if the following conditions all hold, the IP core behavior depends on the flow control scheme.
- In priority-based flow control, the IP core informs the TX client of the
received XOFF frame. The IP core continues to process packets it receives on the
TX client interface. The IP core tracks the pause quanta countdown internally
and informs the TX client when the pause period is ended.
Note: In the priority-based flow control sceme, the client is responsible to throttle the flow of data to the TX client interface after the IP core informs the client of the received XOFF frame.
- In standard flow control, the IP core TX MAC does not process TX packets and in fact, prevents the client from sending additional data to the TX client interface, for the duration of the pause quanta of the incoming pause frame.
The IP core responds to an incoming XOFF pause control frame if the following conditions all hold:
- The relevant cfg_enable bit of the RX_PAUSE_ENABLE register has the value of 1.
- In the case of standard flow control, bit [0] of the TX_XOF_EN register also has the value of 1.
- Address matching is positive.
The pause quanta can be configured in the pause quanta register of the device sending XOFF frames. If the pause frame is received in the middle of a frame transmission, the transmitter finishes sending the current frame and then suspends transmission for a period specified by the pause quanta. Data transmission resumes when a pause frame with quanta of zero is received or when the timer has expired. The pause quanta received overrides any counter currently stored. When more than one pause quanta is sent, the value of the pause is set to the last quanta received.
XOFF pause frames stop the remote transmitter. XON pause frames let the remote transmitter resume data transmission.
One pause quanta fraction is equivalent to 512 bit times. The duration of a pause quantum depends on the client interface datapath width (256 bits for Low Latency 40GbE IP cores and 512 bits for Low Latency 100GbE IP cores) and on the system clock (clk_txmac) frequency (312.5 MHz for Low Latency 40GbE IP cores and 390.625 MHz for Low Latency 100GbE IP cores).
XOFF Frame | XON Frame | |
START[7:0] | START[7:0] | |
PREAMBLE[47:0] | PREAMBLE[47:0] | |
SFD[7:0] | SFD[7:0] | |
DESTINATION ADDRESS[47:0] = 0x010000C28001 3 | DESTINATION ADDRESS[47:0] = 0x010000C28001 | |
SOURCE ADDRESS[47:0] | SOURCE ADDRESS[47:0] | |
TYPE[15:0] = 0x8808 | TYPE[15:0] = 0x8808 | |
OPCODE[15:0] = 0x001 (standard FC) | OPCODE[15:0] = 0x001 (standard FC) | |
PAUSE QUANTA[15:0] = 0xP1, 0xP2 4 | PAUSE QUANTA[15:0] = 0x0000 | |
PAD[335:0] | PAD[335:0] | |
CRC[31:0] | CRC[31:0] |
XOFF Frame | XON Frame | |
START[7:0] | START[7:0] | |
PREAMBLE[47:0] | PREAMBLE[47:0] | |
SFD[7:0] | SFD[7:0] | |
DESTINATION ADDRESS[47:0] = 0x010000C28001 3 | DESTINATION ADDRESS[47:0] = 0x010000C28001 | |
SOURCE ADDRESS[47:0] | SOURCE ADDRESS[47:0] | |
TYPE[15:0] = 0x8808 | TYPE[15:0] = 0x8808 | |
OPCODE[15:0] = 0x0101 (PFC) | OPCODE[15:0] = 0x0101 (PFC) | |
PRIORITY_ENABLE[15:0] 5 | PRIORITY_ENABLE[15:0] 6 | |
TIME0[15:0] 7 | TIME0[15:0] = 0x0000 | |
... | ... | |
TIME7[15:0] 7 | TIME7[15:0] = 0x0000 | |
PAD[207:0] | PAD[207:0] | |
CRC[31:0] | CRC[31:0] |
Conditions Triggering XOFF Frame Transmission
The LL 40-100GbE IP core supports retransmission. In retransmission mode, the IP core retransmits a XOFF frame periodically, extending the pause time, based on signal values.
The TX MAC transmits XOFF frames when one of the following conditions occurs:
- Client requests XOFF transmission—A client can explicitly request that XOFF frames be sent using the pause control interface signal. When pause_insert_tx is asserted, an XOFF frame is sent to the Ethernet network when the current frame transmission completes.
- Host (software) requests XOFF transmission—Setting the pause request register triggers a request that an XOFF frame be sent.
- Retransmission mode—If the retransmit hold-off enable bit has the value of 1, and the pause_insert_tx signal remains asserted or the pause request register value remains high, when the time duration specified in the hold-off quanta register has lapsed after the previous XOFF transmission, the TX MAC sends another XOFF frame to the Ethernet network. While the IP core is paused in retransmission mode, you cannot use either of the other two methods to trigger a new XOFF frame: the signal or register value is already high.
Conditions Triggering XON Frame Transmission
The TX MAC transmits XON frames when one of the following conditions occurs:
- Client requests XON transmission—A client can explicitly request that XON frames be sent using the pause control interface signal. When pause_insert_tx is de-asserted, an XON frame is sent to the Ethernet network when the current frame transmission completes.
- Host (software) requests XON transmission— Resetting the pause request register triggers a request that an XON frame be sent.
Pause Control and Generation Interface
The pause control interface implements flow control as specified by the IEEE 802.3ba 2010 100G Ethernet Standard. If you turn on priority-based flow control, the interface implements the IEEE Standard 802.1Qbb.The pause logic, upon receiving a pause packet, temporarily stops packet transmission, and can pass the pause packets through as normal traffic or drop the pause control frames in the RX direction.
Signal Name |
Direction |
Description |
---|---|---|
pause_insert_tx[N-1:0] 8 |
Input |
Level signal which directs the IP core to insert a pause frame for priority traffic class [n] on the Ethernet link. If bit [n] of the TX_PAUSE_EN register has the value of 1, the IP core transmits an XOFF frame when this signal is first asserted. If you enable retransmission, the IP core continues to transmit XOFF frames periodically until the signal is de-asserted. When the signal is deasserted, the IP core inserts an XON frame. |
pause_receive_rx[N-1:0] 8 |
Output |
Asserted to indicate an RX pause signal match. The IP core asserts bit [n] of this signal when it receives a pause request with an address match, to signal the TX MAC to throttle its transmissions from priority queue [n] on the Ethernet link. |
Pause Control Frame Filtering
The Low Latency 40GbE and 100GbE IP cores support options to enable or disable the following features for incoming pause control frames. These options are available if you set the Flow control mode parameter to the value of Standard flow control or Priority-based flow control.
- Processing—You can enable or disable pause frame processing. If you disable pause frame processing, the IP core does not modify its behavior in response to incoming pause frames on the Ethernet link. You can enable or disable pause frame processing with the cfg_enable bit of the RX_PAUSE_ENABLE register. By default, RX pause frame processing is enabled.
- Filtering—If pause frame processing
is enabled, the IP core automatically performs address filtering on incoming
pause control frames before processing them. You set the matching address value
in these registers:
- RX_PAUSE_DADDRL[31:0] at offset 0x707
- RX_PAUSE_DADDRH[15:0] at offset 0x708
- TX MAC filtering—For standard flow control only, Altera provides an additional level of filtering to enable or disable the TX MAC from responding to notification from the RX MAC that it received an incoming pause frame with an address match. Even if the RX MAC processes an incoming pause frame, you can separately set the TX MAC to ignore the RX MAC request to pause outgoing frames, by setting bit [0] of the TX_XOF_EN register to the value of 0. By default this register field has the value of 1.
- Pass-through—The Low Latency 40GbE and 100GbE MAC IP cores can pass the matching pause packets through as normal traffic or drop these pause control frames in the RX direction. You can enable and disable pass-through with the cfg_fwd_ctrl bit of the RX_PAUSE_FWD register. By default, pass-through is disabled. All non-matching pause frames are passed through to the RX client interface irrespective of the cfg_fwd_ctrl setting.
The following rules define pause control frames filtering control:
- If you have disabled pause frame processing, by setting the cfg_enable bit of the RX_PAUSE_ENABLE register to the value of 0, the IP core drops packets that enter the RX MAC and match the destination address, length, and type of 0x8808 with an opcode of 0x1 (pause packets)
- If you have enabled pause frame processing, and the destination address in the pause frame is a match, when the RX MAC receives a pause packet it passes a pause request to the TX MAC. The RX MAC only processes pause packets with a valid packet multicast address or a destination address matching the destination address specified in the RX_PAUSE_DADDR1 and RX_PAUSE_DADDR0 registers, or in the RX_PAFC_DADDRH and RX_PFC_DADDRL registers, as appropriate for the flow control mode . If you have turned on pause frame pass-through, the RX MAC also forwards the pause frame to the RX client interface. If you have not turned on pause frame pass-through, the RX MAC does not forward the matching pause frame to the RX client interface.
- In priority-based flow control, or in standard flow control if you have enabled TX MAC filtering, when the TX MAC receives a pause request from the RX MAC, it pauses transmission on the TX Ethernet link.
Pause packet pass-through does not affect the pause functionality in the TX or RX MAC.
Link Fault Signaling Interface
If you turn on Enable link fault generation in the Low Latency 40-100GbE parameter editor, t he Low Latency 40‑100GbE IP core provides link fault signaling as defined in the IEEE 802.3ba-2010 100G Ethernet Standard and Clause 66 of the IEEE 802.3-2012 Ethernet Standard, based on the LINK_FAULT_CONFIG register settings.. The Low Latency 40GbE and 100GbE MAC include a Reconciliation Sublayer (RS) located between the MAC and the XLGMII or CGMII to manage local and remote faults. Link fault signaling on the Ethernet link is disabled by default but can be enabled by bit [0] of the LINK_FAULT_CONFIG register . When the LINK_FAULT_CONFIG register bits [1:0] have the value of 2'b01, link fault signaling is enabled in normal bidirectional mode. In this mode , the local RS TX logic transmits remote fault sequences in case of a local fault and transmits IDLE control words in case of a remote fault.
If you turn on bit [1] of the LINK_FAULT_CONFIG register, the IP core conforms to Clause 66 of the IEEE 802.3-2012 Ethernet Standard. When LINK_FAULT_CONFIG[1:0] has the value of 2'b11, the IP core transmits the fault sequence ordered sets in the interpacket gaps according to the clause requirements.
The RS RX logic sets remote_fault_status or local_fault_status to 1 when the RS RX block receives remote fault or local fault sequence ordered sets. When valid data is received in more than 127 columns, the RS RX logic resets the relevant fault status (remote_fault_status or local_fault_status) to 0.
The IEEE standard specifies RS monitoring of RXC<7:0> and RXD<63:0> for Sequence ordered_sets. For more information, refer to Figure 81–9—Link Fault Signaling state diagram and Table 81-5—Sequence ordered_sets in the IEEE 802.3ba 2010 100G Ethernet Standard. The variable link_fault is set to indicate the value of an RX Sequence ordered_set when four fault_sequences containing the same fault value are received with fault sequences separated by less than 128 columns and with no intervening fault_sequences of different fault values. The variable link_fault is set to OK following any interval of 128 columns not containing a remote fault or local fault Sequence ordered_set.
Signal Name |
Direction |
Description |
---|---|---|
remote_fault_status |
Output |
Asserted by the IP core when it detects a real-time remote fault in the RX MAC. The IP core asserts this signal regardless of the settings in the LINK_FAULT_CONFIG register. This signal is clocked by clk_rxmac. |
local_fault_status |
Output |
Asserted by the IP core when it detects a real-time local fault in the RX MAC. The IP core asserts this signal regardless of the settings in the LINK_FAULT_CONFIG register. This signal is clocked by clk_rxmac. |
unidirectional_en | Output | The IP core asserts this signal if it includes
Clause 66 support for remote link fault reporting on the Ethernet
link. Connects to the Unidir
Enable field in bit [1] of the LINK_FAULT_CONFIG register at offset 0x405.
This signal is clocked by clk_txmac. |
link_fault_gen_en | Output | The IP core asserts this signal if the PCS is
enabled to generate a remote fault sequence on the Ethernet link
when appropriate. Connects to the Link
Fault Reporting Enable field in bit [0] of the LINK_FAULT_CONFIG register at offset
0x405.
This signal is clocked by clk_txmac. |
Statistics Counters Interface
The statistics counters module s are synthesis options that you select in the Low Latency 40-100GbE parameter editor. However, the statistics status bit output vectors are provided whether you select the statistics counters module option or not.
The increment vectors are brought to the top level as output ports. The increment vectors also function internally as input ports to the control and status registers (CSR).
Name |
Signal Direction |
Description |
---|---|---|
TX Statistics Counter Increment Vectors |
||
tx_inc_64 |
Output |
Asserted for one cycle when a 64-byte TX frame is transmitted. |
tx_inc_127 |
Output |
Asserted for one cycle when a 65–127 byte TX frame is transmitted. |
tx_inc_255 |
Output |
Asserted for one cycle when a 128–255 byte TX frame is transmitted. |
tx_inc_511 |
Output |
Asserted for one cycle when a 256–511 byte TX frame is transmitted. |
tx_inc_1023 |
Output |
Asserted for one cycle when a 512–1023 byte TX frame is transmitted. |
tx_inc_1518 |
Output |
Asserted for one cycle when a 1024–1518 byte TX frame is transmitted. |
tx_inc_max |
Output |
Asserted for one cycle when a maximum-size TX frame is transmitted. You program the maximum number of bytes in the MAX_TX_SIZE_CONFIG register. |
tx_inc_over |
Output |
Asserted for one cycle when an oversized TX frame is transmitted. You program the maximum number of bytes in the MAX_TX_SIZE_CONFIG register. |
tx_inc_mcast_data_err |
Output |
Asserted for one cycle when an errored multicast TX frame, excluding control frames, is transmitted. |
tx_inc_mcast_data_ok |
Output |
Asserted for one cycle when a valid multicast TX frame, excluding control frames, is transmitted. |
tx_inc_bcast_data_err |
Output |
Asserted for one cycle when an errored broadcast TX frame, excluding control frames, is transmitted. |
tx_inc_bcast_data_ok |
Output |
Asserted for one cycle when a valid broadcast TX frame, excluding control frames, is transmitted. |
tx_inc_ucast_data_err |
Output |
Asserted for one cycle when an errored unicast TX frame, excluding control frames, is transmitted. |
tx_inc_ucast_data_ok |
Output |
Asserted for one cycle when a valid unicast TX frame, excluding control frames, is transmitted. |
tx_inc_mcast_ctrl |
Output |
Asserted for one cycle when a valid multicast TX frame is transmitted. |
tx_inc_bcast_ctrl |
Output |
Asserted for one cycle when a valid broadcast TX frame is transmitted. |
tx_inc_ucast_ctrl |
Output |
Asserted for one cycle when a valid unicast TX frame is transmitted. |
tx_inc_pause |
Output |
Asserted for one cycle when a valid pause TX frame is transmitted. |
tx_inc_fcs_err |
Output |
Asserted for one cycle when a TX packet with FCS errors is transmitted. |
tx_inc_fragment |
Output |
Asserted for one cycle when a TX frame less than 64 bytes and reporting a CRC error is transmitted. |
tx_inc_jabber |
Output |
Asserted for one cycle when an oversized TX frame reporting a CRC error is transmitted. |
tx_inc_sizeok_fcserr |
Output |
Asserted for one cycle when a valid TX frame with FCS errors is transmitted. |
RX Statistics Counter Increment Vectors |
||
rx_inc_runt |
Output |
Asserted for one cycle when an RX runt packet is received. |
rx_inc_64 |
Output |
Asserted for one cycle when a 64-byte RX frame is received. |
rx_inc_127 |
Output |
Asserted for one cycle when a 65–127 byte RX frame is received. |
rx_inc_255 |
Output |
Asserted for one cycle when a 128–255 byte RX frame is received. |
rx_inc_511 |
Output |
Asserted for one cycle when a 256–511 byte RX frame is received. |
rx_inc_1023 |
Output |
Asserted for one cycle when a 512–1023 byte RX frame is received. |
rx_inc_1518 |
Output |
Asserted for one cycle when a 1024–1518 byte RX frame is received. |
rx_inc_max |
Output |
Asserted for one cycle when a maximum-size RX frame is received. You program the maximum number of bytes in the MAX_RX_SIZE_CONFIG register. |
rx_inc_over |
Output |
Asserted for one cycle when an oversized RX frame is received. You program the maximum number of bytes in the MAX_RX_SIZE_CONFIG register. |
rx_inc_mcast_data_err |
Output |
Asserted for one cycle when an errored multicast RX frame, excluding control frames, is received. |
rx_inc_mcast_data_ok |
Output |
Asserted for one cycle when valid a multicast RX frame, excluding control frames, is received. |
rx_inc_bcast_data_err |
Output |
Asserted for one cycle when an errored broadcast RX frame, excluding control frames, is received. |
rx_inc_bcast_data_ok |
Output |
Asserted for one cycle when a valid broadcast RX frame, excluding control frames, is received. |
rx_inc_ucast_data_err |
Output |
Asserted for one cycle when an errored unicast RX frame, excluding control frames, is received. |
rx_inc_ucast_data_ok |
Output |
Asserted for one cycle when a valid unicast RX frame, excluding control frames, is received. |
rx_inc_mcast_ctrl |
Output |
Asserted for one cycle when a valid multicast RX frame is received. |
rx_inc_bcast_ctrl |
Output |
Asserted for one cycle when a valid broadcast RX frame is received. |
rx_inc_ucast_ctrl |
Output |
Asserted for one cycle when a valid unicast RX frame is received. |
rx_inc_pause |
Output |
Asserted for one cycle when valid RX pause frames are received. |
rx_inc_fcs_err |
Output |
Asserted for one cycle when a RX packet with FCS errors is received. |
rx_inc_fragment |
Output |
Asserted for one cycle when a RX frame less than 64 bytes and reporting a CRC error is received. |
rx_inc_jabber |
Output |
Asserted for one cycle when an oversized RX frame reporting a CRC error is received. |
rx_inc_sizeok_fcserr |
Output |
Asserted for one cycle when a valid RX frame with FCS errors is received. |
rx_inc_pause_ctrl_err |
Output |
Asserted for one cycle when an errored pause RX frame is received. |
rx_inc_mcast_ctrl_err |
Output |
Asserted for one cycle when an errored multicast RX control frame is received. |
rx_inc_bcast_ctrl_err |
Output |
Asserted for one cycle when an errored broadcast RX control frame is received. |
rx_inc_ucast_ctrl_err |
Output |
Asserted for one cycle when an errored unicast RX control frame is received. |
OctetOK Count Interface
The statistics counters include two 64-bit counters, RxOctetsOK and TxOctetsOK, which count the payload bytes (octets) in frames with no FCS, undersized, oversized, or payload length errors. The RxOctetsOK register maintains a cumulative count of the payload bytes in the qualifying received frames, and complies with section 5.2.1.14 of the IEEE Standard 802.3-2008. The TxOctetsOK register maintains a cumulative count of the payload bytes in the qualifying transmitted frames, and complies with section 5.2.2.18 of the IEEE Standard 802.3-2008.
To support payload size checking per frame, the LL 40-100GbE IP core provides an octetOK count interface instead of standard increment vectors. For most purposes, the number of payload bytes per frame is of more interest than the cumulative count, and an increment vector that pulses when the counter increments would be difficult to track. For each of these two registers, the IP core maintains two signals. A 16-bit signal provides a count of the payload bytes in the current frame, and the other signal pulses to indicate when the first signal is valid. The per-frame count is valid only when the valid signal is asserted. All signals in this interface are functional even if you do not turn on the corresponding statistics module.
Name |
Signal Direction |
Description |
---|---|---|
tx_inc_octetsOK[15:0] |
Output |
When tx_inc_octetsOK_valid is asserted, tx_inc_octetsOK[15:0] holds the count of payload bytes in the current valid frame. |
tx_inc_octetsOK_valid |
Output |
Pulses to indicate that tx_inc_octetsOK[15:0] currently holds the number of payload bytes for the current transmitted frame, and that the current frame is a qualifying frame. A qualifying frame has no FCS errors, no oversized error, no undersized error, and no payload length error. |
rx_inc_octetsOK[15:0] |
Output |
When rx_inc_octetsOK_valid is asserted, rx_inc_octetsOK[15:0] holds the count of payload bytes in the current valid frame. |
rx_inc_octetsOK_valid |
Output |
Pulses to indicate that rx_inc_octetsOK[15:0] currently holds the number of payload bytes for the current received frame, and that the current frame is a qualifying frame. A qualifying frame has no FCS errors, no oversized error, no undersized error, and no payload length error. |
1588 Precision Time Protocol Interfaces
If you turn on Enable 1588 PTP , the Low Latency 40‑100GbE IP core processes and provides 1588 Precision Time Protocol (PTP) timestamp information as defined in the IEEE 1588-2008 Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Standard.
1588 PTP packets carry timestamp information. The Low Latency 40-100GbE IP core updates the incoming timestamp information in a 1588 PTP packet to transmit a correct updated timestamp with the data it transmits on the Ethernet link, using a one-step or two-step clock.
A fingerprint can accompany a 1588 PTP packet. You can use this information for client identification and other client uses. If provided fingerprint information, the IP core passes it through unchanged.
The IP core connects to a time-of-day (TOD) module that continuously provides the current time of day based on the input clock frequency. Because the module is outside the LL 40-100GbE IP core, you can use the same module to provide the current time of day for multiple modules in your system.
Implementing a 1588 System That Includes a LL 40-100GbE IP Core
The 1588 specification in IEEE 1588-2008 Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Standard describes various systems you can implement in hardware and software to synchronize clocks in a distributed system by communicating offset and frequency correction information between master and slave clocks in arbitrarily complex systems. A 1588 system that includes the LL 40-100GbE IP core with 1588 PTP functionality uses the incoming and outgoing timestamp information from the IP core and the other modules in the system to synchronize clocks across the system.
The LL 40-100GbE IP core with 1588 PTP functionality provides the timestamp manipulation and basic update capabilities required to integrate your IP core in a 1588 system. You can specify that packets are PTP packets, and how the IP core should update incoming timestamps from the client interface before transmitting them on the Ethernet link. The IP core does not implement the event messaging layers of the protocol, but rather provides the basic hardware capabilities that support a system in implementing the full 1588 protocol.

PTP Receive Functionality
If you turn on Enable 1588 PTP in the Low Latency 40-100GbE parameter editor, the IP core provides a 96-bit (V2 format) or 64-bit timestamp with every packet on the RX client interface, whether it is a 1588 PTP packet or not. The value on the timestamp bus (rx_ingress_timestamp_96b_data[95:0] or rx_ingress_timestamp_64b_data[63:0] or both, if present) is valid in the same clock cycle as the RX SOP signal. The value on the timestamp bus is not the current timestamp; instead, it is the timestamp from the time when the IP core received the packet on the Ethernet link. The IP core captures the time-of-day from the TOD module on rx_time_of_data_96b_data or rx_time_of_day_64b_data at the time it receives the packet on the Ethernet link, and sends that timestamp to the client on the RX SOP cycle on the timestamp bus rx_ingress_timestamp_96b_data[95:0] or rx_ingress_timestamp_64b_data[63:0] or both, if present. User logic can use this timestamp or ignore it.
PTP Transmit Functionality
When you send a 1588 PTP packet to a Low Latency 40-100GbE IP core with Enable 1588 PTP turned on in the parameter editor, you must assert one and only one of the following input signals with the TX SOP signal to tell the IP core the incoming packet is a 1588 PTP packet:
- tx_egress_timestamp_request_valid: assert this signal to tell the IP core to process the current packet in two-step processing mode.
- tx_etstamp_ins_ctrl_timestamp_insert: assert this signal to tell the IP core to process the current packet in one-step processing mode and to insert the exit timestamp for the packet in the packet (insertion mode).
- tx_etstamp_ins_ctrl_residence_time_update: assert this signal to tell the IP core to process the current packet in one-step processing mode and to update the timestamp in the packet by adding the latency through the IP core (the residence time in the IP core) to the cumulative delay field maintained in the packet (correction mode). This mode supports transparent clock systems.
The IP core transmits the 1588 PTP packet in an Ethernet frame after PTP processing.
In one-step mode, the IP core either overwrites the timestamp information provided at the user-specified offset with the packet exit timestamp (insertion mode), or adds the residence time in this system to the value at the specified offset (correction mode). You tell the IP core how to process the timestamp by asserting the appropriate signal with the TX SOP signal. You must specify the offset of the timestamp in the packet (tx_etstamp_ins_ctrl_offset_timestamp) in insertion mode, or the offset of the correction field in the packet (tx_etstamp_ins_ctrl_offset_correction_field) in correction mode. In addition, the IP core zeroes out or updates the UDP checksum, or leaves the UDP checksum as is, depending on the mutually exclusive tx_etstamp_ins_ctrl_checksum_zero and tx_etstamp_ins_ctrl_checksum_correct signals.
Two-step PTP processing ignores the values on the one-step processing signals. In two-step processing mode, the IP core does not modify the current timestamp in the packet. Instead, the IP core transmits a two-step derived timestamp on the separate tx_egress_timestamp_96b_data[95:0] or tx_egress_timestamp_64b_data[63:0] bus, when it begins transmitting the Ethernet frame. The value on the tx_egress_timestamp_{96b,64b}_data bus is the packet exit timestamp. The tx_egress_timestamp_{96b,64b}_data bus holds a valid value when the corresponding tx_egress_timestamp_{96b,64b}_valid signal is asserted.
In addition, to help the client to identify the packet, you can specify a fingerprint to be passed by the IP core in the same clock cycle with the timestamp. To specify the number of distinct fingerprint values the IP core can handle, set the Timestamp fingerprint width parameter to the desired number of bits W. You provide the fingerprint value to the IP core in the tx_egress_timestamp_request_fingerprint[(W–1):0] signal. The IP core then drives the fingerprint on the appropriate tx_egress_timestamp_{96b,64b}_fingerprint[(W–1):0] port with the corresponding output timestamp, when it asserts the tx_egress_timestamp_{96b,64b}_valid signal.
The IP core calculates the packet exit timestamp.
exit TOD = entry TOD + IP core maintained expected latency + user-specified extra latency
- entry TOD is the value in tx_time_of_day_96b_data or tx_time_of_day_64b_data when the packet enters the IP core.
- The expected latency through the IP core is a static value. The IP core maintains this value internally.
- The IP core reads the user-specified extra latency from the TX_PTP_EXTRA_LATENCY register. This option is provided for user flexibility.
The IP core provides the exit TOD differently in different processing modes.
- In two-step mode, the IP core drives the exit TOD on tx_egress_timestamp_96b_data and on tx_egress_timestamp_64b_data, as available.
- In one-step processing insertion mode, the IP core inserts the exit TOD in the timestamp field of the packet at the offset you specify in tx_etstamp_ins_ctrl_offset_timestamp.
- In one-step processing correction mode, the IP core calculates the exit TOD and uses it only to calculate the residence time.
In one-step processing correction mode, the IP core calculates the updated correction field value:
exit correction field value = entry correction field value + residence time + asymmetry extra latency
- residence time = exit TOD – entry (ingress) timestamp.
- entry (ingress) timestamp is the value on tx_etstamp_ins_ctrl_ingress_timestamp_{95,64}b in the SOP cycle when the IP core received the packet on the TX client interface. The application is responsible to drive this signal with the correct value for the cumulative calculation. The correct value depends on system configuration.
- The IP core reads the asymmetry extra latency from the TX_PTP_ASYM_DELAY register if the tx_egress_asymmetry_update signal is asserted. This option is provided for additional user-defined precision. You can set the value of this register and set the tx_egress_asymmetry_update signal to indicate the register value should be included in the latency calculation.
External Time-of-Day Module for 1588 PTP Variations
Low Latency 40-100GbE IP cores that include the 1588 PTP module require an external time-of-day (TOD) module to provide the current time-of-day in each clock cycle, based on the incoming clock. The TOD module must update the time-of-day output value on every clock cycle, and must provide the TOD value in the V2 format (96 bits) or the 64-bit TOD format, or both.
The example project you can generate for your IP core PTP variation includes two TOD modules, one for the RX MAC and one for the TX MAC, and demonstrates their connections to the IP core.
PTP Timestamp and TOD Formats
The Low Latency 40-100GbE IP core supports a 96-bit timestamp (V2 format) or a 64-bit timestamp (V1 format) in PTP packets. It supports the PHY operating speed random error with timestamp accuracy of ± 7 ns. The 64-bit timestamp and TOD signals of the IP core are in an Altera-defined 64-bit format that is distinct from the V1 format, for improved efficiency in one-step processing correction mode. Therefore, if your system need not handle any packets in one-step processing correction mode, Altera recommends that you turn off the Enable 64b Time of Day Format parameter.
You control the format or formats the IP core supports with the Enable 96b Time of Day Format and Enable 64b Time of Day Format parameters. If you turn on Enable 96b Time of Day Format, your IP core can support two-step processing mode, one-step processing insertion mode, and one-step processing correction mode, and can support both V1 and V2 formats. You can turn on Enable 64b Time of Day Format and turn off Enable 96b Time of Day Format to support one-step processing correction mode more efficiently. However, if you do so, your IP core variation cannot support two-step processing mode and cannot support one-step processing insertion mode. If you turn on both of these parameters, the value you drive on the tx_estamp_ins_ctrl_timestamp_format or tx_etstamp_ins_ctrl_residence_time_calc_format signal determines the format the IP core supports for the current packet.
The IP core completes all internal processing in the V2 format. However, if you specify V1 format for a particular PTP packet in one-step insertion mode, the IP core inserts the appropriate V1-format timestamp in the outgoing packet on the Ethernet link.
V2 Format
The IP core maintains the time-of-day (TOD) in V2 format according to the IEEE specification::
- Bits [95:48]: Seconds (48 bits).
- Bits [47:16]: Nanoseconds (32 bits). This field overflows at 1 billion.
- Bits [15:0]: Fractions of nanosecond (16 bits). This field is a true fraction; it overflows at 0xFFFF.
The IP core can receive time-of-day information from the TOD module in V2 format or in 64-bit TOD format, or both, depending on your settings for the Enable 64b Time of Day Format and Enable 96b Time of Day Format parameters.
V1 Format
V1 timestamp format is specified in the IEEE specification:
- Bits [63:32]: Seconds (32 bits).
- Bits [31:0]: Nanoseconds (32 bits). This field overflows at 1 billion.
Altera 64-Bit TOD Format
The Altera 64-bit TOD format is distinct from the V1 format and supports a longer time delay. It is intended for use in transparent clock systems, in which each node adds its own residence time to a running total latency through the system. This format matches the format of the correction field in the packet, as used in transparent clock mode.
- Bits [63:16]: Nanoseconds (48 bits). This field can specify a value greater than 4 seconds.
- Bits [15:0]: Fractions of nanosecond (16 bits). This field is a true fraction; it overflows at 0xFFFF.
The TOD module provides 64-bit TOD information to the IP core in this 64-bit TOD format. The expected format of all 64-bit input timestamp and TOD signals to the IP core is the Altera 64-bit TOD format. The format of all 64-bit output timestamp and TOD signals from the IP core is the Altera 64-bit TOD format. If you build your own TOD module that provides 64-bit TOD information to the IP core, you must ensure it provides TOD information in the Altera 64-bit TOD format.
1588 PTP Interface Signals
Signal Name |
Direction |
Description |
---|---|---|
PTP Interface to TOD module | ||
tx_time_of_day_96b_data[95:0] | Input | Current V2-format (96-bit) TOD in clk_txmac clock domain. Connect this
signal to the external TOD module.
This signal is available only if you turn on the Enable 96b Time of Day Format parameter. |
tx_time_of_day_64b_data[63:0] | Input | Current 64-bit TOD in clk_txmac clock domain. Connect this signal to the
external TOD module.
This signal is available only if you turn on the Enable 64b Time of Day Format parameter. |
rx_time_of_day_96b_data[95:0] | Input | Current
V2-format
(96-bit) TOD in clk_rxmac clock domain. Connect this signal to the
external TOD
module.
This signal is available only if you turn on the Enable 96b Time of Day Format parameter. |
rx_time_of_day_64b_data[63:0] | Input | Current 64-bit TOD in clk_rxmac clock domain. Connect this signal to the
external TOD module.
This signal is available only if you turn on the Enable 64b Time of Day Format parameter. |
PTP Interface to Client | ||
TX Signals Related to One Step Processing | ||
tx_etstamp_ins_ctrl_timestamp_insert | Input | Indicates the current packet on the TX client interface is a 1588
PTP packet, and directs the IP core to process the packet in
one-step processing insertion mode. In this mode, the IP core
overwrites the timestamp of the packet with the timestamp when the
packet appears on the TX Ethernet
link.
The TX client must assert and deassert this signal synchronously with the TX SOP signal for the 1588 PTP packet. If the TX client asserts this signal simultaneously with either of tx_etstamp_ins_ctrl_residence_time_update or tx_egress_timestamp_request_valid, the results are undefined. |
tx_etstamp_ins_ctrl_residence_time_update | Input | Indicates the current packet on the TX client interface is a 1588
PTP packet, and directs the IP core to process the packet in
one-step processing correction mode. In this mode, the IP core adds
the latency through the IP core (residence time) to the current
contents of the timestamp
field.
The TX client must assert and deassert this signal synchronously with the TX SOP signal for the 1588 PTP packet. If the TX client asserts this signal simultaneously with either of tx_etstamp_ins_ctrl_timestamp_insert or tx_egress_timestamp_request_valid, the results are undefined. |
tx_etstamp_ins_ctrl_ingress_timestamp_96b[95:0] | Input |
Iindicates the V2-format TOD when the packet entered the system. The TX client must ensure this signal is valid in each TX SOP cycle when it asserts tx_etstamp_ins_ctrl_residence_time_update. The TX client must maintain the desired value on this signal while the TX SOP signal is asserted. This signal is useful only in transparent clock mode when the TX client asserts tx_etstamp_ins_ctrl_residence_time_update. This signal is available only if you turn on the Enable 96b Time of Day Format parameter. |
tx_etstamp_ins_ctrl_ingress_timestamp_64b[63:0] | Input |
Indicates the TOD (in Altera 64-bit format) when the packet entered the system. The TX client must ensure this signal is valid in each TX SOP cycle when it asserts tx_etstamp_ins_ctrl_residence_time_update. The TX client must maintain the desired value on this signal while the TX SOP signal is asserted. This signal is useful only in transparent clock mode when the TX client asserts tx_etstamp_ins_ctrl_residence_time_update. This signal is available only if you turn on the Enable 64b Time of Day Format parameter. |
tx_etstamp_ins_ctrl_timestamp_format | Input | Specifies the timestamp format (V1 or V2 format) for the current
packet if the TX client simultaneously asserts tx_etstamp_ins_ctrl_timestamp_insert.
Values are:
The TX client must maintain the desired value on this signal while the TX SOP signal is asserted. If the client specifies the V1 format, you read and write the V1 format TOD (32 bits of seconds and 32 bits of nanoseconds) in bits [79:16] of the 96-bit timestamp and TOD signals. Note: If you do not turn on the Enable 96b Time of Day Format
parameter, the results of asserting tx_etstamp_ins_ctrl_timestamp_insert are
undefined. Therefore, the timestamp in either case maps to the
96-bit signals.
|
tx_etstamp_ins_ctrl_residence_time_calc_format | Input | Specifies the
TOD
format
(Altera
64-bit TOD format or the V2 96-bit format) for the
current packet if the TX client simultaneously asserts tx_etstamp_ins_ctrl_residence_time_update. Values
are:
The TX client must maintain the desired value on this signal while the TX SOP signal is asserted. If you turned on Enable 96b Time of Day Format and the client specifies the 64-bit format, the IP core maps the 64-bit TOD format time-of-day (32 bits of seconds and 32 bits of nanoseconds) as is in bits [79:16] of the 96-bit timestamp and TOD signals. If you turned off Enable 96b Time of Day Format and the client specifies the 96-bit format (V2), the results are undefined. |
tx_etstamp_ins_ctrl_offset_timestamp[15:0] |
Input |
Specifies the byte offset of the timestamp information in the current packet if the TX client simultaneously asserts tx_etstamp_ins_ctrl_timestamp_insert. The IP core overwrites the value at this offset. The TX client must maintain the desired value on this signal while the TX SOP signal is asserted. If the packet supports V2 format, the timestamp has 96 bits. In this case, the IP core inserts ten bytes (bits [95:16]) of the timestamp at this offset and the remaining two bytes (bits [15:0]) of the timestamp at the offset specified in tx_etstamp_ins_ctrl_offset_correction_field. The offset must support inclusion of the entire timestamp in the first 256 bytes of the packet. The TX client must ensure that the timestamp bytes and the UDP checksum bytes in the packet do not overlap. The IP core does not check for overlap. If these two fields overlap, the results are undefined. |
tx_etstamp_ins_ctrl_offset_correction_field[15:0] | Input | If the TX client simultaneously asserts tx_etstamp_ins_ctrl_residence_time_update, this signal
specifies the byte offset of the correction field in the the current
packet.
If the TX client simultaneously asserts tx_etstamp_ins_ctrl_timestamp_insert and deasserts (sets to the value of 0) the tx_etstamp_ins_ctrl_timestamp_format signal, this signal specifies the byte offset of bits [15:0]] of the timestamp. The TX client must maintain the desired value on this signal while the TX SOP signal is asserted. The offset must support inclusion of the entire timestamp in the first 256 bytes of the packet. The TX client must ensure that the correction field bytes and the UDP checksum bytes in the packet do not overlap. The IP core does not check for overlap. If these two fields overlap, the results are undefined. |
tx_etstamp_ins_ctrl_checksum_zero | Input | The TX client asserts this signal during a TX SOP cycle to tell the
IP core to zero the
UDP
checksum in the current packet.
If the TX client asserts the tx_etstamp_ins_ctrl_checksum_correct signal, it cannot assert this signal. This signal is meaningful only in two-step clock mode. A zeroed UDP checksum indicates the checksum value is not necessarily correct. This information is useful to tell the application to skip checksum checking of UDP IPv4 packets. This function is illegal for UDP IPv6 packets. |
tx_etstamp_ins_ctrl_offset_checksum_field[15:0] | Input | Indicates the byte offset of the
UDP
checksum in the current packet. The TX client must ensure this
signal has a valid value during each TX SOP cycle when it also
asserts the tx_etstamp_ins_ctrl_checksum_zero signal. Holds the
byte offset of the two bytes in the packet that the IP core should
reset. This signal is meaningful only in two-step clock mode.
The TX client must ensure that the UDP checksum bytes and the timestamp bytes in the packet do not overlap. The IP core does not check for overlap. If these two fields overlap, the results are undefined. |
tx_etstamp_ins_ctrl_checksum_correct | Input | The TX client asserts this signal during a TX SOP cycle to tell the
IP core to update (correct) the
UDP
checksum in the current packet.
If the TX client asserts the tx_etstamp_ins_ctrl_checksum_zero signal, it cannot assert this signal. This signal is meaningful only in two-step clock mode. The application must assert this signal for correct processing of UDP IPv6 packets. |
tx_etstamp_ins_ctrl_offset_checksum_correction[15:0] | Input | Indicates the byte offset of the
UDP
checksum in the current packet. The TX client must ensure this
signal has a valid value during each TX SOP cycle when it also
asserts the tx_etstamp_ins_ctrl_checksum_correct signal. Holds the
byte offset of the two bytes in the packet that the IP core should
correct. This signal is meaningful only in two-step clock mode.
The TX client must ensure that the UDP checksum bytes and the timestamp bytes in the packet do not overlap. The IP core does not check for overlap. If these two fields overlap, the results are undefined. |
tx_egress_asymmetry_update | Input | Indicates the IP core should include the value in the TX_PTP_ASYM_DELAY register in its
correction calculations. The TX client must maintain the desired
value on this signal while the TX SOP signal is asserted.
This option is useful in two-step correction mode. |
TX Signals Related to Two Step Processing | ||
tx_egress_timestamp_request_valid | Input | Indicates the current packet on the TX client
interface is a 1588 PTP packet, and directs the IP core to process
the packet in two-step processing mode. In this mode, the IP core
outputs the timestamp of the packet when it exits the IP core, and
does not modify the packet timestamp information.
The TX client must assert and deassert this signal synchronously with the TX SOP signal for the 1588 PTP packet. If the TX client asserts this signal simultaneously with either of tx_etstamp_ins_ctrl_timestamp_insert or tx_etstamp_ins_ctrl_residence_time_update, the results are undefined. |
tx_egress_timestamp_96b_data[95:0] |
Output |
Provides the V2-format timestamp when a 1588 PTP frame begins transmission on the Ethernet link. Value is valid when the tx_egress_timestamp_96b_valid signal is asserted. This signal is meaningful only in two-step clock mode. This signal is available only if you turn on the Enable 96b Time of Day Format parameter. |
tx_egress_timestamp_96b_valid | Output | Indicates that the tx_egress_timestamp_96b_data and tx_egress_timestamp_96b_fingerprint
signals are valid in the current clk_txmac clock cycle. This signal is meaningful only
in two-step clock mode.
This signal is available only if you turn on the Enable 96b Time of Day Format parameter. |
tx_egress_timestamp_64b_data[63:0] |
Output |
Provides the timestamp when a V1-format 1588 PTP frame begins transmission on the Ethernet link. Value is valid when the tx_egress_timestamp_64b_valid signal is asserted. This signal is meaningful only in two-step clock mode. This signal is available only if you turn on the Enable 64b Time of Day Format parameter. |
tx_egress_timestamp_64b_valid | Output | Indicates that the tx_egress_timestamp_64b_data and tx_egress_timestamp_64b_fingerprint
signals are valid in the current clk_txmac clock cycle. This signal is meaningful only
in two-step clock mode.
This signal is available only if you turn on the Enable 64b Time of Day Format parameter. |
tx_egress_timestamp_request_fingerprint[(W–1):0]
where W is the value between 1 and 16, inclusive, that you specify for the Timestamp fingerprint width parameter |
Input | Fingerprint of the current packet.
The TX client must assert and deassert this signal synchronously with the TX SOP signal for the 1588 PTP packet. |
tx_egress_timestamp_96b_fingerprint[(W–1):0]
where W is the value between 1 and 16, inclusive, that you specify for the Timestamp fingerprint width parameter |
Output | Provides the fingerprint of the V2-format 1588
PTP frame currently beginning transmission on the Ethernet link.
Value is valid when the tx_egress_timestamp_96b_valid signal is asserted.
This signal is available only if you turn on the Enable 96b Time of Day Format parameter. |
tx_egress_timestamp_64b_fingerprint[(W–1):0]
where W is the value between 1 and 16, inclusive, that you specify for the Timestamp fingerprint width parameter |
Output | Provides the fingerprint of the V1-format 1588
PTP frame currently beginning transmission on the Ethernet link.
Value is valid when the tx_egress_timestamp_64b_valid signal is asserted.
This signal is available only if you turn on the Enable 64b Time of Day Format parameter. |
RX Signals | ||
rx_ingress_timestamp_96b_data[95:0] |
Output |
Whether or not the current packet on the RX client interface is a 1588 PTP packet, indicates the V2-format timestamp when the IP core received the packet on the Ethernet link. The IP core provides a valid value on this signal in the same cycle it asserts the RX SOP signal for 1588 PTP packets. This signal is available only if you turn on the Enable 96b Time of Day Format parameter. |
rx_ingress_timestamp_96b_valid |
Output |
Indicates that the rx_ingress_timestamp_96b_data signal is valid in the
current cycle. This signal is redundant with the RX SOP signal for
1588 PTP packets.
This signal is available only if you turn on the Enable 96b Time of Day Format parameter. |
rx_ingress_timestamp_64b_data[63:0] |
Output |
Whether or not the current packet on the RX client interface is a 1588 PTP packet, indicates the 64-bit TOD (in Altera 64-bit format) when the IP core received the packet on the Ethernet link. The IP core provides a valid value on this signal in the same cycle it asserts the RX SOP signal for 1588 PTP packets. This signal is available only if you turn on the Enable 64b Time of Day Format parameter. |
rx_ingress_timestamp_64b_valid |
Output |
Indicates that the rx_ingress_timestamp_64b_data signal is valid in the
current cycle. This signal is redundant with the RX SOP signal for
1588 PTP packets.
This signal is available only if you turn on the Enable 64b Time of Day Format parameter. |
PHY Status Interface
The rx_pcs_ready output signal is available to provide status information to user logic. This signal is asserted when the RX lanes are fully aligned and ready to receive data.
The tx_lanes_stable output signal is available to provide status information to user logic. This signal is asserted when the TX lanes are fully aligned and ready to transmit data.
Transceiver PHY Serial Data Interface
The core uses an <n> lane digital interface to send data to the TX high-speed serial I/O pins operating at 10.3125 Gbps in the standard 40GbE and 100GbE variations and at 25.78125 Gbps in the CAUI–4 variations. The rx_serial and tx_serial ports connect to the 10.3125 Gbps or 25.78125 Gbps pins. Virtual lanes 0 and 1 transmit data on tx_serial[0].
Low Latency 40GBASE-KR4 IP Core Variations
The LL 40GBASE-KR4 IP core supports low-level control of analog transceiver properties for link training and auto-negotiation in the absence of a predetermined environment for the IP core. For example, an Ethernet IP core in a backplane may have to communicate with different link partners at different times. When it powers up, the environment parameters may be different than when it ran previously. The environment can also change dynamically, necessitating reset and renegotiation of the Ethernet link.
The LL 40-100GbE IP core 40GBASE-KR4 variations implement the IEEE Backplane Ethernet Standard 802.3ap-2007. The LL 40-100GbE IP core provides this reconfiguration functionality in Arria 10 devices by configuring each physical Ethernet lane with an Altera Backplane Ethernet 10GBASE-KR PHY IP core if you turn on Enable KR4 in the 40-100GbE parameter editor. The parameter is available in variations parameterized with these values:
- Device family: Arria 10
- Protocol speed: 40GbE
- Enable 1588 PTP : Off
The IP core includes the option to implement the following features:
- KR auto-negotiation provides a process to explore coordination with a link partner on a variety of different common features. The 40GBASE-KR4 variations of the LL 40-100GbE IP core can auto-negotiate only to a 40GBASE-KR4 configuration. Turn on the Enable KR4 Reconfiguration and Enable Auto-Negotiation parameters to configure support for auto-negotiation.
-
Link training provides a process for the IP core to train the link to the data frequency of incoming data, while compensating for variations in process, voltage, and temperature. Turn on the Enable KR4 Reconfiguration and Enable Link Training parameters to configure support for link training.
- After the link is up and running, forward error correction (FEC) provides an error detection and correction mechanism to enable noisy channels to achieve the Ethernet-mandated bit error rate (BER) of 10-12. Turn on the Include FEC sublayer parameter to configure support for FEC.
The LL 40GBASE-KR4 IP core variations include separate link training and FEC modules for each of the four Ethernet lanes, and a single auto-negotiation module. You specify the master lane for performing auto-negotiation in the parameter editor, and the IP core also provides register support to modify the selection dynamically.
Altera provides a testbench for LL 40GBASE-KR4 IP core variations with an Avalon-ST client interface that generate their own TX MAC clock (Use external TX MAC PLL is turned off). Altera provides an example project for all LL 40GBASE-KR4 IP core variations that generate their own TX MAC clock, to assist you in integrating your LL 40GBASE-KR4 IP core into your complete design. You can examine the testbench and example project for an example of how to drive and connect the 40GBASE-KR4 IP core.
IP core FEC functionality relies on register settings in the LL 40GBASE-KR4 registers and on some specific register fields in the Arria 10 device registers.
To simulate correctly and to run correctly in hardware, you must drive the reconfig_clk and the clk_status inputs from the same source clock.
Control and Status Interface
The control and status interface provides an Avalon-MM interface to the IP core control and status registers. The Avalon-MM interface implements a standard memory‑mapped protocol. You can connect an embedded processor or JTAG Avalon master to this bus to access the control and status registers.
Signal Name |
Direction |
Description |
---|---|---|
status_addr [15:0] |
Input |
Address for reads and writes |
status_read |
Input |
Read command |
status_write |
Input |
Write command |
status_writedata [31:0] |
Input |
Data to be written |
status_readdata [31:0] |
Output |
Read data |
status_readdata_valid |
Output |
Read data is ready for use |
status_waitrequest |
Output |
Busy signal indicating control and status interface cannot currently respond to requests |
status_read_timeout |
Output |
Timeout signal indicating read data did not arrive when expected. Hardwired timeout counter is set so that this timeout should only occur in the presence of an error condition, such as status_addr with an undefined value. This signal is not an Avalon-MM defined signal |
The status interface is designed to operate at a low frequencies, typically 100 MHz, so that control and status logic does not compete for resources with the surrounding high speed datapath.
Arria 10 Transceiver Reconfiguration Interface
Arria 10 variations provide a dedicated Avalon-MM interface, called the Arria 10 transceiver reconfiguration interface, to access the transceiver registers. You access the Arria 10 Native PHY IP core registers through this dedicated interface and not through the IP core general purpose control and status interface.
The Avalon-MM interface implements a standard memory‑mapped protocol. You can connect an embedded processor or JTAG Avalon master to this bus to access the registers of the embedded Arria 10 Native PHY IP core.
Signal Name |
Direction |
Description |
---|---|---|
reconfig_address [11:0] (40GbE and CAUI-4) reconfig_address [13:0] (100GbE) |
Input |
Address for reads and writes |
reconfig_read |
Input |
Read command |
reconfig_write |
Input |
Write command |
reconfig_writedata [31:0] |
Input |
Data to be written |
reconfig_readdata [31:0] |
Output |
Read data |
reconfig_waitrequest |
Output |
Interface busy signal |
The Arria 10 reconfiguration interface is designed to operate at a low frequency, 100 MHz to 125 MHz, so that the user's Arria 10 transceiver reconfiguration logic does not compete for resources with the surrounding high speed datapath.
Clocks
You must set the transceiver reference clock (clk_ref) frequency to a value that the IP core supports. The Low Latency 40-100GbE IP core supports clk_ref frequencies of 644.53125 MHz ±100 ppm and 322.265625 MHz ± 100 ppm. The ±100ppm value is required for any clock source providing the transceiver reference clock.
Sync–E IP core variations are IP core variations for which you turn on Enable SyncE in the parameter editor. These variations provide the RX recovered clock as a top-level output signal. This option is available only for IP core variations that target an Arria 10 device.
The Synchronous Ethernet standard, described in the ITU-T G.8261, G.8262, and G.8264 recommendations, requires that the TX clock be filtered to maintain synchronization with the RX reference clock through a sequence of nodes. The expected usage is that user logic drives the TX PLL reference clock with a filtered version of the RX recovered clock signal, to ensure the receive and transmit functions remain synchronized. In this usage model, a design component outside the LL 40-100GbE IP core performs the filtering.
Signal Name |
Description |
---|---|
clk_status |
Clocks the control and status interface. The clock quality and pin chosen are not critical. clk_status is expected to be a 100–125 MHz clock. In LL 40GBASE-KR4 variations, you must drive clk_status and reconfig_status from a single clock source. |
reconfig_clk |
Clocks the Arria 10 transceiver reconfiguration interface. The clock quality and pin chosen are not critical. reconfig_clk is expected to be a 100 MHz clock; the allowed frequency range depends on Arria 10 transceiver requirements and is not IP core specific. In LL 40GBASE-KR4 variations, you must drive clk_status and reconfig_clk from a single clock source. |
clk_ref |
In IP core variations that target an Arria 10 device, clk_ref is the reference clock for the transceiver RX CDR PLL. In other IP core variations, clk_ref is the reference clock for the transceiver TX PLL and the RX CDR PLL. The frequency of this input clock must match the value you specify for PHY reference frequency in the IP core parameter editor, with a ±100 ppm accuracy per the IEEE 802.3ba-2010 100G Ethernet Standard. . In addition, clk_ref must meet the jitter specification of the IEEE 802.3ba-2010 100G Ethernet Standard. The PLL and clock generation logic use this reference clock to derive the transceiver and PCS clocks. The input clock should be a high quality signal on the appropriate dedicated clock pin. Refer to the relevant device datasheet for transceiver reference clock phase noise specifications. |
clk_txmac_in | If you turn on Use external TX MAC PLL in the LL 40-100GbE parameter editor, this clock drives the TX MAC. The port is expected to receive the clock from the external TX MAC PLL and drives the internal clock clk_txmac. The required TX MAC clock frequency is 312.5 MHz for 40GbE variations, and 390.625 MHz for 100GbE variations. User logic must drive clk_txmac_in from a PLL whose input is the PHY reference clock, clk_ref. |
tx_serial_clk[3:0] (for 40GbE and CAUI-4 variations that target an Arria 10 device) tx_serial_clk[9:0] (for standard 100GbE variations that target an Arria 10 device) |
These input clocks are present only in variations that target an Arria 10 device. They are part of the external PLL interface to these variations. Each clock targets a single transceiver PHY link. You must drive these clocks from one or more TX transceiver PLLs that you configure separately from the Low Latency 40-100GbE IP core. |
Signal Name |
Description |
---|---|
clk_txmac |
The TX clock for the IP core is clk_txmac. The TX MAC clock frequency is 312.5 MHz for 40GbE IP core variations and 390.625 MHz for 100GbE IP core variations. If you turn on Use external TX MAC PLL in the LL 40-100GbE parameter editor, the clk_txmac_in input clock drives clk_txmac. |
clk_rxmac |
The RX clock for the IP core is clk_rxmac. The RX MAC clock frequency is 312.5 MHz for 40GbE IP core variations and 390.625 MHz for 100GbE IP core variations. This clock is only reliable when rx_pcs_ready has the value of 1. The IP core generates clk_rxmac from a recovered clock that relies on the presence of incoming RX data. |
clk_rx_recover | RX recovered clock. This clock is available
only if you turn on Enable
SyncE in the LL 40-100GbE parameter
editor.
The RX recovered clock frequency is 257.81 MHz in 40GbE IP core variations and 322.265625 MHz in 100GbE IP core variations. The expected usage is that you drive the TX transceiver PLL reference clock with a filtered version of clk_rx_recover, to ensure the receive and transmit functions remain synchronized in your Synchronous Ethernet system. To do so you must instantiate an additional component in your design. The IP core does not provide filtering. |
Resets
The Low Latency 40-100GbE IP core has a single asynchronous reset signal. Asserting this signal resets the full IP core. You must hold the reset signal asserted for ten clk_status clock cycles to ensure proper hold time.
You should not release the reset signal until after you observe that the reference clock is stable. If the reference clock is generated from an fPLL, wait until after the fPLL locks. Ten clk_status cycles should be sufficient for the fPLL to lock and the reference clock to stabilize.
Signal Name |
Direction |
Description |
---|---|---|
reset_async |
Input |
Low Latency 40-100GbE IP core asynchronous reset signal |
In addition, the Low Latency 40-100GbE IP core has one or two of the following synchronous reset signals:
- reset_status—Resets the IP core control and status interface, an Avalon-MM interface. Associated clock is the clk_status clock, which clocks the control and status interface.
- reconfig_reset—Resets the IP core Arria 10 transceiver reconfiguration interface, an Avalon-MM interface. Associated clock is the reconfig_clk, which clocks the Arria 10 transceiver reconfiguration interface. This signal is available only in Arria 10 IP core variations.
Signals
This section lists the external signals of the different 40-100GbE IP core variations.
Low Latency 40-100GbE IP Core Signals
The signals of the Low Latency 40-100GbE IP core are described in the following formats:
- The figure identifies the IP core interfaces.
- Tables list the signals and the interfaces to which they belong.
- Links guide you to descriptions for the individual signals, by interface. The links are available only if you are viewing this topic in the context of the Functional Description chapter of the Low Latency 40- and 100-Gbps Ethernet MAC and PHY MegaCore Function User Guide. The links appear in Related Links, below.
Signal Name |
Direction |
Interface |
---|---|---|
clk_ref |
Input |
Clocks |
clk_rx_recover | Output | Clocks
This signal is only available if you turn on Enable SyncE in the parameter editor. |
reset_async |
Input |
Reset |
tx_serial[3:0] (40GbE and CAUI–4) tx_serial[9:0] (100GbE) |
Output |
Transceiver PHY serial data interface |
rx_pcs_ready |
Output |
PHY status |
tx_lanes_stable | Output | |
clk_txmac_in | Input |
Clocks Interface to external TX MAC PLL This signal is only available if you turn on Enable external TX MAC PLL in the parameter editor. |
clk_txmac |
Output |
Clocks TX client interface |
l<n>_tx_data[<n>*64-1:0] |
Input |
Avalon-ST TX client interface Each IP core instance has Avalon-ST TX and RX client interfaces, or custom streaming TX and RX client interfaces. |
l<n>_tx_empty[<l>-1:0] |
Input |
|
l<n>_tx_startofpacket |
Input |
|
l<n>_tx_endofpacket |
Input |
|
l<n>_tx_ready |
Output |
|
l<n>_tx_valid |
Input |
|
l<n>_tx_error | Input | |
din[<w>*64-1:0] |
Input |
Custom streaming TX client interface Each IP core instance has Avalon-ST TX and RX client interfaces, or custom streaming TX and RX client interfaces. |
din_sop[<w>-1:0] |
Input |
|
din_eop[<w>-1:0] |
Input |
|
din_eop_empty[<w>*3-1:0] |
Input |
|
din_idle[<w>-1:0] |
Input |
|
din_req |
Output |
|
tx_error[<w>-1:0] | Input | |
clk_rxmac |
Output |
Clocks RX client interface |
l<n>_rx_data[<n>*64-1:0] |