Low Latency Ethernet 10G MAC User Guide · Low Latency Ethernet 10G MAC User Guide Last updated for Altera Complete Design Suite: 14.1 Subscribe Send Feedback UG-01144 2014.12.15

Low Latency Ethernet 10G MACUser Guide

Last updated for Altera Complete Design Suite: 14.1

Subscribe

Send Feedback

UG-011442014.12.15

101 Innovation DriveSan Jose, CA 95134www.altera.com

https://www.altera.com/servlets/subscriptions/alert?id=UG-01144

mailto:[email protected]?subject=Feedback%20on%20Low%20Latency%20Ethernet%2010G%20MAC%20User%20Guide%20(UG-01144%202014.12.15)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

Contents

About this IP Core...............................................................................................1-1Features......................................................................................................................................................... 1-1Release Information.....................................................................................................................................1-2Device Family Support................................................................................................................................ 1-3Performance and Resource Utilization.....................................................................................................1-4Transmit and Receive Latencies.................................................................................................................1-5

Getting Started.................................................................................................... 2-1Introduction to Altera IP Cores.................................................................................................................2-1Installing and Licensing IP Cores.............................................................................................................. 2-2Specifying IP Core Parameters and Options............................................................................................2-2Parameterizing the IP Core........................................................................................................................ 2-3Parameter Settings....................................................................................................................................... 2-4Generated Files.............................................................................................................................................2-7Simulating Altera IP Cores in other EDA Tools..................................................................................... 2-7Upgrading Outdated IP Cores................................................................................................................... 2-9Migrating IP Cores to a Different Device.................................................................................................2-9LL Ethernet 10G MAC Design Considerations.....................................................................................2-10

Migrating from Ethernet 10G MAC to LL Ethernet 10G MAC..............................................2-10Timing Constraints........................................................................................................................2-11

Functional Description....................................................................................... 3-1Architecture.................................................................................................................................................. 3-1Interfaces....................................................................................................................................................... 3-2Frame Types..................................................................................................................................................3-4Transmit Datapath.......................................................................................................................................3-4

Padding Bytes Insertion.................................................................................................................. 3-4Address Insertion.............................................................................................................................3-4CRC-32 Insertion.............................................................................................................................3-5XGMII Encapsulation..................................................................................................................... 3-6Inter-Packet Gap Generation and Insertion................................................................................ 3-7XGMII Transmission...................................................................................................................... 3-7Unidirectional Feature.................................................................................................................... 3-8TX Timing Diagrams.......................................................................................................................3-9

Receive Datapath........................................................................................................................................3-13Minimum Inter-Packet Gap ........................................................................................................3-13XGMII Decapsulation................................................................................................................... 3-13CRC Checking................................................................................................................................ 3-14Address Checking.......................................................................................................................... 3-14Frame Type Checking................................................................................................................... 3-14Length Checking............................................................................................................................ 3-15

TOC-2 Low Latency Ethernet 10G MAC User Guide

Altera Corporation

CRC and Padding Bytes Removal................................................................................................3-16Overflow Handling........................................................................................................................ 3-16RX Timing Diagrams.................................................................................................................... 3-17

Flow Control...............................................................................................................................................3-18IEEE 802.3 Flow Control.............................................................................................................. 3-18Priority-Based Flow Control........................................................................................................ 3-20

PHY Configurations..................................................................................................................................3-2110GBASE-R Register Mode..........................................................................................................3-22

Error Handling (Link Fault).....................................................................................................................3-23IEEE 1588v2................................................................................................................................................3-24

Architecture.................................................................................................................................... 3-25Transmit Datapath.........................................................................................................................3-26Receive Datapath............................................................................................................................3-27Frame Format.................................................................................................................................3-27

Configuration Registers...................................................................................... 4-1Register Access Type Convention............................................................................................................. 4-1Register Map................................................................................................................................................. 4-2Register Map (with and without Avalon-MM Adapter)........................................................................ 4-2Primary MAC Address................................................................................................................................4-6Transmit Configuration and Status Registers..........................................................................................4-7Flow Control Registers..............................................................................................................................4-10Unidirectional Control Register.............................................................................................................. 4-12Receive Configuration and Status Registers...........................................................................................4-13Transmit Timestamp Registers................................................................................................................4-20Receive Timestamp Registers...................................................................................................................4-22PMA Delay for IEEE 1588v2 MAC Registers........................................................................................ 4-23Statistics Registers......................................................................................................................................4-24ECC Registers............................................................................................................................................. 4-30

Interface Signals.................................................................................................. 5-1Clock and Reset Signals...............................................................................................................................5-1Speed Selection Signal................................................................................................................................. 5-3Error Correction Signals............................................................................................................................. 5-3Unidirectional Signals................................................................................................................................. 5-4Avalon-MM Programming Signals........................................................................................................... 5-4Avalon-ST Data Interfaces..........................................................................................................................5-5

Avalon-ST Transmit Data Interface Signals.................................................................................5-5Avalon-ST Receive Data Interface Signals....................................................................................5-6

Avalon-ST Flow Control Signals............................................................................................................... 5-7Avalon-ST Status Interface......................................................................................................................... 5-9

Avalon-ST Transmit Status Signals............................................................................................... 5-9Avalon-ST Receive Status Signals................................................................................................5-10

PHY-side Interfaces...................................................................................................................................5-12XGMII Transmit Signals...............................................................................................................5-12XGMII Receive Signals..................................................................................................................5-15GMII Transmit Signals..................................................................................................................5-17

Low Latency Ethernet 10G MAC User Guide TOC-3

Altera Corporation

GMII Receive Signals.....................................................................................................................5-18MII Transmit Signals.....................................................................................................................5-18MII Receive Signals........................................................................................................................5-18

1588v2 Interfaces....................................................................................................................................... 5-19IEEE 1588v2 Egress Transmit Signals.........................................................................................5-19IEEE 1588v2 Ingress Receive Signals.......................................................................................... 5-23

Additional Information......................................................................................A-1Low Latency Ethernet 10G MAC User Guide Document Revision History...................................... A-1

TOC-4 Low Latency Ethernet 10G MAC User Guide

Altera Corporation

About this IP Core 12014.12.15

UG-01144 Subscribe Send Feedback

The Low Latency (LL) Ethernet 10G Media Access Controller (MAC) IP core is a configurable componentthat implements the IEEE 802.3-2008 specification. The MAC IP core offers the following modes:

• 10 Gbps mode—uses the Avalon® Streaming (Avalon-ST) interface on the client side and the 32-bitsingle data rate (32-bit SDR) XGMII on the network side.

• 1 Gbps/10 Gbps mode— uses the Avalon-ST interface on the client side and GMII/32-bit SDR XGMIIon the network side.

• 10 Mbps/100 Mbps/1 Gbps/10 Gbps (quad-speed) mode—uses the Avalon-ST interface on the clientside and MII/GMII/32-bit SDR XGMII on the network side.

To build a complete Ethernet subsystem in an Altera® device and connect it to an external device, you canuse the LL Ethernet 10G MAC IP core with an Altera PHY IP core such as a soft XAUI PHY in FPGAfabric, hard silicon-integrated XAUI PHY, a 10GBASE-R PHY, a Backplane Ethernet 10GBASE-KR PHY,or a 1G/10 Gbps Ethernet PHY IP.

The following figure shows a system with the LL Ethernet 10G MAC core.

Figure 1-1: Typical Application of LL Ethernet 10G MAC

Avalon-STInterface

ClientModule

Altera FPGA

10GbE MAC or

1G/10GbE MAC or

10M/100M/ 1000M/10GbE MAC

External PHY

XAUI or

10GBASE-R or

Backplane Ethernet 10GBASE-KR PHY or

1G/10Gbps Ethernet

XGMII/GMII/MII

Serial Interface

FeaturesThe LL Ethernet 10G MAC supports the following features:

• Operating modes: 10 Gbps, 1 Gbps/10 Gbps, or multi-speed (10 Mbps, 100 Mbps, 1 Gbps or 10 Gbps).• Available in the following variations: MAC Tx only block, MAC Rx only block, and MAC Tx and

MAC Rx block.• Full duplex.• Client-side interface—32-bit Avalon-ST interface running at 312.5 MHz.

© 2014 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos aretrademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified astrademarks or service marks are the property of their respective holders as described at www.altera.com/common/legal.html. Altera warrants performanceof its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to anyproducts and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information,product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of devicespecifications before relying on any published information and before placing orders for products or services.

ISO9001:2008Registered

www.altera.com101 Innovation Drive, San Jose, CA 95134


mailto:[email protected]?subject=Feedback%20on%20(UG-01144%202014.12.15)%20About%20this%20IP%20Core&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

http://www.altera.com/support/devices/reliability/certifications/rel-certifications.html



• PHY-side interface:

• 32-bit XGMII running at 312.5 MHZ.• 8-bit GMII running at 125 MHZ.• 4-bit MII running at 125 MHZ with clock enable; effective at 2.5 MHz for 10 Mbps and 25 MHz for

