Low Latency 40- and 100-Gbps Ethernet MAC and PHY MegaCore Function User Guide

RSS

UG-01172 | 2017.12.28

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.

Note: This user guide documents the 16.0 version of the Altera Low Latency 40- and 100-Gbps Ethernet MAC and PHY IP core that targets a Stratix^® V device or an Arria^® 10 device. For the 16.1 release and beyond, two IP core user guides are available to document the Low Latency 40-Gbps Ethernet IP core and the Low Latency 100-Gbps Ethernet IP core separately. These two user guides document the variations that target an Arria^® 10 device. As of 2017.12.28, the 16.0 version of the Stratix^® V Low Latency 40-100GbE IP core is the most recent Stratix^® V Low Latency 40-100GbE IP core available in the Self-Service Licensing Center and this user guide provides its most current documentation.

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.

Note: The full product name, Low Latency 40- and 100-Gbps Ethernet MAC and PHY MegaCore Function, is shortened to Low Latency (LL) 40-100GbE IP core in this document. In addition, although multiple variations are available from the parameter editor, this document refers to this product as a single IP core, because all variations are configurable from the same parameter editor.

Figure 1. Low Latency 40GbE and 100GbE MAC and PHY IP CoresMain blocks, internal connections, and external block requirements.

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

Table 1. Altera IP Core Device Support Levels
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.

Table 2. Low Latency 40-100GbE IP Core Device Family Support. Shows the level of support offered by the Low Latency 40‑100GbE IP core for each Altera device family.
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

Table 3. Slowest Supported Device Speed Grades. Lists the slowest supported device speed grades for standard variations of the Low Latency 40-100GbE IP core. IP core variations that include a 1588 PTP module might require Quartus^® Prime seed sweeping to achieve a comfortable timing margin.
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.

Table 4. IP Core Variation Encoding for Resource Utilization Tables. "On" indicates the parameter is turned on. The symbol "—" indicates the parameter is turned off or not available.
IP Core Variation	A	B	C	D	E	F
Parameter	A	B	C	D	E	F
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.

Table 5. IP Core FPGA Resource Utilization in Stratix V Devices . Lists the resources and expected performance for selected variations of the Low Latency 40-100GbE IP cores in a Stratix V device.
These results were obtained using the Quartus II v14.1 software.

The numbers of ALMs and logic registers are rounded up to the nearest 100.

The numbers of ALMs, before rounding, are the **ALMs needed** numbers from the Quartus II Fitter Report.
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

Table 6. IP Core FPGA Resource Utilization in Arria 10 Devices . Lists the resources and expected performance for selected variations of the Low Latency 40-100GbE IP cores in an Arria 10 device.
These results were obtained using the Quartus II v14.1 software.

The numbers of ALMs and logic registers are rounded up to the nearest 100.

The numbers of ALMs, before rounding, are the **ALMs needed** numbers from the Quartus II Fitter Report.
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

Table 7. Low Latency 40‑100GbE IP Core Current 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 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.

Figure 2. IP Core Directory Structure Directory structure after you install the Low Latency 40-100GbE IP core. The default installation directory <path> on Windows is C:\altera\< version number >; on Linux it is /opt/altera< version number >.

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

The Altera^® IP Library provides many useful IP core functions for your production use without purchasing an additional license. Some Altera MegaCore^® IP functions require that you purchase a separate license for production use. However, the OpenCore^® feature allows evaluation of any Altera IP core in simulation and compilation in the Quartus^® Prime software. After you are satisfied with functionality and performance, visit the Self Service Licensing Center to obtain a license number for any Altera product.

Figure 3. IP Core Installation Path

Note: The default IP installation directory on Windows is <drive>:\altera\ <version number>; on Linux the IP installation directory is <home directory> /altera/ <version number> .

OpenCore Plus IP Evaluation

Altera's free OpenCore^® Plus feature allows you to evaluate licensed MegaCore^® IP cores in simulation and hardware before purchase. You only need to purchase a license for MegaCore IP cores if you decide to take your design to production. OpenCore Plus supports the following evaluations:

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.

Note: All IP cores that use OpenCore Plus time out simultaneously when any IP core in the design times out.

Specifying the Low Latency 40-100GbE IP Core Parameters and Options

The Low Latency 40-100GbE parameter editor allows you to quickly configure your custom IP variation. Use the following steps to specify IP core options and parameters in the Quartus Prime software.

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:
1. Optionally, to generate a simulation testbench or example project, follow the instructions in Generating the Low Latency 40-100GbE Testbench.
2. Click Generate HDL. The Generation dialog box appears.
3. Specify output file generation options, and then click Generate. The IP variation files generate according to your specifications.
4. 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:
1. Click Finish.
2. 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.

Table 8. Low Latency 40-100GbE Parameters: Main Tab. Describes the parameters for customizing the 40-100GbE IP core on the Main tab of the 40-100GbE parameter editor.
Parameter	Type	Range	Default Setting	Parameter Description
General Options
Device family	String	Stratix V Arria 10	According to the setting in the project or IP Catalog settings.	Selects the device family.
Protocol speed	String	40 GbE 100 GbE	100 GbE	Selects the MAC datapath width.
Data interface	String	Custom–ST Avalon–ST	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
Enable CAUI4 PCS ¹ ²	Boolean	True False	False	If turned on, the IP core is a 100GbE CAUI-4 variation, with four 25.78125 Gbps transceiver PHY links.
Enable SyncE	Boolean	True False	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)	322.265625 MHz 644.53125 MHz	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	True False	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 Standard flow control Priority-based flow control	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	Disable deficit idle counter 8 12	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	True False	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 False	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	True False	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	True False	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 False	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	True False	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 False	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 False	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 False	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	True False	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: Enable Altera Debug Master Endpoint (ADME) Enable capability registers 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.

Table 9. LL 40-100GbE Parameters: 40GBASE-KR4 Tab. Describes the parameters for customizing a 40GBASE-KR4 Low Latency 40-100GbE IP core, on the 40GBASE-KR4 tab of the LL 40-100GbE parameter editor. The parameters on this tab are available only if the following conditions hold:

Your IP core targets an Arria 10 device. You set the target device family for your Quartus Prime project or in the Quartus Prime software before you acess the IP Catalog.

You select the value of 40GbE for the Protocol speed parameter on the Main tab.

You turn off the Enable 1588 PTP parameter on the Main tab.
Parameter	Type	Range	Default Setting	Parameter Description
KR4 General Options
Enable KR4	Boolean	True False	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: To ensure the IP core measures the link fail inhibit time accurately. Determines the value of the Link Fail Inhibit timer (IEEE 802.3 clause 73.10.2) correctly. If `clk_status` frequency is not 100 MHz, to adjust the PHY clock monitors to report accurate frequency 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 False	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 Lane 1 Lane 2 Lane 3	Lane 0	Selects the master channel for auto-negotiation.
Pause ability–C0	Boolean	True False	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 False	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 V_OD. The default value, 60, represents 1200 mV.
VMINRULE	Integer	0–31	6	Specifies the minimum V_OD. The default value, 9, represents 165 mV.
VODMINRULE	Integer	0–31	14	Specifies the minimum V_OD 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 V_OD 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 V_OD 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 False	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	2ⁿ – 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 255	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	True False	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 False	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 False	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.

Table 10. Low Latency 40-100GbE PHY Parameter Settings. Lists the PHY parameters that are configured automatically based on parameter values you select in the Low Latency 40G/100G Ethernet parameter editor.
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

¹ The Enable CAUI4 PCS parameter is disabled when Protocol speed is set to 100GbE and Device family is not Arria 10 , and when Protocol speed is set to 40GbE. If the parameter is disabled, the IP core is configured with the regular 100 Gbps PHY link option of 10 x 10.3125 Gbps.

² For the Device family parameter, the CAUI-4 option requires the Arria 10 device.

Files Generated for Stratix V Variations

The Quartus Prime software generates the following output for your Stratix V LL 40-100GbE IP core.

Figure 4. IP Core Generated Files

Files Generated for Arria 10 Variations

The Quartus Prime software generates the following IP core output file structure when targeting Arria 10 devices.

Figure 5. IP Core Generated Files