100 Mbps.• Management interface—32-bit Avalon-MM interface.• Virtual local area network (VLAN) and stacked VLAN tagged frames decoding (of type 'h8100)• Cyclic redundancy code (CRC)-32 computation and insertion on the transmit datapath. Optional CRC

checking and forwarding on the receive datapath.• Deficit idle counter (DIC) for optimized performance with average inter-packet gap (IPG) for LAN

applications.• Optional statistics collection on the transmit and receive datapaths.• Programmable maximum length of transmit and receive data frames up to 64 Kbytes (KB).• Programmable promiscuous (transparent) mode.• Ethernet flow control using pause frames.• Optional unidirectional feature as specified by IEEE 802.3 (Clause 66)• Optional 10GBASE-R register mode on the transmit and receive datapaths to enable even lower

latency for the MAC and PHY (only in 10 Gbps operating mode).• Optional priority-based flow control (PFC) with programmable pause quanta. PFC supports 2 to 8

priority queues.• Optional padding termination on the receive datapath and insertion on the transmit datapath.• Optional preamble passthrough mode on the transmit and receive datapaths. The preamble

passthrough mode allows you to define the preamble in the client frame.• Optional IEEE 1588v2 feature for the following configurations:

• 10GbE MAC with 10GBASE-R PHY IP core• 1G/10GbE MAC with 1G/10GbE PHY IP core• Multi-speed 10M-10GbE MAC with 10M-10GbE PHY IP core

Release InformationThe following table lists information about this release of the LL Ethernet 10G MAC IP core.

Table 1-1: Release Information

Item Description

Version 14.1

Release Date December 2014

Ordering Code IP-10GEUMAC

Product ID ID 0119

Vendor ID 6AF7

Altera verifies that the current version of the Quartus II software compiles the previous version of eachMegaCore function, if this MegaCore function was included in the previous release. Any exceptions to

1-2 Release InformationUG-01144

2014.12.15

Altera Corporation About this IP Core

Send Feedback

mailto:[email protected]?subject=Feedback%20on%20About%20this%20IP%20Core%20(UG-01144%202014.12.15)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

this verification are reported in the MegaCore IP Library Release Notes and Errata. Altera does not verifycompilation with MegaCore function versions older than the previous release.

Related Information

• MegaCore IP Library Release Notes and Errata• Errata for Low Latency Ethernet 10G MAC MegaCore function in the Knowledge Base

Device Family SupportThe IP core provides the following support for Altera device families:

• Preliminary support—Altera verifies the IP core with preliminary timing models for this device family.The core meets all functional requirements, but might still be undergoing timing analysis for thedevice family. It can be used in production designs with caution.

• Final support—Altera verifies the IP core with final timing models for this device family. The coremeets all functional and timing requirements for the device family and can be used in productiondesigns.

Table 1-2: Device Family Support for LL Ethernet 10G MAC

Device Family Support

Arria® 10 PreliminaryArria V GZ FinalStratix® V Final

The following table lists the devices supported by the different configurations.

Table 1-3: Device Family Support for Configurations

Configuration Arria V GZ Arria 10 Stratix V

Multi-Speed 10M-10GbE MAC Yes Yes YesMulti-Speed 10M-10GbE MAC with IEEE1588v2

Yes Yes Yes

10GbE MAC with 10GBASE-R PHY Yes No Yes10GbE MAC with 10GBASE-R PHY and IEEE1588v2

Yes No Yes

10GbE MAC with Arria 10 Transceiver NativePHY presets:

• 10GBASE-R• 10GBASE-R Low Latency• 10GBASE-R Register Mode• 10GBASE-R w/KR-FEC

No Yes No

Multi-Speed 10M-10GbE MAC with BackplaneEthernet 10GBASE-KR PHY

Yes Yes Yes

UG-011442014.12.15 Device Family Support 1-3

About this IP Core Altera Corporation

Send Feedback

http://www.altera.com/literature/rn/rn_ip.pdf

http://www.altera.com/support/kdb/kdb-browse.jsp?keyword=32b_10g_mac_ki


Configuration Arria V GZ Arria 10 Stratix V

Multi-Speed 10M-10GbE MAC with BackplaneEthernet 10GBASE-KR PHY and IEEE 1588v2

Yes Yes Yes

Performance and Resource UtilizationThe following resource estimation are obtained by compiling the LL Ethernet 10G MAC with the QuartusII software targeting a commercial Stratix V device.

These estimates are based on the number of ALMs needed minus the recoverable and unavailable ALMsdue to the virtual I/Os (in Quartus II Fitter terms). These data also apply to Arria V GZ and Arria 10devices.

Table 1-4: Performance and Resource Utilization for LL Ethernet 10G MAC

Settings LowestSupported

SpeedGrade

ALMs ALUTs LogicRegisters

Memory Block(M20K)

All options disabled 4 1,500 2,300 2,600 0

Memory-based statistics counters enabled.Other options disabled.

4 2,000 3,100 3,700 4

Multi-speed 10M-10GbE MAC. Memory-based statistics counters enabled. Otheroptions disabled.

4 2,600 3,800 4,900 4

Multi-speed 10M-10GbEMAC. IEEE 1588v2feature, Time of Dayformat, and memory-basedstatistics counters enabled.Other options disabled.

Enable both96b and 64bTime Of Dayformat

3 5,000 7,000 11,500 19

Only Enable96b Time OfDay format

3 4,700 6,600 10,400 17

Only Enable64b Time OfDay format

3 4,200 5,900 9,500 13

All options enabled exceptthe adaptor.

3 6,800 10,400 14,300 21

1-4 Performance and Resource UtilizationUG-01144

2014.12.15

Altera Corporation About this IP Core

Send Feedback


Transmit and Receive LatenciesAltera uses the following definitions for the transmit and receive latencies:

• Transmit latency is the number of clock cycles the MAC function takes to transmit the first byte on thenetwork-side interface (XGMII SDR) after the bit was first available on the Avalon-ST interface.

• Receive latency is the number of clock cycles the MAC function takes to present the first byte on theAvalon-ST interface after the bit was received on the network-side interface (32-bit SDR XGMII).

Table 1-5: Transmit and Receive Latencies of the LL Ethernet 10G MAC

MAC Configuration

Latency (ns) (1)

Transmit (withrespect to TX clock)

Receive (withrespect to RX clock)

Total

MAC only (2) 22.4 38.4 60.8

MAC with 10 Mbps mode 1,952.8 27,215.2 29,168

MAC with 100 Mbps mode 232.8 2,735.2 2,968

MAC with 1 Gbps mode (3) 79.2 277.6 356.8

(1) The latency values are based on the assumption that there is no backpressure on the Avalon-ST TX and RXinterfaces.

(2) MAC only configuration without Avalon-ST and XGMII adapter.(3) The latency values for 1 Gbps mode is 360 ns under quad-speed mode.

UG-011442014.12.15 Transmit and Receive Latencies 1-5

About this IP Core Altera Corporation

Send Feedback


Getting Started 22014.12.15


This chapter provides a general overview of the Altera IP core design flow to help you quickly get startedwith LL Ethernet 10G MAC. The Altera IP Library is installed as part of the Quartus II installationprocess. You can select and parameterize any Altera IP core from the library. Altera provides anintegrated parameter editor that allows you to customize the MAC IP core to support a wide variety ofapplications. The parameter editor guides you through the setting of parameter values and selection ofoptional ports.

Introduction to Altera IP CoresAltera and strategic IP partners offer a broad portfolio of off-the-shelf, configurable IP cores optimized forAltera devices. The Altera Complete Design Suite (ACDS) installation includes the Altera IP library. TheOpenCore and OpenCore Plus IP evaluation features enable fast acquisition, evaluation, and hardwaretesting of Altera IP cores.

You can integrate optimized and verified IP cores into your design to shorten design cycles and maximizeperformance. The Quartus® II software also supports IP cores from other sources. Use the IP Catalog toefficiently parameterize and generate a custom IP variation for instantiation in your design.

The Altera IP library includes the following IP core types:

• Basic functions• DSP functions• Interface protocols• Memory interfaces and controllers• Processors and peripherals

Note: The IP Catalog (Tools > IP Catalog) and parameter editor replace the MegaWizard™ Plug-InManager for IP selection and parameterization, beginning in Quartus II software version 14.0. Usethe IP Catalog and parameter editor to locate and paramaterize Altera and other supported IPcores.

Related Information

• IP User Guide Documentation• Altera IP Release Notes





mailto:[email protected]?subject=Feedback%20on%20(UG-01144%202014.12.15)%20Getting%20Started&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

http://www.altera.com/literature/lit-ip.jsp





Installing and Licensing IP CoresThe Altera IP Library provides many useful IP core functions for production use without purchasing anadditional license. You can evaluate any Altera IP core in simulation and compilation in the Quartus IIsoftware using the OpenCore® evaluation feature. Some Altera IP cores, such as MegaCore® functions,require that you purchase a separate license for production use. You can use the OpenCore Plus feature toevaluate IP that requires purchase of an additional license until you are satisfied with the functionality andperformance. After you purchase a license, visit the Self Service Licensing Center to obtain a licensenumber for any Altera product.

Figure 2-1: IP Core Installation Path

acds

quartus - Contains the Quartus II softwareip - Contains the Altera IP Library and third-party IP cores

altera - Contains the Altera IP Library source code<IP core name> - Contains the IP core source files

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

Related Information

• Altera Licensing Site• Altera Software Installation and Licensing Manual

Specifying IP Core Parameters and OptionsThe parameter editor GUI allows you to quickly configure your custom IP variation. Use the followingsteps to specify IP core options and parameters in the Quartus II software. Refer to Specifying IP CoreParameters and Options (Legacy Parameter Editors) for configuration of IP cores using the legacyparameter editor.

1. In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize.The parameter editor appears.

2. Specify a top-level name for your custom IP variation. The parameter editor saves the IP variationsettings in a file named <your_ip>.qsys. Click OK.

3. Specify the parameters and options for your IP variation in the parameter editor, including one ormore of the following. Refer to your IP core user guide for information about specific IP coreparameters.

• Optionally select preset parameter values if provided for your IP core. Presets specify initialparameter values for specific applications.

• Specify parameters defining the IP core functionality, port configurations, and device-specificfeatures.

• Specify options for processing the IP core files in other EDA tools.4. Click Generate HDL, the Generation dialog box appears.

2-2 Installing and Licensing IP CoresUG-01144

2014.12.15

Altera Corporation Getting Started

Send Feedback

http://www.altera.com/licensing

http://www.altera.com/literature/manual/quartus_install.pdf

mailto:[email protected]?subject=Feedback%20on%20Getting%20Started%20(UG-01144%202014.12.15)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

5. Specify output file generation options, and then click Generate. The IP variation files generateaccording to your specifications.

6. To generate a simulation testbench, click Generate > Generate Testbench System.7. To generate an HDL instantiation template that you can copy and paste into your text editor, click

Generate > HDL Example.8. 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 inProject to add the file.

9. After generating and instantiating your IP variation, make appropriate pin assignments to connectports.

Figure 2-2: IP Parameter Editor

View IP portand parameter details

Apply preset parameters forspecific applications

Specify your IP variation nameand target device

Parameterizing the IP Core1. Select the speed for the LL Ethernet 10G MAC IP.2. Turn on the necessary MAC Options.3. Type the number of PFC priorities.4. Select the datapath option.

UG-011442014.12.15 Parameterizing the IP Core 2-3

Getting Started Altera Corporation

Send Feedback


5. Turn on the necessary resource optimization options. Some options are grayed out if it is notsupported in a selected configuration.

6. Turn on the necessary timestamp options. Some options are grayed out if it is not supported in aselected configuration.

7. Click Finish.

Related Information

• Parameter Settings on page 2-4

Parameter SettingsYou customize the MAC IP core by specifying the parameters on the parameter editor in the Quartus IIsoftware.

Parameter Value Description

Speed 10 Gbps, 1 Gbps/10Gbps, Multi-Speed 10

Mbps -10 Gbps

Select the desired speed. By default, 10 Gbps isselected.

If you turn on the Enable 10GBASE-R registermode parameter, only 10 Gbps is available.

Datapath options TX only, RX only, TX &RX

Select the MAC variation to instantiate.

• TX only—instantiates MAC TX.• RX only—instantiates MAC RX.• TX & RX—instantiates both MAC TX and

RX.

If you turn on the Enable 10GBASE-R registermode parameter, only the TX & RX option isavailable.

Enable ECC on memoryblocks

On, Off Turn on this option to enable error detectionand correction on memory blocks.

Enable preamble pass-through mode

On, Off Turn on this option to enable preamble pass-through mode. You must also set the tx_preamble_control, rx_preamble_control,and rx_custom_preamble_forward registers to1. When enabled, the MAC IP core allowscustom preamble in data frames on thetransmit and receive datapaths.

This parameter applies only to 10Gbps MACvariations.

This parameter is not available if you turn onthe Enable 10GBASE-R register modeparameter.

2-4 Parameter SettingsUG-01144

2014.12.15


Send Feedback



Enable priority-based flowcontrol (PFC)

On, Off Turn on this option to enable PFC. You mustalso set the tx_pfc_priority_enable[n]bit to1 and specify the number of priority queues inthe Number of PFC queues field.

This parameter applies only to 10Gbps MACvariations.


Number of PFC queues 2—8 Specify the number of PFC queues. Thisparameter is only enabled if you turn Enablepriority-based flow control (PFC).

Enable unidirectional feature On, Off Turn on this option to enable unidirectionalfeature as specified in the IEEE802.3 specifica‐tion (Clause 66). This feature is only supportedin 10Gbps speed mode.


Enable 10GBASE-R registermode

On, Off Turn on this option to enable 10GBASE-Rregister mode on the transmit and receivedatapaths to further reduce the MAC and PHYround-trip latency. In this mode, the MACdatapaths must run at 322.265625 MHz. Thisfeature is only supported in 10Gbps speedmode.

Enable supplementaryaddress

On, Off Turn on this option to enable supplementaryaddresses. You must also set the EN_SUPP0/1/2/3 bits in the rx_frame_control register to 1.

Enable statistics collection On, Off Turn on this option to collect statistics on thetransmit and receive datapaths.

UG-011442014.12.15 Parameter Settings 2-5


Send Feedback



Statistics counters Memory-based,Register-based

Specify the implementation of the statisticscounters. When you turn on Statisticscollection, the default implementation of thecounters is Memory-based.

• Memory-based—selecting this option freesup logic elements. The MAC IP core doesnot clear memory-based counters after theyare read.

• Register-based—selecting this option freesup the memory. The MAC IP core clearsregister-based statistic counters after thecounters are read.

Enable time stamping On, Off Turn on this option to enable time stamping onthe transmit and receive datapaths.


Enable PTP one-step clocksupport

On, Off Turn on this option to enable 1-step timestamping. This option is enabled only whenyou turn on time stamping.

Timestamp fingerprint width 1–32 Specify the width of the timestamp fingerprintin bits on the transmit path. The default value is4 bits.

Time of Day Format Enable 96b Time of DayFormat only, Enable 64b

Time of Day Formatonly, Enable both 96band 64b Time of Day

Format

Specify the time of day format.

Use 64-bit Ethernet 10GMAC XGMII

On, Off Turn on this option to maintain compabilitywith the 64-bit Ethernet 10G MAC on theXGMII.


Use 64-bit Ethernet 10GMAC Avalon Memory-Mapped Interface

On, Off Turn on this option to maintain compabilitywith the 64-bit Ethernet 10G MAC on theAvalon-MM Interface.

2-6 Parameter SettingsUG-01144

2014.12.15


Send Feedback



Use 64-bit Ethernet 10GMAC Avalon StreamingInterface

On, Off Turn on this option to maintain compabilitywith the 64-bit Ethernet 10G MAC on theAvalon-ST interface.


Generated FilesThe following table describes the generated files and other files that might be in your project directory.The names and types of generated files specified in the MegaWizard Plug-In Manager report varydepending on whether you create your design with VHDL or Verilog HDL.

Table 2-1: Generated Files

Extension Description

<variation name>.v or .vhd A MegaCore function variation file, which defines a VHDL or Verilog HDLdescription of the custom MegaCore function. Instantiate the entity definedby this file inside of your design. Include this file when compiling yourdesign in the Quartus II software.

<variation name>.cmp A VHDL component declaration file for the MegaCore function variation.Add the contents of this file to any VHDL architecture that instantiates theMegaCore function.

<variation name>.qsys A Qsys file for the MAC IP core design.

<variation name>.qip Contains Quartus II project information for your MegaCore functionvariation.

<variation name>.bsf Quartus II symbol file for the MegaCore function variation. Use this file inthe Quartus II block diagram editor.

<variation name>.sip Contains IP core library mapping information required by the Quartus IIsoftware.The Quartus II software generates a . sip file during generation ofsome Altera IP cores. You must add any generated .sip file to your projectfor use by NativeLink simulation and the Quartus II Archiver.

<variation name>.spd Contains a list of required simulation files for your MegaCore function.

Simulating Altera IP Cores in other EDA ToolsThe Quartus II software supports RTL and gate-level design simulation of Altera IP cores in supportedEDA simulators. Simulation involves setting up your simulator working environment, compilingsimulation model libraries, and running your simulation.

UG-011442014.12.15 Generated Files 2-7


Send Feedback


You can use the functional simulation model and the testbench or example design generated with your IPcore for simulation. The functional simulation model and testbench files are generated in a projectsubdirectory. This directory may also include scripts to compile and run the testbench. For a complete listof models or libraries required to simulate your IP core, refer to the scripts generated with the testbench.You can use the Quartus II NativeLink feature to automatically generate simulation files and scripts.NativeLink launches your preferred simulator from within the Quartus II software.

Figure 2-3: Simulation in Quartus II Design Flow

Post-fit timing simulation netlist

Post-fit timing simulation (3)

Post-fit functional simulation netlist

Post-fit functional simulation

Analysis & Synthesis

Fitter(place-and-route)

TimeQuest Timing Analyzer

Device Programmer

Quartus II Design Flow Gate-Level Simulation

Post-synthesis functional

simulation

Post-synthesis functional simulation netlist

(Optional) Post-fit timing simulation

RTL Simulation

Design Entry(HDL, Qsys, DSP Builder)

Altera Simulation Models

EDA Netlist Writer

Note: Post-fit timing simulation is not supported for 28nm and later device archetectures. Altera IPsupports a variety of simulation models, including simulation-specific IP functional simulationmodels and encrypted RTL models, and plain text RTL models. These are all cycle-accuratemodels. The models support fast functional simulation of your IP core instance using industry-standard VHDL or Verilog HDL simulators. For some cores, only the plain text RTL model isgenerated, and you can simulate that model. Use the simulation models only for simulation andnot for synthesis or any other purposes. Using these models for synthesis creates a nonfunctionaldesign.

Related InformationSimulating Altera Designs

2-8 Simulating Altera IP Cores in other EDA ToolsUG-01144

2014.12.15


Send Feedback

http://www.altera.com/literature/hb/qts/qts_qii5v3.pdf


Upgrading Outdated IP CoresAltera IP components are version-specific with the Quartus II software. The Quartus II software alertsyou when your IP core is outdated. Click Project > Upgrade IP Components to easily identify andupgrade outdated IP cores.

To upgrade outdated IP cores appropriately, your restored project archive must retain the originalQuartus II-generated file structure. Failure to upgrade outdated IP cores can result in a mismatch betweenthe outdated IP core variation and the current supporting libraries.

Altera verifies that the current version of the Quartus II software compiles the previous version of each IPcore. The MegaCore IP Library Release Notes and Errata reports any verification exceptions. Altera doesnot verify compilation for IP cores older than the previous release.

Figure 2-4: Upgrading IP Components in Project Navigator

Related InformationMegaCore IP Library Release Notes and Errata

Migrating IP Cores to a Different DeviceIP migration allows you to target the latest device families with IP originally generated for a differentdevice. Some Altera IP cores require individual migration to upgrade. The Upgrade IP Componentsdialog box prompts you to double-click IP cores that require individual migration.

1. To display IP cores requiring migration, click Project > Upgrade IP Components. The Descriptionfield prompts you to double-click IP cores that require individual migration.

2. Double-click the IP core name, and then click OK after reading the information panel.The parameter editor appears showing the original IP core parameters.

3. For the Currently selected device family, turn off Match project/default, and then select the newtarget device family.

4. Click Finish, and then click Finish again to migrate the IP variation using best-effort mapping to newparameters and settings. Click OK if you are prompted that the IP core is unsupported for the currentdevice. A new parameter editor opens displaying best-effort mapped parameters.

5. Click Generate HDL, and then confirm the Synthesis and Simulation file options. Verilog is theparameter editor default HDL for synthesis files. If your original IP core was generated for VHDL,select VHDL to retain the original output HDL format.

UG-011442014.12.15 Upgrading Outdated IP Cores 2-9


Send Feedback



6. To regenerate the new IP variation for the new target device, click Generate. When generation iscomplete, click Close.

7. Click Finish to complete migration of the IP core. Click OK if you are prompted to overwrite IP corefiles. The Device Family column displays the migrated device support. The migration process replaces<my_ip>.qip with the <my_ip>.qsys top-level IP file in your project.

Note: If migration does not replace <my_ip>.qip with <my_ip>.qsys, click Project > Add/RemoveFiles in Project to replace the file in your project.

8. Review the latest parameters in the parameter editor or generated HDL for correctness. IP migrationmay change ports, parameters, or functionality of the IP core. During migration, the IP core's HDLgenerates into a library that is different from the original output location of the IP core. Update anyassignments that reference outdated locations. If your upgraded IP core is represented by a symbol in asupporting Block Design File schematic, replace the symbol with the newly generated <my_ip>.bsfafter migration.

Note: The migration process may change the IP variation interface, parameters, and functionality.This may require you to change your design or to re-parameterize your variant after theUpgrade IP Components dialog box indicates that migration is complete. The Descriptionfield identifies IP cores that require design or parameter changes.

Related InformationAltera IP Release Notes

LL Ethernet 10G MAC Design Considerations

Migrating from Ethernet 10G MAC to LL Ethernet 10G MACAltera recommends the following migration path. Migrating your existing design in this manner allowsyou to take advantage of the benefits of LL Ethernet 10G MAC—low resource count and low latency.

Migration—32-bit Datapath on Avalon-STThis migration path implements 32-bit datapath on the Avalon ST transmit and receive data interfacesand configuration and status registers of LL Ethernet 10G MAC.

1. Instantiate the LL Ethernet 10G MAC IP core in your design. If you are using a PHY with 64-bit SDRXGMII interface, turn on the Use 64-bit Ethernet 10G MAC XGMII option.

2. Modify your user logic to accommodate 32-bit datapath on both Avalon-ST transmit and receive datainterfaces.

3. Change the TX and RX clock sources of the MAC IP core to 312.5 MHz.4. Update existing register offsets to the register offsets of the LL Ethernet 10G MAC. Using the configu‐

ration and status registers of the LL Ethernet 10G MAC allows access to features implemented usingregisters such as error correction and detection on memory blocks.

5. If you turn on the Use 64-bit Ethernet 10G MAC XGMII option, add a 156.25 MHz clock source forthe 32-bit/64-bit XGMII adapter. This 156.25 MHz clock source must be rise-to-rise synchronous withthe 312.5 MHz clock source.Make sure the CSR clock range is within 125 MHz to 156.25 MHz. Otherwise, some statistic countersmay not track correctly.

2-10 LL Ethernet 10G MAC Design ConsiderationsUG-01144

2014.12.15


Send Feedback



Migration—Maintains 64-bit on Avalon-STThis migration path implements 32-bit to 64-bit adapters on the Avalon ST transmit and receive datainterfaces and XGMII, and uses the same register offsets to maintain backward compatibility with the 10-Gbps Ethernet (10GbE) MAC IP Core.

1. Instantiate the LL Ethernet 10G MAC IP core in your design. To maintain compatibility on theinterfaces, turn on the Use 64-bit Ethernet 10G MAC XGMII, Use 64-bit Ethernet 10G MAC AvalonMemory-Mapped Interface, and Use 64-bit Ethernet 10G MAC Avalon Streaming Interfaceoptions.

2. Change the clock source to the MAC IP core to 312.5 MHz.3. Add 156.25 MHz clock source for the 32-bit/64-bit Avalon-ST and XGMII adapters. This 156.25 MHz

clock source must be rise-to-rise synchronous with the 312.5 MHz clock source.Make sure the CSR clock range is within 125 MHz to 156.25 MHz. Otherwise, some statistic countersmay not track correctly.

Timing ConstraintsAltera provides timing constraint files (.sdc) to ensure that the IP core meets the design timingrequirements in Altera devices. The files constraints the false paths and multi-cycle paths in the IP core.The timing constraints files are specified in the <variation_name>.qip file and is automatically included inthe Quartus II project files.

The timing constraints files of the MAC IP core are available in the IP directory and are user-editable. Thefiles are for clock crossing logic and are separated into three groups:

• Pseudo-static CSR fields• Clock crosser• Dual clock FIFO

Note: For the files to work correctly, there must be no other timing constraints files cutting or overridingthe paths, for example, set_false_path, set_clock_groups, at the project level.

Pseudo-Static CSR Fields

Most of the configuration registers in the MAC IP core must not be programmed when the MAC is inoperation. As such, they are not synchronized to reduce resource usage. These registers are all in theset_false_path constraint.

Clock CrosserClock crossers perform multi-bit signals crossing from one clock domain to another.

The working principle of the clock crosser is to let the crossed-over data stabilize first before indicatingthat the data is valid in the latched clock domain. Using such structure, the data bits must not skew formore than one latched clock period. The timing constraint file applies a common timing check over allthe clock crossers irrespective of their latched clock domain. This is over-pessimistic for signals crossinginto the CSR clock, but there are no side-effects, like significant run-time impact and false violations,during the internal testing. If your design runs into clock crosser timing violation paths within the IP andthe latched clock domain is csr_clk, you can dismiss the violation manually or by editing the .sdc file ifthe violation is less than one csr_clk period.

The timing constraint file uses the set_net_delay to constraint the fitter placement and set_max_skew toperform timing check on the paths. For a project with very high device utilization, Altera recommends

UG-011442014.12.15 Migration—Maintains 64-bit on Avalon-ST 2-11


Send Feedback


that you implement addition steps like floor planning or LogicLock to aid the place-and-route process.The additional steps can give a more consistent timing closure along these paths instead of only relying onthe set_net_delay.

A caveat of using set_max_skew is that it does not analyze whether the insertion delay of the path inconcern exceeds a limit. In other words, a path could meet skew requirement but have longer thanexpected insertion delay. If this is not checked, it may cause functional failure in certain latency-sensitivepaths. Therefore, a custom script (alt_em10g32_clock_crosser_timing_info.tcl) is available for you to checkthat the round-trip clock crosser delay is within expectation. To use this script, manually add it to the userflow and run it. To ensure that the IP core operates correctly, the results must be positive (no error).

Dual Clock FIFOThe bit skew of the dual clock FIFO gray-coded pointers must be within one 312.5 MHz clock period.

The timing constraint file uses the set_net_delay to constraint the fitter placement and set_max_skew toperform timing check on the paths. For a project with very high device utilization, Altera recommendsthat you implement addition steps like floor planning or LogicLock to aid the place-and-route process.The additional steps can give a more consistent timing closure along these paths instead of only relying onthe set_net_delay.

2-12 Dual Clock FIFOUG-01144

2014.12.15


Send Feedback


Functional Description 32014.12.15


The Low Latency (LL) Ethernet 10G MAC IP core handles the flow of data between a client and anEthernet network through an Ethernet PHY. On the transmit path, the MAC IP core accepts client framesand constructs Ethernet frames by inserting various control fields, such as checksums before forwardingthem to the PHY. Similarly, on the receive path, the MAC accepts Ethernet frames via a PHY, performschecks, and removes the relevant fields before forwarding the frames to the client. You can configure theMAC IP core to collect statistics on both transmit and receive paths.

This chapter describes the MAC IP core, its architecture, interfaces, data paths, registers, and interfacesignals.

ArchitectureThe LL Ethernet 10G MAC IP core is a composition of the following blocks: MAC receiver (MAC RX),MAC transmitter (MAC TX), configuration and status registers, and clock and reset.

Figure 3-1: LL Ethernet 10G MAC Block Diagram

MAC TX

Control & StatusRegisters

MAC RX

Clock & Reset

LL Ethernet 10G MAC

CSR Adapter(Optional)

Avalo

n-ST

32/6

4b Ad

apte

r(O

ption

al)

XGM

II SDR

32/6

4b Ad

apte

r(O

ption

al)

32-Bit XGMII Transmit Interface8-Bit GMII Transmit Interface4-Bit MII Transmit Interface

32-Bit XGMII Receive Interface8-Bit GMII Receive Interface4-Bit MII Receive Interface64-Bit XGMII

Receive Interface

64-Bit XGMII Transmit Interface

64-Bit XGMII Receive Interface

64-Bit XGMII Transmit Interface

FlowControl

LinkFault

RespectiveDomains

Clock & ResetSignals Clock & Reset

SignalsClock & Reset

Signals

32-Bit Avalon-STTransmit Interface

32-Bit Avalon-MMInterface

32-Bit Avalon-STReceive Interface

Notes: (1) Applies to 1G/10G and Multi Speed MAC only.(2) Applies to Multi Speed MAC only.

(1)

(1)

(2)

(2)





mailto:[email protected]?subject=Feedback%20on%20(UG-01144%202014.12.15)%20Functional%20Description&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.




Interfaces

Table 3-1: Interfaces

Interfaces Description

Avalon-ST Interface The client-side interface of the MAC employs the Avalon-STprotocol, which is a synchronous point-to-point, unidirectionalinterface that connects the producer of a data stream (source) to aconsumer of the data (sink). The key properties of this interfaceinclude:

• Frame transfers marked by startofpacket and endofpacketsignals.

• Signals from source to sink are qualified by the valid signal.• Errors marking a current packet are aligned with the end-of-

packet cycle.• Use of the ready signal by the sink to backpressure the source.

In the MAC IP core, the Avalon-ST interface acts as a sink in thetransmit datapath and source in the receive datapath. These 32-bitinterfaces operate at 312.5 and support packets, backpressure, anderror. The ready latency on these interfaces is 0.

Avalon-MM Control and StatusRegister Interface

The Avalon-MM control and status register interface is anAvalon-MM slave port. This interface uses word addressing whichprovides host access to the configuration and status registers, andstatistics counters.

XGMII When you configure the MAC IP core to operate in 10-Gbpsmode, the network-side interface of the MAC IP core implementsthe XGMII protocol. The XGMII consists of 32-bit data bus and 4-bit control bus operating at 312.5 MHz. The data bus carries theMAC frame with the most significant byte occupying the leastsignificant lane.

GMII When you configure the MAC IP core to operate in 1-Gbps, thenetwork-side interface of the MAC IP core also implements theGMII protocol. This 8-bit interface supports gigabit operations at125 MHz.

MII When you configure the MAC IP core to operate in 10 Mbps or100 Mbps, the network-side interface of the MAC IP coreimplements the MII protocol. This 4-bit MII supports 10-Mbpsand 100-Mbps operations at 125 MHz, with a clock enable signalthat divides the clock to effective rates of 2.5 MHz for 10 Mbpsand 25 MHz for 100 Mbps.

3-2 InterfacesUG-01144

2014.12.15

Altera Corporation Functional Description

Send Feedback

mailto:[email protected]?subject=Feedback%20on%20Functional%20Description%20(UG-01144%202014.12.15)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

Figure 3-2: Interface Signals

MAC RX

Clock andReset

csr_clkcsr_rst_ntx_312_5_clktx_156_25_clk

rx_156_25_clkrx_rst_n

tx_rst_nrx_312_5_clk

Avalon-MMControl and

Status Interface

csr_readcsr_readdata[31:0]csr_writecsr_writedata[31:0]csr_address[12:0]csr_waitrequest

XGMII Transmit

MAC TX xgmii_tx_data[35:0]link_fault_status_xgmii_tx_data[1:0]

GMII Transmit(1G/10Gbps, multi-speed)

gmii_tx_clkgmii_tx_d[7:0]

gmii_tx_engmii_tx_err

MII Transmit(multi-speed)

tx_clkenatx_clkena_half_rate

mii_tx_d[3:0]mii_tx_enmii_tx_err

Avalon-ST TransmitData Interface

avalon_st_tx_startofpacketavalon_st_tx_endofpacketavalon_st_tx_validavalon_st_tx_readyavalon_st_tx_erroravalon_st_tx_data[31:0]avalon_st_tx_empty[1:0]

Avalon-ST TransmitFlow Control Interface

avalon_st_pause_data[1:0]avalon_st_tx_pause_length_validavalon_st_tx_pause_length_data[15:0]avalon_st_tx_pfc_gen_data[n]

Avalon-ST TransmitStatus Interface

avalon_st_txstatus_validavalon_st_txstatus_data[39:0]avalon_st_txstatus_error[6:0]avalon_st_tx_pfc_status_validavalon_st_tx_pfc_status_data[n]

IEEE 1588v2Interface

tx_egress_timestamp_request_validtx_egress_timestamp_request_fingerprint[n]

tx_path_delay_10g_data[15:0]

xgmii_rx_data[35:0]link_fault_status_xgmii_rx_data[1:0] XGMIIReceive

gmii_rx_clkgmii_rx_d[7:0]

gmii_rx_dvgmii_rx_err

GMII Receive(1G/10Gbps, multi-speed)

rx_clkenarx_clkena_half_rate

mii_rx_d[3:0]mii_rx_dvmii_rx_err

MII Receive(multi-speed)

avalon_st_rx_startofpacketavalon_st_rx_endofpacketavalon_st_rx_validavalon_st_rx_readyavalon_st_rx_error[5:0]avalon_st_rx_data[31:0]avalon_st_rx_empty[1:0]

Avalon-ST ReceiveData Interface

avalon_st_rx_pause_length_valid

avalon_st_rx_pause_length_data[15:0]avalon_st_rx_pfc_pause_data[n]

Avalon-STReceive Flow

Control Interface

avalon_st_rxstatus_validavalon_st_rxstatus_data[39:0]avalon_st_rxstatus_error[6:0]avalon_st_rx_pfc_status_validavalon_st_rx_pfc_status_data[n]

Avalon-ST ReceiveStatus Interface

rx_ingress_timestamp_96b_data[95:0]rx_ingress_timestamp_96b_valid

rx_path_delay_10g_data[15:0]

IEEE 1588v2Time-StampInterface

speed_sel

ecc_err_det_correcc_err_det_uncorr

tx_xcvr_clk rx_xcvr_clk

xgmii_tx_valid

xgmii_tx_valid

unidirectional_enunidirectional_remote_fault_dis

LL Ethernet 10G MAC

Avalon-MM

Control and Reset

Related InformationInterface Signals on page 5-1Describes each signal in detail.

UG-011442014.12.15 Interfaces 3-3

Functional Description Altera Corporation

Send Feedback


Frame TypesThe MAC IP core supports the following frame types:

• Basic Ethernet frames, including jumbo frames.• VLAN and stacked VLAN frames.• Control frames, which include pause and PFC frames.

Transmit DatapathThe MAC TX receives the client payload data with the destination and source addresses, and appendsvarious control fields depending on the MAC configuration.

Figure 3-3: Typical Client Frame at Transmit Interface

Client - MAC Tx Interface(optional)

Client Frame

MAC Frame

Destination Addr[47:0]

Source Addr[47:0]

Type/Length[15:0]

Payload[<p-1>:0]


SFD[7:0]Preamble [55:0]

CRC32[31:0]

PAD [<s>]

Source Addr[47:0]

Client-Defined Preamble[63:0]

(optional)

Type/Length[15:0]

Payload[<p-1>:0]

PAD [<s>] CRC32[31:0]

EFD[7:0] IPG[<l-1>:0]

Frame Length

(1) (2)

(3)

Padding Bytes InsertionBy default, the MAC TX inserts padding bytes (0x00) into transmit frames to meet the followingminimum payload length:

• 46 bytes for basic frames• 42 bytes for VLAN tagged frames• 38 bytes for stacked VLAN tagged frames

Ensure that CRC-32 insertion is enabled when padding bytes insertion is enabled.

You can disable padding bytes insertion by setting the tx_pad_control register to 0. When disabled, theMAC IP core forwards the frames to the PHY-side interface without padding. Ensure that the minimumpayload length is met; otherwise the current frame may get corrupted. You can check for undersizedframes by referring to the statistics collected.

Address InsertionBy default, the MAC TX retains the source address received from the client. You can configure the MACTX to replace the source address with the primary MAC address specified in the tx_addrins_macaddr0and tx_addrins_macaddr1 registers by setting the bit tx_src_addr_override[0] to 1.

3-4 Frame TypesUG-01144

2014.12.15


Send Feedback


CRC-32 InsertionBy default, the MAC TX computes and inserts CRC-32 checksum into transmit frames. The MAC TXcomputes the CRC-32 checksum over frame bytes that include the source address, destination address,length, data, and padding bytes. The computation excludes the preamble and SFD bytes. The MAC TXthen inserts the CRC-32 checksum into the transmit frame. Bit 31st of the checksum occupies the leastsignificant bit of the first byte in the CRC field.

You can disable this function by setting the tx_crc_control[1] register bit to 0.

The following figure shows the timing diagram on the Avalon-ST data interfaces where CRC insertion isenabled on transmit and CRC removal is disabled on receive. The frame from the client is withoutCRC-32 checksum. The MAC TX inserts the CRC-32 checksum (4EB00AF4) into the frame. The frame isthen looped back to the receive datapath with the CRC-32 checksum.

Figure 3-4: Avalon-ST Transmit and Receive Interface with CRC Insertion Enabled

tx_312_5_clk

avalon_st_tx_ready

avalon_st_tx_valid

avalon_st_tx_startofpacket

avalon_st_tx_endofpacket

avalon_st_tx_data[31:0]

avalon_st_tx_empty[1:0]

avalon_st_tx_error

...00000000

0

rx_312_5_clk

avalon_st_rx_ready

avalon_st_rx_valid

avalon_st_rx_startofpacket

avalon_st_rx_endofpacket

avalon_st_rx_data[31:0]

avalon_st_rx_empty[1:0]

avalon_st_rx_error[5:0]

...4EB30AF4

0

UG-011442014.12.15 CRC-32 Insertion 3-5


Send Feedback


The following figure shows the timing diagram on the Avalon-ST data interfaces where CRC insertion isdisabled on transmit and CRC removal is disabled on receive. The MAC TX receives the frame from theclient with a CRC-32 checksum (4EB00AF4). The frame with the same CRC-32 checksum is then loopedback to the receive datapath.

Figure 3-5: Avalon-ST Transmit and Receive Interface with CRC Insertion Disabled

tx_312_5_clk

avalon_st_tx_ready

avalon_st_tx_valid





avalon_st_tx_error

0

rx_312_5_clk

avalon_st_rx_ready

avalon_st_rx_valid

avalon_st_rx_startofpacket

avalon_st_rx_endofpacket

avalon_st_rx_data[31:0]

avalon_st_rx_empty[1:0]

avalon_st_rx_error[5:0]

...4EB30AF4

...4EB30AF4

0

XGMII EncapsulationBy default, the MAC TX inserts 7-byte preamble, 1-byte SFD and 1-byte EFD (0xFD) into frames receivedfrom the client.

The MAC TX also supports custom preamble. To use custom preamble, set the tx_preamble_controlregister to 1. In this mode, the MAC TX accepts the first 8 bytes in the frame from the client as custompreamble and inserts only 1-byte EFD (0xFD) into the frame. The MAC TX also replaces the first byte ofthe preamble with 1-byte START (0xFB).

3-6 XGMII EncapsulationUG-01144

2014.12.15


Send Feedback


An underflow could occur on the Avalon-ST transmit interface. An underflow occurs when theavalon_st_tx_valid signal is deasserted in the middle of frame transmission. When this happens, the10GbE MAC TX inserts an error character |E| into the frame and forwards the frame to the XGMII.

Inter-Packet Gap Generation and InsertionThe MAC TX maintains an average IPG between transmit frames as required by the IEEE 802.3 Ethernetstandard. The average IPG is maintained at 96 bit times (12 byte times) using the deficit idle count (DIC).The MAC TX's decision to insert or delete idle bytes depends on the value of the DIC; the DIC is boundedbetween a value of nine to fifteen bytes. Averaging the IPG ensures that the MAC utilizes the maximumavailable bandwidth.

XGMII TransmissionOn the XGMII, the MAC TX performs the following:

• Aligns the first byte of the frame to lane 0 of the interface.• Performs endian conversion. Transmit frames received from the client on the Avalon-ST interface are

big endian. Frames transmitted on the XGMII are little endian; the MAC TX therefore transmitsframes on this interface from the least significant byte.

The following figure shows the timing on the Avalon-ST transmit data interface and XGMII. The leastsignificant byte of the value in D5 is transmitted first on the XGMII.

UG-011442014.12.15 Inter-Packet Gap Generation and Insertion 3-7


Send Feedback


Figure 3-6: Endian Conversion

55 (1) D5 CC CC EE 01 05 09 0D

55(1) 55 88 EE AA 00 04 08 0C

55(1) 55 EE CC 2E 03 07 0B 0F

FB 55 EE AA 88 00 02 06 0A 0E

CC

tx_312_5_clk

0 4

D1 D2 D3 D4 D5 D6 D7 D8

15 19 1D 21 25 29 2D F4 07

14 18 1C 20 24 28 2C 0A 07

13 17 1F 23 27 2B B3 07

12 16 1A 1E 22 26 2A 4E FD

1B

10

11

07

0 4

D9 D10 D11 D12 D13 D14 D15 D16 D17

D1: 555555D5

D2: EECC88CC

D3: AAEEEECC

D4: 88CCAAEE

D5: 002E0001

D6: 02030405

D7: 06070809

D8: 0A0B0C0D

D9: 0E0F1011

D10: 12131415

D11: 16171819

D12: 1A1B1C1D

D13: 1E1F2021

D14: 22232425

D15: 26272829

D16: 2A2B2C2D

D17: 4EB30AF4

avalon_st_tx_ready

avalon_st_tx_valid





avalon_st_tx_error

tx_312_5_clk

xgmii_tx_control[3]

xgmii_tx_data[31:24]

xgmii_tx_control[2]


xgmii_tx_control[1]

xgmii_tx_data[15:8]

xgmii_tx_control[0]

xgmii_tx_data[7:0]

Data value:

Unidirectional FeatureThe unidirectional feature is an option that you can enable on the TX datapath. This feature isimplemented as specified in the IEEE802.3 specification, Clause 66.

This feature is only supported in 10Gbps speed mode. When you enable this feature, two output ports—unidirectional_en, unidirectional_remote_fault_dis— and two register fields—UniDir_En (Bit 0),UniDirRmtFault_Dis (Bit 1)— are accessible to control the TX XGMII interface.

3-8 Unidirectional FeatureUG-01144

2014.12.15


Send Feedback


Table 3-2: Register Field and Link Status

Bit 0 Register Field Bit 1 Register Field Link Status TX XGMII Interface Behavior

Don't care Don't care No link fault Continue to allow normal packet transmission.

0 Don't care Local fault Immediately override the current content withremote fault sequence.

1 0 Local fault Continue to send packet if there is one.Otherwise, override the IPG/IDLE bytes withremote fault sequence.(4)

1 1 Local fault Continue to allow normal packet transmission(similar to no link fault).

0 Don't care Remote fault Immediately override the current content withIDLE control characters.

1 Don't care Remote fault Continue to allow normal packet transmission(similar to no link fault).

TX Timing Diagrams

Figure 3-7: Normal Frame

The following diagram shows the transmission of a normal frame.

tx_312_5_clkavalon_st_tx_startofpacket

avalon_st_tx_validavalon_st_tx_ready

avalon_st_tx_endofpacketavalon_st_tx_error

avalon_st_tx_empty[1:0]avalon_st_tx_data[31:0]

xgmii_tx_data[31:0]xgmii_tx_control[3:0]

avalon_st_tx_data[31:24]avalon_st_tx_data[23:16]


xgmii_tx_data[7:0]xgmii_tx_data[15:8]


0 3 0

0f8e_8236 0023_4567 *5 *1 *2 *2 *5 *b *c *7 *e *d *5 *3 *e *5 *0 cc6b_d355

0707_0707 *b *5 *0 *9 *1 *0 *c *e *b *6 *1 *0 *b *7 *6 *d *d *d *2 0707_0707

f 1 0 e f

0f 00 89 f1 00 fc ce 6b 26 01 e0 0b 87 a6 7d 4d 5d cc8e 23 ab c7 2f 8c 3f 9f d9 77 59 71 e5 3a 42 00 6b

82 45 c4 e9 fb 00 62 f7 80 84 09 c5 21 65 4b b1 00 d336 67 d5 61 d2 82 85 4b fc 67 9e 9d 45 23 ee a5 00 55

07 7dfb 55 00 89 f1 00 fc ce 6b 26 01 e0 0b 87 a6 07

07 3a55 23 ab c7 2f 8c 3f 9f d9 77 71 e5 07

07 4b55 45 c4 e9 fb 00 62 f7 80 84 09 c5 21 65 07

07 ee55 d5 67 d5 61 d2 82 85 4b fc 67 9e 8d 45 23 07

a24d 5d

fd42 13

b1 8a

a5 d0

59

(4) At least a full column of IDLE (four IDLE characters) must precede the remote fault sequence.

UG-011442014.12.15 TX Timing Diagrams 3-9


Send Feedback


Figure 3-8: Normal Frame with Preamble Passthrough Mode, Padding Bytes Insertion, and SourceAddress Insertion Enabled

The following diagram shows the transmission of good frames with preamble passthrough mode, paddingbytes insertion, and source address insertion enabled.

0 37c91_5b8d*5 *_fff *fb *4 *5 *3 *f *0 *9 *a *1 *3 *0 *3 *0

0707_0707*b *1 *_fff *ff *2 *0 *b *0 *e *5 *5 *6 *3 *0 *4 *c *0 *8 *d

f 1

7cd1 ff 2b 00 5b 60 8e 65 25 36 13 10 0481bf ff 0098 2f 5d de 4b 4e 54 53 13 60 a1

83 001d 45 e3 5b 09 bb db 10 e8 86 a9d5 0024 f5 f3 2f 20 69 ba 21 53 f0 83

ff 44ff fb

5b8d

fb 0422 00 5b 60 8e 65 25 36 13 10d1 ff 07fd7c 00 38*5 a133 2f 5d de 4b 4e 54 53 13 60*5 ff 0700 7a*5 a944 45 e3 5b 09 bb db 10 e8 86*5 0700 9cff 00*5 8355 f5 f3 2f 20 69 ba 21 53 f0*5 0700 eeff 00










092e6_9b29 0faa_4s5e

92 0fe6 aa9b 4a29 5e

0707_0707f0

07070707

Figure 3-9: Back-to-back Transmission of Normal Frames with Source Address Insertion Enabled.

The following diagram shows back-to-back transmission of normal frames with source address insertionenabled. The MAC primary address registers are set to 0x000022334455.

0 3 0

8190_a0b0 *a7 *8d *ed *05 *56 *f0 *d6 *44 *95 *f4 *38 *03 *31 *0b *7a *00 *0_a0b0 *d2 *96 *01 *5c *43 *cb *e3 b4c1_cafd *f0 *4c 0023_456

0707_0707 *fb *55 *81 *c0 *22 *3d *f5 *08 *d6 *7e *51 *37 *1a *95 *a2 *9f *96 *b9 *e3 *be *7_0707 *fb *55 *81 *c0 *22

f 1 0 e f 1 0

81 c0 15 3d f5 08 d6 7e 51 37 1a 95 a2 31 96 b9 e3 81 c0 d6 88 00 7b 31 0e b4 49 25 00

90 d0 83 61 1c 75 e3 f4 7b 99 cd bc 83 85 5a 00 90 d0 07 08 0a 40 9f 76 c1 04 8b 23

a0 e7 35 1b 2f ff 5a b1 fc 06 b2 a8 ca 54 0d 4f 00 a0 cd 39 00 1d 05 11 57 ca e1 27 45

b0 a7 8d ed 05 56 f0 d6 44 95 f4 38 ca 31 0b 7a 00 b0 d2 96 01 5c 43 cb e3 fd f0 4c 67

07 fb 55 81 c0 22 3d f5 08 d6 7e 51 37 1a 95 a2 9f 96 b9 e3 be 07 fb 55 81 c0 22

07 55 90 d0 33 61 1c 75 e3 f4 7b 99 cd bc 83 85 5a c7 fd 07 55 90 d0 33

07 55 a0 00 44 1b 2f ff 5a b1 fc 06 b2 a8 ca 54 0d 4f 53 07 55 a0 00 44

07 55 d5 b0 00 55 ed 05 56 f0 d6 44 95 f4 38 03 31 0b 7a 88 07 55 d5 b0 00 55










3-10 TX Timing DiagramsUG-01144

2014.12.15


Send Feedback


Figure 3-10: Back-to-back Transmission of Normal Frames with Preamble Passthrough Mode Enabled

The following diagram shows back-to-back transmission of normal frames with preamble passthroughmode enabled.










* * * * * * * ** * *3 ac8b_600d* * * * * * * * ** * * * * * * * ** * * * * * * * ** ** * * * ** * aa2f_4bbd ** **

* * * * * * * ** * * * *707 *b * * * * * **0 * * * * * * * ** * * * * * * * ** ** * * * ** **707 *** * * * * **b

0 f 1 0 1f 0e

6f de b3 23 32 5f 00 3b89 a5 00 ac0b 71 a0 90 c9 4c f0 6c a461 f9 36 22 1a 21 b7 f3 bca3 69 30 fa 2e a9 87 bb dbf5 b584 22 ff 64 6700 4d aa 2cea c87a

2b d2 b4 5f 1f 37 23 05ab 1b ff 8b7e d3 bc 59 b0 db 15 ae ade2 02 0f 21 62 74 c0 36 c8 13 d9 12 15 f0 a4 00da 45f9 37 ff bd 03ac 53 2f 4b81 e704

25 d4 48 e9 ad a5 45 e3f0 8f b7 60fa da d7 38 0f a9 60 be 344d 83 d4 8c68 5d e0 c1 26 74 95 65 ac ce 0079 85e7 8a 5d f53b ba 4b eb97 240df8 eb6e ff 03

89 8d 93 66 3a d5 67 62 94 f3 0d9c ee 3f 2c 44 d5 ca 11 6c85 4e 7b 26 64 d8 e7 0a 19 a4 5c 9e b0 004a 400a d5 5b a850 83 bd ce94 4857 03bc ff 225e 48

fe 8d ad 56 98 fb 8f 50b3 6f de b3 07 fb 5f 00 89 3b a5 0b00 71 a0 90 c9 4c f0 6c a461 f9 30 22 1a 21 b7 f3 bca3 847a 69 2e 87a9 bb fb07 22ac23 4a fd 30 fa dbf5 7e

8d b9 81 16 88 54 ac b3fc 2b d2 b4 07 1f 37 23 ab 05 1b 7eff d3 bc 59 b0 db 15 ae ade2 02 0f 21 62 74 c0 36 f904 c8 12 f015 a4 4507 378b5f a6 13 d9 f4da fd

2b 0f 49 ca 38 40 9f f814 25 d4 48 07 ad a5 45 f0 e3 8f fab7 da d7 38 0f a9 60 be 344d 83 d4 68 5d 8c e0 eb6e e70d c1 95 ac65 ce 8507 8a60e9 0a 26 74 0f79

d6 38 84 f0 3a 76 7f c59c 89 8d 93 07 3a d5 67 62 94 9cf3 ee 3f 2c 44 d5 ca 11 6c85 4e 7b 26 64 d8 03bc 0a57 e7 a4 9e5c b0 4007 d50d66 e7 0a 19 ce4a5e 48

Figure 3-11: Error Condition—Underflow

The following diagrams show an underflow on the transmit datapath followed by the transmission of anormal frame.

0

c990_2f08

0

0707_0707

f 00f

*c61

*0707

97

36

6c

61

c9

90

2f

08

fc

07

07

07

07

07

07

07

07










pulse_tx_udf_errcnt

An underflow happens in the middle of a frame that results in a premature termination on the XGMII.The remaining data from the Avalon-ST transmit interface is still received after the underflow but thedata is dropped. The transmission of the next frame is not affected by the underflow.

UG-011442014.12.15 TX Timing Diagrams 3-11


Send Feedback


Figure 3-12: Error Condition—Underflow, continued










pulse_tx_udf_errcnt

* *4 *f *3 *c *1 *e *d *a *c *e *9 *7 c531_fcb6

*c *d *9 *e *3 *e *4 *5 *d *2 *c *f *f *6 *0 *3 *6 *fe *7 0707_0707

0 f 0 f

fed9 6e 63 6e 74 d5 ed 42 cc 3f 5f 76 c0 93 b6 07

fe1e c7 2f 1b 0c 02 37 39 3b 31 07

fe95 46 23 39 c1 d4 fc a9 4a 37 8b 13 f0 07fe48 c8 3f 14 84 6f 23 33 a1 5e 8d 1a fc 1e 49 07

fd37 b8

a4 3a

37 e337 13

15

* *1 *6 *1 *8 *d

*8 *6 *5 *2 *5b793_b875 *b *7 *

6e 74 d5 ed 42 cc 3f 5d 76 c0 93 b6 37 c5 de ad bd b0 71b7 d6 23 5

c7 2f 1b 0c 02 37 39 3b 15 31 cd 99 a4 31 79 37 c6 0d 3693 d5 d4 a

46 23 39 c1 d4 fc a9 4a 37 8b 13 f0 37 fc ec e2 1e 6b cab8 95 d8 8

14 84 6f 23 33 a1 5e 8d 1a fc 1e 49 37 b6 48 16 a5 52 d575 2b d7 0

c1

7a

6d

61

cd 99

ff d1 e6 c1 3c ad

c1 01 51 35

41 c3 42 3a95 44 a2 61 16 05

f7

20

72

5d

Figure 3-13: Short Frame with Padding Bytes Insertion Enabled

The following diagram shows the transmission of a short frame with no payload data. Padding bytesinsertion is enabled.










0 2

*c

0

92e6_9b29 *f *2 1626_4dfe *e *6 *5 *a *e *1 *e *f *a *b

*b0707_0707 *5 *1 0000_0000 *e *6*0 *2 *0

f 1 0

c081 4f 00 16 2f 57 ee fe 13 f0 2d d2 5c 9d

d090 e0 2e 26 a8 57 cf c3 d3 e9 87 52 ca 63

aea0 66 a0 4d d8 ea 91 b8 b5 b0 9f ad e0 d7

acb0 8f f2 fe de e6 85 3a 8e 61 be af 0a 4b

fb07 55 81 00 9f fdc0 22

07 55 90 00 ded0 33 2e

07 55 a0 00 6c00 44

07 b0 00 1500 5555 d5

3-12 TX Timing DiagramsUG-01144

2014.12.15


Send Feedback


Receive DatapathThe MAC RX receives Ethernet frames from the XGMII and forwards the payload with relevant framefields to the client after performing checks and filtering invalid frames. Some frame fields are optionallyremoved from the frame before MAC RX forwards the frame to the client.

The following figure shows the typical flow of frame through the MAC RX.

Figure 3-14: Typical Client Frame at Receive Interface

Client - MAC Rx Interface(optional)

Client FrameDestination Addr[47:0]

Source Addr[47:0]

Type/Length[15:0]

Payload[<p-1>:0]


CRC32[31:0]

PAD [<s>]

Source Addr[47:0]

Client-Defined Preamble[55:0]

(optional)

Type/Length[15:0]

Payload[<p-1>:0]

PAD [<s>] CRC32[31:0]

EFD[7:0]

Start[7:0]

Frame Length

(1) (2)

MAC Frame

SFD[7:0]Preamble [47:0]

Start[7:0]

Minimum Inter-Packet Gap

Table 3-3: Minimum IPG for the MAC on the Receive Path

Interfaces Minimum IPG (Bytes)

XGMII (10 Gbps) 5

GMII (1 Gbps) 8

MII (10 Mbps and 100 Mbps) 6

XGMII DecapsulationThe MAC RX expects the first byte of receive packets to be in lane 0, xgmii_rx_data[7:0]. If the 32-bit/64-bit adapter on the XGMII is present, the first byte of receive packets must be in lane 0 or lane 4,xgmii_rx_data[39:32]. Receive packets must also be preceded by a column of idle bytes or an orderedset such as a local fault. Packets that do not satisfy these conditions are invalid and the MAC RX dropsthem.

By default, the MAC RX only accepts packets that begin with a 1-byte START, 6-byte preamble, and 1-byte SFD. Packets that do not satisfy this condition are invalid and the MAC RX drops them.

When you enable the preamble passthrough mode (rx_preamble_control register = 1), the MAC RXonly checks packets that begin with a 1-byte START. In this mode, the MAC RX does not remove theSTART and custom preamble, but passes the bytes along with the frame to the client.

After examining the packet header bytes in the correct order, the MAC IP retrieves the frame data fromthe packet. If the frame data starting from the destination address field is less than 17 bytes, the MAC IPmay or may not drop the frame. If the erroneous frame is not dropped but forwarded, an undersized errorwill be flagged to the external logic to drop the frame. If the frame is more than 17 bytes, the MACforwards the frame as normal and flags error whenever applicable.

UG-011442014.12.15 Receive Datapath 3-13


Send Feedback


CRC CheckingThe MAC RX computes the CRC-32 checksum over frame bytes received and compares the computedvalue against the CRC field in the receive frame. If the values do not match, the MAC RX marks the frameinvalid by setting avalon_st_rx_error[1] to 1 and forwards the receive frame to the client. When theCRC error indicator is asserted, the external logic is expected to drop the frame bytes.

Address CheckingThe MAC RX can accept frames with the following address types:

• Unicast address—bit 0 of the destination address is 0.• Multicast address—bit 0 of the destination address is 1.• Broadcast address—all 48 bits of the destination address are 1.

The MAC RX always accepts broadcast frames. By default, it also receives all unicast and multicast framesunless configured otherwise in the EN_ALLUCAST and EN_ALLMCAST bits of the rx_frame_control register.

When the EN_ALLUCAST bit is set to 0, the MAC RX filters unicast frames received. The MAC RX acceptsonly unicast frames with a destination address that matches the primary MAC address specified in theprimary_mac_addr0 and primary_mac_addr1 registers. If any of the supplementary address bits are set to1 (EN_SUPP0/1/2/3 in the rx_frame_control register), the MAC RX also checks the destination addressagainst the supplementary addresses in the rx_frame_spaddr*_* registers.

When the EN_ALLMCAST bit is set to 0, the MAC RX drops all multicast frames. This condition does notapply to global multicast pause frames.

Frame Type CheckingThe MAC RX checks the length/type field to determine the frame type:

• Length/type < 0x600—The field represents the payload length of a basic Ethernet frame. The MAC RXcontinues to check the frame and payload lengths.

• Length/type >= 0x600—The field represents the frame type.

• Length/type = 0x8100—VLAN or stacked VLAN tagged frames. The MAC RX continues to checkthe frame and payload lengths.

• Length/type = 0x8808—Control frames. The next two bytes are the Opcode field which indicatesthe type of control frame. For pause frames (Opcode = 0x0001) and PFC frames (Opcode =0x0101), the MAC RX proceeds with pause frame processing. By default, the MAC RX drops allcontrol frames. If configured otherwise (FWD_CONTROL bit in the rx_frame_control register = 1),the MAC RX forwards control frames to the client.

• For other field values, the MAC RX forwards the receive frame to the client.

If the length/type is less than payload, the MAC RX considers the frame to have excessive padding anddoes not assert avalon_st_rx_error[4]. For detailed information about the MAC behavior, refer to thefollowing table.

3-14 CRC CheckingUG-01144

2014.12.15


Send Feedback


Table 3-4: MAC Behavior for Different Frame Types

Category Packet SizeLength/Type =

Payload

Length/Type >

Payload

Length/Type <

Payload

MAC Behavior

FrameDrop

Error Type

NormalPacket 65–1518

Yes No No No —

No Yes No No Payload length error: avalon_st_rx_error[4] = 1

No No Yes No —

Undersized Packet < 64

Yes No No No Undersized frame error:avalon_st_rx_error[2] = 1

No Yes No No Undersized frame and payloadlength error: avalon_st_rx_error[2] = 1 avalon_st_rx_error[4] = 1

No No Yes No Undersized frame error:avalon_st_rx_error[2] = 1

Oversized 1518 < Packet< 1535

Yes No No No Oversized frame error: avalon_st_rx_error[3] = 1

No Yes No No Oversized frame and payloadlength error: avalon_st_rx_error[3] = 1 avalon_st_rx_error[4] = 1

No No Yes No Oversized frame error: avalon_st_rx_error[3] = 1

Length CheckingThe MAC RX checks the frame and payload lengths of basic, VLAN tagged, and stacked VLAN taggedframes.

The frame length must be at least 64 (0x40) bytes and not exceed the following maximum value for thedifferent frame types:

• Basic—The value in the rx_frame_maxlength register.• VLAN tagged—The value in the rx_frame_maxlength register plus four bytes.• Stacked VLAN tagged—The value in the rx_frame_maxlength register plus eight bytes.

The MAC RX keeps track of the actual payload length as it receives a frame and checks the actual payloadlength against the length/type or client length/type field. The payload length must be between 46 (0x2E)and 1500 (0x5DC). For VLAN and VLAN stacked frames, the minimum payload length is 42 (0x2A) or 38(0x26) respectively and not exceeding the maximum value of 1500 (0x5DC).

UG-011442014.12.15 Length Checking 3-15


Send Feedback


The MAC RX does not drop frames with invalid length. For the following length violations, the MAC RXsets the corresponding error bit to 1:

• avalon_st_rx_error[2]—Undersized frame• avalon_st_rx_error[3]—Oversized frame• avalon_st_rx_error[4]—Invalid payload length, the actual payload length doesn't match the value

of the length/type field. The checking applies to frames with length/type of 0x600 or less.

CRC and Padding Bytes RemovalBy default, the MAC RX forwards receive frames to the client without removing the CRC field andpadding bytes from the frames. You can configure the MAC RX to remove the CRC field by setting therx_padcrc_control register to 1. To remove both the CRC field and padding bytes, set therx_padcrc_control register to 3.

The MAC RX removes padding bytes from receive frames whose payload length is less than the followingvalues for the different frame types:

• 46 bytes for basic frames• 42 bytes for VLAN tagged frames• 38 bytes for stacked VLAN tagged frames

To retain the CRC-2 field, set the rx_padcrc_control register to 0.

Overflow HandlingWhen an overflow occurs on the client side, the client can backpressure the Avalon-ST receive interfaceby deasserting the avalon_st_rx_ready signal. If an overflow occurs in the middle of frame transmission,the MAC RX truncates the frame by sending out the avalon_st_rx_endofpacket signal after theavalon_st_rx_ready signal is reasserted. The error bit, avalon_st_rx_error[5], is set to 1 to indicatean overflow. If there is an overflow during client data reception, the current frame will get truncated. TheMAC RX will drop the remaining payload of the erroneous frame and the subsequent frames if theoverflow condition persists. The MAC RX then continues to receive data when the overflow conditionceases.

3-16 CRC and Padding Bytes RemovalUG-01144

2014.12.15


Send Feedback


RX Timing DiagramsFigure 3-15: Back-to-back Transmission of Normal Frames with CRC Removal Enabled

The following diagram shows back-to-back reception of normal frames with CRC removal enabled.

rx_312_5_clkxgmii_rx_data[31:0]

xgmii_rx_control[3:0]avalon_st_rx_startofpacket

avalon_st_rx_validavalon_st_rx_ready

avalon_st_trx_endofpacketavalon_st_rx_data[31:0]

avalon_st_rx_empty[1:0]avalon_st_rx_error[5:0]

avalon_st_rx_data[31:24]avalon_st_rx_data[23:16]


xgmii_rx_data[7:0]xgmii_rx_data[15:8]


* *fff * * * * *c 0000_0000 *0faa_4s5e * * * * * * * * * *

1 0 1f 0 1f 0

* *fff *0 * *0707_0707 * *0 0000_0000 * * * *

fb *ff cf 88 21 22 8cc 00 fd07 fb 3a 00 c0 0a 4d da * cd3a b6 fa 07 01 8187 95 46 94 f2

88 ff 58 08 d3 be 88 00 0707 88 3a 01 16 51 ae c5 * 403a df 55 80 00f3 c7 46 df f6

88 d0 d5 cd a7 ff 00 0707 88 3a 0a 50 51 2e 2b * 0a3a 62 73 c246 97 24 43 aa

88 ad 49 f5 2a 00 0707 88 d5 d9 6d 18 8d 57 * 7cd5 2b f1 003e 28 55 70 95

ff 61 68 03

5c 81ff 60

fb ff 88 b607 22 8c 00 07 3a 01 c03a cf f121 00fb

88 ff 08 df07 be 89 00 07 3a 80 163a 58 55d3 0188

88 d5 6207 a7 ff 00 07 3a c2 503a d0 73cd 0a88ff 61

88 49 2b07 2a 00 07 d5 00 6dd5 ad f1f5 d988ff 60

UG-011442014.12.15 RX Timing Diagrams 3-17


Send Feedback


Figure 3-16: Back-to-back Transmission of Normal Frames with Preamble Passthrough Mode Enabled

The following diagram shows back-to-back reception of normal frames with preamble passthrough modeand padding bytes and CRC removal enabled.

rx_312_5_clkavalon_st_rx_startofpacketavalon_st_trx_endofpacket

avalon_st_rx_validavalon_st_rx_ready

avalon_st_rx_error[5:0]avalon_st_rx_empty[1:0]avalon_st_rx_data[31:0]

xgmii_rx_data[31:0]xgmii_rx_control[3:0]





*52*1 *38 *10 *1 *a *5 *0 *a *f3 *1c *af *9 *_34a8 *7 *88 *5 *f_ff*52 *c *b4 *9 *c *94 *b *e *c *3 *e1 *df *e8 *7 *6a *ff *_8601 *07 0707_0

*9* *20 *7 *fb *a *f_ff*fff *1 *81 *1 *4 *fb *a *e *4f *85 *c8 *e *fe *92 *0 *1 fd 0707_0707*6 *c

c0 f 1 0 f 1 0 1 0 1 0 1 0 1 0 1 0 1

8916 20 07 fb 3a ff a1 81 64 fb 6a 8e 4f 85 c8 4e fe 92 70 91 fd 0766 0c

345b fd 07 88 3a ff f5 dd 2f 34 c2 8e ce 0e 3a 20 1e a4 26 a6 86 07c9 2a

8534 94 07 88 3a ff 85 00 1e 59 29 6d b3 3a 1f 38 f0 05 b3 29 0790 87

a8a9 07 88 d5 ff 26 bc b4 e9 9c 94 bc e3 e1 df e8 37 6a ff 079b ee 01 68

ff3c fa c2 85 53 26 36 34 f2 35 f4 16 89 07 fb 3a ff a1 81 64 fb 66 0c 6a 8e 4f 85 c8 4e fe 92 70 fd 07

c5ff 92 f5 6d 41 3c b0 1d 20 4e 32 5b 34 07 88 3a ff f5 dd 2f 34 c2 8e c9 2a ce 0e 3a 20 1e a4 26 a6 86 07

6c81 36 0e 34 8a 30 92 c4 50 f5 80 34 85 07 88 3a ff 85 00 1e 59 90 87 29 6d b3 3a 1f 38 f0 05 b3 07

5211 38 10 51 0a 95 b0 0a f3 1c af a9 a8 07 88 d5 ff 26 bc b4 e9 c2 94 9b ee bc e3 e1 df e8 37 6a ff 01 07

0 02

00

Flow ControlThe MAC IP core implements the following flow control mechanisms:

• The MAC IP core implements the following flow control mechanisms:IEEE 802.3 flow control—implements the IEEE 802.3 Annex 31B standard to manage congestion. When the MAC IP coreexperiences congestion, the core sends a pause frame to request its link partner to suspend transmis‐sion for a given period of time. This flow control is a mechanism to manage congestion at the local orremote partner. When the receiving device experiences congestion, it sends an XOFF pause frame tothe emitting device to instruct the emitting device to stop sending data for a duration specified by thecongested receiver. Data transmission resumes when the emitting device receives an XON pause frame(pause quanta = zero) or when the timer expires.

• Priority-based flow control (PFC)—implements the IEEE 802.1Qbb standard. PFC managescongestion based on priority levels. It supports up to 8 priority queues. When the receiving deviceexperiences congestion on a priority queue, it sends a PFC frame requesting the emitting device to stoptransmission on the priority queue for a duration specified by the congested receiver. When thereceiving device is ready to receive transmission on the priority queue again, it sends a PFC frameinstructing the emitting device to resume transmission on the priority queue.

Note: Altera recommends that you enable only one type of flow control at any one time.

IEEE 802.3 Flow ControlThis section describes the pause frame reception and transmission in the IEEE 802.3 flow control.

3-18 Flow ControlUG-01144

2014.12.15


Send Feedback


To use the IEEE 802.3 flow control, set the following registers:

• On the transmit datapath:

• Set tx_pfc_priority_enable to 0 to disable the PFC.• Set tx_pauseframe_enable to 1 to enable the IEEE 802.3 flow control.

• On the receive datapath:

• Set rx_pfc_control to 1 to disable the PFC.• Set the IGNORE_PAUSE bit in the rx_decoder_control register to 0 to enable the IEEE 802.3 flow

control.

Pause Frame Reception

When the MAC receives an XOFF pause frame, it stops transmitting frames to the remote partner for aperiod equal to the pause quanta field of the pause frame. If the MAC receives a pause frame in the middleof a frame transmission, the MAC finishes sending the current frame and then suspends transmission fora period specified by the pause quanta. The MAC resumes transmission when it receives an XON pauseframe or when the timer expires. The pause quanta received overrides any counter currently stored. Whenthe remote partner sends more than one pause quanta, the MAC sets the value of the pause to the lastquanta it received from the remote partner. You have the option to configure the MAC to ignore pauseframes and continue transmitting frames by setting the IGNORE_PAUSE bit in the rx_decoder_controlregister to 1.

Pause Frame Transmission

The MAC provides the following two methods for the client or connecting device to trigger pause frametransmission:

• avalon_st_pause_data signal (tx_pauseframe_enable[2:1] set to 0)—You can connect this 2-bitsignal to a FIFO buffer or a client. Bit setting:

• avalon_st_pause_data[1]: 1—triggers the transmission of XOFF pause frames.• avalon_st_pause_data[0]: 1—triggers the transmission of XON pause frames. The transmission

of XON pause frames only trigger for one time after XOFF pause frames regardless of how long theavalon_st_pause_data[0] signal is asserted.

If pause frame transmission is triggered when the MAC is generating a pause frame, the MAC ignoresthe incoming request and completes the generation of the pause frame. Upon completion, if theavalon_st_pause_data signal remains asserted, the MAC generates a new pause frame and continuesto do so until the signal is deasserted. You can also configure the gap between successive XOFFrequests for using the tx_pauseframe_quanta register. XON pause frames will only be generated if theMAC generates XOFF pause frames.

• tx_pauseframe_control register (tx_pauseframe_enable[2:0] set to 0x1)—A host (software) canset this register to trigger pause frames transmission. Setting tx_pauseframe_control[1] to 1 triggersthe transmission of XOFF pause frames; setting tx_pauseframe_control[0] to 1 triggers thetransmission of XON pause frames. The register clears itself after the request is executed.

You can configure the pause quanta in the tx_pauseframe_quanta register. The MAC sets the pausequanta field in XOFF pause frames to this register value.

Note: The new register field determines which pause interface takes effect.

UG-011442014.12.15 Pause Frame Reception 3-19


Send Feedback


The following figure shows the transmission of an XON pause frame. The MAC sets the destinationaddress field to the global multicast address, 01-80-C2-00-00-01 (0x010000c28001) and the source addressto the MAC primary address configured in the tx_addrins_macaddr0 and tx_addrins_madaddr1registers.

Figure 3-17: XON Pause Frame Transmission

tx_clk_clk

FB 55 01 00 FD

xgmii_tx_control[3]


xgmii_tx_control[2]


xgmii_tx_control[1]

xgmii_tx_data[15:8]

xgmii_tx_control[0]

xgmii_tx_data[7:0] 00 88 88 96

55 55 80 0001 CC 08 96

55 55 C2 00EE AA 96

55 D5 00 00CC EE 01 96

Priority-Based Flow ControlThis section describes the PFC frame reception and transmission. Follow these steps to use the PFC:

1. Turn on the Priority-based flow control (PFC) parameter and specify the number of priority levelsusing the Number of PFC priorities parameter. You can specify between 2 to 8 PFC priority levels.

2. Set the following registers.

• On the transmit datapath:

• Set tx_pauseframe_enable to 0 to disable the IEEE 802.3 flow control.• Set tx_pfc_priority_enable[n] to 1 to enable the PFC for priority queue n.

• On the receive datapath:

• Set the IGNORE_PAUSE bit in the rx_decoder_control register to 1 to disable the IEEE 802.3flow control.

• Set the PFC_IGNORE_PAUSE_n bit in the rx_pfc_control register to 0 to enable the PFC.3. Connect the avalon_st_tx_pfc_gen_data signal to the corresponding RX client logic and the

avalon_st_rx_pfc_pause_data signal to the corresponding TX client logic.4. You have the option to configure the MAC RX to forward the PFC frame to the client by setting the

FWD_PFC bit in the rx_pfc_control register to 1. By default, the MAC RX drops the PFC frame afterprocessing it.

3-20 Priority-Based Flow ControlUG-01144

2014.12.15


Send Feedback


PFC Frame Reception

When the MAC RX receives a PFC frame from the remote partner, it asserts theavalon_st_rx_pfc_pause_data[n] signal if Pause Quanta n is valid (Pause Quanta Enable [n] = 1) andgreater than 0. The client suspends transmission from the TX priority queue n for the period specified byPause Quanta n. If the MAC RX asserts the avalon_st_rx_pfc_pause_data[n] signal in the middle of aclient frame transmission for the TX priority queue n, the client finishes sending the current frame andthen suspends transmission for the queue.

When the MAC RX receives a PFC frame from the remote partner, it deasserts theavalon_st_rx_pfc_pause_data[n] signal if Pause Quanta n is valid (Pause Quanta Enable [n] = 1) andequal to 0. The MAC RX also deasserts this signal when the timer expires. The client resumes transmis‐sion for the suspended TX priority queue when the avalon_st_rx_pfc_pause_data[n] signal isdeasserted.

When the remote partner sends more than one pause quanta for the TX priority queue n, the MAC RXsets the pause quanta n to the last pause quanta received from the remote partner.

PFC Frame Transmission

PFC frame generation is triggered through the avalon_st_tx_pfc_gen_data signal. Set the respectivebits to generate XOFF or XON requests for the priority queues.

For XOFF requests, you can configure the pause quanta for each priority queue using thepfc_pause_quanta_n registers. For an XOFF request for priority queue n, the MAC TX sets bit n in thePause Quanta Enable field to 1 and the Pause Quanta n field to the value of the pfc_pause_quanta_nregister. You can also configure the gap between successive XOFF requests for a priority queue using thepfc_holdoff_quanta_n register.

For XON requests, the MAC TX sets the pause quanta to 0. You must generate a XOFF request beforegenerating a XON request.

PHY ConfigurationsThe MAC can connect to a PHY IP core through the standard XGMII, GMII, and MII interfaces.

Supported PHY configurations:

• 10G only PHY—10GBASE-R PHY (for Arria 10 devices, use the Arria 10 Transceiver Native PHY IPcore 10GBASE-R presets)

• 10M/100M/1G/10G capable PHY—10GBASE-KR or 1G/10G PHY• XAUI PHY

Note: Implement a 32b/64b adaptation layer outside of the MAC to connect to any of these 64-bit PHYinterfaces.

Related InformationAN 701: Scalable Low Latency Ethernet 10G MAC using Arria 10 1G/10G PHYDesign examples to demonstrate the Altera Low Latency Ethernet 10G MAC IP systems using Arria 10PHY.

UG-011442014.12.15 PFC Frame Reception 3-21


Send Feedback

http://www.altera.com/literature/an/an701.pdf


10GBASE-R Register ModeThis feature is supported as a synthesizable option and is only available for use with the Arria 10Transceiver Native PHY IP core preset configuration. When operating in this mode, the round-triplatency for the MAC and PHY can be further reduced to 140 ns with a slight increase in resource countand clock frequencies.

When you enable this feature, the MAC implement two additional signals to determine whether informa‐tion on the XGMII TX and RX interfaces are valid. These signals ensures that the effective data rate of theMAC is at 10 Gbps. In addition to the information on the XGMII interfaces, the following configurationsmust be complied:

• The selected preset is 10GBASE-R Register Mode• The PHY must expose the TX and RX parallel clocks.• The PHY must expose data valid signals, with MAC/PHY TX/RX interfaces in register mode, as in the

IEEE 1588v2 configuration.• The MAC and PHY runs at the parallel clock frequency of 322.265625 MHz (the PCS/PMA width

equals to 32)

Figure 3-18: PHY Configuration with 10GBASE-R Register Mode Enabled.

Figure shows a block diagram of the PHY configuration when operating in 10GBASE-R mode.

Transmitter 10G PCS

Receiver 10G PCS

Transmitter PMA

Receiver PMA

Parallel Clock (Recovered)

Parallel Clock (322+ MHz)

FPGAFabric

Regis

ter

Regis

ter

Fram

e Gen

erat

or

CRC3

2Ge

nera

tor

CRC3

2Ch

ecke

r

64B/

66B E

ncod

eran

d TX S

M

64B/

66B D

ecod

eran

d RX S

M

Scra

mble

rDe

-Scra

mble

r

Disp

arity

Chec

ker

Bloc

k Syn

chro

nizer

Fram

e Syn

chro

nizer

Disp

arity

Gene

rato

r

TX G

ear B

ox

RX G

ear B

ox

Seria

lizer

Dese

rializ

er

CDR

rx_s

erial

_dat

atx

_ser

ial_d

ata

Parallel Clock

Serial Clock

Parallel and Serial Clock

BER Monitor

Div 32

Clock Divider

Parallel and Serial Clocks (From the ×6 or ×N Clock Lines)Serial Clock

(From the ×1 Clock Lines)

Central/ Local Clock Divider

Parallel and Serial Clocks(Only from the Central Clock Divider)

CMU PLL

64-Bit Data 8-Bit Control

64-Bit Data 8-Bit Control

6666 32

3266

Input Reference Clock

64-Bit Data 8-Bit

Control

fPLL

64-Bit Data 8-Bit

Control

Related InformationArria 10 Transceiver PHY User GuideMore information on how to configure the transceivers to implement 10GBASE-R functionality by usingthe preset of the Arria 10 Transceivers Native PHY IP core.

3-22 10GBASE-R Register ModeUG-01144

2014.12.15


Send Feedback

http://www.altera.com/literature/hb/arria-10/ug_arria10_xcvr_phy.pdf


Error Handling (Link Fault)The LL Ethernet 10G MAC supports link fault generation and detection.

When the MAC RX receives a local fault, the MAC TX starts sending remote fault status (0x9c000002) onits XGMII. If the packet transmission was in progress at the time, the remote fault bytes will override thepacket bytes until the fault condition ceases.

When the MAC RX receives a remote fault, the MAC TX starts sending IDLE bytes (0x07070707) on itsXGMII. If packet transmission was in progress at the time, the IDLE bytes will override the packet bytesuntil the fault condition ceases.

The MAC considers the link fault condition has ceased if the client and the remote partner both receivevalid data in more than 127 columns.

Figure 3-19: Fault Signaling

Remote Fault (0x9c000002)Idle (07070707)

Remote Fault (0x9c000002)

ClientInterface

MACTx

RS Tx

MACRx

RS Rx

2 link_fault_status_xgmii_rx_data XAUI /10GBASE-R

PHY

ExternalPHY

RemotePartner

XAUI /10GBASE-R

NetworkInterface

Local Fault (0x9c000001)

XGMII

UG-011442014.12.15 Error Handling (Link Fault) 3-23


Send Feedback


Figure 3-20: XGMII TX interface Transmitting Remote Fault Signal

The following figure shows the timing for the XGMII TX interface transmitting the remote fault signal(0x9c000002).

tx_clk_clk

xgmii_tx_control[3]


xgmii_tx_control[2]


xgmii_tx_control[1]

xgmii_tx_data[15:8]

xgmii_tx_control[0]

xgmii_tx_data[7:0]

02

00

00

9C

When you instantiate the MAC RX only variation, connect the link_fault_status_xgmii_rx_datasignal to the corresponding RX client logic to handle the link fault. Similarly, when you instantiate theMAC TX only variation, connect the link_fault_status_xgmii_tx_data signal to the correspondingTX client logic.

Note: The 1G/10GbE MAC does not support error handling through link fault. Instead, the MAC usesthe gmii_rx_err signal.

IEEE 1588v2The IEEE 1588v2 option provides time stamp for receive and transmit frames in the LL Ethernet 10GMAC IP core designs. The feature consists of Precision Time Protocol (PTP). PTP is a protocol thataccurately synchronizes all real time-of-day clocks in a network to a master clock.

3-24 IEEE 1588v2UG-01144

2014.12.15


Send Feedback


The IEEE 1588v2 option has the following features:

• Supports 4 types of PTP clock on the transmit datapath:

• Master and slave ordinary clock• Master and slave boundary clock• End-to-end (E2E) transparent clock• Peer-to-peer (P2P) transparent clock

• Supports PTP with the following message types:

• PTP event messages—Sync, Delay_Req, Pdelay_Req, and Pdelay_Resp.• PTP general messages—Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Announce,

Management, and Signaling.• Supports simultaneous 1-step and 2-step clock synchronizations on the transmit datapath.

• 1-step clock synchronization—The MAC function inserts accurate timestamp in Sync PTP messageor updates the correction field with residence time.

• 2-step clock synchronization—The MAC function provides accurate timestamp and the relatedfingerprint for all PTP message.

• Supports the following PHY operating speed random error:

• 10 Gbps—Timestamp accuracy of ± 1 ns• 1 Gbps—Timestamp accuracy of ± 2 ns• 100 Mbps—Timestamp accuracy of ± 5 ns

• Supports static error of ± 3 ns across all speeds.• Supports IEEE 802.3, UDP/IPv4, and UDP/IPv6 protocol encapsulations for the PTP packets.• Supports untagged, VLAN tagged, and Stacked VLAN Tagged PTP packets, and any number of MPLS

labels. The packet classifier under user control parses the packet (Ethernet packet or MPLS packet) andgives the IP core the required offset, at which either the ToD or CF update can happen.

• Supports configurable register for timestamp correction on both transmit and receive datapaths.• Supports ToD clock that provides streams of 64-bit and 96-bit timestamps. The 64-bit timestamp is for

transparent clock devices and the 96-bit timestamp is for ordinary clock and boundary clock devices.

ArchitectureThe following figure shows the overview of the IEEE 1588v2 feature.

UG-011442014.12.15 Architecture 3-25


Send Feedback


Figure 3-21: Overview of IEEE 1588v2 Feature

IEEE 1588v2Tx Logic

IEEE 1588v2Rx Logic

PTP SoftwareStack

Time-of-DayClock

PHYTx

PHYRx

10GbE MAC IP 10GBASE-R PHY IP

tx_path_delay

rx_path_delay

Timestamp &User Fingerprint

Correction

Time of Day

Timestamp Aligned toReceive Frame

tx_egress_timestamp_requesttx_ingress_timestamp

tx_time_of_dayrx_time_of_day

Transmit DatapathThe IEEE 1588v2 feature supports 1-step and 2-step clock synchronizations on the transmit datapath.

• For 1-step clock synchronization,

• Timestamp insertion depends on the PTP device and message type.• The MAC function inserts a timestamp in the PTP packet when the client specifies the Timestamp

field offset and asserts Timestamp Insert Request.• Depending on the PTP device and message type, the MAC function updates the residence time in

the correction field of the PTP packet when the client assertstx_etstamp_ins_ctrl_residence_time_update and Correction Field Update. The residencetime is the difference between the egress and ingress timestamps.

• For PTP packets encapsulated using the UDP/IPv6 protocol, the MAC function performs UDPchecksum correction using extended bytes in the PTP packet.

• The MAC function recomputes and reinserts CRC-32 into the PTP packets after each timestamp orcorrection field insertion.

• The format of timestamp supported includes 1588v1 and 1588v2• For 2-step clock synchronization, the MAC function returns the timestamp and the associated

fingerprint for all transmit frames when the client asserts tx_egress_timestamp_request_valid.

The following table summarizes the timestamp and correction field insertions for various PTP messagesin different PTP clocks.

3-26 Transmit DatapathUG-01144

2014.12.15


Send Feedback


Table 3-5: Timestamp and Correction Insertion for 1-Step Clock Synchronization

PTP Message

Ordinary Clock Boundary Clock E2E TransparentClock P2P Transparent Clock

InsertTime

stamp

InsertCorrection

InsertTime

stamp

InsertCorrection

InsertTime

stamp

InsertCorrection

InsertTime

stamp

InsertCorrection

Sync Yes (5) No Yes(5) No No Yes (6) No Yes (6)

Delay_Req No No No No No Yes (6) No Yes (6)

Pdelay_Req No No No No No Yes (6) No No

Pdelay_Resp No Yes (5) (6) No Yes (5) (6) No Yes (6) No Yes (5) (6)

Delay_Resp No No No No No No No No

Follow_Up No No No No No No No No

Pdelay_Resp_

Follow_UpNo No No No No No No No

Announce No No No No No No No No

Signaling No No No No No No No No

Management No No No No No No No No

Receive DatapathIn the receive datapath, the IEEE 1588v2 feature provides a timestamp for all receive frames. Thetimestamp is aligned with the avalon_st_rx_startofpacket signal.

Frame FormatThe MAC function, with the IEEE 1588v2 feature, supports PTP packet transfer for the followingtransport protocols:

• IEEE 802.3• UDP/IPv4• UDP/IPv6

PTP Packet in IEEE 802.3

The following figure shows the format of the PTP packet encapsulated in IEEE 802.3.

(5) Applicable only when 2-step flag in flagField of the PTP packet is 0.(6) Applicable when you assert the tx_etstamp_ins_ctrl_residence_time_update signal.

UG-011442014.12.15 Receive Datapath 3-27


Send Feedback


Figure 3-22: PTP Packet in IEEE 8002.3

flagField

correctionField

transportSpecific | messageType

reserved | versionPTP

reserved

1 Octet

1 Octet

1 Octet

2 Octets

8 Octets

reserved4 Octets

SourcePortIdentify10 Octets

sequenceId2 Octets

controlField1 Octet

logMessageInterval1 Octet

TimeStamp

Payload

10 Octets

domainNumber

messageLength2 Octets

1 Octet

Length/Type = 0x88F7

Source Address

Destination Address

2 Octets

6 Octets

6 Octets

MAC Header

PTP Header

0..1500/9600 Octets

CRC

Note:(1) For packets with VLAN or Stacked VLAN tag, add 4 or 8 octets offsets before the length/type field.

4 Octets

(1)

PTP Packet over UDP/IPv4

The following figure shows the format of the PTP packet encapsulated in UDP/IPv4. Checksum calcula‐tion is optional for the UDP/IPv4 protocol. The 1588v2 TX logic should set the checksum to zero.

3-28 PTP Packet over UDP/IPv4UG-01144

2014.12.15


Send Feedback


Figure 3-23: PTP Packet over UDP/IPv4

MAC Header

UDP Header

IP Header

PTP Header

Time To Live

Protocol = 0x11

Version | Internet Header Length

Differentiated Services

Flags | Fragment Offsets

1 Octet

1 Octet

2 Octets

1 Octet

1 Octet

Header Checksum2 Octets

Source IP Address4 Octets

Destination IP Address4 Octets

Options | Padding0 Octet

Source Port2 Octets

Destination Port = 319 / 3202 Octets

Identification

Total Length2 Octets

2 Octets

Length/Type = 0x0800

Source Address

Destination Address

2 Octets

6 Octets

6 Octets

Checksum

Length

2 Octets

2 Octets

flagField

correctionField



reserved

1 Octet

1 Octet

1 Octet

2 Octets

8 Octets

reserved4 Octets


sequenceId2 Octets

controlField1 Octet


TimeStamp

Payload

10 Octets

domainNumber


1 Octet

0..1500/9600 Octets

CRC


4 Octets

(1)

PTP Packet over UDP/IPv6

The following figure shows the format of the PTP packet transported over the UDP/IPv6 protocol.Checksum calculation is mandatory for the UDP/IPv6 protocol. You must extend 2 bytes at the end of theUDP payload of the PTP packet. The MAC function modifies the extended bytes to ensure that the UDPchecksum remains uncompromised.

UG-011442014.12.15 PTP Packet over UDP/IPv6 3-29


Send Feedback


Figure 3-24: PTP Packet over UDP/IPv6

Version | Traffic Class | Flow Label

Payload Length

4 Octet

2 Octets

Source IP Address16 Octets

Destination IP Address16 Octets

Source Port2 Octets

Destination Port = 319 / 3202 Octets

Hop Limit

Next Header = 0x111 Octet

1 Octet

Length/Type = 0x86DD

Source Address

Destination Address

2 Octets

6 Octets

6 Octets

Checksum

Length

2 Octets

2 Octets

flagField

correctionField



reserved

1 Octet

1 Octet

1 Octet

2 Octets

8 Octets

reserved4 Octets


sequenceId2 Octets

controlField1 Octet


TimeStamp

Payload

10 Octets

0..1500/9600 Octets

extended bytes2 Octets

CRC


4 Octets

domainNumber


1 Octet

MAC Header

UDP Header

IP Header

PTP Header

(1)

3-30 PTP Packet over UDP/IPv6UG-01144

2014.12.15


Send Feedback


Configuration Registers 42014.12.15


The LL Ethernet 10G MAC IP core provides a total of 4Kb register space that is accessible via the Avalon-MM interface. Each register is 32 bits wide. Access only registers that apply to the variation of the MAC IPcore you use. For example, if you use the MAC RX only variation, avoid accessing registers that arespecific to MAC TX only variation. Accessing registers that do not apply to the variation you are usingmay cause lock Avalon-MM bus.

Note: Assessing reserved registers may produce non-deterministic behavior.

Register Access Type ConventionThis table describes the register access type for Altera IP cores.

Table 4-1: Register Access Type and Definition

Access Type Definition

RO Software read only (no effect on write). The value is hard-tied internally to either '0'or '1' and does not vary.

RO/v Software read only (no effect on write). The value may vary.

RC • Software reads shall return the current bit value, then the bit is self-clear to 0.• Software reads also cause the bit value to be cleared to 0.

RW • Software reads shall return the current bit value.• Software writes shall set the bit to the desired value.

RW1C • Software reads shall return the current bit value.• Software writes 0 shall have no effect.• Software writes 1 shall clear the bit to 0, if the bit has been set to 1 by hardware.• Hardware sets the bit to 1.• Software clear has higher priority than hardware set.





mailto:[email protected]?subject=Feedback%20on%20(UG-01144%202014.12.15)%20Configuration%20Registers&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.




Access Type Definition

RW1S • Software reads shall return the current bit value.• Software writes 0 shall have no effect.• Software writes 1 shall set the bit to 1.• Hardware clears the bit to 0, if the bit has been set to 1 by software.• Software set has higher priority than hardware clear.

Register Map

Table 4-2: Register Map

Word Offset Purpose MAC Variation

0x0000: 0x000F Reserved —

0x0010: 0x0011 Primary MAC Address MAC TX, MAC RX


0x0020: 0x003F Transmit Configuration and Status Registers MAC TX

0x0040: 0x005F Transmit Flow Control Registers MAC TX


0x0070 Transmit Unidirectional Control Registers MAC TX


0x00A0: 0x00FF Receive Configuration and Status Registers MAC RX

0x0100: 0x010C Transmit Timestamp Registers MAC TX

0x0120: 0x012C Receive Timestamp Registers MAC RX

0x0140: 0x023F Statistics Registers MAC TX, MAC RX

0x0240: 0x0241 ECC Registers MAC TX, MAC RX

Register Map (with and without Avalon-MM Adapter)Table 4-3: Register Mapping of 32-bit and 64-bit MAC

Register (in 64-bit MAC) 64-bit MAC Avalon-MM Adapter Address

(csr_address[12:0])

32-bit MAC Avalon-MMNative Address (csr_

address[10:0])

TX MAC Configuration RegistersTX Transfer Control 1000 020TX Transfer Status 1001 reserved

4-2 Register MapUG-01144

2014.12.15

Altera Corporation Configuration Registers

Send Feedback

mailto:[email protected]?subject=Feedback%20on%20Configuration%20Registers%20(UG-01144%202014.12.15)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.


(csr_address[12:0])


address[10:0])

TX Pad Insertion Control 1040 024TX CRC Insertion Control 1080 026TX Packet Underflow Count[31:0] 10C0 03ETX Packet Underflow Count[35:32] 10C1 03FTX Preamble Pass-Through Mode Control 1100 028TX Unidirectional 1120 070TX Pause Frame Control 1140 040TX Pause Frame Quanta 1141 042TX Pause Frame Enable 1142 044TX PFC0 Pause Quanta 1180 048TX PFC1 Pause Quanta 1181 049TX PFC2 Pause Quanta 1182 04ATX PFC3 Pause Quanta 1183 04BTX PFC4 Pause Quanta 1184 04CTX PFC5 Pause Quanta 1185 04DTX PFC6 Pause Quanta 1186 04ETX PFC7 Pause Quanta 1187 04FTX PFC0 Hold-off Quanta 1190 058TX PFC1 Hold-off Quanta 1191 059TX PFC2 Hold-off Quanta 1192 05ATX PFC3 Hold-off Quanta 1193 05BTX PFC4 Hold-off Quanta 1194 05CTX PFC5 Hold-off Quanta 1195 05DTX PFC6 Hold-off Quanta 1196 05ETX PFC7 Hold-off Quanta 1197 05FTX PFC Enable 11A0 046TX Address Insertion Control 1200 02A