Table 11. IP Core Generated Files (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

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

Low Latency 40-100GbE IP cores that target Stratix V devices require an external reconfiguration controller to compile and to function correctly in hardware. Low Latency 40-100GbE IP cores that target Arria 10 devices include a reconfiguration controller block in the PHY component and do not require an external reconfiguration controller.

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.

Table 12. Number of Reconfiguration Interfaces. Lists the number of reconfiguration interfaces you should specify for the Altera Transceiver Reconfiguration Controller for your Stratix V Low Latency 40-100GbE IP core. Low Latency 40-100GbE IP cores that target Arria 10 devices include a reconfiguration controller block in the PHY component and do not require any external reconfiguration controllers.
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..

Table 13. External Altera Transceiver Reconfiguration Controller Ports for Connection to Low Latency 40-100GbE 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.

Figure 6. PLL Configuration ExampleIn this example, the TX transceiver PLL is instantiated with an Altera ATX PLL IP core. The TX transceiver PLL must always be instantiated outside the LL 40-100GbE IP core.

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.

Note: If your Arria 10 design includes multiple instances of the LL 40-100GbE IP core, do not use the ATX PLL HDL code provided with the IP core. Instead, generate new TX PLL IP cores to connect in your design.

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.

Table 14. TOD Module Required Connections. Required connections for TOD module, listed using signal names for TOD modules that provide both a 96-bit TOD and a 64-bit TOD. If you create your own TOD module it must have the output signals required by the LL 40-100GbE IP core. However, its signal names could be different than the TOD module signal names in the table. The signals that that the IP core includes depend on the Enable 96b Time of Day Format and Enable 64b Time of Day Format parameters. For example, an RX TOD module might require only a 96-bit TOD out signal.
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.

Figure 7. Low Latency 40-100GbE non-40GBASE-KR4 IP Core Testbench Illustrates the top-level modules of the Low Latency 40GbE and 100GbE example testbenches.

Figure 8. 40GBASE-KR4 LL 40GbE IP Core TestbenchIllustrates the top-level modules of the LL 40GBASE-KR4 example testbench. To support the simulation of auto-negotiation, the testbench uses two instances of the IP core instead of configuring the IP core in loopback mode.

Table 15. Low Latency 40-100GbE IP Core Testbench File Descriptions. Lists the key files that implement the example testbenches.
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.

Figure 9. Typical 40GbE Traffic on the Avalon-ST InterfaceShows typical traffic from the simulation testbench created using the run_vsim.do script in ModelSim. In this case the IP core is a 40GbE IP core with adapters. In Stratix V variations the script is found in <instance_name> _example_design/alt_eth_ultra/example_testbench/run_vsim.do and in Arria 10 variations the script is found in <example_design_directory> /example_testbench/run_vsim.do.

Note: Client logic must maintain the l4_tx_valid signal asserted while asserting SOP, through the assertion of EOP. Client logic should not pull this signal low during a packet transmission.

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.

Note: The ready latency on the Avalon-ST TX client interface is 0.

Understanding the Testbench Behavior

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

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>;

Note: Whether you use the Altera-provided testbench or your own custom testbench, you must update the testbench file with these lines and the derived values. The testbench file generated with the Low Latency 40-100GbE IP core does not include the correct values, which depend on your IP core variation and simulation tool.

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 2¹⁴ 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

Figure 10. Low Latency 40GbE and 100GbE MAC and PHY IP CoresMain blocks, internal connections, and external block requirements.

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.

Figure 11. Typical Client Frame at the Transmit InterfaceIllustrates the changes that the TX MAC makes to the client frame. This figure uses the following notational conventions:

<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.

CAUTION:

The Low Latency 40-100GbE IP core does not process incoming (egress) frames of less than nine bytes correctly. You must ensure such frames do not reach the TX client interface.

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.

Figure 12. TX Client to MAC Interface with Adapters (Avalon-ST)The Avalon-ST interface bus width varies with the IP core variation. In the figure, <n> = 4 for the 40GbE IP core and <n> = 8 for the 100GbE IP core. <l> is log₂(8*<n>).

Table 17. Signals of the TX Client Interface . In the table, *<n>* = 4 for the 40GbE IP core and *<n>* = 8 for the 100GbE IP core. *<l>* is log₂(8**<n>*). All interface signals are clocked by the `clk_txmac` clock.
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.

Figure 13. Traffic on the TX and RX Avalon-ST Client Interface for Low Latency 40GbE IP CoreShows typical traffic for the TX and RX Avalon-ST interface Low Latency 40GbE IP core.

Figure 14. Traffic on the TX and RX Avalon-ST Client Interface for Low Latency 100GbE IP CoreShows typical traffic for the TX and RX Avalon‑ST interface of the 100GbE IP core.

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.

Figure 15. TX Client to MAC Interface Without Adapters The custom streaming interface bus width varies with the IP core variation. In the figure, <w> = 2 for the 40GbE IP core and <w> = 4 for the 100GbE IP core.

Table 18. Signals of the TX Client Interface Without Adapters . In the table, *<w>* = 2 for the 40GbE IP core and *<w>* = 4 for the 100GbE IP core. The signals are clocked by `clk_txmac`.
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.

Figure 16. Reduced Bandwidth With Left-Aligned SOP Requirement Illustrates the reduction of bandwidth that would be caused by left‑aligning the SOP for the 100GbE IP core.

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.

Figure 17. Byte Order on the Client Interface Lanes Without Preamble Pass‑ThroughDescribes the byte order on the Avalon-ST interface when the preamble pass-through feature is turned off. Destination Address[40] is the broadcast/multicast bit (a type bit), and Destination Address[41] is a locally administered address bit.

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]).