64b: TX Address Insertion MAC Address[31:0]

32b: Primary MAC Address[31:0] - shared with RX

1201 010

64B: TX Address Insertion MAC MAC Address[47:32]

32b: Primary MAC Address[47:32] - shared with RX

1202 011

UG-011442014.12.15 Register Map (with and without Avalon-MM Adapter) 4-3

Configuration Registers Altera Corporation

Send Feedback



(csr_address[12:0])


address[10:0])

TX Maximum Frame Length 1801 02CRX MAC Configuration Registers

RX Transfer Enable 0000 0A0RX Transfer Status 0001 ReservedRX Pad/CRC Control 0040 0A4RX CRC Check Control 0080 0A6RX Overflow Truncated Packet Count[31:0] 00C0 0FCRX Overflow Truncated Packet Count[35:32] 00C1 0FDRX Overflow Dropped Packet Count[31:0] 00C2 0FERX Overflow Dropped Packet Count[35:32] 00C3 0FFRX Preamble Forward Control 0100 0A8RX Preamble Pass-Through Mode Control 0140 0AARX Frame Filtering Control 0800 0ACRX Maximum Frame Length 0801 0AE

64b: RX Frame MAC Address[31:0]

32b: Primary MAC Address[31:0] - shared with TX

0802 010

64b: RX Frame MAC Address[47:32]

32b: Primary MAC Address[47:32] - shared with TX

0803 011

RX Supplementary Address 0[31:0] 0804 0B0RX Supplementary Address 0[47:32] 0805 0B1RX Supplementary Address 1[31:0] 0806 0B2RX Supplementary Address 1[47:32] 0807 0B3RX Supplementary Address 2[31:0] 0808 0B4RX Supplementary Address 2[47:32] 0809 0B5RX Supplementary Address 3[31:0] 080A 0B6RX Supplementary Address 3[47:32] 080B 0B7RX PFC Control 0818 0C0

TX Time Stamp RegistersTX Period for 10G 1110 100TX Fractional Nano-second Adjustment for 10G 1112 102TX Nano-second Adjustment for 10G 1113 104

4-4 Register Map (with and without Avalon-MM Adapter)UG-01144

2014.12.15


Send Feedback



(csr_address[12:0])


address[10:0])

TX Period for 10M/100M/1G 1118 108TX Fractional Nano-second Adjustment for 10M/100M/1G

111A 10A

TX Nano-second Adjustment for 10M/100M/1G 111B 10CRX Time Stamp Registers

RX Period for 10G 0110 120RX Fractional Nano-second Adjustment for 10G 0112 122RX Nano-second Adjustment for 10G 0113 124RX Period for 10M/100M/1G 0118 128RX Fractional Nano-second Adjustment for 10M/100M/1G

011A 12A

RX Nano-second Adjustment for 10M/100M/1G 011B 12CAll TX Statistics Registers 1Cxx 14xAll RX Statistics Registers 0Cxx 1Cx

Status Registers

64b: N/A

32b: ECC Error Status

0820 240

64b: N/A

32b: ECC Error Enable

0821 241

UG-011442014.12.15 Register Map (with and without Avalon-MM Adapter) 4-5


Send Feedback


Primary MAC Address

Table 4-4: Primary MAC Address

Word Offset Register Name Description Access HW ResetValue

0x0010 primary_mac_addr0 6-byte primary MAC address. Configurethis register with a non-zero value beforeyou enable the MAC IP core foroperations.

Map the primary MAC address as follows:

• primary_mac_addr0: Lower four bytesof the address.

• primary_mac_addr1[15:0]: Uppertwo bytes of the address.

• primary_mac_addr1[31:16]:Reserved.

Example

If the primary MAC address is 00-1C-23-17-4A-CB, set primary_mac_addr0 to0x23174ACB and primary_mac_addr1 to0x0000001C.

Usage

On transmit, the MAC IP core uses thisaddress to fill the source address field incontrol frames. For data frames from theclient, the MAC IP core replaces the sourceaddress field with the primary MACaddress when the tx_src_addr_overrideregister is set to 1.

On receive, the MAC IP core uses thisaddress to filter unicast frames when theEN_ALLUCAST bit of the rx_frame_controlregister is set to 0. The MAC IP core dropsframes whose destination address isdifferent from the value of the primaryMAC address.

RW 0x0

0x0011 primary_mac_addr1

4-6 Primary MAC AddressUG-01144

2014.12.15


Send Feedback


Transmit Configuration and Status Registers

Table 4-5: Transmit Configuration and Status Registers


0x0020 tx_packet_control • Bit 0—configures the transmit path.

0: Enables transmit path.

1: Disables transmit path. The MAC IPcore backpressures the client on theAvalon-ST transmit data interface bydeasserting the avalon_st_tx_readysignal. New Pause and PFC frames willnot be generated.

• Bits 31:1—reserved.

You can change the value of this register asnecessary. If the transmit path is disabledwhile a frame is being transmitted, theMAC IP core completes the transmissionbefore disabling the transmit path.

RW 0x0

0x0022 tx_packet_status • Bits 31:0—reserved. RO 0x0

0x0024 tx_pad_control • Bit 0—padding insertion enable ontransmit.

0: Disables padding insertion. Theclient must ensure that the length of thedata frame meets the minimum lengthas required by the IEEE 802.3 specifica‐tions.

1: Enables padding insertion. The MACIP core inserts padding bytes into thedata frames from the client to meet theminimum length as required by theIEEE 802.3 specifications.

When padding insertion is enabled, youmust set tx_crc_control[] to 0x3 toenable CRC insertion.


Configure this register before you enablethe MAC IP core for operations.

RW 0x1

UG-011442014.12.15 Transmit Configuration and Status Registers 4-7


Send Feedback



0x0026 tx_crc_control • Bit 0—always set this bit to 1.• Bit 1—configures CRC insertion.

0: Disables CRC insertion. The clientmust provide the CRC field and ensurethat the length of the data frame meetsthe minimum required length.

1: Enables CRC insertion. The MAC IPcore computes the CRC field andinserts it into the data frame.



RW 0x3

0x0028 tx_preamble_control • Bit 0—configures the preamblepassthrough mode on transmit.

0: Disables preamble passthrough. TheMAC IP core inserts the standardpreamble specified by the IEEE 802.3specifications into the data frame.

1: Enables preamble passthrough. TheMAC IP core identifies the first 8 bytesof the data frame from the client as acustom preamble.



RW 0x0

4-8 Transmit Configuration and Status RegistersUG-01144

2014.12.15


Send Feedback



0x002A tx_src_addr_override • Bit 0—configures source addressoverride.

0: Disables source address override. Theclient must fill the source address fieldwith a valid address..

1: Enables source address override. TheMAC IP core overwrites the sourceaddress field in data frames with theprimary MAC address specified in thetx_primary_mac_addr0 and tx_primary_mac_addr1 registers.



RW 0x0

0x002C tx_frame_maxlength • Bits 15:0—specify the maximumallowable frame length. The MAC IPcore uses this register only for thepurpose of collecting statistics. Whenthe length of the data frame from theclient exceeds this value, the MAC IPcore asserts avalon_st_txstatus_error[1] to flag the frame as oversized.The MAC IP core then forwards theoversized frame through the transmitdatapath as is.



RW 0x5EE(1518)

0x003E tx_underflow_counter0 36-bit error counter that collects thenumber of truncated transmit frameswhen transmit buffer underflow persists. (7)

• tx_underflow_counter0: Lower 32bits of the error counter.

• tx_underflow_counter1[3:0]: Upper4 bits of the error counter.

• tx_underflow_counter1[31:4]—reserved.

RO 0x0

0x003F tx_underflow_

counter1

(7) The software must read the lower 32-bit of the counter first, followed by the upper 4-bit to obtain the correctvalue. The hardware clears the counter after read access. All other 36-bits statistic registers do not self-clear.

UG-011442014.12.15 Transmit Configuration and Status Registers 4-9


Send Feedback


Flow Control Registers

Table 4-6: Flow Control Registers


0x0040 tx_pauseframe_control • Bits 1:0—configures the transmission ofpause frames.

00: No pause frame transmission.

01: Trigger the transmission of an XONpause frame (pause quanta = 0), if thetransmission is not disabled by otherconditions.

10: Trigger the transmission of anXOFF pause frame (pause quanta = tx_pauseframe_quanta register), if thetransmission is not disabled by otherconditions.

11: Reserved. This setting does nottrigger any action.


Changes to this self-clearing register affectsthe next transmission of a pause frame.

RW 0x0

0x0042 tx_pauseframe_quanta • Bits 15:0—pause quanta in unit ofquanta, 1 unit = 512 bits time. TheMAC IP core uses this value when itgenerates XOFF pause frames. AnXOFF pause frame with a quanta valueof 0 is equivalent to an XON frame.



RW 0x0

4-10 Flow Control RegistersUG-01144

2014.12.15


Send Feedback



0x0043 tx_pauseframe_holdoff_

quanta• Bits 15:0—specifies the gap between