Figure 18. Octet Transmission on the Avalon-ST Signals Without Preamble Pass-Through Illustrates how the octets of the client frame are transferred over the TX datapath when preamble pass-through is turned off.

Figure 19. Byte Order on the Avalon-ST Interface Lanes With Preamble Pass‑ThroughDescribes the byte order on the Avalon-ST interface when the preamble pass-through feature is turned on.

Destination Address[40] is the broadcast/multicast bit (a type bit), and Destination Address[41] is a locally administered address bit.

Figure 20. Octet Transmission on the Avalon-ST Signals With Preamble Pass-ThroughIllustrates how the octets of the client frame are transferred over the TX datapath when preamble pass-through is turned on. The eight preamble bytes precede the destination address bytes. The preamble bytes are reversed: the application must drive the Start byte on l8_tx_data[455:448] and the SFD byte on l8_tx_data[511:504].

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.

Figure 21. Flow of Frame Through the MAC RX Without Preamble Pass-Through Illustrates the typical flow of frame through the MAC RX when the preamble pass-through feature is turned off. In this figure, <p> is payload size (0–1500 bytes), and <s> is the number of pad bytes (0–46 bytes).

Figure 22. Flow of Frame Through the MAC RX With Preamble Pass-Through Turned On Illustrates the typical flow of frame through the MAC RX when the preamble pass-through feature is turned on. In this figure, <p> is payload size (0–1500 bytes), and <s> is the number of pad bytes (0–46 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

Table 16. Table 19. User Interface Width Depends on IP Core Variation. The Low Latency 40-100GbE IP core provides two different client interfaces: the Avalon-ST interface and a custom interface. The Avalon-ST interface requires adapters and the custom streaming interface does not require adapters.
Client Interface	Data Bus Width (Bits)
Client Interface	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.

Figure 23. RX MAC to Client Interface The Avalon-ST interface bus width varies with the IP core variation. In the figure, <n> = 4 for the 40GbE IP core and <n> = 8 for the 100GbE IP core. <l> is log₂(8*<n>).

Table 20. Signals of the RX Client Interface . In the table, *<n>* = 4 for the 40GbE IP core and *<n>* = 8 for the 100GbE IP core. *<l>* is log₂(8**<n>*). The signals are clocked by `clk_rxmac`.
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: Bit [0]: Malformed packet error. If this bit has the value of 1, the packet is malformed. The IP core identifies a malformed packet when it receives a control character that is not a terminate character, while receiving the packet. Bit [1]: CRC error. If this bit has the value of 1, the IP core detected a CRC error in the frame. If you turn on Enable alignment EOP on FCS word , this bit and the `l<n>_rx_fcs_error` signal behave identically. Bit [2]: undersized payload. If this bit has the value of 1, the frame size is between nine and 63 bytes, inclusive. The IP core does not recognize an incoming frame of size eight bytes or less as a frame, and those cases are not reported here.The `l<n>_rx_error[1]` or `rx_error[1]` also signals an FCS error. Bit [3]: oversized payload. If this bit has the value of 1, the frame size is greater than the maximum frame size programmed in the `MAX_RX_SIZE_CONFIG` register at offset 0x506. Bit [4]: payload length error. If this bit has the value of 1, the payload received in the frame did not match the length field value, and the value in the length field is less than 1536 bytes. This bit only reports errors if you set bit [0] of the `CFG_PLEN_CHECK` register at offset 0x50A to the value of 1. Bit [5} Reserved.
`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: Bit [0]: Indicates the IP core received a standard flow control frame. If the IP core is in standard flow control mode and the `cfg_fwd_ctrl` bit of the `RX_PAUSE_FWD` register has the value of 0, this bit maintains the value of 0. Bit [1]: Indicates the IP core received a priority flow control frame. If the IP core is in priority flow control mode and the `cfg_fwd_ctrl` bit of the `RX_PAUSE_FWD` register has the value of 0, this bit maintains the value of 0. Bit [2]: Indicates the IP core received a control frame that is not a flow control frame.

Figure 24. Traffic on the TX and RX Avalon-ST Client Interface for Low Latency 40GbE IP CoreShows typical traffic for the TX and RX Avalon-ST interface Low Latency 40GbE IP core.

Figure 25. Traffic on the TX and RX Avalon-ST Client Interface for Low Latency 100GbE IP CoreShows typical traffic for the TX and RX Avalon‑ST interface of the 100GbE IP core.

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.

Figure 26. RX MAC to Client Interface Without Adapters The custom streaming interface bus width varies with the IP core variation. In the figure, <w> = 2 for the 40GbE IP core and <w> = 4 for the 100GbE IP core.

Table 21. Signals of the RX Client Interface Without Adapters. In the table, *<w>* = 2 for the 40GbE IP core and *<w>* = 4 for the 100GbE IP core. The signals are clocked by `clk_rxmac`.
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: Bit [0]: Malformed packet error. If this bit has the value of 1, the packet is malformed. The IP core identifies a malformed packet when it receives a control character that is not a terminate character, while receiving the packet. Bit [1]: CRC error. If this bit has the value of 1, the IP core detected a CRC error in the frame. If you turn on Enable alignment EOP on FCS word , this bit and the `rx_fcs_error` signal behave identically. Bit [2]: undersized payload. If this bit has the value of 1, the frame size is between nine and 63 bytes, inclusive. The IP core does not recognize an incoming frame of size eight bytes or less as a frame, and those cases are not reported here. Bit [3]: oversized payload. If this bit has the value of 1, the frame size is greater than the maximum frame size programmed in the `MAX_RX_SIZE_CONFIG` register at offset 0x506. Bit [4]: payload length error. If this bit has the value of 1, the payload received in the frame did not match the length field value, and the value in the length field is less than 1536 bytes. This bit only reports errors if you set bit [0] of the `CFG_PLEN_CHECK` register at offset 0x50A to the value of 1. Bit [5} Reserved.
`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: Bit [0]: Indicates the IP core received a standard flow control frame. If the IP core is in standard flow control mode and the `cfg_fwd_ctrl` bit of the `RX_PAUSE_FWD` register has the value of 0, this bit maintains the value of 0. Bit [1]: Indicates the IP core received a priority flow control frame. If the IP core is in priority flow control mode and the `cfg_fwd_ctrl` bit of the `RX_PAUSE_FWD` register has the value of 0, this bit maintains the value of 0. Bit [2]: Indicates the IP core received a control frame that is not a flow control frame.
`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).

Figure 27. The XOFF and XON Pause Frames for Standard Flow Control

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 ³		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 ⁴		PAUSE QUANTA[15:0] = 0x0000
PAD[335:0]		PAD[335:0]
CRC[31:0]		CRC[31:0]

Figure 28. The XOFF and XON Pause Frames for Priority Flow Control

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 ³		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] ⁵		PRIORITY_ENABLE[15:0] ⁶
TIME0[15:0] ⁷		TIME0[15:0] = 0x0000
...		...
TIME7[15:0] ⁷		TIME7[15:0] = 0x0000
PAD[207:0]		PAD[207:0]
CRC[31:0]		CRC[31:0]

³ This is a multicast destination address.

⁴ The bytes P1 and P2 are filled with the value configured in the TX_PAUSE_QUANTA register.

⁵ Bit [n] has the value of 1 if the TIMEn field is valid.

⁶ Bit [n] has the value of 1 if the XON request applies to priority queue n.

⁷ The TIMEn field is filled with the value available in the TX_PAUSE_QUANTAregister when the TX_PAUSE_QNUMBER register holds the value of n.

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.

Note: Altera recommends that you use the pause_insert_tx signal to backpressure the remote Ethernet node.

Note: Altera recommends that you set and maintain the value of the retransmit hold-off enable bit at 1 to control the rate of XOFF pause frame transmission.

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.

Table 22. Pause Control and Generation Signals. Describes the signals that implement pause control. These signals are available only if you turn on flow control in the LL 40-100GbE parameter editor or you upgrade your IP core from an earlier release in which the signals are available in any case.
Signal Name	Direction	Description
`pause_insert_tx[N-1:0]` ⁸	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]` ⁸	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.

⁸ N is the number of priority queues. If the IP core implements Ethernet standard flow control, N is 1.

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
The 48-bit address ({RX_PAUSE_DADDRH[15:0],RX_PAUSE_DADDRL[31:0]} can be an individual MAC address, a multicast address, or a broadcast address.
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.

Table 23. Signals of the Link Fault Signaling Interface. These signals are available only if you turn on Enable link fault generation in the LL 40-100GbE parameter editor.
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).

Table 24. Statistics Counters Increment Vectors . The TX statistics counter increment vectors are clocked by the `clk_txmac` clock, and the RX statistics counter increment vectors are clocked by the `clk_rxmac` clock.
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.

Table 25. OctetOK Count Interface Signals. The signals for received frames are clocked by the `clk_rxmac` clock. The signals for transmitted frames are clocked by the `clk_txmac` clock.
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.

Figure 29. Example Ethernet System with Ordinary Clock Master and Ordinary Clock SlaveYou can implement both master and slave clocks using the Altera LL 40-100GbE IP core with 1588 PTP functionality.

Figure 30. Hardware Configuration Example Using Altera LL 40-100GbE IP core in a 1588 System in Transparent Clock Mode

Figure 31. Software Flow Using Transparent Clock Mode SystemThis figure from the 1588 standard is augmented with the timestamp labels shown in the transparent clock system figure. A precise description of the software requirements is beyond the scope of this document. Refer to the 1588 standard.

Figure 32. Example Boundary Clock with One Slave Port and Two Master PortsYou can implement a 1588 system in boundary clock mode using the LL 40-100GbE IP core with 1588 PTP functionality.

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.

Figure 33. PTP Receive Block Diagram

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.

Figure 34. PTP Transmit Block Diagram

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

Table 26. Signals of the 1588 Precision Time Protocol Interface. Signals are clocked by `clk_rxmac` or `clk_txmac`, as specified. All 64-bit output signals are in the Altera 64-bit TOD format, and you are expected to drive all 64-bit input signals in this format.
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: 1'b0: 96-bit timestamp format (V2) 1'b1: 64-bit timestamp format (V1) 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: 1'b0: 96-bit TOD format (V2) 1'b1: 64-bit TOD format 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.

Table 27. Avalon-MM Control and Status Interface Signals. The `clk_status` clocks the signals on the LL 40-100GbE IP core control and status interface. The synchronous `reset_status` reset signal resets the interface.
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.

Figure 35. Read and Write Register Access ExampleThe waveform demonstrates a write-read-write sequence of back-to-back register accesses. The delay from the time the application asserts status_read until the IP core asserts status_readdata_valid and deasserts status_waitrequest is approximately 80 clk_status cycles in this example.

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.

Table 28. Avalon-MM Arria 10 Reconfiguration Interface Signals. The `reconfig_clk` clocks the signals on the Low Latency 40-100GbE IP core Arria 10 transceiver reconfiguration interface. The synchronous `reconfig_reset` reset signal resets the interface.
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.

Table 29. Clock Inputs. Describes the input clocks that you must provide.
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.

Table 30. Clock Outputs. Describes the output clocks that the IP core provides. In most cases these clocks participate in internal clocking of the IP core as well.
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.

Figure 36. Clock Generation Circuitry Provides a high-level view of the clock generation circuitry and clock distribution to the transceiver. In Arria 10 variations, the TX transceiver PLL is configured outside the 40-100GbE IP core, and clk_ref drives the RX CDR PLL. In Arria 10 variations, you can connect a separate reference clock for the external TX transceiver PLL.

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.

Table 31. Asynchronous Reset Signal
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.

Figure 37. Top-Level Signals of the Low Latency 40-100GbE IP Cores In the figure, <n> = 4 for the 40GbE IP cores and <n> = 8 for the 100GbE IP cores. <l> is log₂(8*<n>). In the custom streaming client interface, <w> = 2 for the 40GbE IP core and <w> = 4 for the 100GbE IP core. <v> is the number of transceiver PHY links (4 for 40GbE and CAUI-4 IP cores, and 10 for standard 100GbE IP cores). <N> is the number of priority flow control queues. (<N> = 1 for IP cores configured with standard flow control or with no flow control, and <N> = the value of the relevant parameter for IP cores configured with priority-based flow control). In the 1588 PTP signals, <W> is the width of the fingerprint.

Table 32. Low Latency 40-100GbE MAC and PHY IP Core Signals
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	PHY status
`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]`