two consecutive transmissions of XOFFpause frames in unit of quanta, 1 unit =512 bits time. The gap prevents back-to-back transmissions of pause frames,which may affect the transmission ofdata frames.



RW 0x1

0x0044 tx_pauseframe_enable • Bit 0—configures the transmission ofpause frames. This bit affects pauseframe requests from both register andvector settings.

0: Disables pause frame transmission.

1: Enables pause frame transmission, iftransmit path is enabled by tx_packet_control.

• Bits 2:1—specifies the trigger for pauseframe requests.

00: Accepts pause frame requests onlyfrom vector setting, avalon_st_pause_data.

01: Accepts pause frame requests onlyfrom register setting, tx_pauseframe_control.

10 / 11: Reserved.• Bits 31:3—reserved.


RW 0x1

UG-011442014.12.15 Flow Control Registers 4-11


Send Feedback



0x0046 tx_pfc_priority_enable Enables priority-based flow control on thetransmit datapath.

• Bits 7:0—setting bit n enables priority-based flow control for priority queue n.For example, setting tx_pfc_priority_enable[0] enables queue 0.



Note: MAC TX only transmits PFCframe only if transmit path is alsoenabled by tx_packet_control.

RW 0x0

0x0048 pfc_pause_quanta_0 Specifies the pause quanta for each priorityqueue.

• Bits 15:0—pfc_pause_quanta_

n[15:0] specifies the pause length forpriority queue n in quanta unit, where 1unit = 512 bits time.


Configure these registers before you enablethe MAC IP core for operations.

RW 0x0

0x0049 pfc_pause_quanta_1

0x004A pfc_pause_quanta_2

0x004B pfc_pause_quanta_3

0x004C pfc_pause_quanta_4

0x004D pfc_pause_quanta_5

0x004E pfc_pause_quanta_6

0x004F pfc_pause_quanta_7

0x0058 pfc_holdoff_quanta_0 Specifies the gap between two consecutivetransmissions of XOFF pause frames inunit of quanta, 1 unit = 512 bits time. Thegap prevents back-to-back transmissionsof pause frames, which may affect thetransmission of data frames.

• Bits 15:0— pfc_holdoff_quanta_n[15:0] specifies the gap for priorityqueue n.


Configure these registers before you enablethe MAC IP core for operations.

RW 0x1

0x0059 pfc_holdoff_quanta_1

0x005A pfc_holdoff_quanta_2

0x005B pfc_holdoff_quanta_3

0x005C pfc_holdoff_quanta_4

0x005D pfc_holdoff_quanta_5

0x005E pfc_holdoff_quanta_6

0x005F pfc_holdoff_quanta_7

Unidirectional Control RegisterThe Unidirectional control registers are available only when you turn on the Enable Unidirectionalfeature parameter.

4-12 Unidirectional Control RegisterUG-01144

2014.12.15


Send Feedback


Table 4-7: Unidirectional Control Register


0x0070 tx_unidir_control • Bit 0—configures unidirectional featureon the transmit path.

0: Disables unidirectional feature.

1: Enables unidirectional feature.• Bit 1—configures remote fault sequence

generation when unidirectional featureis enabled on the transmit path.

0: Enable remote fault sequencegeneration on detecting local fault.

1: Disable remote fault sequencegeneration.



RW 0x0

Receive Configuration and Status Registers

Table 4-8: Receive Configuration and Status Registers


0x00A0 rx_transfer_control • Bit 0—receive path enable.

0: Enables the receive path.

1: Disables the receive path. The MACIP core drops all incoming frames.


A change of value in this register takeseffect at a packet boundary. Any transfer inprogress is not affected.

RW 0x0

0x00A2 rx_transfer_status • Bits 31:0—reserved. RO 0x0

UG-011442014.12.15 Receive Configuration and Status Registers 4-13


Send Feedback



0x00A4 rx_padcrc_control • Bits [1:0]—Padding and CRC removalon receive.

00: Retains the padding bytes and CRCfield, and forwards them to the client.

01: Retains only the padding bytes. TheMAC IP core removes the CRC fieldbefore it forwards the receive frame tothe client.

11: Removes the padding bytes andCRC field before the receive frame isforwarded to the client.

10: Reserved.• Bits 31:2—reserved.


RW 0x1

0x00A6 rx_crccheck_control CRC checking on receive.

• Bit 0—always set this bit to 0.• Bit 1—CRC checking enable.

0: Ignores the CRC field.

1: Checks the CRC field and reports thestatus to avalon_st_rx_error[1] andavalon_st_rxstatus_error.



RW 0x2

0x00A8 rx_custom_preamble_

forward• Bit 0—configures the forwarding of the

custom preamble to the client. TheMAC IP core supports custompreamble only in 10 Gbps operations.

0: Removes the custom preamble fromthe receive frame.

1: Retains and forwards the custompreamble to the client.



RW 0x0

4-14 Receive Configuration and Status RegistersUG-01144

2014.12.15


Send Feedback



0x00AA rx_preamble_control • Bit 0—preamble passthrough enable onreceive.

Note: The MAC IP core supportscustom preamble only in10Gbps operations.

0: Disables preamble passthrough. TheMAC IP core checks for START andSFD during packet decapsulationprocess.

1: Enables preamble passthrough. TheMAC IP core checks only for STARTduring packet decapsulation process.



RW 0x0



Send Feedback



0x00AC rx_frame_control

Bit 0—EN_ALLUCAST

0: Filters unicast receive frames using theprimary MAC address. The MAC IP coredrops unicast frames with a destinationaddress other than the primary MACaddress.

1: Accepts all unicast receive frames.

Setting this bit and the EN_ALLMCAST to 1puts the MAC IP core in the promiscuousmode.

RW 0x3

Bit 1—EN_ALLMCAST

0: Drops all multicast receive frames.

1: Accepts all multicast receive frames.

Setting this bit and the EN_ALLUCAST to1 is equivalent to setting the MAC IPcore to the promiscuous mode.

Bit 2—reserved.

Bit 3—FWD_CONTROL. When you turnon the Priority-based Flow Controlparameter, this bit affects all controlframes except the IEEE 802.3 pauseframes and priority-based controlframes. When the Priority-based FlowControl parameter is not enabled, thisbit affects all control frames except theIEEE 802.3 pause frames.

0: Drops the control frames.

1: Forwards the control frames to theclient.

Bit 4—FWD_PAUSE

0: Drops pause frames.

1: Forwards pause frames to the client.

Bit 5—IGNORE_PAUSE

0: Processes pause frames.

1: Ignores pause frames.

Bits 15:6—reserved.


2014.12.15


Send Feedback



0x00AC rx_frame_control

Bit 16—EN_SUPP0

0: Disables the use of supplementaryaddress 0.

1: Enables the use of supplementaryaddress 0.

RW 0x3

Bit 17—EN_SUPP1



Bit 18—EN_SUPP2



Bit 19—EN_SUPP3



Bits 31:20—reserved.

Configure this register before youenable the MAC IP core for operations.

0x00AE rx_frame_maxlength • Bits 15:0—specify the maximumallowable frame length. The MACasserts avalon_st_rx_error[3] whenthe length of the receive frame exceedsthe value of this register.



RW 1518



Send Feedback



0x00B0 rx_frame_spaddr0_0 You can specify up to four 6-bytesupplementary addresses:

• rx_framedecoder_spaddr0_0/1




Configure the supplementary addressesbefore you enable the MAC receivedatapath. Map the supplementaryaddresses to the respective registers in thesame manner as the primary MACaddress. Refer to the description ofprimary_mac_addr0 and primary_mac__addr1.The MAC IP core uses thesupplementary addresses to filter unicastframes when the following conditions areset:

• The use of the supplementary addressesare enabled using the respective bits inthe rx_frame_control register.

• The en_allucast bit of the rx_frame_control register is set to 0.

RW 0x0

0x00B1 rx_frame_spaddr0_1







0x00C0 rx_pfc_control • Bits 7:0—enables priority-based flowcontrol on the receive datapath. Settingbit n enables priority-based flowcontrol for priority queue n. Forexample, setting rx_pfc_priority_enable[0] enables queue 0.

• Bits 15:9—reserved.• Bit 16—configures the forwarding of

priority-based control frames to theclient.

0: Drops the control frames.

1: Forwards the control frames to theclient.



RW 0x1


2014.12.15


Send Feedback



0x00FC

rx_pktovrflow_error

36-bit error counter that collects thenumber of receive frames that aretruncated when a FIFO buffer overflowpersists: (8)

• The first 32 bits of the counter occupyoffset 0x00FC.

• The last 4 bits occupy bits 0:3 at offset0x00FD. Bits 4 to 31 are unused.

RO 0x0

0x00FD

0x00FE

rx_pktovrflow_

etherStatsDropEvents

36-bit error counter that collects thenumber of receive frames that are droppedwhen FIFO buffer overflow persists: (8)

• The first 32 bits of the counter occupythe register at offset 0x00FE.

• The last 4 bits occupy bits 0:3 at offset0x00FF. Bits 4 to 31 are unused.

RO 0x0

0x00FF

(8) The software must read the lower 32-bit of the counter first, followed by the upper 4 bits to ensure that thecorrect value is obtained. The counter is cleared by the hardware after read access. All other 36 bits statisticregisters do not self-clear.



Send Feedback


Transmit Timestamp Registers

Table 4-9: Transmit Timestamp Registers

WordOffset

Register Name Description Access HW ResetValue

0x0100 tx_period_10G Specifies the clock period for timestampadjustment on the transmit datapathwhen the PHY speed is 10 Gbps. TheMAC IP core multiplies the value of thisregister by the number of stagesseparating the actual timestamp andXGMII bus.

• Bits 15:0—period in fractionalnanoseconds.

• Bits 19:16—period in nanoseconds.• Bits 31:20—reserved. Set these bits to

0.

The default value is 3.2 ns for 312.5 MHzclock. Configure this register before youenable the MAC IP core for operations.

RW 0x33333

0x0102 tx_fns_adjustment_10G Static timing adjustment in fractionalnanoseconds on the transmit datapathwhen the PHY speed is 10 Gbps.

• Bits 15:0—adjustment period infractional nanoseconds.

• Bits 31:16—reserved. Set these bits to0.

Configure this register before you enablethe MAC IP core for operations. (9)

RW 0x0

0x0104 tx_ns_adjustment_10G Static timing adjustment in nanosecondson the transmit datapath when the PHYspeed is 10 Gbps.

• Bits 15:0—adjustment period innanoseconds.



RW 0x0

(9) For an example of how to calculate the value of the static timing adjustment registers (convert fractionalnanoseconds to hexadecimal), refer to this solution in the Altera Knowledge Base page.

4-20 Transmit Timestamp RegistersUG-01144

2014.12.15


Send Feedback

http://www.altera.com/support/kdb/solutions/rd08282014_422.html


WordOffset


0x0108 tx_period_mult_speed Specifies the clock period for timestampadjustment on the transmit datapathwhen the PHY speed is 10 Mbps/100Mbps/1 Gbps. The MAC IP coremultiplies the value of this register by thenumber of stages separating the actualtimestamp and GMII/MII bus.



0.

The default value is 8 ns for 125 MHzclock. Configure this register before youenable the MAC IP core for operations.

RW 0x80000

0x10A tx_fns_adjustment_mult_

speed

Static timing adjustment in fractionalnanoseconds on the transmit datapathwhen the PHY speed is 10 Mbps/100Mbps/1 Gbps.




RW 0x0

0x10C tx_ns_adjustment_mult_

speed

Static timing adjustment in nanosecondson the transmit datapath when the PHYspeed is 10 Mbps/100 Mbps/1 Gbps.




RW 0x0

UG-011442014.12.15 Transmit Timestamp Registers 4-21


Send Feedback


Receive Timestamp Registers

Table 4-10: Receive Timestamp Registers

WordOffset


0x0120 rx_period_10G Specifies the clock period on the receivedatapath when the MAC IP core operatesat 10 Gbps. The MAC IP core multipliesthe value of this register by the number ofstages separating the actual timestampand XGMII bus.


• Bits 19:16—period in nanoseconds.• Bits 31:20—reserved.

The default value is 3.2 ns for 312.5 MHzclock. Configure this register before youenable the MAC IP core for operations.

RW 0x33333

0x0122 rx_fns_adjustment_10G Static timing adjustment in fractionalnanoseconds on the receive datapathwhen the PHY speed is 10 Gbps.




RW 0x0

0x0124 rx_ns_adjustment_10G Static timing adjustment in nanosecondson the receive datapath when the PHYspeed is 10 Gbps.




RW 0x0

(10) For an example of how to calculate the value of the static timing adjustment registers (convert fractionalnanoseconds to hexadecimal), refer to this solution in the Altera knowledge database page.

4-22 Receive Timestamp RegistersUG-01144

2014.12.15


Send Feedback

http://www.altera.com/support/kdb/solutions/rd08282014_422.html


WordOffset


0x0128 rx_period_mult_speed Specifies the clock period on the receivedatapath when the PHY speed is 10Mbps/100 Mbps/1 Gbps. The MAC IPcore multiplies the value of this registerby the number of stages separating theactual timestamp and GMII/MII bus.



0.

The default value is 8 ns for 125 MHzclock. Configure this register before youenable the MAC IP core for operations.

RW 0x80000

0x12A rx_fns_adjustment_mult_

speed

Static timing adjustment in fractionalnanoseconds on the receive datapathwhen the PHY speed is 10 Mbps/100Mbps/1 Gbps.




RW 0x0

0x12C rx_ns_adjustment_mult_

speed

Static timing adjustment in nanosecondson the receive datapath when the PHYspeed is 10 Mbps/100 Mbps/1 Gbps.




RW 0x0

PMA Delay for IEEE 1588v2 MAC RegistersYou need to configure the PMA analog and digital delay to adjust the IEEE 1588v2 MAC registers. TheTX and RX paths are configured individually.

UG-011442014.12.15 PMA Delay for IEEE 1588v2 MAC Registers 4-23


Send Feedback


Table 4-11: IEEE 1588v2 Feature PMA Delay—Hardware

PMA digital and analog delay of hardware for the IEEE 1588v2 feature and the register timing adjustment.

• 1 UI for 10G is equivalent to 97 ps• 1 UI for 1G/100M/10M is equivalent to 800 ps

Delay Device PMA Mode(bit)

Timing AdjustmentMAC Configurations

TX Register RX Register

Digital Arria V GZ andStratix V

40 123 UI 87 UI 10GbE or 10G of 10M-10GbE

32 99 UI 84 UI 10GbE

10 53 UI 26 UI 1G/100M/10M of 10M-10GbE

Analog Arria V GZ andStratix V

— –1.1 ns 1.75 ns All

Table 4-12: IEEE 1588v2 Feature PMA Delay—Simulation Model

PMA digital and analog delay of simulation model for the IEEE 1588v2 feature and the register timing adjustment.

• 1 UI for 10G is equivalent to 97 ps• 1 UI for 1G/100M/10M is equivalent to 800 ps

Delay Device PMA Mode(bit)

Timing AdjustmentMAC Configurations

TX Register RX Register

Digital

Arria V GZ andStratix V

40 41 UI 150.5 UI 10GbE or 10G of 10M-10GbE

32 33 UI 196 UI 10GbE

10 11 UI 33.5 UI 1G/100M/10M of 10M-10GbE

Arria 1040 151.5 UI 65.5 UI 10GbE or 10G of 10M-10GbE

10 32 UI 23.5 UI 1G/100M/10M of 10M-10GbE

Statistics Registers

Statistics counters with prefix tx_ collect statistics on the transmit datapath; prefix rx_ collect statistics onthe receive datapath. 36-bit statistics counters occupy two offsets:

• The lower 32 bits of the counter occupy the first offset.• The upper 4 bits of the counter occupy bits 3:0 at the second offset.• Bits 31:5 at the second offset are reserved.

Note: When you enable the Statistics counters parameter, the default implementation of the counters ismemory-based.

• Memory-based—selecting this option frees up logic elements. The MAC IP core does not clearmemory-based counters after they are read.

• Register-based—selecting this option frees up the memory. The MAC IP core clears register-based statistic counters after the counters are read.

4-24 Statistics RegistersUG-01144

2014.12.15


Send Feedback


The counters collect statistics for the following frames:

• Good frame—error-free frames with a valid frame length.• Error frame—frames that contain errors or with an invalid frame length.• Invalid frame—frames that are not supported by the MAC IP core. It may or may not contain error

within the frame or have an invalid frame length. The MAC drops invalid frames.

Updating memory-based counters takes longer than updating register-based counters. If an event occurswhile the MAC IP core is updating the memory counters, the event might not be not captured. In general,the memory based counters will perform correctly as long as the packet sent or received is more than 64bytes. For transmit datapath, if padding is enabled, no issues should be seen. For receive datapath, whenthere are back-to-back packets of less than 64 bytes, some update events may be lost.

Table 4-13: Transmit and Receive Statistics Registers


0x0140 tx_stats_clr • Bit 0—Set this register to 1 to clearall statistics counters for thetransmit path.


RW1C 0x0

0x01C0 rx_stats_clr • Bit 0—Set this register to 1 to clearall statistics counters for the receivepath.


RW1C 0x0

0x0142tx_stats_framesOK 36-bit statistics counter that collects the

number of frames that are successfullyreceived or transmitted, includingcontrol frames.

RO 0x00x0143

0x01C2rx_stats_framesOK

0x01C3

0x0144tx_stats_framesErr 36-bit statistics counter that collects the

number of frames received ortransmitted with error, includingcontrol frames.

RO 0x00x0145

0x01C4rx_stats_framesErr

0x01C5

0x0146tx_stats_framesCRCErr 36-bit statistics counter that collects the

number of frames received ortransmitted with CRC error.

RO 0x00x0147

0x01C6rx_stats_framesCRCErr

0x01C7

UG-011442014.12.15 Statistics Registers 4-25


Send Feedback



0x0148tx_stats_octetsOK Statistics counter that collects the

number of data and padding bytesreceived or transmitted, including thebytes in control frames.

RO 0x00x0149

0x01C8rx_stats_octetsOK

0x01C9

0x014Atx_stats_pauseMACCtrl_Frames 36-bit statistics counter that collects the

number of valid pause frames receivedor transmitted.

RO 0x00x014B

0x01CA rx_stats_pauseMACCtrl_

Frames0x01CB

0x014Ctx_stats_ifErrors 36-bit statistics counter that collects the

number of frames received ortransmitted that are invalid and witherror.

RO 0x00x014D

0x01CCrx_stats_ifErrors

0x01CD

0x014Etx_stats_unicast_FramesOK 36-bit statistics counter that collects the

number of good unicast framesreceived or transmitted, excludingcontrol frames.

RO 0x00x014F

0x01CDrx_stats_unicast_FramesOK

0x01CF

0x0150tx_stats_unicast_FramesErr 36-bit statistics counter that collects the

number of unicast frames received ortransmitted with error, excludingcontrol frames.

RO 0x00x0151

0x01D0 rx_stats_unicast_

FramesErr0x01D1

0x0152tx_stats_multicast_FramesOK 36-bit statistics counter that collects the

number of good multicast framesreceived or transmitted, excludingcontrol frames.

RO 0x00x0153

0x01D2 rx_stats_multicast_

FramesOK0x01D3

0x0154tx_stats_multicast_FramesErr 36-bit statistics counter that collects the

number of multicast frames received ortransmitted with error, excludingcontrol frames.

RO 0x00x0155

0x01D4 rx_stats_multicast_

FramesErr0x01D5


2014.12.15


Send Feedback



0x0156tx_stats_broadcast_FramesOK 36-bit statistics counter that collects the

number of good broadcast framesreceived or transmitted, excludingcontrol frames.

RO 0x00x0157

0x01D6 rx_stats_broadcast_

FramesOK0x01D7

0x0158tx_stats_broadcast_FramesErr 36-bit statistics counter that collects the

number of broadcast frames receivedor transmitted with error, excludingcontrol frames.

RO 0x00x0159

0x01D8 rx_stats_broadcast_

FramesErr0x01D9

0x015Atx_stats_etherStatsOctets Statistics counter that collects the total

number of octets received ortransmitted. This count includes good,errored, and invalid frames.

RO 0x00x015B

0x01DArx_stats_etherStatsOctets

0x01DB

0x015Ctx_stats_etherStatsPkts 36-bit statistics counter that collects the

total number of good, errored, andinvalid frames received or transmitted.

RO 0x00x015D

0x01DCrx_stats_etherStatsPkts

0x01DD

0x015E tx_stats_

etherStatsUndersizePkts 36-bit statistics counter that collects thenumber of undersized transmit orreceive frames.

RO 0x00x015F

0x01DE rx_stats_etherStatsUnder-

sizePkts0x01DF

0x0160 tx_stats_

etherStatsOversizePkts36-bit statistics counter that collects thenumber of receive or transmit frameswhose length exceeds the maximumframe length specified.

RO 0x00x0161

0x01E0 rx_stats_etherStatsOver-

sizePkts0x01E1

0x0162 tx_stats_

etherStatsPkts64Octets

36-bit statistics counter that collects thenumber of 64-byte receive or transmitframes, including the CRC field butexcluding the preamble and SFD bytes.This count includes good, errored, andinvalid frames.

RO 0x00x0163

0x01E2rx_stats_

etherStatsPkts64Octets0x01E3



Send Feedback



0x0164 tx_stats_

etherStatsPkts65to127Octets

36-bit statistics counter that collects thenumber of receive or transmit framesbetween the length of 65 and 127 bytes,including the CRC field but excludingthe preamble and SFD bytes. Thiscount includes good, errored, andinvalid frames.

RO 0x0

0x0165

0x01E4rx_stats_

etherStatsPkts65to127Octe

ts

0x01E5

0x0166 tx_stats_


36-bit statistics counter that collects thenumber of receive or transmit framesbetween the length of 128 and 255bytes, including the CRC field butexcluding the preamble and SFD bytes.This count includes good, errored, andinvalid frames.

RO 0x0

0x0167

0x01E6rx_stats_

etherStatsPkts128to255Oct

ets

0x01E7

0x0168 tx_stats_


36-bit statistics counter that collects thenumber of receive or transmit framesbetween the length of 256 and 511bytes, including the CRC field butexcluding the preamble and SFD bytes.This count includes good, errored, andinvalid frames.

RO 0x0

0x0169

0x01E8rx_stats_

etherStatsPkts256to511Oct

ets

0x01E9

0x016A tx_stats_

etherStatsPkts512to1023Octet

s

36-bit statistics counter that collects thenumber of receive or transmit framesbetween the length of 512 and 1,023bytes, including the CRC field butexcluding the preamble and SFD bytes.This count includes good, errored, andinvalid frames.

RO 0x0

0x016B

0x01EA rx_stats_

etherStatsPkts512to1023Oc

tets0x01EB

0x016C tx_stats_

etherStatPkts1024to1518Octet

s

36-bit statistics counter that collects thenumber of receive or transmit framesbetween the length of 1,024 and 1,518bytes, including the CRC field butexcluding the preamble and SFD bytes.This count includes good, errored, andinvalid frames.

RO 0x0

0x016D

0x01EC rx_stats_

etherStatPkts1024to1518Oc

tets0x01ED

0x016E tx_stats_

etherStatsPkts1519toXOctets

36-bit statistics counter that collects thenumber of receive or transmit framesequal or more than the length of 1,519bytes, including the CRC field butexcluding the preamble and SFD bytes.This count includes good, errored, andinvalid frames.

RO 0x0

0x016F

0x01EErx_stats_

etherStatsPkts1519toXOcte

ts

0x01EF


2014.12.15


Send Feedback



0x0170tx_stats_etherStatsFragments

36-bit statistics counter that collects thetotal number of receive or transmitframes with length less than 64 bytesand CRC error. This count includeserrored and invalid frames.

RO 0x00x0171

0x01F0 rx_stats_etherStatsFrag-

ments0x01F1

0x0172tx_stats_etherStatsJabbers 36-bit statistics counter that collects the

number of oversized receive ortransmit frames with CRC error. Thiscount includes invalid frame types.

RO 0x00x0173

0x01F2 rx_stats_etherStatsJab-

bers0x01F3

0x0174tx_stats_etherStatsCRCErr

36-bit statistics counter that collects thenumber of receive or transmit frameswith CRC error, whose length isbetween 64 and the maximum framelength specified in the register. Thiscount includes errored and invalidframes.

RO 0x0

0x0175

0x01F4

rx_stats_etherStatsCRCErr0x01F5

0x0176 tx_stats_

unicastMACCtrlFrames 36-bit statistics counter that collects thenumber of valid unicast control framesreceived or transmitted.

RO 0x00x0177

0x01F6 rx_stats_unicastMACCtrl-

Frames0x01F7

0x0178 tx_stats_

multicastMACCtrlFrames 36-bit statistics counter that collects thenumber of valid multicast controlframes received or transmitted.

RO 0x00x0179

0x01F8 rx_stats_multicast-

MACCtrlFrames0x01F9

0x017A tx_stats_

broadcastMACCtrlFrames 36-bit statistics counter that collects thenumber of valid broadcast controlframes received or transmitted.

RO 0x00x017B

0x01FA rx_stats_broadcast-

MACCtrlFrames0x01FB

0x017Ctx_stats_PFCMACCtrlFrames 36-bit statistics counter that collects the

number of valid PFC frames receivedor transmitted.

RO 0x00x017D

0x01FCrx_stats_PFCMACCtrlFrames

0x01FD



Send Feedback


ECC RegistersThe ECC registers are available only when you turn on the Enable ECC on memory blocks parameter.

Table 4-14: ECC Registers


0x0240 ecc_status • Bit 0—a value of '1' indicates that anECC error was detected and corrected.Once set, the client must write a '1' tothis bit to clear it.

• Bit 1—a value of '1' indicates that anECC error was detected but notcorrected. Once set, the client mustwrite a '1' to this bit to clear it.


RW1C 0x0

0x0241 ecc_enable • Bit 0—specifies how detected andcorrected ECC errors are reported.

0: Reported by the ecc_status[0]register bit only.

1: Reported by the ecc_status[0]register bit and the ecc_err_det_corrsignal.

• Bit 1—specifies how detected anduncorrected ECC errors are reported.

0: Reported by the ecc_status[0]register bit only.

1: Reported by the ecc_status[0]register bit and the ecc_err_det_uncorr signal.


RW 0x0

4-30 ECC RegistersUG-01144

2014.12.15


Send Feedback


Interface Signals 52014.12.15


The LL Ethernet 10G MAC IP core interface signals.

Related InformationInterfaces on page 3-2Overview of the interfaces and signals.

Clock and Reset SignalsThe LL Ethernet 10G MAC IP core operates in multiple clock domains. You can use different sources todrive the clock and reset domains. You can also use the same clock source as specified in the descriptionof each signal.

Table 5-1: Clock and Reset Signals

Signal Direction Width Description

tx_312_5_clk In 1 312.5-MHz clock for the Avalon-ST transmit datainterface. Altera recommends that you use the sameclock source for this clock and rx_312_5_clk. Thisclock is available only when the Enable 10GBASE-Rregister mode parameter is turned off.

tx_156_25_clk In 1 This 156.25-MHz clock is present only when you chooseto maintain compatibility with the 64-bit Ethernet 10GMAC on the Avalon-ST transmit data interface orXGMII. Altera recommends that you use the same clocksource for this clock and tx_312_5_clk. This clockmust be synchronous to tx_312_5_clk. Their risingedges must align and must have 0 ppm and phase-shift.This clock is available only if the following conditionsare true:

• the Avalon-ST 32b<->64b or XGMII 32b<->64bXGMII adapter is synthesized.

• the Enable 10GBASE-R register mode parameter isturned off.





mailto:[email protected]?subject=Feedback%20on%20(UG-01144%202014.12.15)%20Interface%20Signals&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.





tx_xcvr_clk In 1 This 322.265625-MHz clock is available only when youturn on the Enable 10GBASE-R register modeparameter.

tx_rst_n (11) In 1 Active-low reset for the MAC TX datapath. The resetmust be held active for two or more slowest clockperiods (typically csr_clk) of the MAC. Assert thissignal when the csr_rst_n signal is asserted. You mustonly release this signal after all clocks are stable, andmust not be earlier than csr_rst_n. After it isdeasserted, wait for 150 ns or more to ensure that theMAC IP core has completed the reset internally.

rx_312_5_clk In 1 312.5-MHz clock for the Avalon-ST receive datainterface. Altera recommends that you use the sameclock source for this clock and tx_312_5_clk. Thisclock is available only when the Enable 10GBASE-Rregister mode parameter is turned off.

rx_156_25_clk In 1 This 156.25-MHz clock is present only when you chooseto maintain compatibility with the 64-bit Ethernet 10GMAC on the Avalon-ST receive data interface orXGMII. Altera recommends that you use the same clocksource for this clock and rx_312_5_clk. This clockmust be synchronous to rx_312_5_clk. Their risingedges must align and must have 0 ppm and phase-shift.This clock is available only if the following conditionsare true:

• the Avalon-ST 32b<->64b or XGMII SDR adapter issynthesized.

• the Enable 10GBASE-R register mode parameter isturned off.

rx_xcvr_clk In 1 This 322.265625-MHz clock is available only when youturn on the Enable 10GBASE-R register modeparameter.

(11) From Quartus II version 14.0 onwards, this signal has changed from asynchronous reset to synchronousreset. The tx_rst_n signal ties to the tx_312_5_clk or tx_xcvr_clk signal while the rx_rst_n signal ties tothe rx_312_5_clk or rx_xcvr_clk signal.

5-2 Clock and Reset SignalsUG-01144

2014.12.15

Altera Corporation Interface Signals

Send Feedback

mailto:[email protected]?subject=Feedback%20on%20Interface%20Signals%20(UG-01144%202014.12.15)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.


rx_rst_n (11) In 1 Active-low reset for the MAC RX datapath. The resetmust be held active for two or more slowest clockperiods (typically csr_clk) of the MAC. Assert thissignal when the csr_rst_n signal is asserted. You mustonly release this signal after all clocks are stable, andmust not be earlier than csr_rst_n. After it isdeasserted, wait for 150 ns or more to ensure that theMAC IP core has completed the reset internally.

csr_clk In 1 Clock for the Avalon-MM control and status interface.Altera recommends that this clock operates within 125 -156.25 MHz (regardless of whether you select register-based or memory-based statistics counter). A lowerfrequency might result in inaccurate statistics forregister-based statistics counters.

csr_rst_n In 1 Active-low asynchronous reset signal for the csr_clkdomain. This signal acts as a global reset for the MACIP core. When you assert this signal, you must alsoassert rx_rst_n and tx_rst_n together. This signalmust be asserted for at least two csr_clk clock periodsand must not be deasserted until all clocks are stable.

Speed Selection Signal

Table 5-2: Speed Selection Signal


speed_sel In 2 Connect this signal to the PHY to obtain the PHY'sspeed:

• 0x0 = 10 Gbps• 0x1 = 1 Gbps• 0x2 = 100 Mbps• 0x3 = 10 Mbps

Error Correction SignalsThe error correction signals are present only when you turn on the ECC option.

UG-011442014.12.15 Speed Selection Signal 5-3

Interface Signals Altera Corporation

Send Feedback


Table 5-3: Error Correction Signals


ecc_err_det_corr Out 1 The MAC IP core can indicate detected and correctedECC errors using the ecc_status register, or both theregister and this signal.

This signal indicates the state of the ecc_status[0]register bit when the ecc_enable[0] register bit is set to1. This signal is 0 when the ecc_enable[0] register bitis set to 1.

ecc_err_det_uncorr Out 1 The MAC IP core can indicate detected anduncorrected ECC errors using the ecc_status register,or both the register and this signal.

This signal indicates the state of the ecc_status[1]register bit when the ecc_enable[1] register bit is set to1. This signal is 0 when the ecc_enable[1] register bitis set to 1.

Unidirectional SignalsThe unidirectional signals are present only when you turn on the Unidirectional feature option.

Table 5-4: Unidirectional Signals


unidirectional_en Out 1 When asserted, this signal indicates the state of the tx_unidir_control register bit 0.

unidirectional_

remote_fault_dis

Out 1 When asserted, this signal indicates the state of the tx_unidir_control register bit 1.

Avalon-MM Programming Signals

Table 5-5: Avalon-MM Programming Signals


csr_address[] In 10 Use this bus to specify the register address to read fromor write to.

csr_read In 1 Assert this signal to request a read.

csr_readdata[] Out 32 Data read from the specified register.

5-4 Unidirectional SignalsUG-01144

2014.12.15


Send Feedback



csr_write In 1 Assert this signal to request a write.

csr_writedata[] In 32 Data to be written to the specified register.

csr_waitrequest Out 1 When asserted, this signal indicates that the MAC IPcore is busy and not ready to accept any read or writerequests.

• During read operations, the csr_readdata[] is notvalid until csr_waitrequest is deasserted.

• During write operations, the data in csr_writedata[] is not written until csr_waitrequestis deasserted.

• The reset value for this signal is 1'b1. However, theuser logic should not rely on this default resetbehavior to operate. This is to prevent violating theAvalon-MM specification, where the default can be 0or 1.

Avalon-ST Data Interfaces

Avalon-ST Transmit Data Interface Signals

Table 5-6: Avalon-ST Transmit Data Interface Signals


avalon_st_tx_startof-

packet

In 1 Assert this signal to mark the beginning of the transmitdata on the Avalon-ST interface.

avalon_st_tx_

endofpacket

In 1 Assert this signal to mark the end of the transmit dataon the Avalon-ST interface.

avalon_st_tx_valid In 1 Assert this signal to indicate that avalon_st_tx_data[] and other signals on this interface are valid.

avalon_st_tx_ready Out 1 When asserted, this signal indicates that the MAC IPcore is ready to accept data. The reset value for thissignal is 1'b1. However, the user logic should not rely onthis default reset behavior to operate.

avalon_st_tx_error In 1 Assert this signal to indicate the current transmit packetcontains errors.

avalon_st_tx_data[] In 32 Carries the transmit data from the client.

UG-011442014.12.15 Avalon-ST Data Interfaces 5-5


Send Feedback



avalon_st_tx_empty[] In 2 Use this signal to specify the number of bytes that areempty (not used) during cycles that contain the end of apacket.

0x0: All bytes are valid.

0x1: The last byte is invalid.

0x2: The last two bytes are invalid.

0x3: The last three bytes are invalid.

Avalon-ST Receive Data Interface Signals

Table 5-7: Avalon-ST Receive Data Interface Signals


avalon_st_rx_startof-

packet

Out 1 When asserted, this signal marks the beginning of thereceive data on the Avalon-ST interface.

avalon_st_rx_

endofpacket

Out 1 When asserted, this signal marks the end of the receivedata on the Avalon-ST interface.

avalon_st_rx_valid Out 1 When asserted, this signal indicates that avalon_st_rx_data[]and other signals on this interface are valid.

avalon_st_rx_ready In 1 Assert this signal when the client is ready to accept data.

avalon_st_rx_error[] Out 6 When set to 1, the respective bits indicate an error type:

• Bit 0—PHY error. For 10 Gbps, the data on xgmii_rx_data contains a control error character (FE). For10 Mbps,100 Mbps,1 Gbps, gmii_rx_err or mii_rx_err is asserted.

• Bit 1—CRC error. The computed CRC value differsfrom the received CRC.

• Bit 2—Undersized frame. The receive frame length isless than 64 bytes.

• Bit 3—Oversized frame. The receive frame length ismore than MAX_FRAME_SIZE.

• Bit 4—Payload length error. The actual framepayload length is different from the value in thelength/type field.

• Bit 5—Overflow error. The receive FIFO buffer is fullwhile it is still receiving data from the MAC IP core.

avalon_st_rx_data[] Out 32 Carries the receive data to the client.

5-6 Avalon-ST Receive Data Interface SignalsUG-01144

2014.12.15


Send Feedback



avalon_st_rx_empty[] Out 2 Contains the number of bytes that are empty (not used)during cycles that contain the end of a packet.

Avalon-ST Flow Control Signals

Table 5-8: Avalon-ST Flow Control Signals


avalon_st_pause_

data[]

In 2 Set this signal to the following values to trigger thecorresponding actions.

• 0x0: Stops pause frame generation.• 0x1: Generates an XON pause frame.• 0x2: Generates an XOFF pause frame. The MAC IP

core sets the pause quanta field in the pause frame tothe value in the tx_pauseframe_quanta register.

• 0x3: Reserved.

Note: This signal only takes effect if tx_pauseframe_enable[2:1] is 00 (default)

avalon_st_tx_pause_

length_valid

In 1 This signal is present in the MAC TX only variation.

Assert this signal to request the MAC IP core to suspenddata transmission. When you assert this signal, ensurethat a valid pause quanta is available on the avalon_st_tx_pause_length_data bus.

avalon_st_tx_pause_

length_data[]

In 16 This signal is present only in the MAC TX onlyvariation.

Use this bus to specify the pause quanta in unit ofquanta, where 1 unit = 512 bits time.

UG-011442014.12.15 Avalon-ST Flow Control Signals 5-7


Send Feedback



avalon_st_tx_pfc_gen_

data[]

In n

(4–16)

n = 2 x Number of PFC queues parameter.

Each pair of bits is associated with a priority queue. Bits0 and 1 are for priority queue 0, bits 2 and 3 are forpriority queue 1, and so forth. Set the respective pair ofbits to the following values to trigger the specifiedactions for the corresponding priority queue.

• 0x0: Stops pause frame generation for thecorresponding queue.

• 0x1: Generates an XON pause frame for thecorresponding queue.

• 0x2: Generates an XOFF pause frame for thecorresponding queue. The MAC IP core sets thepause quanta field in the pause frame to the value inthe tx_pauseframe_quanta register.

• 0x3: Reserved.

avalon_st_rx_pfc_

pause_data[]

Out n

(2–8)

n = Number of PFC queues parameter.

When the MAC RX receives a pause frame, it asserts bitn of this signal when the pause quanta for the nth queueis valid (Pause Quanta Enable [n] = 1) and greater than0. For each quanta unit, the MAC RX asserts bit n foreight clock cycle.

The MAC RX deasserts bit n of this signal when thepause quanta for the nth queue is valid (Pause QuantaEnable [n] = 1) and equal to 0. The MAC RX alsodeasserts bit n when the timer expires.

avalon_st_rx_pause_

length_valid

Out 1 This signal is present in the MAC RX only variation.

The MAC IP core asserts this signal to request its linkpartner to suspend data transmission. When asserted, avalid pause quanta is available on the avalon_st_rx_pause_length_data bus.

avalon_st_rx_pause_

length_data[]

Out 16 This signal is present only in the MAC RX onlyvariation.

Specifies the pause quanta in unit of quanta, where 1unit = 512 bits time.

5-8 Avalon-ST Flow Control SignalsUG-01144

2014.12.15


Send Feedback


Avalon-ST Status Interface

Avalon-ST Transmit Status Signals

Table 5-9: Avalon-ST Transmit Status Signals


avalon_st_txstatus_

valid

Out 1 When asserted, this signal qualifies avalon_st_txstatus_data[] and avalon_st_txstatus_error[].

avalon_st_txstatus_

data[]

Out 40 Contains information about the transmit frame.

• Bits 0 to 15: Payload length.• Bits 16 to 31: Packet length.• Bit 32: When set to 1, indicates a stacked VLAN

frame.• Bit 33: When set to 1, indicates a VLAN frame.• Bit 34: When set to 1, indicates a control frame.• Bit 35: When set to 1, indicates a pause frame.• Bit 36: When set to 1, indicates a broadcast frame.• Bit 37: When set to 1, indicates a multicast frame.• Bit 38: When set to 1, indicates a unicast frame.• Bit 39: When set to 1, indicates a PFC frame.

avalon_st_txstatus_

error[]

Out 7 When set to 1, the respective bit indicates the followingerror type in the receive frame.

• Bit 0: Undersized frame.• Bit 1: Oversized frame.• Bit 2: Payload length error.• Bit 3: Unused.• Bit 4: Underflow.• Bit 5: Client error.• Bit 6: Unused.

The error status is invalid when an overflow occurs.

avalon_st_tx_pfc_

status_valid

Out 1 When asserted, this signal qualifies avalon_st_tx_pfc_status_data[].

UG-011442014.12.15 Avalon-ST Status Interface 5-9


Send Feedback



avalon_st_tx_pfc_

status_data[]

Out n

(4 - 16)

n = 2 x Number of PFC queues parameter

When set to 1, the respective bit indicates the followingflow control request.

• Bit 0: XON request is transmitted for priority queue0.

• Bit 1: XOFF request is transmitted for priority queue0.





• .. and so forth.

Avalon-ST Receive Status Signals

Table 5-10: Avalon-ST Receive Status Signals


avalon_st_rxstatus_

valid

Out 1 When asserted, this signal qualifies avalon_st_txstatus_data[] and avalon_st_txstatus_error[].The MAC IP core asserts this signal in the same clockcycle avalon_st_rx_endofpacket is asserted.

avalon_st_rxstatus_

data[]

Out 40 Contains information about the transmit frame.

• Bits 0 to 15: Payload length.• Bits 16 to 31: Packet length.• Bit 32: When set to 1, indicates a stacked VLAN

frame.• Bit 33: When set to 1, indicates a VLAN frame.• Bit 34: When set to 1, indicates a control frame.• Bit 35: When set to 1, indicates a pause frame.• Bit 36: When set to 1, indicates a broadcast frame.• Bit 37: When set to 1, indicates a multicast frame.• Bit 38: When set to 1, indicates a unicast frame.• Bit 39: When set to 1, indicates a PFC frame.

5-10 Avalon-ST Receive Status SignalsUG-01144

2014.12.15


Send Feedback



avalon_st_rxstatus_

error[]

Out 7 When set to 1, the respective bit indicates the followingerror type in the receive frame.

• Bit 0: Undersized frame.• Bit 1: Oversized frame.• Bit 2: Payload length error.• Bit 3: CRC error.• Bit 4: Unused.• Bit 5: Unused.• Bit 6: PHY error.

The IP core presents the error status on this bus in thesame clock cycle it asserts avalon_st_rxstatus_valid.The error status is invalid when an overflow occurs.

avalon_st_rx_pfc_

status_valid

Out 1 When asserted, this signal qualifies avalon_st_rx_pfc_status_data[].

avalon_st_rx_pfc_

status_data[]

Out n

(4 - 16)

n = 2 x Number of PFC queues parameter

When set to 1, the respective bit indicates the followingflow control request.







• .. and so forth.

UG-011442014.12.15 Avalon-ST Receive Status Signals 5-11


Send Feedback


PHY-side Interfaces

XGMII Transmit Signals

Table 5-11: XGMII Transmit Signals


xgmii_tx_data[]

Out 32 This signal is available only when the Enable 10GBASE-R register mode parameter is turned off. Do not use thissignal together with the xgmii_tx[] signals.

4-lane data bus. Lane 0 starts from the least significantbit.

• Lane 0: xgmii_tx_data[7:0]• Lane 1: xgmii_tx_data[15:8]• Lane 2: xgmii_tx_data[23:16]• Lane 3: xgmii_tx_data[31:24]

Out 64 This signal is available only when you turn on theEnable 10GBASE-R register mode parameter. Do notuse this signal together with the xgmii_tx[] signals.

8-lane SDR XGMII transmit data. This signal connectsdirectly to the NativePHY IP core.

• Lane 0: xgmii_tx_data[7:0]• Lane 1: xgmii_tx_data[15:8]• Lane 2: xgmii_tx_data[23:16]• Lane 3: xgmii_tx_data[31:24]• Lane 4: xgmii_tx_data[39:32]• Lane 5: xgmii_tx_data[47:40]• Lane 6: xgmii_tx_data[55:48]• Lane 7: xgmii_tx_data[63:56]

5-12 PHY-side InterfacesUG-01144

2014.12.15


Send Feedback



xgmii_tx_control[]

Out 4 This signal is available only when the Enable 10GBASE-R register mode parameter is turned off. Do not use thissignal together with the xgmii_tx[] signals.

Control bits for each lane in xgmii_tx_data[].

• Lane 0: xgmii_tx_control[0]• Lane 1: xgmii_tx_control[1]• Lane 2: xgmii_tx_control[2]• Lane 3: xgmii_tx_control[3]

Out 8 This signal is available only when you turn on theEnable 10GBASE-R register mode parameter. Do notuse this signal together with the xgmii_tx[] signals.

8-lane SDR XGMII transmit control. This signalconnects directly to the NativePHY IP core.

• Lane 0: xgmii_tx_control[0]• Lane 1: xgmii_tx_control[1]• Lane 2: xgmii_tx_control[2]• Lane 3: xgmii_tx_control[3]• Lane 4: xgmii_tx_control[4]• Lane 5: xgmii_tx_control[5]• Lane 6: xgmii_tx_control[6]• Lane 7: xgmii_tx_control[7]

UG-011442014.12.15 XGMII Transmit Signals 5-13


Send Feedback



xgmii_tx[] Out 72 This signal is available only when you turn on the Use64-bit Ethernet 10G MAC XGMII interface parameter.Do not use this signal together with the xgmii_tx_data[] and xgmii_tx_control[] signals.

8-lane SDR XGMII transmit data and control bus. Eachlane contains 8 data plus 1 control bits. The signalmapping is compatible with the 64b MAC.

• Lane 0 data: xgmii_tx[7:0]• Lane 0 control: xgmii_tx[8]• Lane 1 data: xgmii_tx[16:9]• Lane 1 control: xgmii_tx[17]• Lane 2 data: xgmii_tx[25:18]• Lane 2 control: xgmii_tx[26]• Lane 3 data: xgmii_tx[34:27]• Lane 3 control: xgmii_tx[35]• Lane 4 data: xgmii_tx[43:36]• Lane 4 control: xgmii_tx[44]• Lane 5 data: xgmii_tx[52:45]• Lane 5 control: xgmii_tx[53]• Lane 6 data: xgmii_tx[61:54]• Lane 6 control: xgmii_tx[62]• Lane 7 data: xgmii_tx[70:63]• Lane 7 control: xgmii_tx[71]

xgmii_tx_valid Out 1 This signal is available only when you turn on theEnable 10GBASE-R register mode parameter. Thefollowing values indicate the validity of the data andcontrol buses:

• 0: Invalid• 1: Valid

link_fault_status_

xgmii_tx_data[]

In 2 This signal is present in the MAC TX only variation.Connect this signal to the corresponding RX client logicto handle the local and remote faults. The followingvalues indicate the link fault status:

• 0x0: No link fault• 0x1: Local fault• 0x2: Remote fault

5-14 XGMII Transmit SignalsUG-01144

2014.12.15


Send Feedback


XGMII Receive Signals

Table 5-12: XGMII Receive Signals


xgmii_rx_data[]

In 32 This signal is available only when the Enable10GBASE-R register mode parameter is turned off. Donot use this signal together with the xgmii_rx[] signals.

4-lane data bus. Lane 0 starts from the least significantbit.

• Lane 0: xgmii_rx_data[7:0]• Lane 1: xgmii_rx_data[15:8]• Lane 2: xgmii_rx_data[23:16]• Lane 3: xgmii_rx_data[31:24]

In 64 This signal is available only when you turn on theEnable 10GBASE-R register mode parameter. Do notuse this signal together with the xgmii_rx[] signals.

8-lane SDR XGMII receive data. This signal connectsdirectly to the NativePHY IP core.

• Lane 0: xgmii_rx_data[7:0]• Lane 1: xgmii_rx_data[15:8]• Lane 2: xgmii_rx_data[23:16]• Lane 3: xgmii_rx_data[31:24]• Lane 4: xgmii_rx_data[39:32]• Lane 5: xgmii_rx_data[47:40]• Lane 6: xgmii_rx_data[55:48]• Lane 7: xgmii_rx_data[63:56]

UG-011442014.12.15 XGMII Receive Signals 5-15


Send Feedback



xgmii_rx_control[]

In 4 This signal is available only when the Enable10GBASE-R register mode parameter is turned off. Donot use this signal together with the xgmii_rx[] signals.

Control bits for each lane in xgmii_rx_data[].

• Lane 0: xgmii_rx_control[0]• Lane 1: xgmii_rx_control[1]• Lane 2: xgmii_rx_control[2]• Lane 3: xgmii_rx_control[3]

In 8 This signal is available only when you turn on theEnable 10GBASE-R register mode parameter. Do notuse this signal together with the xgmii_rx[] signals.

8-lane SDR XGMII receive control. This signal connectsdirectly to the NativePHY IP core.

• Lane 0: xgmii_rx_control[0]• Lane 1: xgmii_rx_control[1]• Lane 2: xgmii_rx_control[2]• Lane 3: xgmii_rx_control[3]• Lane 4: xgmii_rx_control[4]• Lane 5: xgmii_rx_control[5]• Lane 6: xgmii_rx_control[6]• Lane 7: xgmii_rx_control[7]

5-16 XGMII Receive SignalsUG-01144

2014.12.15


Send Feedback



xgmii_rx[] In 72 This signal is available only when you turn on the Use64-bit Ethernet 10G MAC XGMII interface parameter.Do not use this signal together with the xgmii_rx_data[] and xgmii_rx_control[] signals.

8-lane SDR XGMII receive data and control bus. Eachlane contains 8 data plus 1 control bits. The signalmapping is compatible with the 64-bit MAC.

• Lane 0 data: xgmii_rx[7:0]• Lane 0 control: xgmii_rx[8]• Lane 1 data: xgmii_rx[16:9]• Lane 1 control: xgmii_rx[17]• Lane 2 data: xgmii_rx[25:18]• Lane 2 control: xgmii_rx[26]• Lane 3 data: xgmii_rx[34:27]• Lane 3 control: xgmii_rx[35]• Lane 4 data: xgmii_rx[43:36]• Lane 4 control: xgmii_rx[44]• Lane 5 data: xgmii_rx[52:45]• Lane 5 control: xgmii_rx[53]• Lane 6 data: xgmii_rx[61:54]• Lane 6 control: xgmii_rx[62]• Lane 7 data: xgmii_rx[70:63]• Lane 7 control: xgmii_rx[71]

xgmii_rx_valid In 1 This signal is present when you turn on the Enable10GBASE-R register mode parameter. The followingvalues indicate the validity of the data and control buses:

• 0 = Invalid• 1 = Valid

link_fault_status_

xgmii_rx_data[]

Out 2 The following values indicate the link fault status:

• 0x0 = No link fault• 0x1 = Local fault• 0x2 = Remote fault

GMII Transmit Signals

Table 5-13: GMII Transmit Signals


gmii_tx_clk In 1 125-MHz clock for the GMII transmit.

gmii_tx_d [] Out 8 Transmit data bus.

UG-011442014.12.15 GMII Transmit Signals 5-17


Send Feedback



gmii_tx_en Out 1 When asserted, indicates the transmit data is valid.

gmii_tx_err Out 1 When asserted, indicates the transmit data containserror.

GMII Receive Signals

Table 5-14: GMII Receive Signals


gmii_rx_clk In 1 125-MHz clock for the GMII receive.

gmii_rx_d[] In 8 Receive data bus.

gmii_rx_dv In 1 When asserted, indicates the receive data is valid.

gmii_rx_err In 1 When asserted, indicates the receive data contains error.

MII Transmit Signals

Table 5-15: MII Transmit Signals


tx_clkena In 1 Clock enable from the PHY IP. This clock effectivelydivides gmii_tx_clk to 25 MHz for 100 Mbps and 2.5MHz for 10 Mbps.

tx_clkena_half_rate In 1 Clock enable from the PHY IP. This clock effectivelydivides gmii_tx_clk to 12.5 MHz for 100 Mbps and1.25 MHz for 10 Mbps.

mii_tx_d[] Out 4 Transmit data bus.

mii_tx_en Out 1 When asserted, indicates the transmit data is valid.

mii_tx_err Out 1 When asserted, indicates the transmit data containserror.

MII Receive Signals

Table 5-16: MII Receive Signals


rx_clkena In 1 Clock enable from the PHY IP for 100 Mbps and 10Mbps operations. This clock effectively divides gmii_rx_clk to 25 MHz for 100 Mbps and 2.5 MHz for 10Mbps.

5-18 GMII Receive SignalsUG-01144

2014.12.15


Send Feedback



rx_clkena_half_rate In 1 Clock enable from the PHY IP for 100 Mbps and 10Mbps operations. This clock effectively runs at half therate of rx_clkena and divides gmii_rx_clk to 12.5MHz for 100 Mbps and 1.25 MHz for 10 Mbps. Therising edges of this signal and rx_clkena must align.

mii_rx_d[] Out 4 Receive data bus.

mii_rx_dv Out 1 When asserted, indicates the receive data is valid.

mii_rx_err Out 1 When asserted, indicates the receive data contains error.

1588v2 Interfaces

IEEE 1588v2 Egress Transmit Signals

Table 5-17: IEEE 1588v2 Egress Transmit Signals

Signal Direction

Width Description

tx_egress_timestamp_request_

valid

In 1 Assert this signal to request for a timestamp forthe transmit frame. This signal must be assertedin the same clock cycle avalon_st_tx_startofpacket is asserted.

tx_egress_timestamp_request_

fingerprint[]

In n n = value of the Timestamp fingerprint widthparameter.

Use this bus to specify the fingerprint of thetransmit frame that you are requesting atimestamp for. This bus must carry a validfingerprint at the same time tx_egress_timestamp_request_valid is asserted.

The purpose of the fingerprint is to associatethe timestamp with the packet. Thus, it can bethe sequence ID field from the PTP packet orsome other unique field of the packet, tovalidate both the fingerprint and timestampcollected from the CPU.

tx_egress_timestamp_96b_valid Out 1 When asserted, this signal qualifies thetimestamp on tx_egress_timestamp_96b_data[] for the transmit frame whosefingerprint is specified by tx_egress_timestamp_96b_fingerprint[] .

UG-011442014.12.15 1588v2 Interfaces 5-19


Send Feedback


Signal Direction

Width Description

tx_egress_timestamp_96b_data[] Out 96 Carries the 96-bit egress timestamp in thefollowing format:

• Bits 48 to 95: 48-bit seconds field• Bits 16 to 47: 32-bit nanoseconds field• Bits 0 to 15: 16-bit fractional nanoseconds

field

This is required for noting the timestamp ToDwhich is of 80-bit (consisting of seconds andnanoseconds) in the respective field of the PTPpacket. The remaining 16-bit fractionalnanoseconds value, if used, is for updating theCF (Correction Field) of the PTP packet.

tx_egress_timestamp_96b_

fingerprint[]

Out n n = value of the Timestamp fingerprint widthparameter.

The fingerprint of the transmit frame, which isreceived on tx_egress_timestamp_request_data[]. This fingerprint specifies the transmitframe the egress timestamp on tx_egress_timestamp_96b_data[] is for.

tx_egress_timestamp_64b_valid Out 1 When asserted, this signal qualifies thetimestamp on tx_egress_timestamp_64b_data[] for the transmit frame whosefingerprint is specified by tx_egress_timestamp_64b_fingerprint[].

tx_egress_timestamp_64b_data[] Out 64 Carries the 64-bit egress timestamp in thefollowing format:

• Bits 16 to 63: 48-bit nanoseconds field• Bits 0 to 15: 16-bit fractional nanoseconds

field

The 64-bit timestamp is required to update theCF in the PTP header. Updating the CF isfundamental to the transparent clock operation.

tx_egress_timestamp_64b_

fingerprint[]

Out n n = value of the Timestamp fingerprint widthparameter.

The fingerprint of the transmit frame, which isreceived on tx_egress_timestamp_request_data[]. This fingerprint specifies the transmitframe the egress timestamp on tx_egress_timestamp_64b_data[] signal is for.

5-20 IEEE 1588v2 Egress Transmit SignalsUG-01144

2014.12.15


Send Feedback


Signal Direction

Width Description

tx_time_of_day_96b_10g_data

(for 10 Gbps)

In 96

Carries the time of day (ToD) from an externalToD module to the MAC IP core in thefollowing format:

• Bits 48 to 95: 48-bit seconds field• Bits 16 to 47: 32-bit nanoseconds field• Bits 0 to 15: 16-bit fractional nanoseconds

field

This is required for noting the timestamp ToDwhich is of 80-bit, consisting of seconds andnanoseconds, in the respective field of the PTPpacket. The remaining 16-bit fractionalnanoseconds value, if used, is for updating theCF of the PTP packet.


(for 10 Mbps, 100 Mbps, and 1 Gbps)


(for 10 Gbps)

In 64

Carries the ToD from an external ToD moduleto the MAC IP core in the following format:

• Bits 16 to 63: 48-bit nanoseconds field• Bits 0 to 15: 16-bit fractional nanoseconds

field

The 64-bit timestamp is required to update theCF in the PTP header. Updating the CF isfundamental to the transparent clock operation.



tx_path_delay_10g_data

(for 10 Gbps)

In

16 Connect this bus to the Altera PHY IP. This buscarries the path delay, which is measuredbetween the physical network and the PHY sideof the MAC IP Core (XGMII, GMII, or MII).The MAC IP core uses this value whengenerating the egress timestamp to account forthe delay. The path delay is in the followingformat:

• Bits 0 to 9: Fractional number of clock cycle• Bits 10 to 15/21: Number of clock cycle

tx_path_delay_1g_data


22

Table 5-18: IEEE 1588v2 Egress Transmit Signals—1-step Mode

These signals apply to 1-step operation mode only.Signal Directi

onWidth Description

tx_etstamp_ins_ctrl_timestamp_

insert

In 1 Assert this signal to insert egress timestampinto the associated frame. Assert this signal inthe same clock cycle avalon_st_tx_startofpacketis asserted.

UG-011442014.12.15 IEEE 1588v2 Egress Transmit Signals 5-21


Send Feedback


Signal Direction

Width Description

tx_etstamp_ins_ctrl_timestamp_

format

In 1 Use this signal to specify the format of thetimestamp to be inserted.

• 0: 1588v2 format (48-bits second field + 32-bits nanosecond field + 16-bits correctionfield for fractional nanosecond). Requiredoffset location of timestamp andcorrectionfield.

• 1: 1588v1 format (32-bits second field + 32-bits nanosecond field). Required offsetlocation of timestamp.

Assert this signal in the same clock cycle as thestart of packet (avalon_st_tx_startofpacket isasserted).

tx_etstamp_ins_ctrl_residence_

time_update

In 1 Assert this signal to add residence time (egresstimestamp –ingress timestamp) into correctionfield of PTP frame. Required offset location ofcorrection field. Assert this signal in the sameclock cycle as the start of packet (avalon_st_tx_startofpacket is asserted).

tx_etstamp_ins_ctrl_ingress_

timestamp_96b[]

In 96 96-bit format of ingress timestamp.(48 bitssecond + 32 bits nanosecond + 16 bitsfractional nanosecond).Assert this signal in thesame clock cycle as the start of packet (avalon_st_tx_startofpacket is asserted).

tx_etstamp_ins_ctrl_ingress_

timestamp_64b[]

In 64 64-bit format of ingress timestamp. (48-bitsnanosecond + 16-bits fractional nanosecond).Assert this signal in the same clock cycle as thestart of packet (avalon_st_tx_startofpacket isasserted).

tx_etstamp_ins_ctrl_residence_

time_calc_format

In 1 Format of timestamp to be used for residencetime calculation. 0: 96-bits (96-bits egresstimestamp - 96-bits ingress timestamp). 1: 64-bits (64-bits egress timestamp - 64-bits ingresstimestamp). Assert this signal in the same clockcycle as the start of packet (avalon_st_tx_startofpacket is asserted).

tx_etstamp_ins_ctrl_checksum_

zero

In 1 Assert this signal to set the checksum field ofUDP/IPv4 to zero. Required offset location ofchecksum field. Assert this signal in the sameclock cycle as the start of packet (avalon_st_tx_startofpacket is asserted).

5-22 IEEE 1588v2 Egress Transmit SignalsUG-01144

2014.12.15


Send Feedback


Signal Direction

Width Description

tx_etstamp_ins_ctrl_checksum_

correct

In 1 Assert this signal to correct UDP/IPv6 packetchecksum, by updating the checksumcorrection, which is specified by checksumcorrection offset. Required offset location ofchecksum correction. Assert this signal in thesame clock cycle as the start of packet (avalon_st_tx_startofpacket is asserted).

tx_etstamp_ins_ctrl_offset_

timestamp[]

In 16 The location of the timestamp field, relative tothe first byte of the packet. Assert this signal inthe same clock cycle as the start of packet(avalon_st_tx_startofpacket is asserted).


correction_field[]

In 16 The location of the correction field, relative tothe first byte of the packet. Assert this signal inthe same clock cycle as the start of packet(avalon_st_tx_startofpacket is asserted).


checksum_field[]

In 16 The location of the checksum field, relative tothe first byte of the packet. Assert this signal inthe same clock cycle as the start of packet(avalon_st_tx_startofpacket is asserted).


checksum_correction[]

In 16 The location of the checksum correction field,relative to the first byte of the packet. Assertthis signal in the same clock cycle as the start ofpacket (avalon_st_tx_startofpacket is asserted).

IEEE 1588v2 Ingress Receive Signals

Table 5-19: IEEE 1588v2 Ingress Receive Signals


rx_ingress_timestamp_96b_

valid

Out 1 When asserted, this signal qualifies the timestampon rx_ingress_timestamp_96b_data[]. TheMAC IP core asserts this signal in the same clockcycle it asserts avalon_st_rx_startofpacket.

UG-011442014.12.15 IEEE 1588v2 Ingress Receive Signals 5-23


Send Feedback




data[]

Out 96 Carries the 96-bit ingress timestamp in thefollowing format:

• Bits 48 to 95: 48-bit seconds field• Bits 16 to 47: 32-bit nanoseconds field• Bits 0 to 15: 16-bit fractional nanoseconds field

The 96-bit timestamp is usually for noting thecomplete ToD and is useful in ordinary clock andboundary clock devices. The transparent clocktypically uses 64-bit timestamp.


valid

Out 1 When asserted, this signal qualifies the timestampon rx_ingress_timestamp_64b_data[]. TheMAC IP core asserts this signal in the same clockcycle it asserts avalon_st_rx_startofpacket.


data[]

Out 64 Carries the 64-bit ingress timestamp in thefollowing format:

• Bits 16 to 63: 48-bit nanoseconds field• Bits 0 to 15: 16-bit fractional nanoseconds field

This timestamp is used in transparent clockdevices.

rx_time_of_day_96b_10g_

data

(for 10 Gbps) In 96

Carries the time of day (ToD) from an externalToD module to the MAC IP core in the followingformat:

• Bits 48 to 95: 48-bit seconds field• Bits 16 to 47: 32-bit nanoseconds field• Bits 0 to 15: 16-bit fractional nanoseconds field

rx_time_of_day_96b_1g_data

(for 10 Mbps and 100 Mbps)

rx_time_of_day_64b_10g_

data

(for 10 Gbps) In 64

Carries the ToD from an external ToD module theMAC IP core in the following format:

• Bits 16 to 63: 48-bit nanoseconds field• Bits 0 to 15: 16-bit fractional nanoseconds fieldrx_time_of_day_64b_1g_data


5-24 IEEE 1588v2 Ingress Receive SignalsUG-01144

2014.12.15


Send Feedback



rx_path_delay_10g_data

(for 10 Gbps)

In

16 Connect this bus to the Altera PHY IP. This buscarries the path delay (residence time), measuredbetween the physical network and the PHY side ofthe MAC IP Core (XGMII, GMII, or MII). TheMAC IP core uses this value when generating theingress timestamp to account for the delay. Thepath delay is in the following format:

• Bits 0 to 9: Fractional number of clock cycle• Bits 10 to 15/21: Number of clock cycle

rx_path_delay_1g_data


22

UG-011442014.12.15 IEEE 1588v2 Ingress Receive Signals 5-25


Send Feedback


Additional Information A2014.12.15


This section provides additional information about the document and Altera.

Low Latency Ethernet 10G MAC User Guide Document Revision HistoryDate Version Changes

December2014

2014.12.15 • Updated the Performance and Resource Utilization table—improvedthe resource utilization for IEEE 1588v2 feature.

• Added a new feature—10GBASE-R register mode:

• Added a new parameter—Enable 10GBASE-R register mode.• Added new signals—tx_xcvr_clk, rx_xcvr_clk, xgmii_tx_

valid, xgmii_rx_valid.• Added new parameter options for Time of Day Format.• Added a new table in Frame Type Checking on page 3-14 to describe

the MAC behavior for different frame types.• Added a new table—Register Access Type Convention—to describe

the access type for the IP core registers.• Added a new section about Timing Constraints on page 2-11.• Revised the receive timestamp registers word offset to start from

0x0120 to 0x012C.• Added a recommendation for the csr_rst_n signal—deassert the

csr_rst_n signal at least once after tx_clk and rx_clk are stable.• Revised the number of bits for fractional number of clock cycle for

rx_path_delay_10g_data and rx_path_delay_1g_data signals toBit [9:0]: Fractional number of clock cycle, Bit [21/15:10]:Number ofclock cycle.

• Updated the signals description for:

• tx_egress_timestamp_request_fingerprint[]

• tx_egress_timestamp_96b_data[]

• tx_egress_timestamp_64b_data[]

• tx_time_of_day_96b_1g_data

• tx_time_of_day_64b_1g_data





mailto:[email protected]?subject=Feedback%20on%20(UG-01144%202014.12.15)%20Additional%20Information&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.




Date Version Changes

June 2014 2014.06.30 • Improved the performance and resource utilization.• Added a new feature—Unidirectional Ethernet.

• Added a new parameter—Enable Unidirectional feature.• Added Unidirectional registers and signals.

• Added information about PMA analog and digital delay for IEEE1588v2 MAC registers.

• Edited the bit description of avalon_st_rxstatus_error[] signal.• Added more information about the avalon_st_pause_data[0] bit

signal to indicate that the transmission of XON pause frames onlytrigger for one time after XOFF pause frames regardless of how longthe avalon_st_pause_data[0] is asserted.

• Updated the statistics registers description.• Edited the bit description of tx_underflow_counter0, tx_

underflow_counter1, rx_pktovrflow_etherStatsDropE-

vents,rx_pktovrflow_error signals.• Edited the bit description of csr_clk signal to state that the

recommended clock frequency for this signal is 125 Mhz–156.25 Mhzregardless of whether you select register-based or memory-basedstatistics counter.

• Updated the tx_rst_n and rx_rst_n signals description to reflect thechange from asynchronous reset to synchronous reset.

• Updated the csr_waitrequest signal description.

December2013

2013.12.02 Initial release

A-2 Low Latency Ethernet 10G MAC User Guide Document Revision HistoryUG-01144

2014.12.15

Altera Corporation Additional Information

Send Feedback

mailto:[email protected]?subject=Feedback%20on%20Additional%20Information%20(UG-01144%202014.12.15)&body=We%20appreciate%20your%20feedback.%20In%20your%20comments,%20also%20specify%20the%20page%20number%20or%20paragraph.%20Thank%20you.

Documents

Low Latency Ethernet 10G MAC User Guide · Low Latency Ethernet 10G MAC User Guide Last updated for Altera Complete Design Suite: 14.1 Subscribe Send Feedback UG-01144 2014.12.15