76. Ethernet (ETH): gigabit media access control (GMAC) with DMA controller

76.1 Ethernet introduction

Portions Copyright (c) Synopsys, Inc. All rights reserved. Used with permission.

The Ethernet peripheral enables to transmit and receive data over Ethernet in compliance with the IEEE 802.3-2015 standard.

The peripheral is configurable to meet the needs of a large variety of consumer and industrial applications, including AV nodes and TSN (time sensitive networking) nodes.

76.2 Ethernet main features

The Ethernet peripheral embeds a dedicated DMA for direct memory interface, a media access controller (MAC) and a PHY interface block supporting several formats.

76.2.1 Standard compliance

The Ethernet peripheral is compliant with the following standards:

• • IEEE 802.3-2015 for Ethernet MAC and media independent interface (MII)
• • IEEE 1588-2008 for precision networked clock synchronization (PTP)
• • IEEE 802.1AS-2011 and 802.1-Qav-2009 for Audio Video (AV) traffic
• • IEEE 802.3az-2010 for Energy Efficient Ethernet (EEE)
• • IEEE 802.1Qbv-2015, 802.1Qbu-2016, and 802.1AS-Rev D5.0 for Time-Sensitive Networking (TSN) traffic
• • AMBA 2.0 for AHB slave port
• • AMBA4 for AXI master port
• • RGMII specification version 2.6 from HP/Marvell
• • RMII specification version 1.2 from RMII consortium

Caution: The gigabit media independent interface (GMII) is only available internally to supply the RGMII adapter. No GMII signals are available off-chip.

76.2.2 MAC features

MAC Tx and Rx common features

• • Separate transmission, reception, and control interfaces to the application
• • 10, 100, and 1000 Mbit/s data transfer rates with the following PHY interfaces:
  • – IEEE 802.3-compliant MII interface to communicate with an external Fast Ethernet PHY
  • – RGMII interface to communicate with an external gigabit PHY
  • – RMII interface to communicate with an external Fast Ethernet PHY

• • Half-duplex operation:
  • – CSMA/CD protocol support
  • – Flow control using back pressure (based on implementation-specific white papers and UNH Ethernet Clause 4 MAC Test Suite - Annex D)
  • – Packet bursting and packet extension in 1000 Mbps Half-duplex operation
• • Standard IEEE 802.3az-2010 for Energy Efficient Ethernet in MII and reduced gigabit media independent interface (RGMII) PHYs
• • 64-bit data transfer interface on the application side
• • Full-duplex flow control operations (IEEE 802.3x Pause packets and Priority flow control)
• • Network statistics with RMON or MIB counters (partial support of RFC2819/RFC2665)
• • Ethernet packet timestamping as described in IEEE 1588-2002 and IEEE 1588-2008 (64-bit timestamps given in the Tx or Rx status of PTP packet). Both one-step and two-step timestamping are supported in Tx direction.
• • Flexibility to control up to two pulse-per-second (PPS) output signals (eth_otp_pps_outx and ETH_PPS_OUT)
• • MDIO (Clause 22 and Clause 45) master interface for PHY device configuration and management

MAC Tx features

• • Preamble and start-of-frame data (SFD) insertion
• • Separate 32-bit status for each packet transmitted from the application
• • Automatic CRC and pad generation controllable on a per-frame basis
• • Programmable packet length to support Standard or Jumbo Ethernet packets of up to 16 Kbytes
• • Programmable Inter Packet Gap (40–96 bit times in steps of 8)
• • IEEE 802.3x Flow Control automatic transmission of zero-quanta Pause packet when flow control input transitions from assertion to de-assertion (in Full-duplex mode)
• • Source address field insertion or replacement, and VLAN insertion, replacement, and deletion in transmitted packets with per-packet or static-global control
• • Insertion, replacement, or deletion of up to two VLAN tags
• • Option to transmit packets with reduced preamble size in Full-duplex mode
• • Insert, replace, or delete queue/channel-based VLAN tags
• • Frame preemption for MAC Tx

MAC Rx features

• • Automatic Pad and CRC stripping options
• • Option to disable automatic CRC checking
• • Preamble and SFD deletion
• • Separate 112-bit or 128-bit status
• • Programmable watchdog timeout limit
• • Flexible address filtering modes:
  • – Four 48-bit perfect (DA) address filters with masks for each byte
  • – Four 48-bit SA address comparison check with masks for each byte
  • – 64 bit Hash filter for multicast and unicast (DA) addresses

• • Option to pass all multicast addressed packets
• • Promiscuous mode to pass all packets without any filtering for network monitoring
• • Pass all incoming packets (as per filter) with a status report
• • Additional packet filtering:
  • – VLAN tag-based: Perfect match and Hash-based filtering based either on the outer or inner VLAN tag
  • – Layer 3 and Layer 4-based: TCP or UDP over IPv4 or IPv6
  • – Extended VLAN tag based filtering with four filter selection
• • IEEE 802.1Q VLAN tag detection and option to delete the VLAN tags in received packets
• • Detection of remote wake-up packets and AMD magic packets
• • Optional forwarding of received Pause packets to the application (in Full-duplex mode)
• • Layer 3/Layer 4 checksum offload for received packets
• • Stripping of up to two VLAN tags and providing the tags in the status
• • Frame preemption for MAC Rx

76.2.3 Transaction layer (MTL) features

MTL Tx and Rx common features

• • 64-bit transaction layer block (bridges the application and the MAC)
• • Optimization for packet-oriented transfers with packets delimiters
• • Programmable burst length, up to half the size of the MTL Rx queue or Tx queue size, to support burst data transfer in the EQOS-MTL configuration
• • Programmable threshold capability for each queue (default of 64 bytes)

MTL Tx features

• • 4096-byte transmit FIFO with programmable threshold capability
• • Two Tx queues on the transmit path with a common memory for all Tx queues
• • Store-and-forward mechanism or threshold mode (cut-through) for transmission to the MAC
• • Programmable queue size in configurations with multiple queues. Each queue size can be programmed in terms of 256 bytes
• • Automatic retransmission of collision packets in Half-duplex mode
• • Discard packets on late collision, excessive collisions, excessive deferral, and under-run conditions with appropriate status
• • Module to calculate and insert IPv4 header checksum and TCP, UDP, or ICMP checksum on frames transmitted in Store-and-forward mode
• • Statistics by generating pulses for packets dropped (because of underflow) in the Tx FIFO
• • Optional statistics related to bandwidth consumption for each queue of up to 16 blocks over a 125 µs period
• • Packet-level control for
  • – VLAN tag insertion or replacement
  • – Ethernet source address insertion

• – Layer 3/Layer 4 checksum insertion control
• – One-step timestamp
• – Timestamp control
• – CRC and pad control
• • Following scheduling algorithms in configurations with multiple queues
  • – Weighted round robin (WRR)
  • – Strict priority (SP)
  • – Credit-based shaper (CBS)
  • – Enhancement to scheduled traffic (EST)
  • – Time-based scheduling (TBS)

MTL Rx features

• • 4096-byte receive FIFO with configurable threshold
• • Two Rx queues on the receive path with a common memory for all Rx queues
• • Programmable Rx queue threshold (default fixed at 64 bytes) in threshold (or cut-through) mode
• • Option to filter all error packets on reception and not forward them to the application in the store-and-forward mode
• • Option to forward the undersized good packets
• • Statistics by generating pulses for packets dropped (because of overflow) in the Rx FIFO
• • Automatic generation of Pause packet control or backpressure signal to the MAC based on the Rx Queue fill level
• • Arbitration among queues when multiple queues are present. The following arbitration schemes are supported:
  • – Weighted round robin (WRR)
  • – Weighted Strict priority (WSP)
  • – Strict priority (SP)

76.2.4 DMA block features

The DMA block exchanges data between the peripheral and the system memory. DMA transfers are driven by software descriptors structure. The application can use a set of registers (see Section 76.11.2: Ethernet DMA registers ) to control the DMA operations. The DMA block supports the following features:

• • 64-bit data transfers
• • Separate DMA channel in the transmit path for each queue
• • Separate DMA channel in the receive path for each queue
• • Optimization for packet-oriented DMA transfers with packet delimiters
• • Byte-aligned addressing for data buffer support
• • Dual-buffer (ring) descriptor support
• • Descriptor architecture allowing large blocks of data transfer with minimum CPU intervention (each descriptor can transfer up to 32 Kbytes of data)
• • Comprehensive status reporting normal operation and transfer errors

• • Individual programmable burst length for Tx DMA and Rx DMA engines for optimal host bus utilization
• • Programmable interrupt options for different operational conditions
• • Per-packet transmit or receive complete interrupt control
• • Round-robin or fixed-priority arbitration between the receive and transmit engines
• • Fixed-priority, weighted-strict-priority or weighted-round-robin arbitration for data read requests from multiple transmit DMA engines
• • Start and Stop modes
• • Separate ports for host control access and host data interface (AXI)
• • Tx DMA channels with TCP segmentation offload (TSO) feature enabled
• • Routing of received packets to the DMA channels based on the DA or VLAN priority in multichannel DMA configurations
• • Time-sensitive conditional packet transmission by comparing the slot time or IEEE 1588 time information provided in the descriptor (useful for AV applications)
• • Programmable control for transmit descriptor posted writes to improve the throughput

76.2.5 Bus interface features

AXI master interface

The AXI master interface features are the following:

• • Interfaces with the application through AXI4 compatible interface
• • 32-bit address width
• • 64-bit data
• • OKAY, SLVERR, and DECERR responses
• • Software-selected type of AXI burst (fixed and variable length burst) in AXI master interface; extended length fixed bursts of 32, 64, 128, and 256
• • Handshaking on AXI read and write data channels

AHB slave interface

The AHB slave interface supports the following features:

• • Interfaces with the application through AHB
• • AHB slave interface (32-bit) for CSR access
• • All AHB burst types

The AHB slave interface does not generate the following responses:

• • Split
• • Retry

76.2.6 Audio and video features

The Ethernet peripheral can be used in Audio Video (AV) mode. The supported features are compliant with the industry standards for AV traffic:

• • Separate channels or queues for AV data transfer in 100 Mbps and 1000 Mbps modes
• • Multiple Rx queues on the receive paths for AV traffic, and multiple Tx queues on the Transmit path for AV traffic
• • IEEE 802.1-Qav specified credit-based shaper (CBS) algorithm for Transmit channels
• • Single Tx FIFO and Rx FIFO (MTL) for all selected queues
• • Programmable Slot Interval with range from 1 µs to 4096 µs and granularity of 1 µs.

76.2.7 Time sensitive networking features

The Ethernet peripheral supports the following time sensitive networking (TSN) features:

• • IEEE 802.1Qbv-2015, Enhancements to Scheduling Traffic
• • IEEE802.1Qbu/802.3br, Frame preemption and Interspersing Express Traffic

76.2.8 Generic queuing features

The Ethernet peripheral supports the following features for generic queuing:

• • Programmable control for routing receive packets with Multicast/Broadcast destination address to a programmable receive queue
• • Support routing of untagged receive packets to a programmable receive queue
• • Programmable control for routing VLAN tagged and untagged IEEE 1588 PTP over Ethernet receive packets to a same or separate programmable receive queue
• • Programmable control for routing Unicast/Multicast receive packets that fail the destination address filter to a separate programmable receive queues

76.3 Ethernet pins and internal signals

Table 762 lists the Ethernet inputs and output signals connected to package pins or balls. Active pins depend on the PHY type selected (MII, RMII or RGMII) and on the device configuration.

Table 763 shows the internal Ethernet signals.

Table 762. Ethernet peripheral pins

Table 762. Ethernet peripheral pins (continued)

1. This pin is not available on all devices.

Table 763. Ethernet internal input/output signals

Table 763. Ethernet internal input/output signals (continued)

76.4 Ethernet architecture

The Ethernet peripheral is composed of 4 main functional modules:

• • The control and status register module (CSR) that controls the registers access through AHB 32-bit slave interface
• • The direct memory access interface (DMA)
  This is the logical DMA module with two physical channel for reception and two for transmission. It controls the data transfers between MAC and system memory through the AMBA AXI4 64-bit master interface.
• • The media access control module (MAC) in charge of implementing the Ethernet protocol
• • The MAC transaction layer (MTL) in charge of controlling the data flow between application and MAC.

A protocol adaption module is added to support the RMII or the RGMII PHY Media Independent Interfaces.

Caution: The gigabit media independent interface (GMII) is only available internally to supply the RGMII adapter. No GMII signals are available off-chip.

Figure 1019. Ethernet high-level block diagram

1. 1. For a definition of the internal signals, refer to Table 763 .
2. 2. Refer to RCC chapter “Clock distribution for Ethernet” for a detailed description of the Ethernet clock architecture.
3. 3. The ETH_PTP_AUX_TS pin is not available on all devices.

76.4.1 DMA controller

The DMA has independent transmit (Tx) and receive (Rx) engines. The Tx engine transfers data from the system memory to the MAC Transaction Layer (MTL), whereas the Rx engine transfers data from the device port (PHY) to the system memory.

The controller uses descriptors to efficiently move data from source to destination with minimal application CPU intervention. The DMA is designed for packet-oriented data transfers such as packets in Ethernet. The controller can be programmed to interrupt the application CPU for situations such as Packet transmit and receive Transfer completion, and other normal or error conditions.

DMA data structures

The DMA and the application communicate through the following two data structures:

• • Control and Status registers (CSR)
• • Descriptor lists and data buffers

The DMA transfers the data packets received by the MAC to the Rx buffer in system memory and Tx data packets from the Tx buffer in the system memory. The descriptors that reside in the system memory contain the pointers to these buffers.

The base address of each list is written to the respective Tx and Rx registers: Channel x Tx descriptor list address register (ETH_DMACxTXDLAR) and Channel x Rx descriptor list address register (ETH_DMACxRXDLAR) .

The descriptor list is forward linked and the next descriptor is always considered at a fixed offset to the current one. The number of descriptors in the list is programmed in the respective Tx/Rx, Channel x Tx descriptor ring length register (ETH_DMACxTXRLR) and Channel x Rx descriptor ring length register (ETH_DMACxRXRLR) .

Once the DMA processes the last descriptor in the list, it automatically jumps back to the descriptor in the List address register to create a descriptor ring. The descriptor lists reside in the physical memory address space of the application. Each descriptor can point to a maximum of two buffers. This enables two buffers to be used and physically addressed, rather than contiguous buffers in memory.

A data buffer resides in the application physical memory space and consists of an entire packet or part of a packet, but cannot exceed a single packet. Buffers contain only data. The buffer status is saved in the descriptor. Data chaining refers to packets that span multiple data buffers. However, a single descriptor cannot span multiple packets. The DMA skips to the data buffer of next packet when EOP is detected.

Descriptors are specified in Section 76.10: Descriptors .

DMA transmission in default mode

The Tx DMA engine in default mode proceeds as follows:

1. 1. The application sets up the Transmit descriptor (TDES0–TDES3) and sets the Own bit (TDES0[31]) after setting up the corresponding data buffer(s) with Ethernet Packet data.
2. 2. The application shifts the descriptor tail pointer offset value of the Transmit channel.
3. 3. While in the Run state, the DMA runs an arbitration cycle to select the next Tx DMA channel from which the packets requiring transmission should be processed.
4. 4. The DMA fetches the descriptor from the application memory.
5. 5. If the DMA detects one of the following conditions, the transmission from that channel is suspended, bit 2 and 16 of the corresponding DMA channel Status register are set, and the Tx engine proceeds to step 11:
   • – The descriptor is flagged as owned by the application (TDES3 [31] = 0).
   • – The descriptor tail pointer is equal to the current descriptor pointer in Ring Descriptor list mode.
   • – An error condition occurs.
6. 6. If the acquired descriptor is flagged as owned by the DMA (TDES3[31] = 1), the DMA decodes the Transmit Data Buffer address from the acquired descriptor.
7. 7. The DMA fetches the Transmit data from the system memory and transfers the data to the MTL for transmission.
8. 8. If an Ethernet packet is stored over data buffers in multiple descriptors, the DMA closes the intermediate descriptor and fetches the next descriptor. Steps 3 through 7 are repeated until the end-of-Ethernet-packet data is transferred to the MTL.
9. 9. When packet transmission is complete, if IEEE 1588 timestamp feature was enabled for the packet (as indicated in the Tx status), the timestamp value obtained from MTL is written to the Tx descriptor (TDES0 and TDES1) that contains the EOP buffer. The status information is written to this Tx descriptor (TDES3). The application now owns

this descriptor because the Own bit is cleared during this step. If the timestamp feature is disabled for this packet, the DMA does not alter TDES0 and TDES1 contents.

1. 10. Bit 0 of Channel x status register (ETH_DMACxSR) is set after completing transmission of a packet that has Interrupt on Completion (TDES2[31]) set in its Last Descriptor. The DMA engine returns to step 3.
2. 11. In the Suspend state, the DMA tries to acquire the descriptor again (and thereby return to step 3). A poll demand command is triggered by writing any value to the Channel x Tx descriptor tail pointer register (ETH_DMACxTXDTPR) when it receives a Transmit Poll demand and the underflow interrupt status bit is cleared. If the application stopped the DMA by clearing Bit 0 of Transmit control register of corresponding DMA channel, the DMA enters the Stop state.

Figure 1020. DMA transmission flow (standard mode)

graph TD
    StartTx[Start Tx DMA] --> Fetch[(Re-)fetch next descriptor from Tx Queue]
    StopTx[Stop Tx DMA] --> Fetch
    Fetch --> OwnBit{Own bit set?}
    OwnBit -- No --> EndRing{End of descriptor ring?}
    OwnBit -- Yes --> Transfer[Transfer data from Buffer(s)]
    Transfer --> PacketRead{Packet read completely?}
    PacketRead -- No --> CloseInt[Close intermediate descriptor]
    PacketRead -- Yes --> Transmit[Transmit packet]
    Transmit --> StartReq{Start required?}
    StartReq -- No --> EndRing
    StartReq -- Yes --> WaitTx[Wait for Tx status]
    WaitTx --> Timestamp{Timestamp present?}
    Timestamp -- No --> EndRing
    Timestamp -- Yes --> WriteTS[Write timestamp to TDES0 and TDES1]
    WriteTS --> WaitStatus[Wait status word to TDES3]
    WaitStatus --> DMAStopped{DMA Tx stopped?}
    DMAStopped -- Yes --> StopTx
    DMAStopped -- No --> PollDemand[Transmit Poll demand]
    PollDemand --> Fetch
    EndRing -- Yes --> Suspend[Suspend Tx DMAqueue]
    EndRing -- No --> CloseLast[Close TDES3 of last descriptor]
    CloseLast --> Fetch
    CloseInt --> Fetch

MS40862V2

DMA transmission in OSP (operate on second packet) mode

In Run state, if bit 4 is set in the Channel x transmit control register (ETH_DMACxTXCR) , the Transmit process can simultaneously acquire two packets without closing the Status descriptor of the first packet. While the Transmit process completes the first packet transfer, it immediately polls the Transmit descriptor list for the second packet. If the second packet is valid, the Transmit process transfers this packet before writing the status information of the first packet.

In OSP mode, DMA transmission in the Run state operates as described in the following sequence:

1. 1. The DMA executes steps 1 to 7 of the DMA transmission sequence in default mode (see Section : DMA transmission in default mode ).
2. 2. The DMA fetches the next descriptor without closing previous packet last descriptor.
3. 3. If the DMA owns the acquired descriptor, the DMA decodes the transmit buffer address in this descriptor. If the DMA does not own the descriptor, the DMA goes into Suspend mode and jumps to step 7.
4. 4. The DMA fetches the Transmit packet from the system memory and transfers the packet to the MTL until the EOP data is transferred, closing the intermediate descriptors if this packet is split across multiple descriptors.
5. 5. The DMA waits for the packet transmission status and timestamp of previous packet. When the status is available, the DMA writes the timestamp to TDES0 and TDES1 if such timestamp was captured (as indicated by a status bit). The DMA writes the status, with a cleared Own bit, to the corresponding TDES3, thus closing the descriptor. If Timestamp feature is not enabled for the previous packet, the DMA does not alter the contents of TDES2 and TDES3.
6. 6. The Transmit interrupt is set (if enabled). The DMA fetches the next descriptor and proceeds to step 3 (when Status is normal). If the previous transmission status shows an underflow error, the DMA goes into Suspend mode (step 7).
7. 7. In Suspend mode, if a pending status and timestamp are received from the MTL, the DMA performs the following operations:
   1. a) The DMA writes the timestamp (if enabled for the current packet) to TDES2 and TDES3.
   2. a) The DMA writes the status to the corresponding TDES3.
   3. a) The DMA sets the relevant interrupts and returns to Suspend mode.
   If no status is pending and the application stopped the DMA by clearing bit 0 of Transmit Control Register of corresponding DMA channel, the DMA enters the Stop state.
8. 8. The DMA can exit Suspend mode and enter the Run state (it goes either to step 1 or to step 2 depending on pending status) only after receiving a Transmit Poll demand in the transmit descriptor tail pointer register of corresponding channel.

A description of the basic DMA transmission flow in OSP mode is given in Figure 1022: Receive DMA flow .

Figure 1021. DMA transmission flow (OSP mode)

graph TD
    Start[Start Tx DMA] --> Fetch[(Re-)fetch next descriptor from Tx Queue]
    Fetch --> OwnBit{Own bit set?}
    OwnBit -- No --> EndRing{End of descriptor ring?}
    OwnBit -- Yes --> Transfer[Transfer data from Buffer(s)]
    Transfer --> ReadComplete{Packet read completely?}
    ReadComplete -- No --> CloseDesc[Close intermediate descriptor]
    ReadComplete -- Yes --> SecondPacket{Second packet?}
    SecondPacket -- No --> EndRing
    SecondPacket -- Yes --> WaitStatus[Wait for previous packet status]
    WaitStatus --> TimestampPresent{Timestamp present?}
    TimestampPresent -- No --> EndRing
    TimestampPresent -- Yes --> WriteTimestamp[Write timestamp to TDES0 and TDES1]
    WriteTimestamp --> WaitStatusWord[Wait status word to TDES3]
    WaitStatusWord --> EndRing
    EndRing -- No --> Fetch
    EndRing -- Yes --> Suspended[Tx DMA queue suspended]
    Suspended --> PrevPacketStatus{Prev. packet status available?}
    PrevPacketStatus -- Yes --> DMAStopped{DMA Tx stopped?}
    PrevPacketStatus -- No --> TxDMAQueueSuspended[Tx DMA queue suspended]
    TxDMAQueueSuspended --> TxDemand{Tx Poll demand?}
    TxDemand -- Yes --> DMAStopped
    TxDemand -- No --> DMAStopped
    DMAStopped -- Yes --> StopDMA[Stop DMA]
    DMAStopped -- No --> Fetch
    CloseDesc --> EndRing
    MS40863V1[MS40863V1]
    style MS40863V1 fill:none,stroke:none
    

DMA reception

In the receive path, the DMA reads a packet from the MTL receive queue and writes it to the packet data buffers of the corresponding DMA channel.

The DMA Rx descriptor ring structure is described in Section 76.10: Descriptors .

The reception sequence for Rx DMA engine is as follows (see also Figure 1022: Receive DMA flow ):

1. 1. The application sets up the Rx descriptors (RDES0-RDES3) and the Own bit (RDES3[31]). The application should set the correct value in the receive descriptor tail pointer register of corresponding DMA channel to indicate the location of the last valid descriptor for the DMA. If the tail pointer points to descriptor N, the last valid descriptor for the DMA is descriptor N - 1.
2. 2. When bit 0 of Channel x receive control register (ETH_DMAxCxRXCR) is set, the DMA enters the Run state. The DMA looks for free descriptors based on the Rx Current Descriptor and Descriptor tail pointer register values. The descriptors referenced between the current descriptor and the tail pointer registers are available for the DMA. If there are no free descriptors, the DMA channel enters the Suspend state and goes to step 11.
3. 3. The DMA fetches the next available descriptor in the ring and decodes the receive data buffer address from acquired descriptors.
4. 4. If IEEE 1588 timestamping is enabled and the timestamp is available for the previous packet, the DMA writes the timestamp (if available) to the RDES0 and RDES1 of current descriptor and sets the CTXT field (RDES3[30]).
5. 5. The DMA processes the incoming packets and stores them in the data buffers of acquired descriptor.
6. 6. If the current packet transfer is not complete, the DMA closes the current descriptor as intermediate and goes to step 10.
7. 7. The DMA retrieves the status of the receive frame from the MTL and writes the status word to current descriptor with the Own bit cleared and the Last descriptor bit set.
8. 8. The DMA writes the Frame Length to RDES3 and the VLAN tag to RDES0. The DMA also writes the MAC control frame opcode, OAM control frame code, and extended status information (if available) to RDES1 of the last descriptor.
9. 9. The DMA stores the timestamp (if available). The DMA writes the context descriptor after the last descriptor for the current packet (in the next available descriptor).
10. 10. If more descriptors are available in the Rx DMA descriptor ring, go to step 3, otherwise go to the Suspend state (step 11).
11. 11. The receive DMA exits the Suspend state when a receive Poll demand is given, and the application updates the channel receive descriptor tail pointer register to indicate the location of the last valid descriptor for DMA. Then, the engine proceeds to step 2 and fetches again the next descriptor.

Note: Refer to Section : Descriptor tail pointer handling examples for updating the correct value in receive descriptor tail pointer register.

Figure 1022. Receive DMA flow

graph TD
    Start[Start Rx DMA] -- Start --> Stop[Stop Rx DMA]
    Stop --> Fetch[(Re)Fetch next descriptor]
    Fetch --> Poll{Receive Poll demand}
    Poll --> Stopped{Rx DMA stopped?}
    Stopped -- No --> OWN{OWN bit set}
    OWN -- No --> Suspend[Suspend Rx DMA]
    OWN -- Yes --> TimestampPending{Timestamp pending?}
    TimestampPending -- Yes --> WriteTimestamp[Write timestamp to RDES0 and RDES1]
    WriteTimestamp --> ClearTimestamp[Clear pending timestamp]
    TimestampPending -- No --> PacketData{Packet data available?}
    PacketData -- No --> Wait[Wait for packet data]
    PacketData -- Yes --> WriteData[Write data to buffer]
    Wait --> WriteData
    WriteData --> TransferComplete{Packet transfer complete?}
    TransferComplete -- No --> CloseIntermediate[Close RDES3 as intermediate descriptor]
    TransferComplete -- Yes --> TimestampPresent{Timestamp present?}
    TimestampPresent -- Yes --> SetPending[Set pending timestamp]
    SetPending --> Stopped
    TimestampPresent -- No --> CloseLast[Close RDES3 as last descriptor]
    CloseLast --> Stopped
    CloseIntermediate --> RingEnd{End of descriptor ring?}
    Stopped -- No --> RingEnd
    RingEnd -- Yes --> Suspend
    RingEnd -- No --> Fetch
  

Priority scheme for Tx DMA and Rx DMA

The DMA arbiter performs the arbitration between the Tx and Rx paths of DMA channel 0 to access descriptors and data buffers.

If the Tx DMA and Rx DMA of a given channel are enabled, the DMA which gets the bus when the channel gets control of the bus must be specified. The priority between the corresponding Tx DMA and Rx DMA can be configured through the TXPR field of the DMA mode register (ETH_DMAMR) .

76.4.2 MTL

The MAC Transaction Layer (MTL) provides the FIFO memory interface to buffer and regulate the packets between the application system memory and the MAC. It also enables the data to be transferred between the application clock and MAC clock domains. The MTL layer features two 64-bit wide data paths: the Transmit path and the receive path.

• • Transmit path
  The application or internal DMA pushes the Ethernet packets read from the application or system memory into the corresponding queue in Tx FIFO. The packet is then popped out and transferred to the MAC when the queue threshold is reached (threshold mode) or complete packet is in the queue (store-and-forward mode). When EOP is transferred, the status of the transmission is taken from the MAC and transferred back to the application or internal DMA. The Tx queue size is 4096 bytes.
• • Receive path
  The MTL Rx module receives the packets from the MAC and pushes them into the Rx queue. The status (fill level) of the queue is indicated to the application or to DMA when it crosses the configured receive threshold (RTC bits[1:0] defined in the operating mode register of the corresponding queue), or when the complete packet was received. The MTL also indicates the queue fill level so that the DMA can initiate preconfigured burst transfers towards the master interface. The Rx queue size is 4096 bytes.

76.4.3 MAC

The MAC is responsible of the Ethernet protocol processing. In Transmission mode, it receives data from MTL before transferring it to the PHY interface. In Reception mode, the MAC receives data from the PHY interface before transferring them to the Rx FIFO of the MTL module.

This section briefly describes transmission and reception sequences.

MAC transmission

The transmission sequence is as follows:

1. 1. Transmission is initiated when the MTL application pushes in data with the SOP (Start of packet) signal asserted.
2. 2. When the SOP signal is detected, the MAC accepts the data and begins the transmission to the GMII or MII.
3. 3. When the EOP (End of packet) is transferred to the MAC, the MAC does one of the following:
   • – The MAC completes the normal transmission and provides the transmission status to the MTL.
   • – If a normal collision (in Half-duplex mode) occurs during transmission, the MAC provides the Transmit status to the MTL, with the Retry bit set. The MAC provides the Retry request till one of the following is true:
     • the packet was successfully transmitted;
     • the maximum number of Retry requests expires. In this case, the MAC aborts the packet transmission with Excessive Collision Transmit status. The MAC accepts and drops all further data until the next SOP is received. The MTL block should retransmit the same packet from SOP when a Retry request (in the Status) is observed from the MAC.

• – If any one of the following event happens, the MAC aborts the packet transmission:
  • no carrier (Half-duplex mode)
  • loss of carrier (Half-duplex mode)
  • excessive deferral (Half-duplex mode)
  • late collisions (Half-duplex mode)
  • jabber

  the MAC accepts and drops all further data until the next SOP is received.

• 4. The MAC issues an underflow status if the MTL is not able to provide the data continuously during the transmission. The MAC accepts and drops all further data until the next SOP is received.
• 5. During the normal transfer of a packet from MTL, if the MAC receives a SOP without getting an EOP for the previous packet, it ignores the SOP and considers the new packet as continuation of the previous packet.

Figure 1023: Overview of MAC transmission flow illustrates the MAC transmission process flow.

Figure 1023. Overview of MAC transmission flow

graph TD; Start[Start] --> WaitSOP[Wait for data & SOP From MTL]; WaitSOP --> SOPAsserted{SOP asserted by MTL?}; SOPAsserted -- YES --> WaitIPG[Wait for IPG/any back-off delay hal-duplex]; SOPAsserted -- NO --> WaitSOP; WaitIPG --> Transmit[Transmit preamble+SFD+Data received from the MTL to the PHY]; Transmit --> NoCarrier{No carrier/Carrier loss/Excessive defer/Late collisions/Jabber?}; NoCarrier -- YES --> DropData1[Drop all the data received from MTL and abort transmission]; NoCarrier -- NO --> Collision{Collision}; Collision -- YES --> SendStatus[Send status to MTL with Retry bit set]; SendStatus --> ConditionD{Condition D: Retry_count ≤ retry_limit}; ConditionD -- YES --> WaitSOP; ConditionD -- NO --> DropData2[Drop all the data received from MTL and abort transmission]; Collision -- NO --> EOPUnderflow{A. EOP asserted by MTL? B. Underflow asserted by MAC?}; EOPUnderflow -- Condition A --> NormalTrans[Normal transmission completed and Transmission status conveyed to MTL]; EOPUnderflow -- Condition B --> DropData2; NormalTrans --> WaitSOP; DropData1 --> WaitSOP; DropData2 --> WaitSOP;

MSv40390V1

MAC reception

A receive operation is initiated when the MAC detects an SFD on GMII. The MAC strips the preamble and SFD before proceeding to process the packet. The header fields are checked for filtering and the FCS field used to verify the CRC for the packet. The received packet is stored in a shallow buffer until the address filtering is performed. The packet is dropped in the MAC if it fails the address filter.

The reception sequence is as follows:

1. 1. When the receive data valid signal (RxDV) of GMII or MII becomes active, the receive State Machine (RSM) starts looking for the SFD field (0x5D byte).

The state machine drops received packets until it detects SFD.

1. 2. When SFD is detected, the state machine starts sending the data of Ethernet packet to the RPC module, beginning with the first byte following the SFD (destination address).
2. 3. If IEEE 1588 timestamp feature is enabled, the MAC takes a snapshot of the system time at which SFD of any packet is detected on GMII or MII. If this packet is not dropped during MAC filtering, the timestamp is passed to the application. The receive state machine decodes the Length/Type field of the Ethernet packet being received.

If the Length/Type field is less than 1,536 and if the MAC is programmed for the Auto CRC/Pad Stripping (bit 20 of the Operating mode configuration register (ETH_MACCR) ), the state machine sends the packet data up to the count specified in the Length/Type field and starts dropping bytes (including the FCS field). The state machine decodes the Length/Type field and checks for the Length interpretation.

1. 4. If the Length/Type field is greater than or equal to 1,536, the RPE module sends all received Ethernet packet data to the RFC module if you have not enabled the CRC stripping for Type packet in Bit 21 of the Operating mode configuration register (ETH_MACCR) . However, if the CRC stripping has been enabled for Type packets and not enabled the receive checksum offload engine, the MAC strips and drops the last 4 bytes of all packets of ether type before forwarding the packets to the application.
2. 5. By default, the MAC is programmed for watchdog timer to be enabled, that is, packets above 2,048 (10,240 if Jumbo Packet is enabled) bytes (DA + SA + LT + DATA + PAD + FCS) are cut off at the RPE module. In addition, you can use a programmable watchdog timer (bit 16 of Watchdog timeout register (ETH_MACWTR) ) to override the fixed timeout of 2,048 or 10,240 bytes. You can disable the watchdog timer by programming bit 19 of Operating mode configuration register (ETH_MACCR) . However, even if the watchdog timer is disabled, a packet greater than 32 Kbytes is cut off and a watchdog timeout status is given.

Figure 1024. MAC reception flow

graph TD
    Start([Start]) --> Wait1[Wait for phy_rxdv_i from GMII/MII]
    Wait1 --> Wait2[Wait until SFD is detected]
    Wait2 --> SendDA[Start sending the received Ethernet packet to the application layer, starting from DA field]
    SendDA --> IEEE1588{IEEE 1588 timestamp feature enabled?}
    IEEE1588 -- YES --> StoreTime[Store the snapshot of the system time when SFD detected]
    IEEE1588 -- NO --> LengthType{Length/Type field <1536 & Auto CRC/Pad stripping enabled?}
    StoreTime --> LengthType
    LengthType -- NO --> LengthGE1536[Length/Type field ≥1536]
    LengthType -- NO --> SendOnly[Send only the number of bytes (specified in the Length field) of the received Ethernet packet to RFC. Drop extra padding and FCS field]
    LengthGE1536 --> CRCStrip{CRC stripping for Type packets enabled?}
    CRCStrip -- YES --> ChecksumOffload{Receive checksum Offload engine enabled?}
    CRCStrip -- NO --> SendAll[Send all received Ethernet packet data to RFC]
    ChecksumOffload -- YES --> DropLast4[Drop the last 4 bytes of all Ether type packets and send the remaining bytes to RFC]
    ChecksumOffload -- NO --> DropLast4
    SendOnly --> CRCError{CRC error? OR Packet to be filtered?}
    SendAll --> CRCError
    DropLast4 --> CRCError
    CRCError -- NO --> SendPacket[Send the packet, timestamp and Status to the Application layer]
    CRCError -- YES --> DropPacket[Drop the packet and send the Status to the Application layer]
    DropPacket --> Start
    SendPacket --> Start
    DropLast4 --> Start
    SendAll --> Start
    SendOnly --> Start
    

MSv40391V1

76.4.4 Multiple channels and queues support

This chapter describes how the Ethernet peripheral core supports multiple queues and channels.

Two queues on Rx side and two queues on Tx side are supported. Two DMA channels are implemented on Tx side, one channel per queue. Two DMA channels are implemented on Rx side, one channel per queue.

The multiple queues enable to support the Audio video bridging (AVB) protocol.

Multiple queues and channels support in the Transmit path

The number of Tx DMA channels is equal to the number of Tx queues, and is direct one-to-one mapping. This enables the interleaving of packet/data transfer of multiple Tx DMA on the host/system bus, and each Tx queue is reserved for the corresponding Tx DMA. Therefore, the integrity of packet transfer by each Tx DMA is maintained in the Tx queue and enables efficient utilization of the host bus for data transfers among multiple Tx DMA without depending on the packet length, Transmit buffer availability and so on.

If two Tx DMAs are allowed to transfer data into the same Tx queue, when a Tx DMA starts a packet transfer, the other Tx DMA cannot transfer data to the same Tx queue unless the previous packet transfer is complete. This means that the second DMA remains idle until the first packet transferred is complete, which is effectively a one-to-one mapping of the Tx DMA to the Tx queue.

The Ethernet peripheral supports multiple Tx channels. The priority scheme between both channels is fixed priority. In fixed priority scheme, the channel with the highest priority always wins the arbitration when it requests the bus, as shown in Table 764 .

Table 764. Fixed priority scheme for DMA channels

The fixed priority scheme does not necessarily cause the “starving” of lower priority channels for the AXI bus because of the capabilities of the AXI protocol and characteristics of the TxDMA, described as follows:

• • Read command requests from a TxDMA for a burst of data transfers are driven on a separate AXI channel, and their execution takes one clock cycle. The actual data transfer starts on a separate AXI channel only after the request is accepted. It takes several clock cycles to complete with relatively large read access latencies.
• • The AXI master is free to issue subsequent requests even before the previous data transfers are complete.
• • A TxDMA requests another data transfer only after the data transfer corresponding to its previous request is complete and transferred to the MTL Tx queue and space is available in Tx queue to accept the next request.
• • The Ethernet peripheral can be programmed to control the maximum number of outstanding requests, requested burst sizes by DMA, and the burst sizes of each data transfer on the AXI bus.

Considering the previous points, the Ethernet peripheral can be programmed so that the requests of all TxDMAs are placed and executed on the AXI bus before the data transfer of the first TxDMA is complete and it raises the next request to the arbiter. For example, in a 64-bit AXI data bus, proceed as follows:

1. 1. TxDMA PBL = 64 (512 bytes).
2. 2. Number of outstanding AXI read requests = 16.
3. 3. Maximum burst length on AXI (BLEN) = 32 (256 bytes).
4. 4. Number of active TxDMAs = 8.

Assuming that all TxDMAs place a request simultaneously and get serviced by the fixed priority algorithm, all the requests are placed on the AXI bus in a window of 32 clocks (two clocks per AXI request, two AXI burst requests per TxDMA request). The data transfer of the first request takes 32 clock cycles + the read-access latencies (assuming that there are tens of cycles). So, the TxDMA arbiter is already IDLE and has completed servicing all the TxDMA requests before this data transfer completes.

Effectively, all the TxDMA channels get equal access to AXI bus and the corresponding Tx queues get filled up at the same rate. The data gets read out from the Tx queues as per the traffic class scheduler in the MTL. So at a steady state, the bandwidth for each channel is controlled by the priorities and settings of the traffic scheduler in the MTL.

Programming guidelines for multiple queues and channels in the Transmit path

See Section 76.9.8: Programming guidelines for multichannel multiqueue operation on page 4128 .

Multiple queues and channels support in the receive path

The Ethernet controller supports independent selection of the number of Rx DMA channels and the number of Rx queues in the MTL Rx buffer. Therefore, the packets from any Rx queue can be serviced by any of the Rx DMA. As all the packets of Rx queues are stored in a shared RxFIFO buffer in MTL, the Rx scheduler selects the Rx queue whose packet data are to be transferred to the destination Rx DMA, which then forwards the packet data to the host memory. The sequence of events in time is as follows:

1. 1. Each Rx DMA indicates whether it is ready to transfer data, that is, when the Rx DMA has fetched the descriptor and has a receiver buffer ready to accept the packet data. Each Rx DMA also indicates the number of words that it can transfer, based on the space available in the Rx buffer and the value programmed in the RXPBL[5:0] bitfield of its Channel x receive control register (ETH_DMACxRXCR) .
2. 2. The MTL Rx scheduler matches the number of bytes/packets available for transfer at the top of all Rx queues with the corresponding Rx DMA ready status and the number of bytes requested by it.
3. 3. If there are multiple successful matches, the scheduler selects the Rx queue to be serviced, based on the arbitration schemes (Strict priority or Weighted Strict priority) decided by the RAA field of the Operating mode register (ETH_MTLOMR) . In the Weighted Strict priority scheme, the weight of each Rx queue is set in the RXQ_WEGT[2:0] bitfield of the corresponding Rx queue x control register (ETH_MTLRXQxCR) .
4. 4. The MTL Rx controller fetches the data of the selected Rx queue from the shared RxFIFO memory and starts the transfer of the requested PBL number of bytes to the

DMA block or until the end of packet and the corresponding Rx status is transferred (whichever is first).

1. 5. After completing the current request, the scheduler repeats the process by starting a new arbitration cycle. However, it selects the same Rx queue for servicing, if the end of packet is not transferred and the RXQ_FRM_ARBIT field of the Rx queue x control register (ETH_MTLRXQxCR) is 1, for the Rx queue.

Rx queue to DMA mapping

The packets in the MTL Rx queues can be routed to any of the multiple DMA channels, by programming the Rx queue and the Rx queue and DMA channel mapping register (ETH_MTLRXQDMAMR) .

Two types of Rx queue-to-DMA mapping are possible through programming: static mapping and dynamic (per packet) mapping.

• • Static mapping

In Static mapping mode, all the packets of an Rx queue are connected to a specific DMA channel. For example, all the packets from Rx Queue 0 can be routed to a DMA channel by programming Q0MDMACH and Q0DDMACH of the Rx queue and DMA channel mapping register (ETH_MTLRXQDMAMR) .

Similarly, packets from other Rx queues can be routed to any DMA channel by programming the register fields corresponding to each queue.

• • Dynamic (per packet) mapping

In Dynamic (per packet) mapping mode, the destination DMA channel is decided by the MAC core receiver for each packet.

In this mode, the destination DMA channel of a packet being read from a Rx queue is not constant but decided independently for each packet. For example, by setting the Q1DDMACH bit of the Rx queue and DMA channel mapping register (ETH_MTLRXQDMAMR) , the static mapping is disabled for Rx Queue 1 and the value in Q1MDMACH is ignored. The destination DMA channel is decided by the MAC receiver for each packet, depending on the following, in decreasing order of priority:

• – L3-L4 filter based DMA selection

When the Layer 3 and Layer 4 packet filtering is enabled, the TCP/UDP and IP header fields of the received packet are matched against the corresponding values programmed and enabled for comparison in the MAC L3 and L4 address control register. If the match is successful, the DMA channel number programmed in the DMCHNx bits of the L3 and L4 control 0 register (ETH_MACL3L4C0R) and L3 and L4 control 1 register (ETH_MACL3L4C1R) is selected as the destination DMA channel number provided DMCHEN bit of the same register is set.

If none of the L3-L4 registers give a comparison match, the Ethernet peripheral proceeds to the next step.

• – Extended VLAN based DMA selection

Extended routing is applicable only if the VLAN filter has passed. Routing is only based on perfect filter result. Each perfect filter has a DMA channel enable and a DMA channel number field which can be programmed. Routing is applicable for a filter only if the DMA channel enable bit is set.

The frame is routed to the smallest matching filter DMA channel provided it is enabled. If that filter DMA channel number is not enabled, the frame gets routed to Channel 0. For example, if a frame VLAN tag matches filter 1, then the MAC checks if filter 1 DMA channel number is enabled through programming. If yes, the

frame gets routed to the programmed value; otherwise it gets routed to DMA. When the inverse filter is enabled, the frame is routed to the least mismatched filter DMA channel number provided it is enabled. If the DMA channel enable bit is not set, then the frame is routed based on DA-based addressing or to Channel 0. If Hash filter is also enabled, it is used to determine the filter result only. Routing still depends on the enabled perfect filters. If none of the perfect filters are enabled or if all of them are bypassed, the VLAN filter based routing is not done. The frame is routed through DA-based addressing or to Channel 0. If all the perfect filters give a fail result and the Hash filter has passed, VLAN filter result is a pass. However, routing is based on DA-based addressing or to Channel 0. The behavior is similar when the inverse filtering is enabled.

• – Ethernet DA-based DMA selection

The DA address of the received packet is compared against the programmed DA values in MAC address registers. If the address matches any of the programmed values, the corresponding DCS field (when enabled) determines the destination DMA channel number.

If none of the previous operations is able to make a successful match/decision, then the packet is routed to DMA Channel 0 by default.

Programming guidelines for multiple queues and channels in the receive path

See Section 76.9.8: Programming guidelines for multichannel multiqueue operation on page 4128 .

Selection of the tag priorities assigned to Rx queues

The VLAN tag priorities can be assigned to Rx queues by programming the PSRQ field in the corresponding Rx queue control 2 register (ETH_MACRXQC2R) . The bit corresponding to the VLAN tag priority can be set in the PSRQ field to assign the corresponding priority to the Rx queue. As an example, to assign VLAN tag priority 3 to Rx queue 0, set bit3 of PSRQ field in the Rx queue control 2 register (ETH_MACRXQC2R) . The VLAN tag priority assigned to a given Rx queue must be unique. This means that multiple Rx queues cannot be assigned the same VLAN tag priority. However, multiple VLAN tag priorities can be assigned to the same Rx queue.

The settings in the PSRQ field is used for VLAN tagged Rx packet routing to Rx queues as well as for PFC based Tx flow control. The received VLAN tagged Rx packet is routed to the Rx queue that matches the VLAN tag priority. In PFC-based Tx flow control, the PSRQ field corresponding to a particular Rx queue is used to enable VLAN tag priorities in the PFC packet that is transmitted when the corresponding Rx queue threshold levels are reached.

Distribution of Rx packets from MAC to Rx queues

The Ethernet peripheral provides multiple Rx queues to support classification and distribution of ingress packets. The MAC receiver pushes the ingress packets to the Rx queues based on packet type (such as tagged, untagged, multicast, PTP, AVB), tag priorities, MAC packet filter results, preemptable or express packet, and so on. The distribution is controlled by the settings of:

• • Rx Queue control register (ETH_MACRXQCR)
• • Rx queue control 0 register (ETH_MACRXQC0R)
• • Rx queue control 1 register (ETH_MACRXQC1R)
• • Rx queue control 2 register (ETH_MACRXQC2R)
• • Packet filtering control register (ETH_MACPFR)

Additionally, the Ethernet peripheral supports distribution of ingress packets based on user-defined Type field of the ingress packets when TBRQE bit of the Rx queue control 1 register (ETH_MACRXQC1R) is enabled. Up to eight types for matching can be programmed in the MAC type-based Rx queue mapping register (ETH_MAC_TMRQR) which is accessible through MAC indirect access control register (ETH_MAC_IACR) . The ETH_MAC_TMRQR register contains

• • TYP[15:0] field: 16-bit type
• • TMRQ[2:0] bitfield: Rx queue number to which ingress packet is pushed when its Type field matches TYP.
• • PFEX field: this bit indicates whether the TYP is applicable for express packets or preemptable packets.

Based on the packet filter settings, the MAC receiver decides either to drop or forward the ingress packet (for more details, see Section 76.5.4: Packet filtering ). However, the results of Layer 3 and Layer 4 filtering, mentioned in Section : Layer 3 and Layer 4 filtering , are not considered for the distribution of ingress packets into the Rx queues. Only the results of DA/SA/VLAN filters mentioned in Section : MAC source or destination address filtering and Section : VLAN filtering are applicable.

The filtering of the broadcast packets is exclusively controlled by the DBF bit of the Packet filtering control register (ETH_MACPFR) . The filtering of multicast packets is controlled by the PM bit of the Packet filtering control register (ETH_MACPFR) , in addition to the DA/SA match.

By default, packets that fail any of the DA/SA filters, are dropped by the MAC receiver. However, packets that fail the DA/SA/VLAN filter can still be forwarded to the application when the RA field of the Packet filtering control register (ETH_MACPFR) is 1. Even when RA field is 0, VLAN filter fail packets can be forwarded if the VTFR field of the Packet filtering control register (ETH_MACPFR) is 0.

The ingress packets go through the following operations in decreasing order of priority.

1. 1. RA = 0: ingress packets are dropped if any of the following conditions is true.
   • – DA/SA filter fail
   • – VLAN filter fail and VTFR field of the Packet filtering control register (ETH_MACPFR) is 1
2. 2. RA = 1: ingress packets that fail the DA/SA filter are also forwarded to the Rx queue as mentioned in Table 765 .

Table 765. Routing DA/SA failed packets to Rx queue

1. 3. RA = 1 and VTFR = 0: ingress tagged packets that pass the DA/SA filter but fail the VLAN filter are forwarded to the Rx queue as mentioned in Table 766 .

1. 4. Ingress packets that pass the DA/SA/VLAN filters are forwarded to the Rx queue.
2. • – Table 767 shows the routing priority in the decreasing order when OMCBCQ field of the Rx queue control 0 register (ETH_MACRXQC0R) is 0.

• – Table 768 shows the routing priority in the decreasing order when OMCBCQ field of the Rx queue control 1 register (ETH_MACRXQC1R) is 1.

Note: The fields mentioned in Table 765 through Table 768 belong to Rx queue control 0 register (ETH_MACRXQC0R) , Rx queue control 1 register (ETH_MACRXQC1R) and Rx queue control 2 register (ETH_MACRXQC2R) .

Note: If the RxQ pointed by the various fields in Table 765 through Table 768 is not enabled in the Rx queue control 0 register (ETH_MACRXQC0R) as per the packet type, the packet is written to

• • RxQ0 for Express packets
• • FPRQ field for Preemptable packets

If RxQ0/FPRQ is not enabled, the packet is dropped.

Note: If the AV8021ASMEN field of the Timestamp control register (ETH_MACTSCR) is 1, MAC receiver checks only for untagged PTP packet. Packets tagged with PTP payload are considered as Remaining (Unicast/Broadcast/Multicast) tagged packets in Table 765 through Table 768 .

The priority field of the outer VLAN tag is considered for routing.

AV feature

The Ethernet peripheral supports the AV data transfer in 100-Mbps and 1000-Mbps modes. The AV feature enables transmission of time-sensitive traffic over bridged local area networks (LANs). The following standards define various aspects of the AV feature implementation:

• • IEEE 802.1Qav-2009: enables the bridges to provide time-sensitive and loss-sensitive real-time audio video data transmission (AV traffic). It specifies the priority regeneration and controlled bandwidth queue draining algorithms that are used in bridges and AV traffic sources.
• • IEEE 802.1Qat-2009: enables the network resources to be reserved for specific traffic streams traversing a bridged local area network.
• • IEEE 802.1AS-2011: specifies the protocol and procedures used to ensure that the synchronization requirements are met for time-sensitive applications such as audio and video across bridged and virtual-bridged LANs consisting of LAN media where the transmission delays are fixed and symmetrical. For example, IEEE 802.3 Full-duplex links include the maintenance of synchronized time during normal operation followed by addition, removal, or failure of network components and network reconfiguration.

While the AVB standards were originally designed for audio and video over standard Ethernet, extending these to control streams would additionally benefit the industrial and automotive sectors. Time sensitive networking (TSN) is a set of standards developed by the Time Sensitive Networking Task Group with the intent to extend the future AVB enhancements to other sectors that could benefit.

Bridges are increasingly used to interconnect devices that support scheduled applications (for example, industrial automation, process control and vehicle control). The IEEE 802.1Qbv-2015 (Enhancements to Scheduling Traffic) provides performance assurances of latency and delivery variation to enable these applications in an engineered LAN while maintaining the existing guarantees for the credit-based shaper and best-effort traffic.

The IEEE 802.3br (Interspersing Traffic) and IEEE 802.1Qbu (frame preemption) enables the suspension of a large preemptable packet being transmitted by the MAC layer to enable one or more express packets to be transmitted before the transmission of the preemptable packet is resumed. This provides the capability to schedule express traffic packets with minimal delays/latencies or at predictable times with efficient utilization of the line bandwidth.

As per the IEEE specification for 802.1Qbv, 802.1Qbu, and 802.3br, the TSN features are supported only in the following modes:

• • Full duplex
• • 100 Mbps or higher link speed
• • Pause or no flow control
• • When Qbv schedule is enabled for time-sensitive traffic, Pause or PFC is likely to interfere with the Qbv schedules. So, it is recommended not to enable PFC/PAUSE when Qbv scheduler is enabled.
• • Multiple Tx queues (for Qbv) enabled
• • One or more Express queues and one or more preemption queues on both transmit and receive (for Qbu/802.3br) enabled.

Transmit path functions

When the AV feature is selected, the Transmit paths of Tx queues are enabled by default.

The Transmit path of queue 0 supports the strict priority algorithm, and it is used for best-effort traffic. For a queue, the strict priority algorithm determines that a packet is available for transmission if the queue contains one or more packets. When the threshold mode for MTL Tx FIFO is enabled, the strict priority algorithm determines that a packet is available for transmission if the queue contains a partial packet of size equal to the programmed threshold limit.

The Transmit path of the AVB Tx queue supports traffic management by using the credit-based shaper algorithm. For a queue, the credit-based shaper algorithm determines that a queue is available for transmission if the following conditions are true:

• • The queue contains one or more packets.
• • The credit for the queue is positive as per the algorithm.

When the credit-based shaper algorithm is disabled for a queue, the channel uses the default strict priority algorithm.

Each Transmit DMA has a separate descriptor chain for fetching the transmit data. The Transmit channel that gets the access to the system bus depends on the DMA arbiter.

The Transmit path has a shared FIFO (MTL layer) for each queue. The data fetched by the DMA is put in the respective part of the FIFO. The MTL Tx Queue Scheduler controls which part of the FIFO data is transmitted by the MAC. If the credit-based shaper algorithm is enabled for queue 1, the queue is selected if the packet is available in the channel and has a positive or zero credit.

If the credit-based shaper algorithm is disabled for a given Tx queue, the packet to be transmitted is selected based on the fixed priority scheme as described in Table 769 .

Table 769. Weight for DMA channels

Receive path functions

When the AV feature is enabled, the receive path of Queue 0 is enabled by default. The whole traffic is received on this channel. The receive paths of additional queues can be enabled. By enabling the receive paths of multiple channels, the received data can be demultiplexed to send the packets into separate receive channels.

To differentiate between the AV and non-AV traffic, the MAC provides a status that indicates if the received packet is an AV packet as well as the corresponding VLAN Priority tag value. This status is updated in the Extended Status field of the receive descriptor as explained in Section 76.10.4: Receive descriptor . All received packets with an EtherType field of 0x22F0 are detected as AV packets. The AV packets can be of the following two types:

• AV data packets

AV data packets are always tagged. Tagged AV data packets are received following the programmed priority value. To specify the channel to which an AV packet with a given priority must be sent, program bits[15:8] in the transmit flow control register of the corresponding queue.

• AV control packets

The AV control packets can be either tagged or untagged. By default, untagged AV control packets are received on queue 0. To receive these packets on queue 1, program bits[2:0] of the Rx queue control 1 register (ETH_MACRXQC1R) . Similarly to the AV data packets, tagged AV control packets are received following the programmed priority value.

In addition to the AV packets, you can receive the untagged PTP packets on any queue. By default, the PTP packets (tagged or untagged) are received on queue 0. To receive these packets on any other queue, program bits[6:4] of the Rx queue control 1 register (ETH_MACRXQC1R) .

Credit-based shaper algorithm

The Queue Scheduler uses the credit-based shaper algorithm to arbitrate the AV traffic in all queues and the legacy Ethernet traffic in queue 0. Queue 1 can be programmed to use the credit-based shaper algorithm.

The following sections provide information on the credit-based shaper algorithm implementation:

• Credit value
• idleSlopeCredit and sendSlopeCredit values
• Bandwidth status

The credit value is accumulated every transmit clock cycle, that is every 40 ns in 100-Mbps mode and every 8 ns in 1000-Mbps mode. The credit to be added or subtracted per cycle can be fractional depending on the required idleSlope and sendSlope values, as described in Table 770 .

The DMA stores the queue traffic in the respective part of the Tx FIFO depending on the slot number in the transmit descriptor (if enabled) or the bandwidth availability on the AMBA application bus.

The credit for a queue builds up only when the packet is available, but it cannot be transmitted because the MAC is sending a packet from another queue. The Ethernet peripheral supports another mode in which the credit can build up in advance for a queue in which no packet is available in respective part of the FIFO. This enables sending a burst of high priority traffic in a queue as soon as the data is available. This mode can be enabled through the CC bit of the CBS control register ( Tx queue 1 ETS control register (ETH_MTLTXQ1ECR) ).

• • When reset, the accumulated credit parameter in the credit-based shaper algorithm is set to zero if there is positive credit, and there is no packet to transmit in a queue. The credit does not accumulate when there is no packet waiting in a queue and other queues are transmitting.
• • When set, the accumulated credit parameter in the credit-based shaper algorithm is not reset to zero if there is positive credit and no packet to transmit in a queue. The credit accumulates even when there is no packet waiting in a queue and other queues are transmitting.

The software must program the idleSlopeCredit and sendSlopeCredit values. The programmed values should be the credit accumulated or drained per clock cycle scaled by 1024 (such as \( 2.8 \times 1024 = 2867 \) and \( 1.2 \times 1024 = 1229 \) ). In addition, the software must program the hiCredit and loCredit values, scaled by 1024, to adjust for scaling of the idleSlopeCredit and sendSlopeCredit values. This means that if computed hiCredit and loCredit values are 12,000 bits and 3,036 bits respectively, the values to be programmed in the hiCredit and loCredit registers of the corresponding channel are \( 12000 \times 1024 \) bits and two's complement of \( 3036 \times 1024 \) , respectively.

Bandwidth status

The hardware maintains the status of the actual bandwidth consumed by each higher priority queue in the CBS status registers. This enables the software to estimate the average bandwidth consumed by numerically higher traffic classes as compared to the reserved bandwidth.

The CBS status register ( Tx queue x ETS status register (ETH_MTLTXQxESR) ) gives the average number of bits transmitted during the previous programmed slot interval (1, 2, 4, 8, or 16 slots of 125 µs) in a queue. The status register is updated even if the credit-based shaper algorithm is not enabled for a queue. The number of slots over which the average bits transmitted per slot are computed is programmed in bits[6:4] of the CBS control register of the respective queue. For example, if you have programmed two slots, the average bits are computed over slot numbers 0–1, 2–3, 4–5, and so on.

The value programmed in the idleSlopeCredit register of a queue is proportional to the bandwidth reserved for the queue. The software can allocate any bandwidth that is not used by the higher priority queue to the reserved bandwidth of the lower priority queue.

A lower priority queue, which is using the credit-based shaper algorithm, cannot use the unused reserved bandwidth of any higher priority queue that is using the credit-based shaper algorithm. However, a lower priority queue, which is using the strict-priority algorithm, can use the unused reserved bandwidth of any higher priority queue that uses the credit-based shaper algorithm. For example, queue 1 and queue 2 use the credit-based shaper algorithm (with reserved bandwidth of 50% and 25%, respectively) and queue 0 uses the strict-priority algorithm. If queue 1 uses only 40% of reserved bandwidth, the remaining 10% is used by queue 0. Queue 2 cannot exceed the reserved bandwidth of 25%.

Slot number function

When the AV feature is enabled, the slot number function can be used to schedule the data fetching from the system memory by the DMA. This feature is useful when the source AV data needs to be transmitted at specific intervals.

The slot number at which the DMA should fetch the data from system memory can be programmed in the transmit descriptor Word 3 (TDES3). This 4-bit field enables the application to schedule data fetching at up to 16 slots with a programmable slot interval that ranges from 1 µs to 4096 µs and a granularity of 1 µs. This field is applicable only to the AV channels.

When the DMA fetches a Tx descriptor, it compares the slot number of the Tx descriptor with the internally generated reference slot interval. The slot interval is a counter that is updated based on a programmable slot interval (with range from 1 µs to 4096 µs) of the IEEE 1588 system time. In addition, the slot interval counter is initialized to zero when the seconds field of the system time is incremented, that is, when the subsecond counter rolls over. The DMA fetches the data only if it matches the current slot or the next slot. The DMA remains in the descriptor fetch state until a match is found.

To enable the DMA to fetch data only if it matches the current slot or the next two slots, program bit 1 of the Channel x slot function control status register (ETH_DMACxSFCSR) of the corresponding DMA channel.

If the slot number in the descriptor is less than the reference slot number, the DMA considers it as a future slot.

The slot number check can be enabled by setting bit 0 in the Channel x slot function control status register (ETH_DMACxSFCR) of corresponding DMA channel. If this check is disabled, the packets are fetched immediately after the descriptor is read. In addition, bits [19:16] indicate the value of the reference slot number in DMA.

Programming guidelines for AV feature

See Section : Initializing the DMA on page 4137 .

See Section : Enabling slot number checking on page 4138 .

See Section : Enabling average bits per slot reporting on page 4138 .

Queue modes

A Tx queue can be enabled for generic or AV traffic. When multiple Tx queues are enabled for generic traffic, queuing is based on WRR or WSP algorithms.

When a Tx queue is enabled for AVB traffic, queuing is based on CBS or SP algorithms.

A Rx queue can be enabled for generic or AV traffic. A particular queue enabled for generic or AV based routing is determined by the RXQ0EN and RXQ1EN fields in the Rx queue control 0 register (ETH_MACRXQC0R) .

Below an explanation on how Rx queues are enabled based on the selected features:

• • Multiple Rx queues

When multiple Rx queues are selected, all queues are enabled for generic queuing based on the VLAN tag priority. The VLAN tag priority should match the PSRQ[7:0] bitfield of the Rx queue control 2 register (ETH_MACRXQC2R) . By default untagged packets are routed to receive queue specified in UPQ field of Rx queue control 1 register (ETH_MACRXQC1R) . Queue 0 is the default value of UPQ[2:0] bitfield. The default value can be overridden with any other value, for the UPQ[2:0] bitfield. The Rx packets can also be routed to a particular DMA channel based on the DCS field of the perfectly-matched MAC Address register ( MAC address x high register (ETH_MACAxHR) ).

• • Multiple Rx queues with AV feature

When AV is enabled for all selected Rx queues, the queuing is done based on the VLAN tag priority. The VLAN tag priority should match the PSRQ[7:0] bitfield of the Rx queue control 2 register (ETH_MACRXQC2R) . The Rx packets can also be routed to a particular DMA channel based on the DCS field of perfectly-matched MAC Address register ( MAC address x high register (ETH_MACAxHR) ). The AV control packets (tagged or untagged) are routed based on the AVCPQ[2:0] bitfield of the Rx queue control 1 register (ETH_MACRXQC1R) . The PTP over Ethernet packets are routed based on the PTPQ[2:0] bitfield of the Rx queue control 1 register (ETH_MACRXQC1R) .

76.5 Ethernet functional description: MAC

76.5.1 Double VLAN processing

The Ethernet peripheral supports the double VLAN (Virtual LAN) tagging feature in which the MAC can process up to two VLAN tags (inner and outer).

The MAC supports the following:

• • Insertion, replacement, or deletion of up to two VLAN tags in the Transmit path
• • Packet filtering and stripping based on any one of the two VLAN Tags in the receive path. Stripping and providing up to two VLAN Tags in the receive path as a part of the receive status

Transmit path

Table 771: Double VLAN processing features in Tx path describes the features supported by the MAC on the Transmit side.

Table 771. Double VLAN processing features in Tx path

Receive path

Table 772: Double VLAN processing in Rx path describes the features supported by the MAC on the receive side and the corresponding bits in the VLAN tag Control register (ETH_MACVTCR) .

Table 772. Double VLAN processing in Rx path

76.5.2 Source address and VLAN insertion, replacement, or deletion

Source address insertion or replacement

The software can use the SA (source address) insertion or replacement feature to instruct the MAC to do the following for Tx packets:

• • Insert the content of the MAC Address registers in the SA field
• • Replace the content of the SA field with the content of the MAC Address registers

When SA insertion is enabled, the application must ensure that the packets sent to the MAC do not have the SA field. The MAC does not check whether the SA field is present in the Transmit packet and it inserts the content of MAC Address Registers in the SA field. Similarly, when SA replacement is enabled, the application must ensure that the SA field is present in the packets sent to the MAC. The MAC replaces the six bytes following the Destination Address field in the Transmit packet with the content of the MAC Address Registers.

SA insertion or replacement feature can be enabled for all Transmit packets or selective packets:

• • Enabling SA insertion or replacement for all packets
  To enable this feature for all packets, program the SARC field of the Operating mode configuration register (ETH_MACCR) .
• • Enabling SA insertion or replacement for selective packets
  To enable this feature for selective packets, use the following program the SA Insertion Control field (bits[25:23] of transmit descriptor Word 3/TDES3, refer to Section 76.10.3: Transmit descriptor ) in the first Transmit descriptor of the packet. When Bit 25 of TDES3 is set, the SA Insertion Control field indicates insertion or replacement by MAC

Address1 registers. When bit 25 of TDES3 is reset, it indicates insertion or replacement by MAC Address 0 registers.

If MAC Address1 registers are not enabled, the MAC Address0 registers are used for insertion or replacement whatever of the value of the most-significant bit of the SA Insertion Control field.

VLAN insertion, replacement, or deletion

The software can use the VLAN insertion, replacement, or deletion feature to instruct the MAC to do the following for Tx packets:

• • Delete the VLAN Type and VLAN Tag fields
• • Insert or replace the VLAN Type and VLAN Tag fields

Insertion or replacement is performed based on the setting of VLTI bit in the VLAN inclusion register (ETH_MACVIR) as described in Table 773: VLAN insertion or replacement based on VLTI bit .

Table 773. VLAN insertion or replacement based on VLTI bit

When VLAN replacement or deletion is enabled, the MAC checks if the VLAN Type field (0x8100 or 0x88A8) is present after the DA and SA fields in the Transmit packet. The replace or delete operation does not occur if the VLAN Type field is not detected in two bytes following the DA and SA fields. However, when VLAN insertion is enabled, the MAC does not check the presence of VLAN Type field in the Transmit packet and just inserts the VLAN Type and VLAN Tag fields.

You can enable the VLAN insertion, replacement, or deletion feature for all Tx packets or selective packets:

• • To enable this feature for all packets, program the VLC and VLP fields of VLAN inclusion register (ETH_MACVIR) .
• • To enable this feature for selective packets, program the VTIR field of TDES2 Normal Descriptor (see Table 823: TDES2 normal descriptor (read format) ).

In addition, the VLP (VLAN Priority control) bit must be reset in VLAN inclusion register (ETH_MACVIR) (for outer VLAN) and Inner VLAN inclusion register (ETH_MACVIR) (in inner VLAN) for the MAC to take the control inputs from the host, depending on the configuration.

76.5.3 Queue/channel-based VLAN tag insertion on Tx

The peripheral supports channel/queue based VLAN tag insertion on all transmitted packets.

Accessing queue/channel specific VLAN tag registers

Queue/channel specific VLAN tag registers are accessed using indirect addressing through the VLAN inclusion register ( VLAN inclusion register (ETH_MACVIR) ). VLAN type and tag value can be independently programmed for each queue/channel.

Enabling queue/channel based VLAN tag insertion on Tx

To enable this feature, set the CBTI bitfield in the VLAN inclusion register ( VLAN inclusion register (ETH_MACVIR) ). The VLAN tag is then inserted on every packet that is transmitted from a queue/channel, with the programmed tag value taken from queue/channel specific VLAN tag register

Programming guidelines for channel based VLAN tag insertion

See Section 76.9.19: Programming sequence for queue/channel- based VLAN inclusion register on page 4145 .

76.5.4 Packet filtering

The MAC supports the following types of filtering for Rx packets:

• • MAC source or destination address filtering : the Address Filtering Module (AFM) checks the source address and destination address fields of each incoming packet.
• • VLAN filtering : the MAC supports the VLAN tag-based and VLAN Hash filtering.
• • Layer 3 and Layer 4 filtering : Layer 3 filtering refers to IP source address and destination address filtering. Layer 4 filtering refers to source port and destination port filtering.

The three filter types can be cascaded. Figure 1025 shows the filtering sequence for Rx packets.

Figure 1025. Packet filtering sequence

graph TD
    Start[Receive Packet] --> F1[Ethernet DA or SA Filter]
    F1 -- Fail --> Discard[Discard Packet]
    F1 -- Pass --> F2[VLAN Filter]
    F2 -- Fail --> Discard
    F2 -- Pass --> F3[IP SA or DA Filter]
    F3 -- Fail --> Discard
    F3 -- Pass --> F4[TCP or UDP SP or DP Filter]
    F4 -- Fail --> Discard
    F4 -- Pass --> Host[Deliver to the Host]
  

The sequence shown in Figure 1025 is valid when all the filters (L2, VLAN, L3, L4) are active. If any of the Layer filters are not enabled, that filter is bypassed and the subsequent filter is applied. A packet that fails any of the filters is discarded. However, the discarded packet can be forwarded to the host based on the register control.

For example, when RA bit of Packet filtering control register (ETH_MACPFR) is set to 1, all the discarded packets are forwarded to the host but with their packet status indicating the specific filter failure. If RA bit is cleared to 0, VTPE and IPPE bits of Packet filtering control register (ETH_MACPFR) control if the packets that fail the VLAN filter and Layer 3-4 filter should be discarded or forwarded to the host.

MAC source or destination address filtering

The MAC address filtering module checks the source address (SA) and destination address (DA) fields of each incoming packet.

Unicast destination address filtering

The MAC supports 4 MAC addresses for unicast perfect filtering. If perfect filtering is selected (HUC bit of Packet filtering control register (ETH_MACPFR) is reset), the MAC compares all 48 bits of received unicast address with the programmed MAC address for any match. The default MacAddr0 is always enabled.

The MacAddr1 to MacAddr3 addresses are selected with an individual enable bit. You can mask each byte during comparison with corresponding received DA byte by setting the corresponding Mask Byte Control bit in MAC address x high register (ETH_MACAxHR) . This enables group address filtering for the DA.

In Hash filtering mode (when HUC bit is set), the MAC performs imperfect filtering for unicast addresses using a 64-bit Hash table. For Hash filtering, the MAC uses the upper 6 bits CRC of the received destination address to index the content of the Hash table. A value of 00000 selects bit 0 of selected register, and a value of 11111 selects bit 63 of Hash Table register. If the corresponding bit (indicated by the 6-bit CRC) is set to 1, the unicast packet is considered to have passed the Hash filter; otherwise, the packet is considered to have failed the Hash filter.

Multicast destination address filtering

To program the MAC to pass all multicast packets, set the PM bit in Packet filtering control register (ETH_MACPFR) . If the PM bit is reset, the MAC performs the filtering for multicast addresses based on the HMC bit of the Packet filtering control register (ETH_MACPFR) .

In Perfect filtering mode, the multicast address is compared with the programmed MAC destination address registers. Group address filtering is also supported.

In Hash filtering mode, the MAC performs imperfect filtering using a 64-bit Hash table. The MAC uses the upper 6-bits CRC of received multicast address to index the content of the Hash table. A value of 000000 selects bit 0 of selected register and a value of 111111 selects bit 63 of the Hash Table register. If the corresponding bit is set to 1, the multicast packet is considered to have passed the Hash filter. Otherwise, the packet is considered to have failed the Hash filter.

Hash or Perfect address filtering

To configure the DA filter to pass a packet when its DA matches either the Hash filter or the Perfect filter, set the HPF bit and the corresponding HUC or HMC bits in Packet filtering control register (ETH_MACPFR) . This is applicable to both unicast and multicast packets. If the HPF bit is reset, only one of the filters (Hash or Perfect) is applied to receive packet.

Broadcast address filtering

The MAC does not filter any broadcast packets by default. To program the MAC to reject all broadcast packets, set the DBF bit in Packet filtering control register (ETH_MACPFR) .

Unicast source address filtering

The MAC can perform perfect filtering based on the source address field of received packets. By default, the MAC compares the SA field with the values programmed in the SA registers. You can configure the MAC Address registers to use SA instead of DA for comparison by setting bit 30 of MAC address x high register (ETH_MACAxHR) .

The MAC also supports group filtering with SA. You can filter a group of addresses by masking one or more bytes of the address. The MAC drops the packets that fail the SA filter if the SAF bit is set in Packet filtering control register (ETH_MACPFR) . Otherwise, the result of the SA filter is given as a status bit in the receive Status word (see Table 775 ). When the SAF bit is set, the SA filter and DA filter result is ANDed to decide whether the packet needs to be forwarded. This means that the packet is dropped if either filter fails. The packet is forwarded to the application only if the packet passes both filters in-order.

Inverse filtering

For DA and SA filtering, you can invert the filter-match result at the final output by setting the DAIF and SAIF bits of Packet filtering control register (ETH_MACPFR) . The DAIF bit is applicable for both Unicast and Multicast DA packets. The result of the unicast or multicast destination address filter is inverted in this mode. Similarly, when the SAIF bit is set, the result of unicast SA filter is reversed.

Table 774 and Table 775 summarize the DA and SA filtering based on the type of packets received.

Note: When the RA bit of Packet filtering control register (ETH_MACPFR) is set, all packets are forwarded to the system along with the correct result of the address filtering in the Rx status.

Table 774. Destination address filtering

Table 775. Source address filtering

VLAN filtering

The MAC supports Perfect and Hash VLAN filtering. Refer to Section 76.9.17: Programming guidelines to perform VLAN filtering on the receiver for detailed programming steps.

VLAN tag Perfect filtering

In VLAN tag Perfect filtering, the MAC compares the VLAN tag of received packet and provides the VLAN packet status to the application. Based on the programmed mode, the MAC compares the lower 12 bits or all 16 bits of received VLAN tag to determine the perfect match.

If VLAN tag Perfect filtering is enabled, the MAC forwards the VLAN-tagged packets along with VLAN tag match status and drops the VLAN packets that do not match. You can also enable the inverse matching for VLAN packets by setting the VTIM bit of VLAN tag Control register (ETH_MACVTCR) . In addition, you can enable matching of S-VLAN tagged packets along with the default C-VLAN tagged packets by setting the ESVL bit of VLAN tag Control register (ETH_MACVTCR) . The VLAN packet status bit (bit 10 of RDES0) indicates the VLAN tag match status for the matched packets.

Note: The source or destination address (if enabled) has precedence over the VLAN tag filters. This means that a packet that fails the source or destination address filter is dropped irrespective of the VLAN tag filter results.

VLAN tag Hash filtering

The 16-bit VLAN Hash Table is used for group address filtering based on the VLAN tag. The VLAN tag Hash filtering feature can be enabled using the VTHM (VLAN tag Hash Table match enable) bit of the VLAN tag Control register (ETH_MACVTCR) . If the VTHM bit is set, the most significant four bits of CRC-32 of VLAN tag are used to index the content of the VLAN Hash Table register. A value of 1 in the VLAN Hash Table register, corresponding to the index, indicates that the VLAN tag of the packet matched and the packet should be forwarded. A value of 0 indicates that VLAN-tagged packet should be dropped.

Note: The 16 or 12 bits of VLAN Tag are considered for CRC-32 computation based on ETV bit in ETH_MACVTR register.

When ETV bit is reset, most significant four bits of CRC-32 of VLAN Tag are inverted and used to index the content of VLAN Hash table register (ETH_MACVHTR) .

When ETV bit is set, most significant four bits of CRC-32 of VLAN Tag are directly used to index the content of VLAN tag Control register (ETH_MACVTCR) .

The MAC also supports the inverse matching for VLAN packets. In the inverse matching mode, when the VLAN tag of a packet matches the Perfect or Hash filter, the packet should be dropped. If the VLAN perfect and VLAN Hash match are enabled, a packet is considered as matched if either the VLAN Hash or the VLAN perfect filter matches. When inverse

match is set, a packet is forwarded only when both perfect and Hash filters indicate mismatch.

Table 776 shows the different possibilities for VLAN matching and the final VLAN match status. When the RA bit of Packet filtering control register (ETH_MACPFR) is set, all packets are received and the VLAN match status is indicated in the VF bit of RDES2 normal descriptor (write-back format) . When the RA bit is not set and the VTFE bit is set in Packet filtering control register (ETH_MACPFR) , the packet is dropped if the final VLAN match status is Fail. In Table 776 , value X means that this column can have any value.

When VLAN VID is programmed to 0 in the VL field of VLAN tag Control register (ETH_MACVTCR) , all VLAN-tagged packets are considered as perfect matched but the status of the VLAN Hash match depends on the VTHM and VTIM bits in VLAN tag Control register (ETH_MACVTCR) .

Table 776. VLAN match status ⁽¹⁾

1. In this table, 'X' represents any value.

Extended receive VLAN filtering and routing

The MAC receiver can classify the received packets based on VLAN tag, and steer them to a specific Rx DMA channel. The MAC compares the VLAN tag of the received frame with all the enabled and relevant filters, and provides a filtering result. If any of the perfect filters give a pass result and if the respective filter DMA channel number is enabled, the frame is routed to that DMA channel.

In addition to filtering, routing can also be done. For more details about routing, see Extended VLAN-based DMA selection in Section 76.4.4: Multiple channels and queues support .

Comparison modes

For each VLAN tag filter, the application has the following comparison options:

• • It can program the MAC to compare an outer VLAN tag or an inner VLAN tag with the programmed VID.
• • It can choose if 12 or 16 bits of the VID field need to be compared.
• • Type check can be disabled or enabled for each filter. If enabled, the application can choose if the VID comparison is for SVLAN or CVLAN type frames only.

For example, if a filter is enabled for 16-bit comparison, SVLAN type, and Outer VLAN tag, any single or double VLAN-tagged frames with Outer SVLAN tags are compared with this filter, and a pass or fail result is obtained.

Note: The inner VLAN tag comparison is applicable only if Double VLAN tag processing is enabled in VLAN tag Control register (ETH_MACVTCR) .

Filtering

When the Extended RX VLAN filtering and routing feature is enabled, the application can enable both perfect and Hash filtering. The overall VLAN filter result is based on the perfect filter result and the Hash filter result (if enabled). The filter result is passed to the application as part of the status bits.

Perfect filtering is done based on the MAC VLAN tag filters defined in VLAN tag data register (ETH_MACVTDR) . For each VLAN tag filter, the MAC compares the relevant VLAN tag ID and provides a result. If any one of the VLAN tag filters gives a match, the frame is considered to have passed the VLAN tag filters. If the frame mismatches all the filters, the frame is considered to have failed the VLAN filter. This behavior is applicable only when the inverse filtering is not enabled in the VLAN tag Control register (ETH_MACVTCR) .

If inverse filtering is enabled and the frame has mismatched all the relevant filters, then it is considered to have passed the VLAN filter. If the frame matches any one of the relevant filters, then it is considered as a fail. If none of the enabled filters can perform a comparison or if none of the filters are enabled, then the frame is bypassed to the application.

The overall filter result and the values programmed in the VTFE and RA bitfields of the Packet filtering control register (ETH_MACPFR) determine if the frame must be dropped or forwarded to the application:

• • When RA = 1 or VTFE = 0
  The MAC forwards the frame, irrespective of the filter result.
• • When RA = 0 and VTFE = 1
  The MAC forwards the frame only if the VLAN tag filter status is pass. After forwarding a frame to the application, the relevant filter result is indicated through the status bits.

Programming guidelines for Extended VLAN filtering and routing on reception

See Section 76.9.18: Programming guidelines for extended VLAN filtering and routing on reception on page 4144 .

VLAN filter status

The Extended receive VLAN filtering and routing feature provides two status bits to indicate the comparison result of the VLAN tags.

By default, the MAC indicates the VLAN filter status through one bit in the status (VF) in RDES2. When the Extended receive VLAN filtering and routing is enabled, two status bits

are used to indicate the comparison result of VLAN tags. The Outer VLAN tag filter pass and Inner VLAN tag filter pass bits are defined in the following positions in various configurations. The status indicated through these bits is highly dependent on how the fields are programmed:

• • In RDES2:
  • – Bit 15: Outer VLAN tag filter status
  • – Bit 14: Inner VLAN tag filter status
• • Outer VLAN tag filter status (OTS)
  • – In perfect filtering, without inverse filtering enabled, if this bit is set, it indicates that the frame Outer VLAN tag has matched one of the VLAN tag filters.
  • – If this bit is reset, it indicates that the frame Outer VLAN tag has either failed the relevant Outer VLAN tag filters or bypassed them.
  • – If none of the filters are enabled for Outer VLAN tag comparison, then this bit is reset.
  • – If inverse filtering is enabled and this bit is set, then the frame VLAN tag has passed all the relevant VLAN tag filters. If it is reset, then it has failed at least one of the filters or bypassed all the filters programmed for Outer VLAN tag comparison.
  • – This bit is valid for both Single and Double VLAN-tagged frames.
• • Inner VLAN Tag Filter Status (ITS)
  • – In perfect filtering, without inverse filtering enabled, if this bit is set, it indicates that the frame Inner VLAN tag has matched one of the VLAN tag filters.
  • – If this bit is reset, it indicates that the frame Inner VLAN tag has either failed the relevant Inner VLAN tag filters or bypassed them.
  • – If none of the filters are enabled for Inner VLAN tag comparison, then this bit is reset.
  • – If inverse filtering is enabled and this bit is set, then the frame VLAN tag has passed all the relevant VLAN tag filters. If it is reset, then it has failed at least one of the filters or bypassed all the filters programmed for Inner VLAN tag comparison.
  • – This bit is valid for only Double VLAN-tagged frames, when Double VLAN processing is enabled.

The application must monitor the status bits and the programming to determine if the frame has passed or failed the VLAN filter.

Table 777 and Table 778 show the possible filter combinations and the corresponding filter results. These tables explain the scenarios when Double VLAN processing and Hash VLAN filter are enabled.

Table 777 shows the possible values of OTS and ITS status bits when at least one perfect filter is enabled.

Legend for Table 777 :

• • VTIM - VLAN Tag Inverse Match Enable: bit 17 of VLAN tag Control register (ETH_MACVTCR) .
• • HFO - Hash Filter enabled for Outer VLAN Tag Comparison: bit 26 and bit 27 of VLAN tag Control register (ETH_MACVTCR) .
• • HFI - Hash Filter enabled for Inner VLAN Tag Comparison: bit 26 and bit 27 of VLAN tag Control register (ETH_MACVTCR) .
• • PFO - Perfect filter comparison enabled for Outer VLAN Tag: any of the MAC VLAN tag filters in VLAN tag data register (ETH_MACVTDR) is enabled (bit 16 is set) and programmed for Outer VLAN tag comparison (bit 20 is set to 0).
• • PFI - Perfect Filter comparison enabled for Inner VLAN Tag: any of the MAC VLAN tag filters in VLAN tag data register (ETH_MACVTDR) is enabled (bit 16 is set) and programmed for Inner VLAN tag comparison (bit 20 is set to 1).
• • OTS - Outer VLAN tag filter status
• • ITS - Inner VLAN tag filter status

Table 777. OTS and ITS bit values with at least one perfect filter enabled

Table 778 shows the possible values of OTS and ITS status bits when none of the perfect filters are enabled and only the VLAN Hash filter is enabled.

• • When no perfect filters are enabled, any VLAN packet is considered to have bypassed the perfect filter.
• • When VLAN Hash filter is enabled for one of the tags, the respective status bit depends on the result of the filter. Status bits are set to 0 when VLAN Hash filter is not enabled.
• • The value 1/0 for the ITS/OTS field indicates that the final result depends on the result of the enabled relevant filter.

The second row of Table 778 indicates that at least one perfect filter is enabled for Outer VLAN tag comparison and none of the filters are enabled for Inner VLAN tag comparison. Inverse VLAN filtering is not enabled. The bit OTS is given as 1/0. If the received frame passes at the least one of the enabled Outer VLAN tag filters, then the bit is set to 1. If the frame does not pass any of the enabled Outer VLAN tag filters, then the bit is set to 0.

The last row of Table 778 indicates that inverse filtering is enabled, Hash filter and at least one perfect filter is enabled for Inner VLAN tag comparison. If the received frame Inner VLAN tag mismatches with both the Hash filter and all the enabled perfect filters, then the frame has the ITS bit set to 1. Otherwise, the bit is set to 0. OTS bit is set to 0 as comparison is not performed.

Each of the VLAN tags has individual control over stripping. The programming options of always strip, never strip, strip on pass and strip on fail are available. Inner or Outer VLAN tag stripping is based on the pass or fail results of the individual tag. If a tag is bypassed by all the relevant filters, stripping is not applicable for the tag.

• • If strip-on-pass is enabled for the outer VLAN tag, stripping is done only if the Outer VLAN tag has passed the relevant filters. The Outer VLAN tag filter result bit is set.
• • If strip-on-fail is enabled for the outer VLAN tag, stripping is done only if the Outer VLAN tag has failed the relevant filters. The Outer VLAN Tag Filter Result Bit is reset.
• • If the Outer VLAN tag of the received frame is bypassed by the entire filter (no comparison has been made), the tag is not stripped, though the status bit is still 0.
• • As multiple filters are enabled, it is possible that the received VLAN frame matches more than one filters. The VLAN tag value is not always deterministic from the filter status bits.
• • If the application strips the VLAN tag based on the filter result, it might lose the VID. So, if stripping is enabled for any of the tags, the tag can be put in the status. The

application must enable the respective "VLAN Tag in Status" bit[24] or bit[31] in the VLAN tag Control register (ETH_MACVTCR) .

VLAN filter fail packet queue

When VLAN filtering is enabled, the VLAN filter fail packets can be routed to a programmable queue (VFFQ) when RA = 1 or VTFT = 0 and the enable bit (VFFQE) for the queue is set:

• • RA and VTFT bits are implemented in Packet filtering control register (ETH_MACPFR) .
• • VFFQ and VFFQE fields are implemented in Rx Queue control register (ETH_MACRXQCR) .

The packets that pass the VLAN filtering are routed based on the VLAN tag priority field. The VLAN tag priorities can be assigned to Rx queues by programming the PSRQ bitfield in Rx queue control 2 register (ETH_MACRXQC2R) . The packets that fail the VLAN filter are discarded if RA = 0 or VTFT = 1. However when RA = 1 or VTFT = 0, the VLAN filter fail packets are still forwarded to the application. In such a scenario, when the VLAN Filter Fail Queue Enable (VFFQE) bit is set, the VLAN filter fail packets are forwarded to the Rx queue number programmed in the VFFQ bit. If VFFQE = 0, the Rx queue number is determined by the VLAN priority mapping as per the PSRQ bitfield.

Table 779 shows the Rx queue routing table for Unicast tagged packets, with DA/SA filter enabled.

Table 779. Rx Queue routing table for Unicast-tagged packets ⁽¹⁾

1. X = Don't care condition.

2. When UFFQE is enabled, else PSRQ.

Layer 3 and Layer 4 filtering

The MAC supports Layer 3 and Layer 4 based packet filtering. The Layer 3 filtering refers to the IP Source or Destination Address filtering in the IPv4 or IPv6 packets whereas Layer 4 filtering refers to the Source or Destination Port number filtering in TCP or UDP.

The Layer 3 and Layer 4 packet filtering feature automatically enables the IPC Full Checksum Offload Engine on the receive side. For Layer 3 or Layer 4 filtering operation, you must set the IPC bit of the Operating mode configuration register (ETH_MACCR) to enable the Rx Checksum Offload engine.

When Layer 3 and Layer 4 filtering is enabled, the packets are filtered in the following way:

• • Matched packets

The MAC forwards the packets that match all enabled fields to the application along with the status. The MAC gives the matched field status only if the IPC bit of Operating mode configuration register (ETH_MACCR) is set and one of the following conditions is true:

• – All enabled Layer 3 and Layer 4 fields match.
• – At least one of the enabled field matches and other fields are bypassed or disabled

When multiple Layer 3 and Layer 4 filters are enabled, any filter match is considered as a match. If more than one filter matches, the MAC provides the status of the lowest filter where Filter 0 is the lowest filter and Filter 3 is the highest filter. For example, if Filter 0 and Filter 1 match, the MAC gives the status corresponding to filter 0.

Note: The source or destination address and VLAN tag filters (if enabled) have precedence over Layer 3 and Layer 4 filter. This means that a packet which fails the source or destination address or VLAN tag filter is dropped irrespective of the Layer 3 and Layer 4 filter results.

• • Unmatched packets

The MAC drops the packets that do not match any of the enabled fields. You can use the inverse match feature to block or drop a packet with specific TCP or UDP over IP fields and forward all other packets. The aborted or partial packets are dropped in the MTL Rx FIFO. If the Rx FIFO operates in the Threshold (cut-through) mode and the threshold is programmed to a small value. Such packet transfer to the application starts before the failed Layer 3 and Layer 4 filter results are available, the application may receive a partial packet with appropriate abort status.

• • Non-TCP or UDP IP Packets

By default, all non-TCP or UDP IP packets are bypassed from the Layer 3 and Layer 4 filters. You can optionally program the MAC to drop all non-TCP or UDP over IP packets.

Layer 3 filtering

The MAC supports perfect matching or inverse matching for IP Source Address and Destination Address. In addition, you can match the complete IP address or mask the lower bits matching, that is, compare all bits of the address except the specified lower mask bits.

For IPv6 packets filtering, you can enable the last four data registers of a register set to contain the 128-bit IP Source Address or IP Destination Address. The IP Source Address or Destination Address should be programmed in the order defined in the IPv6 specification, that is, the first byte of the IP Source Address or Destination Address in the received packet is in the higher byte of the register and the subsequent registers follow the same order.

For IPv4 packet filtering, you can enable the second and third data registers of a register set to contain the 32-bit IP Source Address and IP Destination Address. The remaining two data registers are reserved. The IP Source Address or Destination Address should be programmed in the order defined in the IPv4 specification, that is, the first byte of IP Source Address and Destination Address in the received packet in the higher byte of the respective register.

Layer 4 filtering

The MAC supports perfect matching or inverse matching for TCP or UDP Source and Destination Port numbers. However, you can program only one type (TCP or UDP) at a time. The first data register contains the 16-bit Source and Destination Port numbers of TCP or UDP, that is, the lower 16 bits for Source Port number and higher 16 bits for Destination Port number.

The TCP or UDP Source and Destination Port numbers should be programmed in the order defined in the TCP or UDP specification, that is, the first byte of TCP or UDP Source and Destination Port number in the received packet is in the higher byte of the register.

Layer 3 and Layer 4 filters register set

The MAC implements two sets of registers for Layer 3 and Layer 4 based packet filtering. In a register set, there is a control register, such as L3 and L4 control 0 register (ETH_MACL3L4C0R) , to control the packet filtering. In addition, there are five address registers to program the Layer 3 and Layer 4 fields to be matched, such as:

• • Layer4 address filter 0 register (ETH_MACL4A0R)
• • Layer3 address 0 filter 0 register (ETH_MACL3A00R)
• • Layer3 address 1 filter 0 register (ETH_MACL3A10R)
• • Layer3 address 2 filter 0 register (ETH_MACL3A20R)
• • Layer3 address 3 filter 0 register (ETH_MACL3A30R)

The second, and independent set of registers are: L3 and L4 control 1 register (ETH_MACL3L4C1R) , Layer 4 address filter 1 register (ETH_MACL4A1R) , Layer3 address 0 filter 1 Register (ETH_MACL3A01R) , Layer3 address 1 filter 1 register (ETH_MACL3A11R) , Layer3 address 2 filter 1 Register (ETH_MACL3A21R) and Layer3 address 3 filter 1 register (ETH_MACL3A31R) .

76.5.5 IEEE 1588 timestamp support

The IEEE 1588 standard defines a precision time protocol (PTP) which allows precise synchronization of clocks in measurement and control systems implemented with technologies such as network communication, local computing, and distributed objects. The PTP applies to systems communicating by local area networks supporting multicast messaging, including (but not limited to) Ethernet. This protocol enables heterogeneous systems that include clocks of varying inherent precision, resolution, and stability to synchronize. The protocol supports system-wide synchronization accuracy in the submicrosecond range with minimal network and local clock computing resources.

This chapter contains the following sections:

• • IEEE 1588 timestamp support
• • IEEE 1588 system time source
• • IEEE 1588 auxiliary snapshots
• • Flexible pulse-per-second output

• • PTP timestamp offload function
• • One-step timestamp"

IEEE 1588 timestamp support

The Ethernet peripheral supports the IEEE 1588-2002 (version 1) and IEEE 1588-2008 (version 2). The IEEE 1588-2002 supports PTP transported over UDP/IP. The IEEE 1588 2008 supports PTP transported over Ethernet. The peripheral provides programmable support for both standards. It supports the following features:

• • Support of both timestamp formats
• • Optional snapshot of all packets or only PTP type packets
• • Optional snapshot of only event messages
• • Optional snapshot based on the clock type: ordinary, boundary, end-to-end transparent, and peer-to-peer transparent
• • Optional selection of the node to act as master or slave for ordinary and boundary clock
• • Identification of the PTP message type, version, and PTP payload in packets sent directly over Ethernet and sends the status
• • Optional measurement subsecond time in digital or binary format

Clock types

The MAC supports the following clock types defined in the IEEE 1588-2008 specifications:

• • Ordinary clock

The ordinary clock of a domain supports a single copy of the protocol. It has a single PTP state and a single physical port. In typical industrial automation applications, an ordinary clock is associated with an application device such as a sensor or an actuator. In telecom applications, the ordinary clock can be associated with a timing demarcation device.

The ordinary clock can be a grandmaster or a slave clock. It supports the following features:

• – Transmission and reception of PTP messages. The timestamp snapshot can be controlled as described in Timestamp control register (ETH_MACTSCR) .
• – Maintenance of the data sets such as timestamp values.

The table below shows the messages for which you can take the timestamp snapshot on the receive side for master and slave nodes.

Table 780. Ordinary clock: PTP messages for snapshot

For an ordinary clock, you can take the snapshot of either of the following PTP message types: version 1 or version 2. You cannot take the snapshots for both PTP message types. You can take the snapshot by setting the TSVER2ENA bit and selecting the snapshot mode in Timestamp control register (ETH_MACTSCR) .

• • Boundary clock

The boundary clock typically has several physical ports which communicate with the network. The messages related to synchronization, master-slave hierarchy, and signaling end in the protocol engine of the boundary clock. Such messages are not forwarded. The PTP message type status given by the MAC helps to identify the type of message and take appropriate action.

The boundary clock is similar to the ordinary clock except for the following features:

• – The clock data sets are common to all ports of the boundary clock.
• – The local clock is common to all ports of the boundary clock.
• • End-to-end transparent clock

The end-to-end transparent clock supports the end-to-end delay measurement mechanism between the slave clocks and the master clock. The end-to-end transparent clock forwards all messages like normal bridge, router, or repeater. The residence time of a PTP packet is the time taken by the PTP packet from the ingress port to the egress port.

The residence time of a SYNC packet inside the end-to-end transparent clock is updated in the correction field of the associated Follow_Up PTP packet before it is transmitted. Similarly, the residence time of a Delay_Req packet, inside the end-to-end transparent clock, is updated in the correction field of the associated Delay_Resp PTP packet before it is transmitted. Therefore, the snapshot needs to be taken at both ingress and egress ports only for the messages mentioned in Table 781 . You can take the snapshot by setting the SNAPTYPSEL bits to 10 in the Timestamp control register (ETH_MACTSCR) .

Table 781. End-to-end transparent clock: PTP messages for snapshot

• • Peer-to-peer transparent clock

In the peer-to-peer transparent clock, the computation of the link delay is based on an exchange of Pdelay_Req, Pdelay_Resp, and Pdelay_Resp_Follow_Up messages with the link peer.

The peer-to-peer transparent clock differs from the end-to-end transparent clock in the way it corrects and handles the PTP timing messages. In all other aspects, it is identical to the end-to-end transparent clock.

The residence time of the Pdelay_Req and the associated Pdelay_Resp packets is added and inserted into the correction field of the associated Pdelay_Resp_Followup packet. Therefore, support for taking snapshot for the event messages related to Pdelay is added as shown in Table 789 .

Table 782. Peer-to-peer transparent clock: PTP messages for snapshot

You can take the snapshot by setting the SNAPTYPESEL bit to 11 in Timestamp control register (ETH_MACTSCR) .

Delay request-response mechanism

The system or network is classified into the master and slave nodes for distributing the timing and clock information. Figure 1026 shows the process that PTP uses for synchronizing a slave node with a master node by exchanging PTP messages.

Figure 1026. Networked time synchronization

sequenceDiagram
    participant Master as Master clock time
    participant Slave as Slave clock time
    Note over Slave: Data at slave clock
    Master->>Slave: Sync message (t1)
    Note right of Slave: t2
    Master->>Slave: Follow_up message containing value of t1 (t2m)
    Note right of Slave: t1, t2
    Slave->>Master: Delay_Req message (t3m)
    Note right of Slave: t1, t2, t3
    Master->>Slave: Delay_Resp message containing value of t4 (t4)
    Note right of Slave: t1, t2, t3, t4

As shown in Figure 1026 , the PTP uses the following process:

1. 1. The master broadcasts the PTP Sync messages to all its nodes. The Sync message contains the reference time information of the master. This message leaves the system of the master at \( t_1 \) . This time must be captured for Ethernet ports at GMII or MII.
2. 2. The slave receives the SYNC message and also captures the exact time, \( t_2 \) , using its timing reference.
3. 3. The master sends a Follow_up message to the slave, which contains \( t_1 \) information for later use.
4. 4. The slave sends a Delay_Req message to the master and notes the exact time, \( t_3 \) , at which this packet leaves the GMII or MII interface.

1. 5. The master receives the message, capturing the exact time \( t_4 \) , at which the message enters its system.
2. 6. The master sends the \( t_4 \) information to the slave in the Delay_Resp message.
3. 7. The slave uses the four values of \( t_1 \) , \( t_2 \) , \( t_3 \) , and \( t_4 \) to synchronize its local timing reference with the timing reference of the master.

Most of the PTP implementation is done in the software above the UDP layer. However, the hardware support is required to capture the exact time when specific PTP packets enter or leave the Ethernet port at the GMII or MII interface. This timing information must be captured and returned to the software for proper implementation of PTP with high accuracy.

Peer-to-peer PTP transparent clock (P2P TC) message support

The IEEE 1588-2008 standard supports peer-to-peer PTP (Pdelay) message in addition to the Sync, Delay Request, Follow_up, and Delay Response messages. Figure 1027 shows the method to calculate the propagation delay in clocks supporting peer-to-peer path correction.

Figure 1027. Propagation delay calculation in clocks supporting peer-to-peer path correction

As shown in Figure 1027 , the propagation delay is calculated as follows:

1. 1. Port 1 issues a Pdelay_Req message and generates a timestamp ( \( t_1 \) ) for the Pdelay_Req message.
2. 2. Port 2 receives the Pdelay_Req message and generates a timestamp ( \( t_2 \) ) for this message.

1. 3. Port 2 returns a Pdelay_Resp message and generates a timestamp ( \( t_3 \) ) for this message.

To minimize errors caused by frequency offset between the two ports, Port 2 returns the Pdelay_Resp message as quickly as possible after the receipt of the Pdelay_Req message. Port 2 returns any one of the following:

1. • – Difference between the timestamps \( t_2 \) and \( t_3 \) in the Pdelay_Resp message
   • – Difference between the timestamps \( t_2 \) and \( t_3 \) in the Pdelay_Resp_Follow_Up message
   • – Timestamps \( t_2 \) and \( t_3 \) in the Pdelay_Resp and Pdelay_Resp_Follow_Up messages, respectively
2. 1. 4. Port 1 generates a timestamp ( \( t_4 \) ) on receiving the Pdelay_Resp message.
   2. 5. Port 1 uses all four timestamps to compute the mean link delay.

Timestamp correction

According to the IEEE 1588 specifications, a timestamp must be captured when the message timestamp point (leading edge of the first bit of the octet immediately following the Start Frame Delimiter octet) crosses the boundary between the node and the network.

As the MAC takes the timestamp at an internal point far from the actual boundary of the node and network, this captured timestamp is corrected/updated for the ingress/egress path latency (including the delay in the PHY layers). Further correction is done for the inaccuracies/errors introduced due to the clock (GMII Tx, Rx clock) being different at the capture point as compared to the PTP clock ( \( clk\_ptp\_ref\_i \) ) that is used to generate the time. The resultant CDC (clock domain crossing) circuits add an error that depends on the clock period of the GMII and PTP clocks.

Ingress correction

In the receive side, the timestamp captured at the internal snapshot point is delayed (later in time) as compared to the time at which that packet SFD bit is received at the port boundary. Therefore, the captured timestamp must be reduced by the ingress latency and the errors in CDC sampling. This correction value must be determined/calculated by the software and written into the Timestamp ingress correction nanosecond register (ETH_MACTSICNR) .

The correction value consists of the following three components:

1. 1. External latency in the PHY layer between boundary point and the input of the core
   If the PHY is compliant with the IEEE 802.3 Clause 45 MMD registers, it has registers indicating the maximum and minimum ingress latency. The software can read these registers and determine the average ingress latency in the PHY. Alternatively (if the PHY does not support these registers), the ingress latency must be determined from the PHY datasheet or timing characteristics.
2. 2. Internal latency from the input of the core to the internal capture point
   The internal ingress latency can be read from the Timestamp ingress latency register (ETH_MACTSILR) . This is a read-only register that gives the latency in scaledNanoseconds format as defined in IEEE 1588 Clause 5.3.2. The latency differs based on the active PHY interface (such as MII or RMII) and the operating speed. Therefore, the software must read this register after any speed change in the MAC, to determine the current internal latency.
3. 3. CDC synchronization
   The CDC synchronization error is almost equal to twice the clock-period of the PTP clock ( \( clk\_ptp\_ref\_i \) ).

The values determined from these three components should be added by the software and must be written into the TSIC field of the Timestamp ingress correction nanosecond register (ETH_MACTSICNR) .

Note: The value written to the register must be negative (two's complement), because it has to be subtracted from the captured timestamp. The MAC receiver adds the value in this register to the captured timestamp and then gives the resultant value as the timestamp of the received packet.

When TSCTRLSSR bit in Timestamp control register (ETH_MACTSCR) is set, the nanoseconds field of the captured timestamp is in decimal format with a granularity of 1 ns. So bit 31 of TSIC must be set to 1 (for negative value) and bits 30 to 0 must be programmed with " \( 10^9 - \text{total ingress\_correction\_value[nanosecond part]} \) " represented in binary. For example, if the required correction value is \( -5 \) ns, then the value is 0xBB9A C9FB.

When TSCTRLSSR bit in Timestamp control register (ETH_MACTSCR) is reset, the nanoseconds field of the captured timestamp is in binary format with a granularity of \( \sim 0.466 \) ns. Therefore, bits[30:0] must be written with " \( 2^{31} - \text{total ingress\_correction\_value} \) " represented in binary with bit[31] = 1.

Egress correction

In the Transmit side, the timestamp captured at the internal snapshot point is earlier (advanced in time) as compared to the time at which that packet SFD bit is output at the port boundary. Therefore, the captured timestamp must be compensated by the egress latency and the errors in CDC sampling. This correction value must be determined/calculated by the software and written into the Timestamp egress correction nanosecond register (ETH_MACTSECNR) .

The correction value consists of the following three components:

1. 1. External latency in the PHY layer between the output of the core and the boundary of the port and the network

If the PHY is compliant with the IEEE 802.3 Clause 45 MMD registers, it has registers indicating the maximum and minimum egress latency. The software can read these registers and determine the average egress latency in the PHY. Alternatively (if the PHY does not support these registers), the egress latency must be determined from the PHY datasheet or timing characteristics.

1. 2. Internal latency from the internal capture point and the output of the core

This internal egress latency can be read from the Timestamp egress latency register (ETH_MACTSELR) . This is a read-only register that gives the latency in scaledNanoseconds format as defined in IEEE 1588 Clause 5.3.2. The latency differs based on the active PHY interface and the operating speed. Therefore, the software must read this register after any speed change in the MAC, to determine the current internal latency.

1. 3. CDC synchronization error

The timestamp correction because of synchronization is compensated by adding

Table 783 lists the egress and ingress latency values for various PHY interfaces:

Frequency range of reference timing clock

The timestamp information are transferred across asynchronous clock domains, from the MAC clock domain to the application clock domain. Therefore, a minimum delay is required between two consecutive timestamp captures. This delay is four clock cycles of GMII or MII and three clock cycles of PTP clocks. If the delay between two timestamp captures is less than this delay, the MAC does not take a timestamp snapshot for the second packet.

The PTP clock frequency limitations are the following:

• Maximum PTP clock frequency

The maximum PTP clock frequency is limited by the maximum resolution of the reference time (10 ns at 100 MHz). In addition, the resolution or granularity of the reference time source determines the accuracy of the synchronization. Therefore, a higher PTP clock frequency gives better system performance.

• Minimum PTP clock frequency

The minimum PTP clock frequency depends on the time required between two consecutive SFD bytes and the time taken for synchronizing the time with the GMII or MII clock domain. This relationship is given by the following equation:

The GMII or MII clock frequency is fixed by IEEE specifications. Therefore, the minimum PTP clock frequency required for proper operation depends on the operating mode and operating speed of the MAC as shown in Table 784 .

Table 784. Minimum PTP clock frequency example (continued)

PTP processing and control

Table 785 shows the common message header for the PTP messages. This format is taken from the IEEE 1588-2008 specifications.

Table 785. Message format defined in IEEE 1588-2008

1. The controlField is used in version 1. In version 2, the messageType field is used for detecting different message types.

Some fields of the Ethernet payload can be used to detect the PTP packet type and control the snapshot to be taken. These fields are different for the following PTP packets:

• • PTP packets over IPv4
• • PTP frames over IPv6
• • PTP packets over Ethernet

PTP packets over IPv4

Table 786 provides information about the fields that are matched to control the snapshot for the PTP packets sent over UDP over IPv4 for IEEE 1588 version 1 and 2. The octet positions for the tagged packets are offset by 4. This is based on the IEEE 1588-2008, Annex D and the message format defined in Table 785 .

Table 786. Message format defined in IEEE 1588-2008

1. PTP event messages are SYNC, Delay_Req (IEEE 1588 version 1 and 2) or Pdelay_Req, Pdelay_Resp (IEEE 1588 version 2 only)

PTP frames over IPv6

Table 787 provides information about the fields that are matched to control the snapshots for the PTP packets sent over UDP over IPv6 for IEEE 1588 version 1 and 2. The octet positions for the tagged packets are offset by 4. This is based on the IEEE 1588-2008, Annex D and the message format defined in Table 785 .

Table 787. IPv6-UDP PTP packet fields required for control and status

1. 1. The Extension header is not defined for PTP packets.

PTP packets over Ethernet

Table 788 provides information about the fields that are matched to control the snapshots for the PTP packets sent over Ethernet for IEEE 1588 version 1 and 2. The octet positions for the tagged packets are offset by 4. This is based on the IEEE 1588-2008, Annex D and the message format.

Table 788. Ethernet PTP packet fields required for control and status

1. 1. The unicast address match of destination addresses (DA), programmed in MAC address 0 to 31, is used if the TSENMACADDR bit of Timestamp control register (ETH_MACTSCR) is set.
2. 2. IEEE 1588-2008, Annex F
3. 3. The MAC does not consider the PTP version 1 messages with Peer delay multicast address (01-80-C2-00-00-0E) as valid PTP messages.

Transmit path functions

The MAC captures a timestamp when the start packet delimiter (SFD) of a packet is sent on the GMII or MII interface. The packets, for which a timestamp has to be captured, can be controlled on per-packet basis. Each Transmit packet can be marked to indicate whether a timestamp should be captured for it.

The MAC does not process the transmitted packets to identify the PTP packets. The packets for which a timestamp has to be captured must be specified. The packets can be defined by using the control bits in the transmit descriptor (see Section 76.10.3: Transmit descriptor ). The MAC returns the timestamp to the software inside the corresponding

Transmit descriptor, thus automatically connecting the timestamp to the specific PTP packet.

The 64-bit timestamp information is written to the TDES0 and TDES1 fields. The TDES0 field holds the 32 least significant bits of the timestamp.

Receive path functions

The MAC can be programmed to capture the timestamp of all packets received on the GMII or MII interface or to process packets to identify the valid PTP messages. The snapshot of the time to be sent to the application can be controlled by using the following options of the Timestamp control register (ETH_MACTSCR) :

• • Enable snapshot for all packets
• • Enable snapshot for IEEE 1588 version 1 or version 2 timestamp
• • Enable snapshot for PTP packets transmitted directly over Ethernet or UDP-IP-Ethernet
• • Enable timestamp snapshot for the received packet for IPv4 or IPv6
• • Enable timestamp snapshot only for EVENT messages (SYNC, DELAY_REQ, PDELAY_REQ, or PDELAY_RESP)
• • Enable the node to be a master or slave and select the snapshot type

This feature controls the type of messages for which snapshots are taken.

Note: The peripheral also supports the PTP messages over VLAN packets.

Table 789 indicates the PTP messages for which a snapshot is taken depending on the SNAPTYPSEL field in Timestamp control register (ETH_MACTSCR) .

Table 789. Timestamp snapshot dependency on ETH_MACTSCR bits

The DMA returns the timestamp to the software application inside the corresponding receive descriptor. The extended status, containing the timestamp message status and the IPC status, is written in the RDES1 normal descriptor and the snapshot of the timestamp is written in RDES0 and RDES1 fields of the context descriptor. The RDES0 field holds the 32 least significant bits of the timestamp.

Programming guidelines for IEEE 1588 timestamping (system time correction)

See Section : System time correction in Section 76.9.10: Programming guidelines for IEEE 1588 timestamping on page 4132 .

IEEE 1588 system time source

To get a snapshot of the time, the MAC requires a reference time in 64-bit format as defined in the IEEE 1588-2002 (80-bit format as defined in the IEEE 1588-2008).

Description of IEEE 1588 system time source

The peripheral uses the reference clock input and uses it to internally generate the Reference time (also called the system time) and capture timestamps.

The timestamp has the following fields:

• • UInteger48 seconds field

The seconds field is the integer portion of the timestamp in units of seconds. It is 48-bit wide. For example, 2.0000000001 seconds are represented as seconds Field = 0x0000 0000 0002.

• • UInteger32 nanosecondsField

The nanoseconds field is the fractional portion of the timestamp in units of nanoseconds. For example, 2.0000000001 seconds are represented as nanoSeconds = 0x0000 0001.

The nanoseconds field supports the following two modes:

• – Digital rollover mode: In this mode, the maximum value in the nanoseconds field is 0x3B9A C9FF, that is, \( (10e9-1) \) nanoseconds.
• – Binary rollover mode: In this mode, the nanoseconds field rolls over and increments the seconds field after value 0x7FFF FFFF. Accuracy is \( \sim 0.466 \) ns per bit.

These modes can be set through TSCTRLSSR bit in Timestamp control register (ETH_MACSCR) .

System time register module

The 64-bit PTP time is updated using the PTP input reference clock, clk_ptp_ref_i. This PTP time is used as a source to take snapshots (timestamps) of the Ethernet frames being transmitted or received at the GMII.

The system time counter can be initialized or corrected using either the coarse or the fine correction method.

In the coarse correction method, the initial value or the offset value is written to the timestamp update register. For initialization, the system time counter is programmed with the value in the timestamp update registers, whereas for system time correction the offset value (timestamp update register) is added to or subtracted from the system time.

In the fine correction method, the slave clock (reference clock) frequency drift with respect to the master clock (as defined in IEEE 1588-2002 specifications) is corrected over a period of time, unlike in the coarse correction method where it is corrected in a single clock cycle. The longer correction time helps maintain linear time and does not introduce drastic changes (or a large jitter) in the reference time between PTP Sync message intervals. In this method, an accumulator sums up the contents of the Addend register as shown in Figure 1028 . The arithmetic carry that the accumulator generates is used as a pulse to

increment the system time counter. The accumulator and the addend are 32-bit registers. The accumulator acts as a high-precision frequency multiplier or divider.

This system time update algorithm is shown in Figure 1028 .

Figure 1028. System time update using fine correction method

graph TD
    Addend[Addend register] -- Addend update --> Adder1[+]
    Addend --> Adder1
    Adder1 --> Accumulator[Accumulator register]
    Accumulator --> Adder1
    Accumulator --> IncSub[Increment Subsecond register]
    IncSub --> Subsecond[Subsecond register]
    Subsecond --> Adder2[+]
    Subsecond --> IncSec[Increment Second register]
    IncSec --> Second[Second register]
    Second --> Out[ ]
    Const[Constant value] --> Adder2
    Adder2 --> Subsecond
    style Out fill:none,stroke:none
  

The system time update logic requires a 50 MHz clock frequency to achieve 20 ns accuracy. The frequency division is the ratio of the reference clock frequency to the required clock frequency. For example, if the reference clock ( clk_ptp_ref_i ) is 66 MHz, this ratio is calculated as \( 66 \text{ MHz} / 50 \text{ MHz} = 1.32 \) . Therefore, the default addend value to be set in the register is \( 2^{32} / 1.32 \) , 0xC1F07C1F.

If the reference clock drifts lower, for example, to 65 MHz, the ratio is \( 65 / 50 \) , that is 1.3 and the value to set in the addend register is \( 2^{32} / 1.30 \) , or 0xC4EC 4EC4.

If the clock drifts higher, for example to 67 MHz, the addend register must be set to 0xBF0B 7672. When there is not clock drift, the default addend value of 0xC1F0 7C1F ( \( 2^{32} / 1.32 \) ) must be programmed.

In Figure 1028 , the constant value used to accumulate the subsecond register is decimal 43, which achieves a system time accuracy of 20 ns (in other words, it is incremented in 20 ns steps).

The software must calculate the drift in frequency based on the SYNC messages and accordingly update the Addend register.

Initially, the slave clock is set with FreqCompensationValue0 in the Addend register. This value is as follows:

If MasterToSlaveDelay is initially assumed to be the same for consecutive Sync messages, the algorithm given in this section must be applied. After a few Sync cycles, frequency lock occurs. The slave clock can then determine a precise MasterToSlaveDelay value and re-synchronize with the master using the new value.

The algorithm is as follows:

1. 1. At time MasterSyncTime _n the master sends the slave clock a SYNC message. The slave receives this message when its local clock is SlaveClockTime _n and computes MasterClockTime _n as follows:

1. 2. The master clock counts for current Sync cycle, MasterClockCount _n is

(assuming that MasterToSlaveDelay is the same for Sync cycles n and n – 1)

1. 3. The slave clock count for current Sync cycle, SlaveClockCount _n is

1. 4. The difference between master and slave clock counts for current Sync cycle, ClockDiffCount _n is

1. 5. The frequency-scaling factor for slave clock, FreqScaleFactor _n is

1. 6. The frequency compensation value for Addend register, FreqCompensationValue _n is

In theory, this algorithm achieves the lock in one Sync cycle. However, it may take several cycles, because of changing network propagation delays and operating conditions. This algorithm is self-correcting. If the slave clock is initially set to an incorrect value by the master, the algorithm corrects it at the cost of additional Sync cycles.

Refer to Section 76.9.10: Programming guidelines for IEEE 1588 timestamping for detailed programming steps.

IEEE 1588 auxiliary snapshots

The auxiliary snapshot feature enables to store a snapshot of the system time based on an external event. The event is considered to be the rising edge of the eth_ptp_trgx (where x = 1 to 4) sideband signal.

Up to four auxiliary snapshot inputs can be configured and up to four snapshots can be stored. A FIFO is accessible through registers: Auxiliary timestamp seconds register (ETH_MACATSSR) and Auxiliary timestamp nanoseconds register (ETH_MACATSNR) .

The snapshots taken for any input are stored in a common FIFO; only 64 bits are kept. The application can read the Timestamp status register (ETH_MACTSSR) to know the timestamp of which input is available for reading at the top of this FIFO.

When a snapshot is stored, the MAC indicates this to the application with an interrupt. The value of the snapshot is read through a FIFO register access. If the FIFO becomes full and an external trigger to take the snapshot is asserted, a snapshot trigger-missed status (ATSSTM) is set in the Timestamp status register (ETH_MACTSSR) . This indicates that the latest auxiliary snapshot of the timestamp is not stored in the FIFO. The latest snapshot is not written to the FIFO when it is full.

When an application reads the 64-bit timestamp from the FIFO, the space becomes available to store the next snapshot. You can clear a FIFO by setting the ATSFC bit in Auxiliary control register (ETH_MACACR) . When multiple snapshots are present in the FIFO, the count is indicated in bits[27:25] of Timestamp status register (ETH_MACTSSR) .

Flexible pulse-per-second output

The MAC supports either a fixed pulse-per-second output mode (also called fixed mode) or a flexible pulse-per-second output mode for the ETH_PPS_OUT and eth_ptp_pps_out1 outputs:

• • Fixed pulse-per-second output

In this mode, only the frequency of the PPS output can be changed by setting the PPSCTRL0 field in the PPS control register (ETH_MACPPSCR) .

• • Flexible pulse-per-second output

In this mode, the software has the flexibility to program the start or stop time, width, and interval of the pulse generated on the eth_ptp_pps_out output:

The start and stop times are programmed through PPS x target time seconds register (ETH_MACPPSTTSxR) and PPS x target time nanoseconds register (ETH_MACPPSTTNxR) .

The PPS width and interval are programmed in terms of granularity of system time (number of the units of subsecond increment value) through PPS x width register (ETH_MACPPSWxR) and PPS x interval register (ETH_MACPPSIXR) , respectively.

Note: By default, the peripheral is in Fixed mode and indicates one second interval. When Fixed mode is selected by clearing PPSEN0 to 0 in the PPS control register (ETH_MACPPSCR) :

• • the output on all PPS outputs is controlled by the value programmed in the PPSCTRL_PPSCMD field. Independent control of individual PPS output is not supported in Fixed mode.
• • PPS x target time seconds register (ETH_MACPPSTTSxR) and PPS x target time nanoseconds register (ETH_MACPPSTTNxR) are used only for generating target time reached interrupt; they are not used for PPS output generation.
• • TRGTMODSEL0/1/2/3 must be programmed to 0.
• • the frequency of the PPS output can be changed by setting the PPSCTRL0 field in the PPS control register (ETH_MACPPSCR) .

Description of flexible pulse-per-second (PPS) output

The peripheral supports the following features with the flexible PPS outputs:

• • Control of up to two independent PPS outputs, available externally (ETH_PPS_OUT) and internally (eth_ptp_pps_out1)
• • Programming the start or stop time in terms of system time.
• • Programming the start point of the single pulse and start and stop points of the pulse train in terms of 64-bit system time. The Target Time registers are used to program the start and stop time.
• • Programming the stop time in advance, that is, the stop time can be programmed before the actual start time has elapsed.
• • Programming the width between the rising edge and corresponding falling edge of PPS signal output in terms of number of units of subsecond increment value programmed in the Subsecond increment register (ETH_MACSSIR) . The pulse width can be programmed from 1 to 232–1 units of subsecond increment value.
• • Programming the interval, between the rising edges of PPS signal, in terms of number of units of subsecond increment value. You can program the interval between pulses from 1 to 232–1 units of subsecond increment value.
• • Option to cancel the programmed PPS start or stop request.
• • Error if the start or stop time being programmed has already elapsed.

Note: The PTP reference clock mentioned in the following sections is the clock at which the system time is updated. When the TSCFUPDT bit of Timestamp control register (ETH_MACTSCR) is set to 0, this clock is similar to the clk_ptp_ref_i clock. In Fine correction mode, this is the clock tick at which the system time is updated (using Subsecond increment register (ETH_MACSSIR) ) (as shown in Figure 1028).

Refer to Section 76.9.14: Programming guidelines for flexible pulse-per-second (PPS) output for further details on how configuring flexible pulse output.

PPS start and stop times

The initial start time can be programmed in the Target Time registers.

Each flexible PPS output is associated to independent Target Time registers, PPS x target time seconds register (ETH_MACPPSTTSxR) and PPS x target time nanoseconds register (ETH_MACPPSTTNxR) .

If required, the start or stop time can be programmed again. However, this can be done only after the earlier programmed value is synchronized with the PTP clock domain. Bit 31 of PPS x target time nanoseconds register (ETH_MACPPSTTNxR) indicates that the synchronization is complete. This enables to program the start or stop time in advance even before the earlier stop or start time has elapsed.

To ensure proper PPS signal output, it is recommended to program advanced system time for the start or stop time. If the application programs a start or stop time that has already elapsed, the MAC sets an error status bit indicating the programming error. If enabled, the MAC also sets the Target Time Reached interrupt event. The application can cancel the start or stop request only if the corresponding start or stop time has not elapsed. If the time has elapsed, the cancel command has no effect.

PPS width and interval

The PPS width and interval are programmed in terms of granularity of system time, that is, number of the units of subsecond increment value. For example, to obtain a PPS pulse width of 40 ns and an interval of 100 ns with a PTP reference clock of 50 MHz, program the width and interval to values 2 and 5, respectively. Smaller granularity can be achieved by using a faster PTP reference clock.

Before giving the command to trigger a pulse or pulse train on the PPS output, program or update the interval and width of the PPS signal output.

Each flexible PPS output is associated to independent interval and width registers, PPS x interval register (ETH_MACPPS1xR) and PPS x width register (ETH_MACPPSWxR) .

PTP timestamp offload function

This feature enables the automatic generation of specific PTP packets to be performed, when the MAC operates as a specific node in the PTP network.

These packets can be generated periodically or triggered by the host software. In other modes, this feature can parse the incoming PTP packets on the receiver, and automatically generate and respond to the required PTP packets. It helps to offload certain PTP node functions with better accuracy and lower response latency.

The PTP offload feature is selected through PTP offload control register (ETH_MACPOCR) . 80-bit PTP node identity is configured through the following three registers: PTP source port identity 0 register (ETH_MACSPI0R) , PTP Source port identity 1 register (ETH_MACSPI1R) and PTP Source port identity 2 register (ETH_MACSPI2R) .

Description of PTP offload function

Depending on the programmed mode, the MAC generates PTP Ethernet messages periodically or from the application, or based on reception of a particular PTP message. Table 790 indicates the PTP message generation criteria.

Table 790. PTP message generation criteria

Table 790. PTP message generation criteria (continued)

Note: Clocks supporting peer delay mechanism must not generate delay request/delay response messages, according to IEEE 1588-2008 specifications. However, the peripheral controller supports this for flexibility, with a programmable control bit (DRRDIS) in the PTP offload control register (ETH_MACPOCR) .

The DRRDIS bit can be used to control the response generation for delay request/delay response message. For example, in transparent slave mode, delay request is generated in response to received SYNC only when the bit is reset.

When the MAC is set as an Ordinary or Boundary Slave clock in the PTP network, it can respond to the reception of SYNC messages with an automatic generation and transmission of the corresponding Delay_Req message. Similarly, various other modes of operation are explained in Table 790 .

The MAC supports the multicast communication model for the generation of SYNC and Pdelay_Req PTP messages. For instance, the Destination Address field of the generated PTP over Ethernet packet is the defined special multicast addresses (0x011B 1900 0000 for

all except peer delay mechanism messages and 0x0180 C200 000E for peer delay mechanism messages).

When the MAC responds to received SYNC, Delay_Req and Pdelay_Req PTP messages with special multicast destination address, it also uses the corresponding special multicast address in the DA field of the automatically generated Delay_Req, Delay_Resp, and Pdelay_Resp PTP messages, respectively.

When the MAC responds to received SYNC, Delay_Req and Pdelay_Req PTP messages with unicast destination address, it takes the SA field of the received packets and makes them as the DA field of the automatically generated Delay_Req, Delay_Resp, and Pdelay_Resp PTP messages, respectively.

At the same time, all the received PTP messages are forwarded to the application along with Rx status, indicating whether the response was generated by the MAC, if it satisfies the packet filtering logic of the MAC receiver

When the MAC automatically generates a PdelayReq or responds with a Delay_Req, the egress timestamp of these two PTP messages are provided in the Tx TS status (Tx Timestamp Status register and interrupt generated).

In addition to messageType and versionPTP fields match for basic PTP over Ethernet message detection, the following additional fields are matched to qualify the received PTP message type:

1. 1. The domainNumber field is checked for a match against the value programmed in the CSR.
2. 2. The twoStepFlag in flagField field is checked for one-step indication (0b0).
3. 3. The transportSpecific field is checked for Default PTP over Ethernet (0b0000) or 802.1AS mode (0b1111) when enabled.

PTP packet generation

This section explains the format and content of the automatically generated PTP packets by the MAC when this mode is enabled. It provides the template of the common PTP message header, as well as the detailed description of the fields of the specific PTP packets generated.

Table 791. Common PTP message header fields

Table 791. Common PTP message header fields (continued)

PTP message header fields

• • messageType

The following encoded values are used for PTP message types:

• – SYNC: 0000
• – Delay_Req: 0001
• – Pdelay_Req: 0010
• – Pdelay_Resp: 0011
• – Delay_Resp: 1001

• • transportSpecific

The following transport protocol encoding is used:

• – Default PTP over Ethernet: 0000
• – 802.1AS mode: 0001

• • versionPTP

It is always set to 2 because PTP version 2 is supported.

• • domainNumber

This field contains the value from the PTP offload control register (ETH_MACPOCR) .

• • flagField

The following values are used:

• – alternateMasterFlag (Octet 0 bit 0): 0 for SYNC and Delay_Resp
• – twoStepFlag (Octet 0 bit 1): 0 for SYNC and Pdelay_Resp
• – unicastFlag (Octet 0 bit 2): 0 for Multicast Address, 1 for Unicast Address

• • correctionField

For more information, see Table 792 .

• • sourcePortIdentity

This field takes the value programmed in the PTP source port identity 0 register (ETH_MACSPI0R) , PTP Source port identity 1 register (ETH_MACSPI1R) and PTP Source port identity 2 register (ETH_MACSPI2R) .

• • sequenceId

Pdelay_Req and Delay_Req use the same sequenceId field from received Pdelay_Resp and Delay_Resp PTP messages. For SYNC/Delay_Req, Pdelay_Req, a separate sequenceId counter is maintained. These sequenceId counters get incremented by 1 every time the corresponding message is generated and transmitted.

• • controlField

The following encoded values are used for controlField:

• – SYNC: 0000 0000
• – Delay_Req: 0000 0001
• – Pdelay_Req: 0000 0010
• – Pdelay_Resp: 0000 0101
• – Delay_Resp: 0000 0011
• • logMessageInterval
  • – SYNC:
    This field contains logSyncInterval from the corresponding MAC_Log_Message_Interval register.
  • – Delay_Resp:
    This field contains the sum of DRSYNCR and logSyncInterval value taken from the Log message interval register (ETH_MACLMIR) for a multicast PTP message and 0111 1111 for unicast PTP message.
  • – Delay_Req, Pdelay_Req and Pdelay_Resp: 0111 1111
    where \( \text{logSyncInterval} = \log_2(\text{Mean Value of Interval in seconds}) \)

The MAC supports values of –15 to 15 for logSyncInterval fields, which translates to a range from 32.768 micro second ( \( 2^{-15} \) ) to 215 second. For a given value of log sync interval (N), the time interval between two SYNC packets is given by the following:

• • \( 2^{(30+N)} \) ns, when N is negative (–1 to –15)
• • \( 2^N \) seconds, when N is positive (0 to 15)

For example:

• • When logSyncInterval is programmed to 1, the interval is \( 2^1 \) ; therefore, the SYNC message is sent once every 2 seconds.
• • When logSyncInterval is programmed to -1, the interval is \( 2^{-1} = 0.536 \) seconds; therefore, the SYNC message is sent once every 536 milliseconds. The value is 0.536 seconds, because \( 2^{-30} = 1 \) ns.
• • When logSyncInterval is programmed to –5, the interval is \( 2^{-5} = 33.55 \) ms; therefore, the SYNC message is sent once every 33.55 ms.

Note: The MAC uses the PTP system time to generate the intervals for periodic packet transmission. For negative values of log message interval programmed, the generated period may deviate from the value given by the equation \( 2^{(30+N)} \) , because of the non-binary nature of the nanoseconds field of the system time.

PTP message-specific fields

The message-specific fields are the following:

• • messageLength

There is no suffix supported, so this field contains the length of the PTP message that includes 34-byte PTP common header and the body specific to the message type.

For SYNC and Delay_Req packets, this field contains 44, whereas for Delay_Resp, Pdelay_Req and Pdelay_Resp, it contains 54.

• • originTimestamp

This field is the captured egress timestamp for SYNC, Delay_Req, and Pdelay_Req PTP messages.

• • receiveTimestamp

For Delay_Resp PTP message, this is the ingress timestamp of the corresponding received Delay_Req PTP message.

• • requestingPortIdentity

For Delay_Resp and Pdelay_Resp PTP messages, this is the sourcePortIdentity field taken from the corresponding received Delay_Req and Pdelay_Req PTP messages.

• • requestReceiptTimestamp

For the Pdelay_Resp PTP message, this field is set to 0.

One-step timestamp

The MAC supports the one-step timestamp feature that enables to identify the offset in the packet and inserts the timestamp received from the application at that offset.

MAC Transmit PTP mode for one-step timestamp

Depending upon the type of message and its mode, the MAC updates the following fields of Transmit PTP packets:

• • correctionField in the PTP header of messages
• • originTimestamp in SYNC, Delay_Req, and Pdelay_Req messages

Table 792 shows how the PTP mode is selected based on the settings of SNAPTYPSEL, TSMSTRENA, and TSEVNTENA bits of the Timestamp control register (ETH_MACTSCR) and the fields that are updated for the incoming PTP packets based on the message type in that mode, during the one-step timestamping operation.

Table 792. MAC Transmit PTP mode and one-step timestamping operation

Table 792. MAC Transmit PTP mode and one-step timestamping operation (continued)

Table 792. MAC Transmit PTP mode and one-step timestamping operation (continued)

1. The per-packet control values provided here are the recommended settings used by devices in typical PTP operation and for the programmed mode.

2. TTSE represents TTSE bit of TDES2 transmit normal descriptor. The TTSE function is independent from the OST function and the programmed operation mode for OST. The MAC captures and returns the timestamp when the TTSE bit is set.

3. OSTC represents OSTC bit of TDES3 transmit context descriptor

4. TTS represents the timestamp value provided in the TTSH, TTSL fields of TDES0 and TDES1 transmit normal descriptor (write-back format).

Note: Residence time/ turnaround time is calculated as the difference between the captured timestamp (egress timestamp) and the ingress timestamp. Clocks supporting peer delay mechanism do not use delay request or response, but it is included in OST for flexibility.

Enabling one-step timestamp

The one-step timestamp feature can be enabled for a given packet by setting bit 20 (OSTC) in TDES3 context descriptor. To update the correction field in certain PTP packets, the ingress timestamp must be given in the TSSL and TSSH fields.

The one-step timestamp feature is supported only for the PTP over Ethernet packets. It is not supported for PTP over IPv4/IPv6 packets.

76.5.6 Time sensitive networking (TSN)

This section describes how the Ethernet peripheral core supports time sensitive network (TSN) features.

TSN is a set of standards, developed by the IEEE 802.1 work group, which define the mechanisms for the time-sensitive transmission of data over Ethernet.

The present section describes:

• • Enhancements for scheduled traffic (EST)
• • Frame preemption (FPE)
• • Time-based scheduling (TBS)

Enhancements for scheduled traffic (EST)

The IEEE 802.1Qbv-2015 defines the schedule for each queue on every egress port that makes the peripheral aware of the traffic arrival schedule. This information can be used to block lower priority traffic from being transmitted in this time window/slot. This ensures that scheduled traffic is forwarded from sender to receiver through all the network nodes with a deterministic delay.

Figure 1029. Time aware shaper implementation for traffic scheduling

One of the important requirements to achieve a low latency is to make sure there are no interfering frames during the scheduled windows that are reserved to high priority traffic. The use of scheduled traffic imposes limitations while starting a transmission.

As shown in Figure 1030 , if an interfering frame transmission begins just before the start of a reserved time period, the transmission can be extended into the reserved window and potentially interfere with higher priority traffic. Therefore, a guard band whose size is equal to the largest possible interfering frame is required before the window starts.

Figure 1030. Implementing a guard band to avoid delays due to interfering frames

A larger guard band equates to a less efficient use of network bandwidth. However, with the implementation of IEEE802.1Qbu (frame preemption), this issue is addressed. Frame preemption breaks the interfering frame into smaller fragments. Therefore, the guard band needs to be only as large as the largest possible interfering fragment instead of the largest possible interfering frame.

During the guard band, only the frames for which the entire frame can be complete before the next gate close event are permitted. This ensures that the high priority traffic can always start at the beginning of the window reserved for it.

The transmit scheduling embeds the following feature to be able to support EST:

• • Gate control list (GCL)
• • Enforced gate controls in the scheduler
• • Gate open duty cycle taken into account in the computation of the idleSlope (CBS)

Gate control list implementation (GCL)

Figure 1031 shows the block diagram extracted from the IEEE 802.1Qbv specifications that illustrates how the gate control list governs the gate close (C) and open (O) events based on the schedule provided for each event.

The GCL consists of two parts:

• • Time interval
  It defines the time (expressed in ns) during which the gate controls are valid and should be applied before reading the next gate controls from the list. The maximum time interval is 16 ms. The left shift of the time interval up to 7 bits is supported to be able to apply a multiplication factor ranging from 1 to 128 ns (in steps of \( 2^n \) ). The maximum value (post shifting) of this field must be 999,999,999 ns.
• • Gate control
  Defines the Open (O) represented by logic 1 or Close (C) represented by logic 0 state for the gate of each traffic class (TC).

Figure 1031. GCL governing gate close and open events block diagram (from IEEE 802.1 Qbv specifications)

The implementation of GCL consists of the following two gate-control lists:

• • Hardware owned list (HWOL), which can be accessed only by hardware
• • Software owned list (SWOL), which can be accessed only by software

The access to these lists is mutually exclusive. The ownership of the list is set by hardware in the SWOL field of EST Status register (ETH_MTLESTSR) . Table 793 shows how the GCL is implemented.

Table 793. External memory used for holding the two gate-control lists

Table 793. External memory used for holding the two gate-control lists (continued)

Four registers are related to the gate control lists (one for each GCL). These registers are implemented through Indirect addressing using EST Gate Control List register (ETH_MTLESTGCLCR) and EST Gate Control List Data register (ETH_MTLESTGCLDR) .

• • 64-bit base time register (BTR)

The base time register is a 64-bit register that holds the start time to execute the GCL. The format of the BTR is the same as the PTP format (upper 32-bit holds time in seconds and lower 32-bit hold time in ns).

Once the execution of a given list starts, the peripheral can update the BTR value to indicate the next list execution start time.

• • 40-bit cycle time (CTR)

The cycle time register is a 40-bit register that holds the time at which the execution of the GCL should be repeated. The cycle time register consists of an 8-bit value in seconds and a 32-bit value in ns (similar to the PTP time format with truncated second register).

For a given GCL, the start time is given by the below formula:

where N is an integer value representing the iteration number starting from 0 for the first iteration.

If the GCL execution takes longer than the cycle time, then the list is truncated at the cycle time and the subsequent loop starts at the cycle time.

• • 32-bit time extension (TER)

The time extension register (TER) is a 32-bit register that holds the amount of time (in ns) of which current GCL can be extended before switching to the new GCL. This is useful to avoid small fragments of the current list before switching to a new list. The time extension value is coded on 31 bits and stored in a 32-bit register, with the most significant bit forced to 0.

• • 7-bit [gate control] list length (LLR) (where n depends on the configured GCL depth)
  The list length register (LLR) is a 7-bit register that holds the integer value of the GCL length, which corresponds to the number of valid rows in each GCL. The processing of the GCL stops after the number of rows read is equal to the LLR value.

Transmission gating

A bridge or an end station can be used to allow transmission from each TC that is yet to be scheduled relative to a known timescale. To achieve this, a transmission gate is associated to each TC. The state of the transmission gate determines if the queued frames can be selected for transmission.

The state of a TC transmission gate can be in one of the following:

• • Open
  Queued frames are selected for transmission according to the definition of the transmission selection algorithm associated to the TC.
• • Closed
  Queued frames are not selected for transmission.

A frame on a traffic class queue is not available for transmission if the transmission gate is in closed state or if there is insufficient time available for transmitting the whole frame before the next gate-close event associated to this queue.

The peripheral has visibility on the current schedule of gate controls and the immediate next schedule of the gate controls. As a result, the maximum gate open period does not exceed the sum of the two time intervals since a frame is selected for transmission only if the gate is currently open and the duration of gate open interval is greater than the time taken to transfer the entire frame.

The implementation must know the frame size before the transmission, so that transmission overruns can be avoided and only the frames that can complete are scheduled. This can be achieved by:

• • programming the OVHD field ([5:0] bits) of EST Extended Control register (ETH_MTELECR) with fixed overhead of the IPG or EIPG, preamble, and scheduler delay
• • automatically predicting the variable overhead due to the offloads enabled for a packet in the MAC transmitter.

Consider the following while programming the EST related fields to ensure correct packet scheduling:

• • Speed: 1 Gbps/100 Mbps
• • PTOV (in ns): 9 PTP clock cycles
• • CTOV (in ns): 3 PTP + 3 Transmit clock cycles
• • The slot interval per packet (in ns) is given by the following formula:

The overhead and scheduler delays in bytes are equal to \( 17 \text{ Tx} + (10 + X) \) application clock cycles, where \( X = 2 \) if VLAN tag insertion is enabled, \( X = 0 \) otherwise.

The peripheral adequately compensates for the data transfer delays from the buffer to the line by offsetting the current time with all the relevant delays (provided by the CTOV field of EST Control register (ETH_MTLESTCR) ). This ensures that the provided schedule is always accurately implemented at the line.

Note: An overhead is added to the packet size to take into account the scheduler delay, IPG or EIPG, and preamble overheads on the line. The gate open window should therefore be able to accommodate at least \( 128 + \text{overhead} \) bytes to transmit a 128-byte frame.

In 100-Mbps mode of operation, the rounding down error is about 0.4 %. For example, the gate open duration should be at least 1035 bytes for transmitting 1000-byte frames at a speed of 100 Mbps (31 bytes for scheduler delay and 4 bytes for rounding down error).

The minimum time interval for GCL entry is the following:

Idle slope computation updates

When EST is enabled, the credit is accumulated only when the gate is open. The effective data rate of the idleSlope must therefore be increased to reflect the duty cycle for the transmission gate associated to the queue.

The idle slope (idleSlope) is computed based on the gate open time (GateOpenTime) and operating cycle time (OperCycleTime) values. Program the idleSlope registers (one per CBS enabled TC) based on the following equation:

Operational details of GCL

Set the switch to software list through the SSWL bitfield in EST Control register (ETH_MTLESTCR) , so that the hardware can access the programmed gate control list. The first set of gate controls is applied when the current time is equal to the value in the base time register (BTR) and is held until the programmed time interval value.

To avoid transmission overruns, an additional gate control event is always read ahead from the list. This enables the GCL to determine the next gate close events (if any) for the TCs that are open.

The scheduling is based only on the gate open state and time interval of the current and subsequent schedule. An internal accumulator is used to add the time intervals when gate controls are applied. The sum of BTR + accumulator holds the time at which the next set of gate controls are planned to be applied.

Figure 1032. GCL and associated registers - BaseTime and CycleTime

The GCL is read progressively from the first row adhering to the schedule. The read operations continue until the list length (defined in the LLR register) is reached. The execution of the list restarts at BTR + CTR time. At this point the BTR is incremented by the value in CTR to mark the beginning of a new cycle. In the absence of gate controls, all the gates are deemed to be in open state during the execution of the list.

In cases where the list execution time is greater than the CycleTime, the list is truncated and the next iteration starts when the current time equals BTR + CTR.

Table 794. GCL and associated registers - BTR and CTR

In the example given in Table 794 , the execution starts at 14200 and the first set of gate controls, O0CCCCCC is immediately applied. Since the time interval is 1000 ns, the next set of gate controls is applied at 14200 (BTR) + 1000 (accumulator) = 15200 ns as shown in Table 794 . Since there are no gate controls available after the execution of the last gate

control and before the next iteration of the loop, the gates are deemed to be in open state during that time period as shown at time 18200 in Table 794 .

Figure 1033. GCL and associated registers - BaseTime and CycleTime list execution time > CycleTime

Since the list execution takes longer than the allocated CycleTime, the list is truncated and the list is started from the BTR+CTR as shown in Table 795 .

Table 795. GCL and associated registers - BTR and CTR, execution time > CycleTime

While applying the third set of gate controls, BTR + CycleTime (17200 ns) is lower than BTR + accumulator (17900), so the list is truncated and execution switches to a new iteration at 17200.

Installing a new GCL

When a new software-programmed GCL is available and must be executed at the new BTR value, the switch to the new GCL can be done in one of the following ways:

• • New base time aligned with current schedule
• • New base time unaligned with current schedule

New base time aligned with current schedule

If the cycle time value for the new gating cycle is the same as the cycle time of the current gating cycle, and if the BTR chosen for the new gating cycle (new BTR) is an integer multiple of the current cycle time (+ current BTR), then the new gating cycle exactly lines up with the old gating cycle, that is, the cycle start times for the new gating cycle are the same as they would have been for the old configuration. This can be considered as the ideal case and enables the new gating cycle to be installed and executed with no timing issues. The peripheral completes the execution of an iteration of the current list and switches to the new list at the beginning of the BaseTime listed in the new list.

If (New BaseTime \( \geq \) Current time) ConfigChangeTime = New BaseTime

Else If (New BaseTime < Current Time)

1. 1. Set the BTRError (BTRE bit in ETHMTLESTR)
2. 2. ConfigChangeTime = New BaseTime + N \( \times \) New CycleTime

where N is the smallest integer for which the relation ConfigChangeTime \( \geq \) CurrentTime and ( \( N \leq 8 \) ) is TRUE.

When N is higher than 8, the hardware cannot auto-recover and the loop count value in BTR error loop count (BTRL bitfield in ETH_MTLESTSR) is set to 0b1111 1111 requiring the software to reprogram the new base time.

Figure 1034 illustrates the installation of the new GCL along with the time lines.

Figure 1034. Switching to a new configuration that is aligned with the existing configuration

In the example given in Table 796 , after the sixth iteration of the first GCL, the BTR values of the old and new GCL are equal. At that point the new GCL is processed as a natural extension to the existing GCL.

Table 796. GCL and associated registers - BTR and CTR

New base time unaligned with current schedule

If the new CycleTime differs from the current CycleTime or the new BaseTime is in the future and is not an integer multiple of current CycleTime, then the old and new cycles do not line up. When a new BaseTime is reached (that is when the new configuration is installed and starts to execute), the last old cycle is normally truncated to start the first new cycle. This can be undesirable if it results in a very short last old cycle. It would be better to simply extend the penultimate old cycle by that small amount, rather than starting a very short cycle. The cycle time extension register (TER, related to the current configuration list) enables this extension of the last old cycle to be done in a defined way. If the last complete old cycle ends normally in less than the current cycle time extension (TER in ns) before the new BaseTime, then the last complete cycle before the new BaseTime is reached is extended so that it ends at the new BaseTime.

Figure 1035. Switching to the new list by truncating the current list

At the end of the fifth iteration, current time + cycle time extension (TER) < New BTR, so the sixth iteration of the current configuration has started. During the sixth iteration of the current list, when the new BTR value is smaller than the next schedule in the current list, it switches to the new list.

Table 797. Extending to new list by truncating the current list

Figure 1036 shows an example where the current configuration list is extended instead of starting a new iteration since the extension time of 800 ns is less than the allowed cycle extension time (TER) of 1000 ns.

Figure 1036. Switching to new list by extending the current list

Table 798. Switching to new list by extending the current list

Impact of transmit scheduling algorithms on EST

When EST is used in isolation, the Gate Control List manages the final open/close state of the queues along with the checks carried out by the transmission selection algorithm in MTL. Since the gate controls operate on a predefined repetitive schedule, it is recommended to use strict priority or credit based shaper (CBS) scheduling algorithms.

Other algorithms such as the weighted round robin (WRR), deficit weighted round robin (DWRR) and weighted fair queuing (WFQ) implement the masking of the queues based on the current winning queue. The algorithm is applied only to the group of queues that open simultaneously. To ensure the queues whose gates are open get priority, these algorithms are modified to treat gate open queues and gate closed queues as separate groups, giving priority to gate open queues.

For example, consider four queues (Q3, Q2, Q1, Q0) with respective weights 4:3:2:1. Q3 and Q2 are in open state in one slot, while Q1 and Q0 are in open state in another slot. In this case, the scheduler works as follows:

1. 1. In the first slot, Q3 and Q2 are serviced in the ratio of 4:3 for the duration during which the slot is open.
2. 2. In the second slot, Q1 and Q0 are serviced in the ratio of 2:1.
3. 3. Fresh arbitration is started every time a slot is opened.

In other words, the traffic does not get distributed in the intended ratio of 4:3:2:1; but as two groups with different ratios, and only for the duration of the slot when the gates are open continuously.

EST programming guidelines

For details about programming guidelines for EST, see Section 76.9.20: Programming guidelines for EST on page 4146 .

Frame preemption (FPE)

Frame preemption overview

One of the important requirements of IEEE 802.1Qbv-2015 standard is to ensure there are no interfering frames during the scheduled windows that are reserved for high priority traffic. To achieve this goal, a guard band, whose size is equal to the largest possible interfering frame, is required before the window starts. However a larger guard band equates to a less efficient use of network bandwidth.

Frame preemption compliant with IEEE802.1Qbu enables reducing the guard band by breaking the interfering frame into smaller fragments. Therefore, the guard band needs to be only as large as the largest possible interfering fragment instead of the largest possible interfering frame.

Note: Internal loopback is not supported for preempted frames

Description of the frame preemption

Preemption enables one or more higher priority (express) frames to interrupt the transmission of a lower priority (preemptable) frame. The preemptable frame transmission is resumed and completed after the express frame transmission is complete. The following two abstractions of the MAC are used to support frame preemption:

• • A preemptable MAC (pMAC), which carries the preemptable traffic
• • An express MAC (eMAC), which carries the express traffic

Only the part of the MAC that holds the state during preemption is replicated and represented as pMAC and eMAC. There are two ways for the MAC to put on hold the transmission of the preemptable traffic in the presence of express traffic:

• • The MTL scheduler interrupts the preemptable traffic that is currently being transmitted.

When the preemption capability is enabled, the MAC interrupts the transmission and reception of preemptable frames. A preempted fragment can be followed by zero or more express frames, before the continuation fragments. The preemptable frame can be fragmented any number of times. However, the minimum final and non-final fragment length criterion must be met.

Interleaving of more than one preemptable packet is not permitted. This implies that if a preemptable packet is fragmented by an express packet, another preemptable packet

cannot be transferred until all the remaining fragments of the first preempted packet are transferred.

• • The MTL scheduler prevents starting the transmission of preemptable traffic
  When the preemption capability is disabled, the pMAC entity is disabled and only express traffic is transmitted or received.

Note: Queue0 can be an express queue when FPE is enabled and EST is disabled.

Enabling frame preemption

Enable the frame preemption feature by setting EFPE field of FPE control and status register (ETH_MACFPECSR) .

Modifying GCL to support FPE

In the EST-only configuration, the GCL entry has 24 bits of time interval and 8 high order bits representing the gate open/close state requirements as shown in Table 799 .

Table 799. Gate control list when FPE is disabled

EST only supports SetGate operations, which implies that the gates are set either to open or close at a given time interval.

However, when both FPE and EST are enabled, the GCL also supports Set-and-Hold-MAC and Set-and-release-MAC operations, in addition to the SetGate operation.

To support hold and release operations, the format of the GCL is slightly changed while configuring and enabling FPE. The first Queue (Q0) is always programmed to carry preemption traffic and therefore it is always open. The bit corresponding to Q0 is renamed as Release/Hold MAC control.

The TX queues whose packets are preemptable are identified by setting the PEC field of FPE control and status register (ETH_MACFPECSR) . The GCL bit of the corresponding queue is ignored and considered as always open. As a result, even if the software writes a 0 (C), it is ignored for such queues.

Table 800. Gate control list when FPE is enabled

Table 800. Gate control list when FPE is enabled (continued)

When the Release/Hold bit transitions from a 0 to 1, a Set-and-Hold-MAC operation is performed. This marks the cease of the preemptable traffic. This is achieved by sending a Hold request to MTL ha ns in advance (where ha is the time interval mentioned in the Hold advance (HADV) field of FPE Frame Preemption Advance register (ETH_MTLFPEAR) ). When the Release/Hold bit transitions from a '1' to '0', a Set-and-Release-MAC operation is performed. This marks the resuming of the preemptable traffic. This is achieved by sending a Release request to MTL ra ns in advance (where ra is the time interval mentioned in the Release Advance (RADV) field of FPE Frame Preemption Advance register (ETH_MTLFPEAR) ). The preemptable traffic is blocked for the time duration the Release/Hold bit is set to a '1' in the gate control list.

Note: HADV is the advance time to initiate the hold state. Ideally HADV should be programmed to a value of minimum fragment size, which should be smaller than the time interval (minimum fragment size + IPG + Preamble overheads in ns).

Impact of preemption on CBS algorithm

When the CBS algorithm is used, the definition of Transmit is as follows:

• • TRUE for the duration of frame transmission from the queue;
• • FALSE when frame transmission from the queue is complete.

When the CBS algorithm is used along with frame preemption, the value of Transmit is TRUE only during the frame transmission by the MAC. If the frame transmission is delayed or interrupted (for instance, a preemptable frame transmission is interrupted to allow the transmission of an express frame from a different queue, or the start of an express frame is delayed because a preemptable frame is being transmitted), the value of Transmit is FALSE until the transmission of the frame begins or is resumed.

In addition, the value of Transmit is FALSE during the transmission of any overhead resulting from a frame preemption. For example, additional frame overhead (mCRC, Fragment Count) that is added to the preemptable frame.

At any given time, if there are no frames in the queue, the value of Transmit is FALSE, and the credit is positive, the credit value is set to zero if there is no preemptable frame from the queue for which transmission is in progress but has been interrupted.

mPacket Format

When the preemption capability is enabled, MAC sends mPackets to the PHY. An mPacket can be:

• • An express packet
• • A preemptable packet
• • An initial fragment of a preemptable packet
• • A continuation fragment of a preemptable packet

Figure 1037 shows the format of the mPacket. It contains an express packet, a complete preemptable packet or the initial fragment of a preemptable packet. Figure 1037 (b) shows the format of an mPacket containing a continuation fragment of a packet.

Figure 1037. mPacket formats

Preamble

The preamble in the mPacket shown in Figure 1037 (a) contains seven octets. The preamble in the mPacket shown in Figure 1037 (b) contains six octets. Each octet contains the value 0x55, transmitted from left to right, 10101010.

Start mPacket Delimiter (SMD)

The value of the SMD indicates whether the mPacket contains an express packet, the start of a preemptable packet (initial fragment or complete packet), or any continuation fragments of a preemptable packet. Table 801 shows the valid SMD values.

A frag_count is a modulo-4 counter that increments for each continuation fragment of the preemptable packet. The frag_count protects against mPacket reassembly errors by enabling detection of the loss of up to three packet fragments.

The frag_count field is present only in mPackets with SMD-C notation (continuation fragment). The frag_count is zero in the first continuation fragment of each preemptable packet.

The contents of the packet from the MAC, starting with the first byte after the SFD to the last byte before the FCS, are sent in the mData fields of one or more mPackets for that frame. The minimum size of the mData field is 60 bytes.

The CRC field contains a cyclic redundancy check (CRC) and provides an indication on the final mPacket of a frame. In the final mPacket of a frame, the CRC field contains the last four octets of the MAC frame (FCS field).

For other mPackets, the CRC field contains an mCRC value. The mCRC is calculated on the octets of the packet from the first octet of the frame (octet following the SFD of

preemption frames) to the last octet of the packet transmitted in that mPacket, by performing an XOR of the calculated 32-bit CRC value of the fragment with 0x0000FFFF.

Summary of Packet Formats

• • Express packet
  Seven bytes of preamble, SMD-E, data and CRC
• • Complete Preemptable packet
  Seven bytes of preamble, current preemptable packet SMD, data, CRC
• • Initial fragment (non-final) of preemptable packet
  Seven bytes of preamble, current preemptable packet SMD, data, mCRC
• • Continuation fragments (non-final) of preemptable packet
  Six bytes of preamble, current preemptable continuation fragment SMD, current preemptable continuation fragment FC, data, mCRC
• • Final fragment of preemptable packet
  Six bytes of preamble, current preemptable continuation fragment SMD, current preemptable continuation fragment FC, data, CRC

Note: When frame preemption is enabled, the MAC receiver communicates the exceptions related to received preempted fragments (such as incorrect fragment sequencing or missed fragment) to the MTL layer by reporting it as CRC error. The software should not set the DCRCC (Disable CRC Checking for Received Packets) bit of Extended operating mode configuration register (ETH_MACECR) to 1, otherwise the MTL layer might forward the unintended preempted fragments to the application.

Table 803. Current and Previous SMD Values

Table 804. Current and previous SMD values

Table 804. Current and previous SMD values (continued)

Transmit preemption

MTL Tx preemption

To support preemption, the MAC should have more than one TX queue with at least one queue designated as express queue, plus one queue designated as preemption queue. When FPE is enabled (EFPE set to 1 in FPE control and status register (ETH_MACFPECSR) ), the MTL preempts a preemptable frame. When a Hold request is asserted (EST configured and enabled), express frames are available for transmission, that is frames are present in the MTL FIFO and qualified for arbitration, after ensuring that the minimum mPacket mData field size is met. Therefore, preemption occurs only if at least 60 bytes of the preemptable frame have been transmitted and at least 64 bytes (including the frame CRC) remain to be transmitted.

The earliest starting position of preemption is controlled by the AFSZ field of FPE control and status register (ETH_MACFPECSR) . Preemption does not occur until at least \( 64 \times (1 + \text{AFSZ}) - 4 \) bytes of the preemptable frame have been sent.

When preemption occurs, all the preemptable queues are blocked and only the express queues are allowed to arbitrate (if more than one express queue has traffic) and transmit.

The continuation fragment of the preempted frame is the first frame to be transmitted after a Release request is asserted (EST configured and enabled) and all the express traffic transmission completes.

Note: All the PTP packets should be transmitted as express packets.

MTL should wait for the previous fragment status to be received before resuming the continuation fragments of a preempted frame.

MAC Tx preemption

The MAC supports the preemption by implementing the functionality required to generate the mPackets as described in Section : mPacket Format .

When the preemption is enabled, the MAC replaces the SFD of a preemption packet with an SMD-S value. A 2-bit rolling frame count is encoded in the SMD-S value.

The SMD-E value is the same as the SFD value, so the SFD of an express packet does not need to be replaced.

Receive preemption

MAC receive preemption

When FPE is enabled, the MAC receiver passes the incoming packets and differentiates between express packets and preemptable packets. An SMD containing an SMD-E indicates express packet while and SMD containing an SMD-S indicates the first mPacket of a preemptable packet.

If an mPacket containing an SMD-S is received when the reception of the previous preempted packet has not be completed, the MAC sets a CRC error status for the previously received partial packet.

When an SMD-S is detected, the MAC records the frame count indicated by the SMD, and begins sending data on the MRI interface.

The MAC checks the last four bytes of the mPacket. If they do not match CRC, it indicates the end of the packet with or without a CRC error as per the CRC check result. If the last four octets of the mPacket match, it indicates that the packet was preempted.

An SMD containing an SMD-C indicates an mPacket that continues the data for a preempted packet. Upon receiving an SMD value of SMD-C, the MAC checks the following:

• • A preempted packet is in progress.
• • The frame count indicated by the SMD matches the frame count of the packet in progress.
• • The frag_count value indicates the next fragment count.

If any of these checks fails, the mPacket is discarded and the MAC sets a CRC error status for the partially received packet.

If all the checks pass, the next fragment count is incremented modulo 4.

When a packet is preempted, the MAC saves the state of the partially received packet (such as filter check status, timestamp, length fields) and can process any received express packets before the continuation fragment is received.

Data alignment

When a received frame cannot be fragmented on any byte boundary, the MAC retains the unaligned bytes of data in the previous fragment and resends them with the next fragment as shown in Figure 1038 .

Figure 1038. MAC data alignment feature

The MTL can choose to ignore the partial data (based on byte enable value) that comes with end of fragment and use instead the data-width-aligned data received in the first beat of the next continuation fragment.

MTL receive preemption

The MTL Rx must have at least two Rx queues to support FPE function since the preemptable packets and the express packets must be routed to separate Rx queues. The destination Rx queue of a received packet is controlled by ETH_MACRXQCiR registers. Program these registers so that preemptable traffic and express traffic are not routed to the same Rx queue. As the queue mapping for tagged packets is based on VLAN user-priority field, this implies that priority of preemptable and express packets are mutually exclusive. In other words, packets of a certain priority (traffic class) are either express or preemptable but cannot be both.

For the preemptable frames, in addition to the PSRQ (Priority Selected in Rx queue) based queue routing, a programmable frame preemption residue queue (FPRQ) is supported to route all the other received preemption packets (untagged, SA/ DA or VLAN filter fails forwarded due to RA being set or VTFE being reset).

1. 1. Only if the queue is enabled for AV feature.
2. 2. Only if the queue is enabled for Generic feature.

The express frames use Queue 0 as a default queue. As a result, Queue 0 must not be used for receiving preemption frames in case of filter failures.

When a fragment is received, it is pushed into its destination Rx queue. When this packet is preempted and is followed by an express packet, it is pushed/stored in a different Rx queue. The MTL saves the context of the preempted frame and processes one or more express frames. When the continuation fragment arrives, it restores the saved context and pushes the remainder of the fragmented frame into its Rx queue.

MTL receive arbitration

On the DMA interface, data is fetched from the MTL Rx FIFO based on the arbitration selected in Operating mode register (ETH_MTLOMR) . Frame based arbitration can be used only when all the MTL preemption queues operate in Store and Forward mode. Otherwise, there is a loss of bandwidth on the ARI interface since all the fragments of a preemptable packet are not available. Therefore, express packets received between the fragments are blocked until all the fragments are received and transferred; this defeats the purpose of express traffic.

When operating either in Threshold (cut through) or Store and Forward operating mode, PBL-based arbitration is recommended over frame-based arbitration. If PBL-based arbitration is used, the watermark check is always performed as well as the arbitration/transfer of data in terms of chunks of PBL size of data, which is almost similar to the concepts of fragments. Therefore the express queue packets is also blocked for less time since the DMA interface transfers the data without loss of efficiency.

Received preemption frames support in offload engines

When FPE is enabled, all the packets processed by the offload engines (ARP, PTO) and PMT, PTP, PAUSE, and PFC packets must be received as express/normal packets. These offload engine logic and functions do not recognize preemption frames.

Verify and respond mPackets

When FPE function is present, the MAC can receive and detect the Verify and Respond mPackets, even when FPE is not enabled by software. When the MAC detects valid verify/respond mPackets, it notifies the software by setting the RVER and RRSP fields of FPE control and status register (ETH_MACFPECSR) , respectively. Optionally an interrupt can be generated. As such packets have empty (all-zero) data payload, they are dropped inside the MAC and not forwarded to the MRI.

The software can set the SVER and SRSP fields of FPE control and status register (ETH_MACFPECSR) to request the MAC to transmit Verify and Respond mPackets respectively. Upon successful transmission of these frames, the MAC clears the SVER/SRSP bits and sets the TVER and TRSP bitfields in FPE control and status register (ETH_MACFPECSR) . Optionally an interrupt can be generated when these events occur.

1. Note:
2. 1. 1. For the preemption frames received with CRC error indication, ignore the following status fields: Packet length, Dribble error indication, Runt frame indication.
   2. 2. When FPE is configured, the forward undersized good packets (FUP) bit of ETH_MTLOMR register should not be set.
   3. 3. When FPE is configured, do not disable CRC checking on receive. This is required because, FPE error fragments are identified internally using CRC checks. For more details, refer to the DCRCC bitfield in Extended operating mode configuration register (ETH_MACECR) .
   4. 4. Express and preemption traffic must be routed to different DMAs.

Frame preemption and MMC counter and interrupt registers

The following MMC counters and associated Interrupt registers are present in the MAC.

Table 806. MMC Counters and Associated Interrupt Registers

The following additional registers are associated to MMC interrupts for the MMC error counters:

• • MMC FPE Tx interrupt status register (ETH_MMC_FPE_TX_ISR)
• • MMC FPE Tx interrupt mask register (ETH_MMC_FPE_TX_IMR)
• • MMC FPE Rx interrupt status register (ETH_MMC_FPE_RX_ISR)
• • MMC FPE Rx interrupt mask register (ETH_MMC_FPE_RX_IMR)

Time-based scheduling (TBS)

The time-based scheduling feature is suitable for traffic whose periodicity and rate are predictable. To improve the quality-of-service of such traffic:

• • The transmit DMA fetches the packet from the host memory for transmission at designated time. This helps the software to set up the Transmit descriptors in advance, even before the packet is ready and available. It reduces the overhead on the software and avoids constant monitoring of the time and preparing descriptors just in time when the packet is targeted to be transmitted.
• • The MAC transmits the packets only at the designated/predetermined time even if the packets are fetched in advance. This helps maintaining a constant transmission rate that can be consumed by the receiver, therefore avoiding congestion and excessive buffering in the network.

Description of time-based scheduling

The time-based scheduling feature supports fetching and launching of an Ethernet packet at (or after) a predetermined time. The time-based scheduling is supported only in the following modes and configurations:

• • Full duplex mode
• • Link speed of 100 Mbps or higher

Note: Do not enable time-based scheduling for channels on which the TSO feature is enabled. The ESTM mode bit setting impacts the time-based scheduling feature only when the DUT processes the GCL list.

The slot number is meaningful only after the GCL is active. So, start the GCL list before enabling the time-based scheduling (TBS) and enhancements to scheduled traffic (EST) features. If the GCL is not started, all gates are deemed open. In addition, if the packets do not make progress, the Tx queue creates back pressure.

Definitions

The following are the definitions specific to the time-based scheduling feature:

• • Launch time: time beyond which the MTL can schedule the packet for transmission.
• • GCL slot number (GSN)
• • Launch expiry time: time beyond which the packet is dropped by the MTL.
• • Fetch time: time beyond which the Tx DMA can schedule a packet fetch from the host memory.

Launch time

The launch time is specified in the enhanced normal descriptor in the DMA configuration. For more details, refer to Section 76.10.5: Enhanced descriptor for time-based scheduling .

When the launch time is specified, it is valid only for the specific frame that is scheduled for transmission. The launch time is reset after the transmission of one frame.

The following are the two launch time formats:

• • Normal/absolute format

In this format, the launch time is an absolute time value at which the packet is launched for transmission. The launch time is interpreted in the normal/absolute format if the ESTM bit of the TBS control register (ETH_MTLTBSCR) is cleared.

The launch time is a 32-bit value where the most-significant eight bits represent the time in seconds and the remaining 24 bits the time in 256 ns. The launch time is compared with the IEEE 1588-based system/PTP time (bits[39:8]) and rolls over after 256 seconds.

The maximum value of the lower 32 bits of system time is 999,999,999 in decimal (0x3B9A C9FF), and it wraps to 0 when reaching this value (representing a full second). Therefore, the maximum value of the lower 24 bits of the launch time (after multiplying by 256) must be 0x3B9AC9.

As the maximum value of the launch time is 256 seconds:

• – The launch time is greater than the current system time when its value is between System Time[39:8] and System Time[39:8] + 128 s.
• – The launch time is less than the current system time when its value is between System Time[39:8] + 128 s and System Time[39:8] + 256 s, because this is a modulo 256 computation.
• • EST/offset format

In this format, the launch time is an offset value relative to the time indicated by the base time register (BTR) of the GCL list provided in the GCL slot number (GSN). The value in the BTR is always updated to the start time of the current loop of the GCL.

For each packet, the GSN and the launch time values are specified in the Enhanced Transmit descriptor in the DMA configurations, or as control word in the MTL configurations.

The launch time offset is a 32-bit value where the upper eight bits represent the time in seconds and the remaining 24 bits the time in 256 ns that is added to the BTR value corresponding to the GCL slot number. The value of the launch time offset must be smaller than the value of the cycle time (it is specified in the CTR register that is implemented when EST is enabled).

If the CTR is greater than or equal to 1 s, the maximum value of the lower 24 bits of launch time offset should be 999 999 999 in decimal (0x3B9A C9FF).

In this format, the launch time is a 64-bit value, which is interpreted as follows:

It is compared with the System Time[63:0].

GSN BTR is the base time value at which the launch GSN loop started execution.

GCL slot number (GSN)

The GCL slot number (GSN) is a modulo 16 count of the GCL loop count. The count is incremented for every new GCL loop. The installation of a new GCL list does not impact the count. The current GCL slot number can be obtained by reading the CGSN field of the EST Status register (ETH_MTLESTSR) .

The maximum value of GSN is 15. Therefore GSN values between the current GSN (CGSN field of EST Status register (ETH_MTLESTSR) ) and CGSN + 8 represent the current or future slots; all the other GSN values are interpreted as elapsed slots or past slots. The GSN value must consequently be between CGSN and CGSN + 8, for a correct interpretation of time.

• • Normal/absolute mode

In Normal mode, when the LEOV (launch expiry offset valid bit of TBS control register (ETH_MTLTBSCR) ) is set, the Launch Expiry Offset (LEOS field of TBS control register (ETH_MTLTBSCR) ) determines the maximum amount of time during which a frame is eligible for launch, starting from the time at which the frame becomes eligible for launch.

The Launch Expiry Offset is a 24-bit value defined in 256 ns units, with a maximum value of 999,999,999 ns (0x3B9A C9FF).

The packet with a specific launch time is considered eligible for transmission when the launch time is less than the system time and (if LEOV is set) the system time is less than the launch expiry time.

When the system time is greater than the launch expiry time, the frame is categorized as expired and is dropped from the MTL FIFO.

Note: For correct interpretation and meaningful operation, the fetch, launch, and launch expiry times should never be set to a value higher than the current system time + 128 s, since such a value is interpreted as time that has already elapsed.

In Full duplex mode, the frames dropped from the MTL FIFO have the Error Summary (bit 15) and Excessive Deferral (bit 3) of the Tx status set.

• • EST/offset mode

In EST mode of operation, when the LEOV field of the TBS control register (ETH_MTLTBSCR) is set, the Launch Expiry GSN Offset (LEGOS field of the TBS control register (ETH_MTLTBSCR) ) and Launch Expiry Offset (LEOS field of TBS control register (ETH_MTLTBSCR) ) determine the maximum amount of time during which a frame remains eligible for launch, starting from the time at which the frame becomes eligible for launch.

LEGOS holds the GSN offset (multiples of CTR time) and LEOS holds the maximum value of CTR (subCTR values) in ns.

The Launch Expiry Offset is a 24-bit value defined in units of 256 ns, with a maximum value which is the smaller of 999,999,999 ns and CTR - 1 ns.

The Launch Expiry GSN is computed as follows:

Where:

CCMA is the CTR carry due to modulo addition. This value is 1 if \( ((\text{Launch Time Offset} + \text{LEOS}) \ll 8) \) is equal to or greater than CTR.

• – When CCMA = 1: \( \text{Launch Expiry Offset} = (\text{Launch Time Offset} + \text{LEOS}) - \text{CTR} \) .
• – When CCMA = 0, \( \text{Launch Expiry Offset} = (\text{Launch Time Offset} + \text{LEOS}) \) .

The launch expiry time is computed as follows:

When LEOV is not set, the launch expiry time is not checked.

When LEOV is set:

• • If the system time is greater than the launch expiry time, the frame is dropped from the MTL FIFO. The frame is considered as expired.
• • If the launch time is smaller than the system time and the launch expiry time is greater than the system time, the frame is considered eligible for launch.

Note: The maximum value of LEGOS is 7. This implies that when LEOV is set, the frame has a maximum life time of less than 8 GCL loop iterations after it becomes eligible for launch. The slot number of the first GCL list executed each time after EST is enabled, is zero.

Fetch time

The fetch time can also be indicated by the software for each packet. This is done by setting the FTOV field of DMA TBS Control Register x (ETH_DMATBSCTRL0R).

If the FTOV field is not set, the Fetch Time Offset is not valid and the DMA fetches packets without any time constraints.

The fetch time accounts for all possible delays in the DMA fetch operation and ensures that the frame is present in the MTL FIFO before the launch time.

• • Normal/absolute mode

In Normal mode, the fetch time is derived/calculated by reducing the time specified in the Fetch Time Offset (FTOS) field of DMA TBS Control Register x (ETH_DMATBSCTRL0R) from the given launch time.

In Normal mode of operation, the fetch launch time is computed as follows:

The fetch time is a 32-bit value. It is compared against System Time[39:8] to determine the eligibility for fetching the frame:

• – The fetch time is defined as greater than the system time if the fetch time is in the range of System Time[39:8] and System Time[39:8] + 128 s. The frame is considered as not-eligible for fetch.
• – The fetch time is defined as smaller than the system time if the fetch time is in the range of System Time[39:8] + 128 s and System Time[39:8] + 256 s. The frame is considered as eligible for fetch.

This is a modulo 256 computation.

• • EST/offset mode

In EST/offset mode, the Fetch GSN Offset (FGOS field of DMA TBS Control Register x (ETH_DMATBSCTRL0R) provides the slot number offset to be deducted from the launch GSN. In this case, the FTOS value should be the smaller of 999,999,999 ns and CTR – 1 ns.

If Launch Time Offset \( \geq \) FTOS:

• – Fetch Time Offset = ((Launch Time Offset – FTOS) \( \times \) 256 ns)
• – CBFS (CTR Borrow for Fetch Subtraction) = 0

If Launch Time Offset \( < \) FTOS:

• – Fetch Time Offset = CTR + ((Launch Time Offset – FTOS) \( \times \) 256 ns)
• – CBFS (CTR Borrow for Fetch Subtraction) = 1

The Fetch GSN is computed as follows:

• – Fetch GSN = Launch GSN – FGOS – CBFS
• – Fetch Time = Fetch GSN BTR[63:0] + Fetch Time Offset

Note: The frame is marked eligible for DMA fetch when the fetch time is smaller than the system time.

The maximum value of FGOS is 7. This implies that when FTOV is set, the frame can be fetched at a maximum of 8 GCL loop iterations before it becomes eligible for Launch.

• • DMA operation sequence

The following is the sequence of operation when FTOV is set:

1. a) Fetch the first enhanced normal descriptor (FD is set).
2. b) If LTV is set and fetch enabled, compute the fetch time based on the launch time. Wait for the system time to be greater than the fetch time
3. c) Read the frame (data) from the host memory and transfer it to the MTL FIFO.
4. d) Close the normal descriptor.
5. e) Fetch the next normal descriptor (if the previous descriptor was not the last).
6. f) Repeat steps d to f until the last descriptor of the frame (LD is set).

After the last descriptor of a frame, the next enhanced normal descriptor should be programmed with a new launch time and with LTV bit set. Otherwise, the subsequent frames are processed without any time restrictions.

• • Impact on the transmission selection algorithm

The time-based scheduler does not directly influence the transmission selection algorithm but has an indirect influence as it determines if a queue is eligible to participate in the scheduling.

If a frame of a specific queue has a valid launch time, the time-based scheduler ensures that the frame participates in transmit scheduling (TRC scheduler) only after the launch time has elapsed.

The gating done by the time-based scheduler is only for the scheduling (picking frame for transmission). It might not alter any other characteristics and behavior of the frame. For example, the frame waiting for the launch time to elapse continues to gain credits in CBS, and the CBS credits are not lost as the frame is marked as available but not ready. Strict priority and CBS are recommended transmit scheduling algorithms for the TBS implementation because scheduling for TBS enabled queues is more predictable.

Figure 1039. Time-based scheduler implementation

For details about programming guidelines, see Section 76.9.21: Programming the launch time in time-based scheduling .

Figure 1040 shows the time-based scheduling flow.

Figure 1040. Time-based scheduling flow

graph TD; A[Fetch the first enhanced normal descriptor] --> B[If LTV = 1, Compute fetch time based on launch time]; B --> C[If LTV = 1, Wait for system time ≥ fetch time]; C --> D[Read packet data from system memory and push into MTL FIFO]; D --> E[Close the descriptor]; E --> F{LD = 1}; F --> G[Fetch next transmit descriptor]; F --> H{End of descriptor ring}; G --> H; H --> I[Wait for Transmit Poll Demand]; I --> A;

76.5.7 Checksum offload engine

Communication protocols such as TCP and UDP implement checksum fields, which help determine the integrity of data transmitted over a network. The most widespread use of Ethernet is to encapsulate TCP and UDP over IP datagrams. The MAC has a Checksum Offload Engine (COE) to support checksum calculation and insertion in the Transmit path, as well as error detection in the receive path.

Transmit checksum offload engine

In the transmit path, the MAC calculates the checksum and inserts it in the Tx packet. This feature helps reducing the load on the software and can improve the overall system throughput.

The COE module supports two types of checksum calculation and insertion. The checksum engine can be controlled for each packet by setting the CIC bits (TDES3 bits[17:16]).

Note: The checksum for TCP, UDP, or ICMP is calculated over a complete packet, and then inserted into its corresponding header field. Because of this requirement, the Tx FIFO

automatically operates in the Store-and-forward mode even if the MAC is configured in Threshold (cut-through) mode.

Make sure that the Tx FIFO is deep enough to store a complete packet before that packet is transferred to the MAC transmitter, the reason being that when space is not available to accept the programmed burst length of data, then the MTL Tx FIFO starts reading to avoid deadlock. In such a case, the COE fails as the start of the packet header is read out before the payload checksum can be calculated and inserted. Therefore, the checksum insertion must be enabled only in the packets that are less than the number of bytes, given by the following equation:

where

TxQSize corresponds to the TQS bitfield of Tx queue x operating mode register (ETH_MTLTXQxOMR)

PBL corresponds to the TxPBL bitfield of Channel x transmit control register (ETH_DMACTXCR)

Refer to IETF specifications RFC 791, RFC 793, RFC 768, RFC 792, RFC 2460, and RFC 4443 for IPv4, TCP, UDP, ICMP, IPv6, and ICMPv6 packet header specifications, respectively.

IP header checksum engine

In IPv4 datagrams, the integrity of the header fields is indicated by the 16-bit Header Checksum field (the eleventh and twelfth bytes of the IPv4 datagram). The COE detects an IPv4 datagram when the Type field of Ethernet packet has the value 0x0800 and the Version field of IP datagram has the value 0x4. The checksum field of the input packet is ignored during calculation and replaced with the calculated value.

Note: IPv6 headers do not have a checksum field. Therefore, the COE does not modify the IPv6 header fields.

The result of this IP header checksum calculation is indicated by the IP Header Error status bit in the Transmit status (bit 0 in Table 828: TDES3 normal descriptor (write-back format) ).

This status bit is set whenever the values of the Ethernet Type field and the Version field of IP header are not consistent, or when the Ethernet packet does not have enough data, as indicated by the IP header Length field. In other words, this bit is set when an IP header error is asserted under the following circumstances:

• • For IPv4 datagrams:
  • – The received Ethernet type is 0x0800, but the Version field of IP header is not equal to 0x4.
  • – The IPv4 Header Length field indicates a value less than 0x5 (20 bytes).
  • – The total packet length is less than the value given in the IPv4 Header Length field.
• • For IPv6 datagrams:
  • – The Ethernet type is 0x86DD but the IP header Version field is not equal to 0x6.
  • – The packet ends before the IPv6 header (40 bytes) or extension header (as given in the corresponding Header Length field in an extension header) is completely received.

TCP/UDP/ICMP checksum engine

The TCP/UDP/ICMP Checksum Engine processes the IPv4 or IPv6 header (including extension headers) and determines whether the encapsulated payload is TCP, UDP, or ICMP. The checksum is calculated for the TCP, UDP, or ICMP payload and inserted into its corresponding field in the header. The Tx COE can work in the following two modes:

• • The TCP, UDP, or ICMPv6 pseudo-header is not included in the checksum calculation and is assumed to be present in the Checksum field of the input packet. This engine includes the Checksum field in the checksum calculation, and then replaces the Checksum field with the final calculated checksum.
• • The engine ignores the Checksum field, includes the TCP, UDP, or ICMPv6 pseudo-header data into the checksum calculation, and overwrites the checksum field with the final calculated value.

Note: For ICMP-over-IPv4 packets, the Checksum field in the ICMP packet must always be 0x0000 in both modes, because pseudo-headers are not defined for such packets. If it does not equal 0x0000, an incorrect checksum may be inserted into the packet.

The result of this operation is indicated by the Payload Checksum Error status bit in the Transmit Status vector (bit 12 in Table 828: TDES3 normal descriptor (write-back format) ). This engine sets the Payload Checksum Error status bit when it detects that the packet has been forwarded to the MAC transmitter engine in the store-and-forward mode without the end of packet (EOP) being written to the FIFO, or when the packet ends before the number of bytes indicated by the Payload Length field in the IP Header is received. When the packet is longer than the indicated payload length, the COE ignores them as stuff bytes, and no error is reported. When this engine detects the first type of error, it does not modify the TCP, UDP, or ICMP header. For the second error type, it still inserts the calculated checksum into the corresponding header field.

Table 807 describes the functions supported by Transmit Checksum Offload engine based on the packet type. When the MAC does not insert the checksum, it is indicated as “No” in the table.

Note: Do not enable checksum insertion for IPv4 or IPv6 packets that are greater than the frame size constraint specified in Section : Transmit checksum offload engine because it might result in incorrect checksum insertion or unexpected behavior.

Table 807. Transmit checksum offload engine functions for different packet types

Receive checksum offload engine

The receive checksum offload engine is used to detect errors in IP packets by calculating the header checksum and further matching it with the received header checksum. This engine also identifies a TCP, UDP, or ICMP payload in received IP packets and calculates the checksum of such payloads appropriately.

The receive checksum offload engine (Rx COE) can be enabled by setting the IPC bit of Operating mode configuration register (ETH_MACCR) . When this bit is set, both IPv4 and IPv6 packet in the received Ethernet packets are detected and processed for data integrity. The MAC receiver identifies IPv4 or IPv6 packets by checking for value 0x0800 or 0x86DD, respectively, in the Type field of the received Ethernet packet. This identification is applicable to single VLAN-tagged packets. It is also applicable to double VLAN-tagged packets when the EDVLP bit of the VLAN tag Control register (ETH_MACVTCR) is set.

The Rx COE calculates the IPv4 header checksums and checks that they match the received IPv4 header checksums. The result of this operation (pass or fail) is given to the RFC module for insertion into the receive status word. The IP Header Error bit is set for any mismatch between the indicated payload type (Ethernet Type field) and the IP header version, or when the received packet does not have enough bytes, as indicated by the Length field of the IPv4 header (or when fewer than 20 bytes are available in an IPv4 or IPv6 header).

Packets with TCP/IP errors (header or payload) are dropped in MTL when DIS_TCP_EF bit of the Rx queue x operating mode register (ETH_MTLRXQxOMR) is reset and FEP bit is set.

This engine also identifies a TCP, UDP, or ICMP payload in the received IP datagrams (IPv4 or IPv6) and calculates the checksum of such payloads properly, as defined in the TCP, UDP, or ICMP specifications. This engine includes the TCP, UDP, or ICMPv6 pseudo-header bytes for checksum calculation and checks whether the received checksum field matches the calculated value. The result of this operation is given as a Payload Checksum Error bit in the receive status word. This status bit is also set if the length of the TCP, UDP, or ICMP payload does not match the expected payload length given in the IP header.

Table 808: Receive checksum offload engine functions for different packet types describes the functions supported by the Rx COE based on the packet type. When the payload of an IP packet is not processed (indicated as "No" in the table), the information (whether the checksum engine is bypassed or not) is given in the receive status.

Note: The MAC does not append any payload checksum bytes to the received Ethernet packets.

Table 808. Receive checksum offload engine functions for different packet types

76.5.8 TCP segmentation offload

The MAC supports the TCP segmentation offload (TSO) feature in which the DMA splits a large TCP packet into multiple small packets and passes these packets to the MTL as shown in Figure 1041 .

This feature is enabled by programming the TSE bit of corresponding ETH_DMACxCR register (see Channel x transmit control register (ETH_DMACxTXCR) ). It is only supported when the MAC operates in Full-duplex mode.

For detailed programming steps, refer to Section 76.9.16: Programming guidelines for TSO .

Figure 1041. TCP segmentation offload overview

graph LR
    TCP[TCP packet] --> TSD[TSD engine]
    subgraph DMA_Block [ ]
        TSD --> DMA_CH[DMA Tx Channel #]
    end
    TSD --> SegN[Seg N]
    SegN --> Dots[...] 
    Dots --> Seg2[Seg 2]
    Seg2 --> Seg1[Seg 1]
    Seg1 --> MTL[MTL Tx queue #]

DMA operation with TSO feature

Figure 1042 shows the TSO flow.

Figure 1042. TCP segmentation offload flow

graph TD; A([Receive TSO packet]) --> B[Read header]; B --> C[Update header fields (if required)]; C --> D[Forward the header to the MTL]; D --> E{Header complete?}; E -- No --> B; E -- Yes --> F[Read payload]; F --> G[Forward the payload to the MTL]; G --> H{Payload length = MSS?}; H -- No --> F; H -- Yes --> I[Segmentation Complete]; I --> J{Payload remaining?}; J -- Yes --> B; J -- No --> K([Read the next packet])

For the TSO feature, the Tx DMA operation is as follows:

1. 1. The application sets up the Transmit descriptor (TDES0-TDES3) and sets the Own bit (TDES3[31]) after setting up the corresponding data buffer(s) with Ethernet packet data.
2. 2. The application increases the offset value of the descriptor tail pointer of the DMA Tx channel.
3. 3. While in the Run state, the DMA fetches the next available descriptor and performs one of the following actions:
   • – If the descriptor is a context descriptor and the context is not between the first and last descriptors of a packet, the DMA stores the context values.
   • – If the descriptor is a context descriptor and the context is between the first and last descriptors of a packet, the DMA closes the context descriptor indicating a Context Descriptor Error (TDES3[23]) and fetches the next descriptor.

• – If the descriptor is a normal descriptor, the DMA checks the TSE bit. If the TSE bit is not set, the DMA continues with the default mode of operation or OSF operation (if enabled).
• 4. The DMA calculates the number of segments from the TCP payload length (TDES3[17:0]) and the MSS value.
• 5. The DMA goes through channel arbitration to fetch the data buffers. The DMA fetches the header and payload separately.
• 6. For the first segment, the DMA fetches the header from the system memory and stores it in the TSO memory (if present and when the length of header is not greater than the TSO memory size). If the current segmented packet is not the first segment, it fetches again the header buffer in system memory, as done for the first segment. In such cases, the DMA does not close the first descriptor containing the header buffer until the header for last segment is fetched.
• 7. The required fields in the header bytes are modified/updated as per the segmentation requirements and written into the corresponding MTL Tx queue.
• 8. The DMA then takes the payload buffer pointer, fetches the MSS number of payload bytes from the system memory, and directly pushes it into the MTL Tx queue. If the buffer(s) in the descriptor do(es) not have enough data for the MSS payload (except for the last segment), the DMA closes this descriptor.
• 9. The DMA jumps to Step 3 and repeats the process until the last segment is written into the Tx queue.
• 10. The DMA closes the last descriptor and the first descriptor (containing the header buffer when it is not stored in TSO memory), and then moves on to the next packet transfer.

The DMA repeats all these steps if more descriptors are available. When no more descriptor are available, the DMA enters the suspend state.

Note: The TSO engine determines whether to perform TSO or USO operation based on the THL field (TCP Header Length) in TDES3 of first Normal Tx descriptor for the packet. The value of 2 indicates USO and any value greater than or equal to 5 indicates TSO.

TCP/IP header fields

While segmenting a TCP packet, the DMA automatically updates the TCP/IP header fields. Table 809 describes how the TCP and IP headers are updated.

Table 809. TSO: TCP and IP header fields

Header and payload fields of segmented packets

After segmentation, the split packets use the same header as the parent TCP packet for header fields other than the ones described in Table 809: TSO: TCP and IP header fields . Figure 1043: Header and payload fields of segmented packets shows how same header is used for the header fields of segmented packets.

The application must create the header in Buffer 1 of the first descriptor of the packet to be segmented and provide the header length in TDES2 of the first descriptor (FD = 1). When the FD bit is set, the DMA reads the header from the header buffer to which the TDES0 is pointing. Buffer 2 of the first descriptor can be used for payload and TDES0 and TDES1 of subsequent descriptors. For subsequent descriptors (FD = 0), the address to which the TDES0 and TDES1 are pointing is treated as payload buffer address of the same packet.

Figure 1043. Header and payload fields of segmented packets

graph TD
    subgraph "Original Packet"
    H[Header H] --- P[TCP payload P]
    end

    H --> H_Tx[H]
    P --> P1[P1]
    P --> P2[P2]
    P --> P_dots[...] 
    P --> PV[P/V]

    subgraph "Single header in Tx buffer"
    H_Tx
    end

    subgraph "Segmented payload in Tx buffer"
    P1 --- P2 --- P_dots --- PV
    end

    H_Tx --> SP1_H[H]
    P1 --> SP1_P[P1]
    
    H_Tx --> SP2_H[H]
    P2 --> SP2_P[P2]

    H_Tx --> SPV_H[H]
    PV --> SPV_P[P/V]

    subgraph "Segmented Packets"
    SP1[H | P1]
    SP2[H | P2]
    SP_dots[H | ...]
    SPV[H | P/V]
    end

Context descriptor sequence

The context descriptor can provide the maximum segment size (MSS) value for segmentation. The application must provide the context descriptor before the normal descriptor to be used for the corresponding TCP packet. If the application needs to provide a new MSS, it must create the context descriptor in the descriptor list before the first normal descriptor of the packet to be segmented with the new MSS value. The MSS value in the context descriptor is valid only if the TCMSSV bit of TDES3 in context descriptor is set and the OSTC bit is reset (refer to Section 76.10.3: Transmit descriptor ).

When the application provides a context descriptor with a valid MSS value, the DMA internally stores the MSS value and uses this value for all subsequent packets for which the TSO is enabled through the TSE bit of TDES3 normal descriptor.

If the application places a context descriptor in the middle of a packet (between the first and last descriptors of a packet), the DMA does the following:

1. 1. The DMA ignores the context and closes the descriptor.
2. 2. The DMA indicates the error in descriptor status.
3. 3. The DMA generates an interrupt if the CDEE bit is set in the Interrupt enable register corresponding to a DMA channel (see Channel x interrupt enable register (ETH_DMACxIER) ).

The application can read the interrupt status through CDE bit of Status register corresponding to a DMA channel (see Channel x status register (ETH_DMACxSR) ).

Building the Descriptor and the packet for the TSO feature

To enable segmentation for a packet, the application must set the TSE bit of TDES3 of first normal descriptor (see Section 76.10.3: Transmit descriptor ). If the TSE bit is set in TDES3 for a non TCP/IP packet, the DMA behavior is unpredictable.

The application must program the length of the TCP packet payload in TDES3[17:0] and the TCP header in TDES3[22:19]. The maximum length of TCP packet payload that can be segmented is 256 Kbytes.

Note: The TDES3[22:19] bitfield is used as slot number in case of AV configurations. If both TSO and AV are enabled for the same DMA Tx channel (TSE bit is set in Channel x transmit control register (ETH_DMACxTXCR) ), then do not enable slot checking for that DMA Tx channel (do not set ESC bit in Channel x slot function control status register (ETH_DMACxSFCR) ).

The header of the packet including Ethernet header, L3 header and L4 header should be provided in Buffer1 of the first normal descriptor of the TSO packet. Only buffer 1 of the first normal descriptor of a packet enabled for TSO is taken as the buffer containing the header.

The TCP payload can begin from buffer 2 of the first normal descriptor and continue to buffer 1 and buffer 2 of second normal descriptor and subsequent descriptors.

The TCP payload may span across multiple buffers and multiple descriptors. The size of buffers containing the TCP payload should add up to be equal to the TCP payload length provided in TDES3[17:0] of the first normal descriptor.

The MAC always calculates and appends CRC and inserts Padding (if required) for all packets segmented by the DMA. If the TSE bit of TDES3 is enabled, the CRC PAD Control (CPC) field of TDES3 is reserved. To determine the size of a TCP packet after segmentation, the DMA uses the Maximum Segment Size (MSS) provided by the application through context descriptor. The DMA segments only those packets which have payload size greater than MSS. The application must provide the MSS by either programming the MSS value in ETH_DMACxCR (see Channel x control register (ETH_DMACxCR) ) or by providing a context descriptor. The DMA uses the last programmed value of MSS or the last MSS value provided through context (whichever is provided later).

The header length plus the MSS size (which is equal to the size of each TCP segment) should not exceed 16383 bytes otherwise the MAC transmitter truncates the packet after 16383 bytes causing a CRC error.

The header length plus MSS size plus programmed PBL value in ETH_DMACxTXCR register (see Channel x transmit control register (ETH_DMACxTXCR) ) should be lesser than the Tx queue size programmed in TQS field of ETH_MTLTXQOMR register (see Tx queue x

operating mode register (ETH_MTLTXQxOMR) ). A MSS plus header equal to half the programmed Tx queue size is recommended.

The DMA also supports segmentation of VLAN-tagged TCP/IP frames. If the TCP packet has a VLAN tag, then the same tag is used for all the segments irrespective of the VLAN tag type provided (C-VLAN or S-VLAN). The VLAN tag insert/replace control bits are used for all segments.

If the Double VLAN feature is selected, then the DMA passes both tags for all segments irrespective of the VLAN tag types provided (C-VLAN or S-VLAN). The VLAN tag Insert/Replace control bits for both tags is applicable to all segments. If the Double VLAN feature is not selected, then the application must not set the TSE bit in TDES3 for a TCP/IP packet with two tags. The DMA behavior in this scenario is unpredictable.

If the TSE bit is set in TDES3 for the packet and TCP header length provided is less than 5 (meaning this is an invalid TCP header because it is less than 20 bytes), the DMA does not perform segmentation, instead it transmits the entire packet as a single packet. In this scenario, the CRC pad control bits are forced by DMA to 00 (MAC does CRC and padding) and checksum insertion control bits are forced to 11 (hardware does the checksum calculation for both header and payload).

76.5.9 IPv4 ARP offload

The MAC supports the Address Recognition Protocol (ARP) Offload for IPv4 packets. This feature allows to process the IPv4 ARP request packet in the receive path and to generate the corresponding ARP response packet in the transmit path.

The MAC generates the ARP reply packets for appropriate ARP request packets. ARP packets for IPv4 are L2 layer packets with Length/Type of 0x0806.

The ARP offloading sequence is as follows:

1. 1. The MAC receiver gets an ARP request if the request Target Protocol Address matches the IPv4 address programmed in the MAC L3 register.
2. 2. The MAC generates an ARP reply packet.
3. 3. The MAC copies the Sender Hardware Address field in the ARP request to the following fields:
   • – DA field of the Ethernet packet header
   • – Target Hardware Address field of the ARP reply packet
4. 4. The MAC copies the Sender Protocol Address field in the ARP request to the Target Protocol Address field in the ARP reply packet.
5. 5. The MAC places its MAC address in the following fields:
   • – SA field of the Ethernet packet header
   • – Sender Hardware Address field of the ARP reply packet
6. 6. The MAC copies the Target Protocol Address field in the ARP request to the Sender Protocol Address field in the ARP reply packet.
7. 7. The MAC sets the opcode field in ARP reply packet to 2 indicating ARP reply.
8. 8. The MAC recalculates the CRC and performs padding for the generated ARP reply packet.
9. 9. The MAC transmitter sends the ARP reply

The MAC processes only one ARP request at a time. It does not store the fields of multiple ARP requests. If the MAC receives an ARP request when it is already processing an earlier

ARP request, the MAC does not generate the ARP reply for new ARP request. The MAC forwards the new ARP request packet to the application with ARP Reply Not Generated status bit set (bit 34). However, in power-down mode, if the MAC receives an ARP request when it is already processing an earlier ARP request, the MAC drops the new ARP request. If the Disable CRC check (DCRCC) bit of the Extended operating mode configuration register (ETH_MACECR) is set, then the MAC does not check for valid CRC of a ARP request packet. It can generate an ARP response packet if the other conditions are valid. The ARP request packet must always have a valid CRC.

Note: When the received ARP request is less than the 64-byte packet length, the MAC does not send an ARP response. It is treated as a normal packet and forwarded to the application based on the MAC filter settings.

76.5.10 Loopback

The MAC supports loopback of transmitted packets to its receiver.

Guidelines for using loopback mode

Below some guidelines for using the loopback mode:

• • Enable loopback only with the Full-duplex mode. In Half-duplex mode, the carrier sense signal or collision signal inputs get sampled which may result into issues such as packet dropping.
• • If the loopback mode is enabled without connecting a PHY chip, externally generate the Tx and Rx clocks and provide these clocks to the MAC.
• • Do not loop back big packets since they may get corrupted in the loopback FIFO.

The transmit and receive clocks can have an asynchronous timing relationship. Therefore, an asynchronous FIFO is used to make the loopback path of the transmitted data to the receive path. The FIFO is free-running to write on the write clock (eth_tx_clk) and read on every read clock (eth_rx_clk). At the start of each packet read from the FIFO, the write and read pointers are reinitialized to have an offset of two or four (in 10/100 Mbit/s mode). This avoids overflow or underflow during a packet transfer, and ensures that the overflow or underflow occurs only during the IPG period between the packets. The FIFO depth of five or nine is sufficient to prevent data corruption for packet sizes up to 9,022 bytes with a difference of 200 ppm between (G)MII transmit and receive clock frequencies.

Therefore, bigger packets should not be looped back because they may get corrupted in this loopback FIFO.

At the end of every received packet, the receive Protocol Engine module generates received packet status and sends it to the receive Packet Controller module. The control, missed packet, and filter fail status are added to the receive status in the receive Packet Controller module. The MAC does not process ARP or PMT packets that are looped back.

Enabling loopback mode

To enable this feature, program the LM bit of the Operating mode configuration register (ETH_MACCR) . Loopback can be enabled for all PHY interfaces. The data is always looped back through internal asynchronous FIFO on to the internal receive MII or GMII interface, irrespective of which PHY interface is selected.

The loopback data is also passed through the corresponding transmit PHY interface block, onto the Ethernet line.

Note: During loopback, the data/packet is reflected on the gmii_txd signal. Preemption is not supported in loopback mode.

76.5.11 Flow control

The transmit flow control involves transmitting Pause packets in Full-duplex mode and back-pressure in Half-duplex mode to control the flow of packets from the remote end. This section describes the flow control for transmit and receive paths.

Flow control in Full-duplex mode

In Full-duplex mode, the MAC uses IEEE 802.3x Pause packets for flow control. Table 810 describes the fields of a Pause packet.

Table 810. Pause packet fields

When the FCB bit is set, the MAC generates and transmits a single Pause packet. If the FCB bit is set again after the Pause packet transmission is complete, the MAC sends another Pause packet irrespective of whether the pause time is complete or not. To extend the pause or terminate the pause prior to the time specified in the previously-transmitted Pause packet, the application should program the Pause Time register with appropriate value and then again set the FCB bit.

Flow control in Half-duplex mode

In Half-duplex mode, the MAC uses the deferral mechanism for the flow control (backpressure). When the application requests to stop receiving packets, the MAC sends a JAM pattern of 32 bytes when it senses a packet reception, provided the transmit flow control is enabled. This results in a collision and the remote station backs off. If the application requests a packet to be transmitted, it is scheduled and transmitted even when the backpressure is activated. If the backpressure is kept activated for a long time (and more than 16 consecutive collision events occur), the remote stations abort the transmission because of excessive collisions.

Table 811 describes the flow control in the Tx path for Queue 0 based on the setting of the following bits:

• • EHFC bit of Rx queue x operating mode register (ETH_MTLRXQxOMR)
• • TFE bit of Tx Queue 0 flow control register (ETH_MACQ0TXFCR)
• • DM bit of Operating mode configuration register (ETH_MACCR)

Flow control is similar for all queues.

Table 811. Tx MAC flow control

Transmit flow control

The transmit flow control is enabled when TFE bit is set in Tx Queue 0 flow control register (ETH_MACQ0TXFCR) .

Flow control trigger

The application can request the MAC to send a Pause packet or initiate back-pressure by setting the FCB bit in the corresponding Tx Queue 0 flow control register (ETH_MACQ0TXFCR) .

The flow control is also triggered based on Rx Queue Threshold: the flow control operation of the MAC is enabled when the EHFC bit in the corresponding Rx queue x operating mode register (ETH_MTLRXQxOMR) is set. The flow control signal to the MAC is asserted when the fill level of the Rx queue crosses the threshold configured in RFA field of Rx queue x operating mode register (ETH_MTLRXQxOMR) . This flow control signal is de-asserted when the fill-level of the queue is lower than the threshold configured in the RFD field.

Note: The RFA sets the threshold at which the flow control is triggered and the MAC schedules to send a PAUSE frame to be sent by the local transmitter.

The remote transmitter can continue to send packets until it receives this PAUSE packet. As a result, the RXQ needs space to take in this data even after the flow control is triggered, in order to avoid overflow and loss of packets.

The maximum space required is calculated theoretically. It can be 2 max-sized packets + a little more assuming that the read from the RxFIFO is not occurring during this whole time.

Theoretically, this makes \( RFA = 4 \) or more, which implies that \( RxQ \) must have a minimum size of 4 Kbytes.

Practically, the system works with \( RFA = 2 \) (full size – 2 Kbytes, with very little probability of overflow).

The RFA bitfield in Rx queue x operating mode register (ETH_MTLRXQxOMR) is used for activating the flow control. These bits control the threshold (fill-level of Rx queue ) at which the flow control is activated.

With an RXQ size of 4 Kbytes, RFA must be set to 2 Kbytes to receive the whole packet.

Receive flow control

In the receive path, the flow control is functional only in full-duplex mode. If any Pause packet is received in half-duplex mode, the packet is considered as a normal control packet.

Description of receive flow control

Table 812 describes the flow control in the Rx path based on the setting of the following bits:

• • RFE bit of Rx flow control register (ETH_MACRXFCR)
• • DM bit of Operating mode configuration register (ETH_MACCR)

Table 812. Rx MAC flow control

The following sequence describes the Rx flow control:

1. 1. The MAC checks the destination address (DA) of the received Pause packet for either of the following:
   • – Multicast destination address: the DA matches the unique multicast address specified for the control packet (0x0180 C200 0001).
   • – Unicast destination address: the DA matches the content of the MAC Address 0 registers ( MAC address 0 high register (ETH_MACA0HR) and MAC address x low register (ETH_MACAxLR) ) and the UP bit of Rx flow control register (ETH_MACRXFCR) is set.
     If the UP bit is set, the MAC processes Pause packets with unicast destination address in addition to the unique multicast address.
2. 2. The MAC decodes the following fields of the received packet:
   • – Type field: this field is checked for 0x8808.
   • – Opcode field: this field is checked for 0x0001 (Pause packet).
   • – Pause time: the Pause time (for Pause packet) is captured to determine the time for which the transmitter needs to be blocked.
3. 3. If the byte count of the status indicates 64 bytes and there is no CRC error, the MAC transmitter pauses the transmission of any data packet for the duration of the decoded Pause Time value multiplied by the slot time (64 byte times).

If subsequent Pause packets are received before the earlier Pause Time expires, the MAC updates the Pause Timer with new value.

Enabling receive flow control

Set the RFE bit in the Rx flow control register (ETH_MACRXFCR) to enable the Pause flow control.

76.5.12 MAC management counters

The peripheral supports storing the statistics about the received and transmitted packets in registers that are accessible through the application.

The counters in the MAC management counters (MMC) module can be viewed as an extension of the register address space of the CSR module. The MMC module maintains a set of registers for gathering statistics on the received and transmitted packets. The register set includes a control register for controlling the behavior of the registers, two 32-bit registers containing interrupts generated (receive and transmit), and two 32-bit registers containing masks for the Interrupt register (receive and transmit). These registers are accessible from the Application through the AHB slave interface in the same way the CSR registers are accessed. The organization of these registers is shown in Section 76.11.4: Ethernet MAC and MMC registers .

The MMC counters are free running. There is no separate enable for the counters to start. A particular MMC counter starts counting when corresponding packet is received or transmitted.

The receive MMC counters are updated for packets that are passed by the Address Filter (AFM) block. The statistics of packets dropped by the AFM module, are not updated unless they are runt packets of less than 6 bytes (DA bytes are not received fully). To get statistics of all packets, set bit 0 in the Packet filtering control register (ETH_MACPFR) . The MMC module gathers statistics on encapsulated IPv4, IPv6, TCP, UDP, or ICMP payloads in received Ethernet packets.

In addition to control registers, two sets of registers are implemented:

• • Six registers used for collision, error, and good packet counters:
  • – Tx single collision good packets register (ETH_TX_SINGLE_COLLISION_GOOD_PACKETS)
  • – Tx multiple collision good packets register (ETH_TX_MULTIPLE_COLLISION_GOOD_PACKETS)
  • – Tx packet count good register (ETH_TX_PACKET_COUNT_GOOD)
  • – Rx CRC error packets register (ETH_RX_CRC_ERROR_PACKETS)
  • – Rx alignment error packets register (ETH_RX_ALIGNMENT_ERROR_PACKETS)
  • – Rx unicast packets good register (ETH_RX_UNICAST_PACKETS_GOOD)
• • Four registers to record LPI mode transition:
  • – Tx LPI microsecond timer register (ETH_TX_LPI_USEC_CNTR)
  • – Tx LPI transition counter register (ETH_TX_LPI_TRAN_CNTR)
  • – Rx LPI microsecond counter register (ETH_RX_LPI_USEC_CNTR)
  • – Rx LPI transition counter register (ETH_RX_LPI_TRAN_CNTR)

Definitions

The following terminology is used in MMC register descriptions:

• • Transmitted packets are considered “good” if transmitted successfully. In other words, a transmitted packet is good if the packets transmission is not aborted because of any of the following errors:
  • – Jabber timeout
  • – No carrier or loss of carrier
  • – Late collision
  • – Packet underflow
  • – Excessive deferral
  • – Excessive collision
• • Received packets are considered “good” if none of the following errors exists:
  • – CRC error
  • – Runt packet (shorter than 64 bytes)
  • – Alignment error (in 10/100 Mbit/s only)
  • – Length error (non-Type packet only)
  • – Out of range (non-Type packet only, longer than 1518 bytes)
  • – GMII_RXER input error
• • The maximum transmit frame size depends on the frame type, as follows:
  • – Untagged frame maxsize = 1,518
  • – VLAN frame maxsize = 1,522
  • – Jumbo frame maxsize = 9,018
  • – JumboVLAN frame maxsize = 9,022
• • The maximum receive packet size depends on the packet type and control bits (JE, S2KP, GPSLCE and EDVLP), as shown in the Table 813 .

Table 813. Size of the maximum receive packet

76.5.13 Interrupts generated by the MAC

Interrupts can be generated from the MAC as a result of various events. These interrupt events are combined with the events in the DMA on the eth_sbd_intr_it signal. The MAC interrupts are of level type, that is, the interrupt remains asserted (high) until it is cleared by the application or software.

The Interrupt status register (ETH_MACISR) describes the events that can cause an interrupt from the MAC. The MAC interrupts are enabled by default. Each event can be prevented from asserting the interrupt on the eth_sbd_intr_it signals by setting the corresponding mask bits in the Interrupt enable register (ETH_MACIER) .

The interrupt register bits only indicate the block from which the event is reported. You must read the corresponding status registers and other registers to clear the interrupt.

76.5.14 MAC and MMC register descriptions

Refer to Section 76.11.4: Ethernet MAC and MMC registers .

76.6 Ethernet functional description: PHY interfaces

The Ethernet peripheral support several PHY interfaces. The root interface is the MII/GMII one. All other interfaces are derived from it as shown in Figure 1044 .

Figure 1044. Supported PHY interfaces

This section describes the SMA module used for PHY control and different PHY interfaces. It contains the following sections:

• • Station management agent (SMA)
• • Media independent interface (MII)
• • Reduced media independent interface (RMII)
• • Reduced gigabit media independent interface (RGMII)

76.6.1 Station management agent (SMA)

The application can access the PHY registers through the station management agent (SMA) module. The SMA includes a two-wire station management interface (MIM).

The SMA module supports accessing up to 32 PHYs. The application can address one of the 32 registers from any 32 PHYs. Only one register in one PHY can be addressed at a time. The application sends the control data to the PHY and receives status information from the PHY through the SMA module, as shown in Figure 1045 .

Figure 1045. SMA Interface block

SMA functional overview

The MAC initiates the management write or read operation with respect to the MDC clock. The MDC clock is derived from the CSR clock (eth_hclk). The maximum operating frequency of the ETH_MDC pin is 2.5 MHz, as specified in IEEE 802.3 specifications. However, a different divider can be selected if the system supports higher clock frequencies. The division factor depends on the clock range setting through CR[3:0] in the MDIO address register (ETH_MACMDIOAR) register. The MDC clock is selected as follows:

Table 814. MDC clock selection

The data exchange between the MAC and the PHY is performed through a three-state buffer and brought out as ETH_MDIO line connected to the PHY.

Figure 1046 shows the structure of a Clause 45 MDIO packet, while Table 815 provides a detailed description of the packet fields.

Figure 1046. MDIO packet structure (Clause 45)

Table 815. MDIO Clause 45 frame structure

The frame structure for Clause 22 frames is also supported. The C45E bit in MDIO address register (ETH_MACMDIOAR) can be programmed to enable Clause 22 or Clause 45 mode of operation. Figure 1047 shows the structure of a Clause 22 MDIO packet, while Table 816 provides a detailed description of the packet fields.

Figure 1047. MDIO packet structure (Clause 22)

Table 816. MDIO Clause 22 frame structure

In addition to normal read and write operations, the SMA also supports post-read increment address while operating in Clause 45 mode.

GMII/MII management write operations

After the station management agent receives the PHY address and the write data from the MAC CSR module, the SMA starts a write operation to the PHY registers.

Figure 1048 illustrates the flow for a write operation from the SMA module to the PHY registers.

Figure 1048. SMA write operation flow

graph TD; A[Set MAC MDIO address register bits[3:2] to 0b10 and bit 0] --> B[MAC CSR transfers PHY address and write data (MAC MDIO data register)]; B --> C[SMA module starts write operation on GMII management interface]; C --> D[Write data packet transmitted on MDIO]; D --> E[MAC drives MDIO for duration of packet]; E --> F[Write operation complete]; F --> G[CSR resets busy bit]; C --> H[Busy bit set high]; H --> I[CSR ignores write operations performed to MAC MDIO address or MAC MDIO data registers when Busy bit high]; I --> G;

When bits[3:2] are set to 01 and bit 0 to 1 in the MDIO address register (ETH_MACMDIOAR) , the MAC CSR module transfers the PHY address, the register address in PHY, and the write data ( MDIO data register (ETH_MACMDIODR) ) to the SMA to initiate a Write operation into the PHY registers. At this point, the SMA module starts a Write operation on the GMII management Interface using the management packet format specified in the GMII specifications (as per IEEE 802.3-2002 specifications, Section 22.2.4.5 ).

When the SMA module starts a Write operation, the write data packet is transmitted on the MDIO line. The MAC drives the MDIO line for complete duration of the packet. The Busy bit is set high until the write operation is complete. The CSR ignores the Write operations per-

formed to the MDIO address register (ETH_MACMDIOAR) or the MDIO data register (ETH_MACMDIODR) during this period (the Busy bit is high). When the Write operation is complete, the SMA module indicates this to the CSR, and the CSR resets the Busy bit. The packet format for the Write operation is as follows:

Figure 1049. Write data packet

MSV40807V1

GMII/MII management read operation

When bits[3:2] are set to 11 and bit 0 to 1 in the MDIO address register (ETH_MACMDIOAR) , the MAC CSR module transfers the PHY address and the register address in PHY to the SMA to initiate a Read operation in the PHY registers. At this point, the SMA module starts a Read operation on the GMII/MII management interface using the management packet format specified in the GMII/MII specifications (as per IEEE 802.3-2002 specifications, Section 22.2.4.5 ).

When the SMA module starts a Read operation on the MDIO, the CSR ignores the Write operations to the MDIO address register (ETH_MACMDIOAR) or MDIO data register (ETH_MACMDIODR) register during this period (the Busy bit is high) and the transaction is completed without any error on the MCI interface. When the Read operation is complete, the SMA indicates this to the CSR. The CSR resets the Busy bit and updates the MDIO data register (ETH_MACMDIODR) with the data read from the PHY. The MAC drives the MDIO line for the complete duration of the frame except during the Data fields when the PHY is driving the MDIO line. For more information about the communication from the application to the PHYs, see the Reconciliation Sublayer and Media Independent Interface Specifications sections of the IEEE 802.3z, 1000BASE Ethernet.

The packet format for the Read operation is as follows:

Figure 1050. Read data packet

MSV40808V1

Preamble suppression

The IEEE standard specifies 32-bit preamble (all-ones) for the MDIO frames. The peripheral provides controls to support preamble suppression. It transmits MDIO frames with only 1 preamble bit. The preamble suppression can be enabled by setting the PSE bit in MDIO address register (ETH_MACMDIOAR) .

Trailing clocks and back-to-back transactions

The peripheral drives the ETH_MDC clock for the duration of the MDIO frame. There is no clock driven during the idle period. The trailing clock feature can be used if the PHY needs the ETH_MDC clock to be active for some cycles after the MDIO frame. The NTC[2:0] bitfield in MDIO address register (ETH_MACMDIOAR) allows the programming of trailing clocks from 0 to 7.

The peripheral supports back-to-back transactions which allow starting the next MDIO frame even before the trailing clocks are complete for previous MDIO frame. This feature can be enabled by setting BTB bit in MDIO address register (ETH_MACMDIOAR) when the trailing clock feature is also enabled. When back-to-back transactions are enabled, the GMII busy bit (GB) is cleared immediately after MDIO frame completion. This allows the software to issue the next command, which is executed by the peripheral while trailing clocks are still on for the previous MDIO frame. When (GB) transactions are not enabled, the GMII busy bit is cleared after the trailing clocks are complete for the MDIO frame.

Interrupt for MDIO transaction completion

The peripheral can generate an interrupt on completion of MDIO read or write transactions. Therefore, the application need not poll the GMII busy bit of the MDIO address register (ETH_MACMDIOAR) to know the completion of MDIO commands.

76.6.2 Media independent interface (MII)

The media-independent interface (MII) defines the interconnection between the MAC sublayer and the PHY for data transfer at 10 Mbit/s and 100 Mbit/s.

MII signals are given in Figure 1051: Media independent interface (MII) signals .

Figure 1051. Media independent interface (MII) signals

• • TX_CLK : continuous clock that provides the timing reference for Tx data transfers. The nominal frequency is 2.5 MHz at 10 Mbit/s and 25 MHz at 100 Mbit/s.
• • TXD[3:0] : transmit data.
  TXD is a bundle of 4 data signals driven synchronously by the MAC sublayer and qualified (valid data) on the assertion of the TX_EN signal. TXD[0] is the least significant bit, TXD[3] is the most significant bit. While TX_EN is deasserted, the transmit data must have no effect upon the PHY.
• • TX_EN : transmission enable signal indicating that the MAC is presenting nibbles on the MII for transmission. It must be asserted synchronously (TX_CLK) with the first nibble of the preamble and must remain asserted while all nibbles to be transmitted are presented to the MII.
• • TX_ER (optional) : required only for Energy Efficient Ethernet (EEE). The transmit error is indicated by inverting the CRC. The remote station can detect the Transmit error through incorrect CRC.
• • RX_CLK : continuous clock that provides the timing reference for Rx data transfers. The nominal frequency is 2.5 MHz at 10 Mbit/s, 25 MHz at 100 Mbit/s.
• • RXD[3:0] : receive data
  RXD is a bundle of 4 data signals driven synchronously by the PHY and qualified (valid data) on the assertion of the RX_DV signal. RXD[0] is the least significant bit, RXD[3] is the most significant bit. While RX_EN is deasserted and RX_ER is asserted, a specific RXD[3:0] value is used to transfer specific information from the PHY.

• • RX_DV: receive data valid

This signal indicates that the PHY is presenting recovered and decoded nibbles on the MII for reception. It must be asserted synchronously (RX_CLK) with the first recovered nibble of the frame and must remain asserted through the final recovered nibble. It must be deasserted prior to the first clock cycle that follows the final nibble. In order to receive the frame correctly, the RX_DV signal must encompass the frame, starting no later than the SFD field.

• • RX_ER: receive error

This signal must be asserted for one or more clock periods (RX_CLK) to indicate to the MAC sublayer that an error was detected somewhere in the frame. This error condition must be qualified by RX_DV assertion.

• • CRS: carrier sense.

This signal is asserted by the PHY when either the transmit or receive medium is non idle. It is deasserted by the PHY when both transmit and receive media are idle. The PHY must ensure that the CS signal remains asserted throughout the duration of a collision condition. This signal is not required to transition synchronously with respect to the Tx and Rx clocks. In Full-duplex mode the state of this signal is don't care for the MAC sublayer.

• • COL: collision detection signal

This signal must be asserted by the PHY upon detection of a collision on the medium and must remain asserted while the collision condition persists. This signal is not required to transition synchronously with respect to the Tx and Rx clocks. In Full-duplex mode, the state of this signal is don't care for the MAC sublayer.

76.6.3 Reduced media independent interface (RMII)

The reduced media independent interface (RMII) specification reduces the pin count between Ethernet PHYs and STM32 MCU (only in 10/100 mode). According to the IEEE 802.3u, an MII contains 16 pins for data and control. RMII specification reduces the pin count to 7.

Part of the Ethernet peripheral, the RMII module is instantiated at the MAC output. This helps in translating the MII of the MAC into the RMII. The RMII block has the following characteristics:

• • Supports 10 Mbit/s and 100 Mbit/s operating rates. It does not support the 1000 Mbit/s operation.
• • Provides independent 2-bits wide transmit and receive paths by sourcing two clock references externally.

RMII block diagram

Figure 1052: RMII block diagram shows the position of the RMII block relative to the MAC and RMII PHY. The RMII block is placed in front of the MAC to translate the MII signals to RMII signals.

Figure 1052. RMII block diagram

• • RMII_REF_CLK: continuous 50 MHz reference clock input
• • TXD[1:0]: transmit data
• • TX_EN: transmit data enable.
  When high, this bit indicates that valid data are being transmitted on TXD[1:0].
• • RXD[1:0]: receive data
• • CRS_DV: carrier Sense (CRS) and RX_Data Valid (RX_DV) multiplexed on alternate clock cycles. In 10 Mbit/s mode, it alternates every 10 clock cycles.

Transmit bit order

Each nibble from the MII interface must be transmitted on the RMII interface di-bit at a time with the order of di-bit transmission shown in Figure 1053: Transmission bit order . The lower order bits (D1 and D0) are transmitted first followed by higher order bits (D2 and D3).

Figure 1053. Transmission bit order

MSV40812V2

Receive bit order

Each nibble is transmitted to the MII interface from the di-bit received from the RMII interface in the nibble transmission order shown in Figure 1054: Receive bit order . The lower order bits (D0 and D1) are received first, followed by the higher order bits (D2 and D3).

Figure 1054. Receive bit order

76.6.4 Reduced gigabit media independent interface (RGMII)

The reduced gigabit media independent interface (RGMII) specification reduces the pin count of the interconnection between the MAC and the PHY for GMII and MII interfaces. To achieve this, the data path and control signals are reduced and multiplexed together with both edges of the transmit and receive clocks. For Gigabit operation, the clocks operate at 125 MHz; for 10/100 operation, the clock rates are 2.5/25 MHz.

The RGMII module is instantiated between the GMII of the MAC and the PHY to translate the control and data signals between the GMII and RGMII protocols. The RGMII block has the following characteristics:

• • Support of 10, 100 and 1000 Mbps operation rates.
• • No extra clock required since both edges of the incoming clocks are used.
• • Extraction of the in-band (link speed, link status, and duplex mode) status signals from the PHY and provides them to the MAC for link detection.

RGMI block diagram

Figure 1055: RGMI block diagram and interface signals shows the position of the RGMI block relative to the MAC and RGMI PHY. The RGMI block is placed between the GMII and the PHY to translate the GMII signals to RGMI signals.

Figure 1055. RGMI block diagram and interface signals

• • Transmit path: this block translates all GMII transmit signals to RGMI signals. The block registers all GMII input signals at the rising edge of eth_gmii_gtx_clk and generates all RGMI transmit signals at the rising and falling edges of eth_gmii_gtx_clk.
• • Receive path: this block translates all RGMI receive signals to GMII receive signals. The block registers all RGMI input signals at the rising and falling edges of eth_rx_clk and generates all GMII receive signals at the rising edge of eth_rx_clk.
• • GTX_CLK: RGMI clock for Tx data transfers, 125 MHz, 25 MHz or 2.5 MHz
• • TXD[3:0]: transmit data
• • TX_CTL: multiplexing of TX_EN on the rising edge of GTX_CLK, and a logical XOR between TX_EN and TX_ER values on falling edge of GTX_CLK
• • RX_CLK: RGMI clock for Rx data transfers
• • RXD[3:0]: receive data
• • RX_CTL: after demultiplexing, this pin provides ETH_RX_DV on the rising edge of ETH_RX_CLK, and ETH_RX_ER (logical XOR between ETH_RX_CTL values on rising edge and falling edge of ETH_RX_CLK).

Signal conversion

The RGMII block performs data conversions in both directions.

Transmit data conversion

As defined in the RGMII specification, multiplexing of data and control in Gigabit mode is accomplished by using both edges of the Transmit clock. The RGMII block accepts the 8-bit GMII transmit data from the MAC GMII (gmii_txd[7:0]) on the rising edge of eth_gmii_gtx_clk. For Gigabit operation, the RGMII block then converts gmii_txd[7:0] to two 4-bit nibbles and transmits the data on the RGMII transmit data port (rgmii_txd_o[3:0]) as follows:

• • At the rising edge of eth_gmii_gtx_clk, rgmii_txd_o[3:0] contains gmii_txd[3:0]
• • At the falling edge of eth_gmii_gtx_clk, rgmii_txd_o[3:0] contains gmii_txd[7:4]

For 10/100 mode, the Transmit data to the PHY is 4 bits. Therefore, for 10/100 mode, the RGMII block drives the gmii_txd[3:0] data to the PHY on rgmii_txd_o[3:0] at the rising edge of eth_gmii_gtx_clk.

Receive data conversion

In 1000-Mbps mode, the RGMII block registers the 4-bit data on the rgmii_rxd_i[3:0] signal at both edges of the Receive clock (eth_rx_clk) and transfers the resulting 8-bit data to the MAC GMII on the rising edge of eth_rx_clk clock, as follows:

• • gmii_rxd[3:0] is the value received on rgmii_rxd_i[3:0] at the rising edge of eth_rx_clk
• • gmii_rxd[7:4] is the value received on rgmii_rxd_i[3:0] at the falling edge of eth_rx_clk

In 10/100 mode, the RGMII block registers the 4-bit data on rgmii_rxd_i[3:0] only at the rising edge of eth_rx_clk and transfers the data to the MAC GMII on the rising edge of eth_rx_clk, as follows:

• • gmii_rxd[3:0] is the value received on rgmii_rxd_i[3:0] at the rising edge of eth_rx_clk.
• • gmii_rxd[7:4] is 0x0.

76.7 Ethernet low-power modes

76.7.1 Low-power management

The Ethernet peripheral supports the following techniques to save power:

• • Magic packet
• • Remote wake-up

The magic packet and remote wake-up techniques are used to save power in the host system when it is in low-power mode, and has to be woken up only at the reception of specific packets from the Ethernet network. In low-power mode, the clocks on most of the host logic, along with the majority of the peripherals (except the MAC receiver logic), can be disabled. On receiving the specific packets from the network, the MAC generates the trigger to wake up the host system and come back to normal state. Refer to the power control (PWR) section of the reference manual for the list of the system operating modes that support Ethernet low-power modes.

The Energy Efficient Ethernet (EEE) mode is compliant with the IEEE 802.3az-2010 standard. It is primarily targeted to save power in the Ethernet port when there is no traffic on the line. In this mode, the host indicates to the far-end that it does not have any packets to transmit in the near future and puts the transmitter port (MAC controller, PCS and PHY

layers) in low-power mode. Similarly, the receiver port can also be put in low-power mode when the far-end host indicates that it does not have any traffic to transfer. This allows significant saving of power in the Ethernet port (mainly in the PHY) with intermittent and burst traffic profile. The triggering of entry and exit out of the EEE mode is controlled by the MAC and is supported within the peripheral.

Simultaneous operation of the EEE mode along with any or both the other power saving modes is also supported.

Description of magic packet mode

This section describes how to save power through magic packet detection.

Note: The magic packet feature is based on the magic packet technology white paper from Advanced Micro Device (AMD).

The watchdog timeout limit for a magic packet is 2,048 bytes irrespective of the value programmed in WD bit in Operating mode configuration register (ETH_MACCCR) and PWE bit in Watchdog timeout register (ETH_MACWTR).

In the magic-packet-based power saving mode, the reception of a valid magic packet by the MAC receiver triggers an exit from low-power mode. The MAC enters power saving mode when PWRDWN bit of PMT control status register (ETH_MACPCSR) is programmed to 1. Exit from the magic-packet-based power saving mode is enabled by setting the MGKPKTEN bit of PMT control status register (ETH_MACPCSR) to 1.

The magic packet contains a unique pattern at any offset after the Destination address, Source address, and Length/Type fields. In addition to the unique pattern matching, the MAC receiver also checks for the following, to detect the received packet as a valid magic packet:

• • The packet must be addressed to it (Destination Address of the received packet should perfect match the MAC address 0 high register (ETH_MACA0HR) and MAC Address 0 low register (ETH_MACA0LR) ) or with multicast/broadcast address.
• • The packet must not have any length error, FCS error, dribble bit error, GMII error, and collision.
• • The packet must not be runt (length including Ethernet header and FCS is at least 64 bytes).

Magic packet data format

The content of the unique pattern in magic packets is described as follows:

• • Six bytes of all-ones (0xFF FF FF FF FF FF) called synchronization stream. There can be more than six bytes of 0xFF, but only the last six are considered.
• • The synchronization stream is immediately followed by 16 repetitions of the Destination address field of the packet ( MAC address 0 high register (ETH_MACA0HR) and the MAC Address 0 low register (ETH_MACA0LR) ) or multicast/broadcast address.
• • No break or interruption between synchronization stream and first repetition of Destination address field or within its 16 repetitions.

If the MAC address of a node is 0x00 11 22 33 44 55, the MAC scans for the following data sequence:

Destination Address Source Address Length/Type..... FF FF FF FF FF FF
00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55
00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55
00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55
00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55 00 11 22 33 44 55
...CRC

Description of remote wake-up packet mode

This section describes the power saving mode based on remote wake-up packet.

Note: The remote wake-up packet feature implementation is based on the Device Class Power Management Reference Specification and various implementation-specific white papers. The watchdog timeout limit for a magic packet is 2,048 bytes irrespective of the value programmed in WD bit in Operating mode configuration register (ETH_MACCCR) and PWE bit in Watchdog timeout register (ETH_MACWTR).

In the remote-wake-up-magic-packet-based power saving mode, the reception of expected remote wake-up packet by the MAC receiver triggers the exit from low-power mode. The MAC enters power saving mode when PWRDWN bit in PMT control status register (ETH_MACPCSR) is programmed to 1. Exit from the remote-wake-up-magic-packet-based power saving mode is enabled by programming RWKPKTEN bit of PMT control status register (ETH_MACPCSR) to 1.

The MAC implements a filter lookup table (programmed through Remote wake-up packet filter register (ETH_MACRWKPFR) in which CRC, offset, and byte mask of the pattern embedded in remote wake-up packet and the filter operation commands are programmed.

The pattern embedded in the remote wake-up packet is located at any offset after the Destination address and Source address fields. In addition to the CRC match for the pattern, the MAC receiver also checks the following, to detect the received packet as a valid remote wake-up packet:

• • The packet must be addressed to it (Destination Address of the received packet should perfect match the MAC address 0 high register (ETH_MACA0HR) and MAC Address 0 low register (ETH_MACA0LR)) or with multicast/broadcast address.
• • The packet must not have any length error, FCS error, dribble bit error, GMII error, and collision.
• • The packet must not be runt (length including Ethernet header and FCS is at least 64 bytes).

When a valid remote wake-up packet is received, the MAC receiver sets the RWKPRCVD bit in PMT control status register (ETH_MACPCSR) and triggers the interrupt on pmt_intr_o output port. The PMTIS bit in Interrupt status register (ETH_MACISR) is set when power-gating is not enabled in low-power mode. An interrupt is triggered to the application on the sbd_intr_o output port when interrupt is enabled (PMTIE bit in Interrupt enable register (ETH_MACIER) is set) and CSR clock is not gated off in low-power mode.

Remote wake-up packet filters

When the remote-wake-up-based power saving mode is enabled, four remote wake-up filters can be selected. The structure of the remote wake-up filters is shown in Table 817: Remote wake-up packet filter register.

Table 817. Remote wake-up packet filter register

The remote wake-up filter fields are described in Table 818: Description of the remote wake-up filter fields .

Table 818. Description of the remote wake-up filter fields

Table 818. Description of the remote wake-up filter fields (continued)

1. 1. The And_ Previous bit setting is applicable within a set of four filters. Setting And_ Previous bit of a filter that is not enabled has no effect, that is setting And_ Previous bit of lowest number filter in the set of four filters has no effect. For example, setting And_ Previous bit of Filter 0 has no effect. If And_ Previous bit is set for a given filter to form an AND chained filter, the AND chain breaks when it finds a disabled filter. For example: If Filter 2 And_ Previous bit is set (bit 1 in Filter 2 command is set) but Filter 1 is not enabled (bit 0 in Filter 1 command is reset), then only Filter 2 result is considered. If Filter 2 And_ Previous bit is set (bit 1 in Filter 2 command is set), Filter 3 And_ Previous bit is set (bit 1 in Filter 3 command is set), but Filter 1 is not enabled (bit 0 in Filter 1 command is reset), then only Filter 2 result ANDed with Filter 3 result is considered. If Filter 2 And_ Previous bit is set (bit 1 in Filter 2 command is set), Filter 3 And_ Previous bit is set (bit 1 in Filter 3 command is set), but Filter 2 is not enabled (bit 0 in Filter 2 command is reset), then since setting Filter 2 And_ Previous bit has no effect, only Filter 1 result ORed with Filter 3 result is considered.
   If filters chained by And_ Previous bit setting have complementary programming, then a frame may never pass the AND chained filter. For example, if Filter 2 And_ Previous bit is set (bit 1 in Filter 2 command is set), Filter 1 Address_Type bit is set (bit 3 in Filter 1 command is set) indicating multicast detection and Filter 2 Address_Type bit is reset (bit 3 in Filter 2 command is reset) indicating unicast detection or vice versa, then a remote wake-up frame does not pass the AND chained filter as a remote wake-up frame cannot be of both unicast and multicast address types.

The remote wake-up filter registers are implemented as eight indirect access registers (wkuppktfilter_reg#i) for four remote wake-up filters, and accessed by the application through Remote wake-up packet filter register (ETH_MACRWKPFR) . The entire set of wkuppktfilter_reg registers must be written to program the remote wake-up filters. The wkuppktfilter_reg register is programmed by sequentially writing the eight register values in Remote wake-up packet filter register (ETH_MACRWKPFR) for wkuppktfilter_reg0 to wkuppktfilter_reg3, respectively. The wkuppktfilter_reg register is read in a similar way. The MAC updates the wkuppktfilter_reg register current pointer value in RWKPTR field of PMT control status register (ETH_MACPCSR) .

Note: If the Remote wake-up packet filter register (ETH_MACRWKPFR) is accessed in byte or half-word mode, the internal counter to access the appropriate wkuppktfilter_reg is incremented when the CPU accesses Lane 3.

When Remote wake-up packet filter register (ETH_MACRWKPFR) is written, the content is transferred from CSR clock domain to PHY receive clock domain after the write operation. There should not be any further write to the Remote wake-up packet filter register (ETH_MACRWKPFR) until the first write is updated in PHY receive clock domain. Otherwise, the second write operation does not get updated to the PHY receive clock domain. Therefore, the delay between two write operations to the Remote wake-up packet filter register (ETH_MACRWKPFR) should be at least 4 cycles of the PHY receive clock.

PMT interrupt

The PMT interrupt signal is asserted when a valid remote wake-up packet is received.

Table 819 lists the remote wake-up scenarios in which PMT interrupt is generated.

Table 819. Remote wake-up packet and PMT interrupt generation ⁽¹⁾

1. 1. In all other combinations, the Remote Wake-up packet is not detected and PMT interrupt is not generated.

In addition to sbd_intr_o signal, the pmt_intr_o (synchronous to Rx clock) signal is asserted. The pmt_intr_o signal, synchronous to the Rx clock domain, is provided so that the application clock can be stopped by software when the MAC is in the power-down mode. It is ORed with lpi_intr_o signal (see Section : LPI interrupt ) and tied to the EXTI peripheral.

As the pmt_intr_o signal is generated in the PHY Rx clock domain, it is not cleared immediately when the PMT control status register (ETH_MACPCSR) is read. This is because the resultant clear signal has to cross to the PHY Rx clock domain, and then clear the interrupt source. This delay is at least 4 clock cycles of Rx clock and can be significant when the peripheral is operating in the 10 Mbit/s mode. When the application clears the PWRDWN bit in Remote wake-up packet filter register (ETH_MACRWKPFR) , the MAC comes out of the power-down mode, but this event does not generate the PMT interrupt.

Power-down sequence

The software must perform the following tasks to initiate the power-down sequence:

• • Disable the Transmit DMA (if applicable) by clearing the ST bit of the Channel x transmit control register (ETH_DMAxCxTXCR) .
• • Wait for any previous frame transmissions to complete. You can check this by reading TFCSTS[1:0] and TPESTS bits in Debug register (ETH_MACDR) and TXQSTS bit in Tx queue x debug register (ETH_MTLTXQxDR) of all MTL Tx Queues.
• • Disable the MAC transmitter and MAC receiver by clearing TE and RE bits in Operating mode configuration register (ETH_MACCR) .
• • Wait till the Receive DMA empties all frames from the Rx FIFO. You can check this by reading PRXQ[13:0] in Rx queue x debug register (ETH_MTLRXQxDR) of all Rx Queues. If these bits are zero, it indicates that the Rx FIFO is empty.
• • Configure the magic packet (MGKPKTEN) and/or remote wake-up (RWKPKTEN) detection in the PMT control status register (ETH_MACPCSR) .
• • Set bit 31 (ARPEN) in the Operating mode configuration register (ETH_MACCR) .
• • Enable the MAC receiver by setting RE bit and then set PWRDOWN bit in the PMT control status register (ETH_MACPCSR) to initiate the power-down sequence in MAC.

Note: If the feature is enabled and the MAC transmitter is in the LPI mode when it is put into the power-down mode, then the MII interface gets clamped to assert the LPI pattern. If the MAC transmitter is not in the LPI mode when it is put into the power-down mode, the GMII or MII interface gets clamped to all-zero.

Power-up sequence

The MAC wakes up on receiving the magic packet or remote wake-up frame. The power-up sequence is as follows:

• • The MAC asserts pmt_intr_o. When only clock-gating is employed in low-power mode, the pmt_intr_o signal can be used to start the clocks that were gated-off after entering low-power mode.
• • The software performs the following tasks:
  • – De-assert the pmt_intr_o by reading the PMT control status register (ETH_MACPCSR) .
  • – Perform a write operation (with reset values) to the PMT control status register (ETH_MACPCSR) and the Remote wake-up packet filter register (ETH_MACRWKPFR) so that the corresponding values in the always-on block gets synchronized. Otherwise, the values of these registers are different.
  • – Perform write operations to the Operating mode configuration register (ETH_MACCR) , MAC address 0 high register (ETH_MACA0HR) and MAC Address 0 low register (ETH_MACA0LR) to synchronize the values in the CSR module and the respective bits in the always-on block. Otherwise, the MAC receiver is on even though the Receive Enable bit is set to 0.

After completing these steps, the software must initialize all registers, enable the transmitter, and program the DMA (in DMA configurations) to resume the normal operation.

76.7.2 Energy-efficient Ethernet (EEE)

EEE is an operational mode that enables the IEEE 802.3 Media Access Control (MAC) sublayer along with a family of physical layers to operate in Low-power idle (LPI) mode. The

EEE operational mode supports the IEEE 802.3 MAC operation at 100 Mbit/s and 1000 Mbps. The peripheral supports the IEEE 802.3az-2010 for EEE.

The LPI mode allows saving power by switching off the parts of the communication device functionality when there is no data to be transmitted and received. The systems on both sides of the link can disable some functionalities to save power during the periods of low-link utilization. The MAC controls whether the system should enter or exit the LPI mode and communicates this to the PHY.

The EEE specifies the capabilities negotiation methods that the link partners can use to determine whether EEE is supported, and then select the set of parameters that are common to both devices.

Transmit path functions

The transmit path functions include tasks that the MAC must perform to make the PHY enter the LPI state.

In the transmit path, the software must set the LPIEN bit of the LPI control and status register (ETH_MACLCSR) to indicate to the MAC to stop transmission and initiate the LPI protocol. The MAC completes the transmission in progress, generates its transmission status, and starts transmitting the LPI pattern instead of the IDLE pattern if the link status has been up continuously for a period specified in the LPI LS TIMER LST[9:0] bitfield of LPI timers control register (ETH_MACLTCR) . The PHY Link Status PLS bit of the LPI control and status register (ETH_MACLCSR) indicates the link status of the PHY.

Note: The EEE feature is not supported when the MAC is configured to use the RMII.

According to the standard (IEEE 802.3az-2010), the PHY must not stop the TxCLK clock during the LPI state in the MII (10 or 100) mode. However, the MAC can stop the GTX_CLK clock during the LPI state in the GMII (1000) mode.

To make the PHY enter the LPI state, the MAC performs the following tasks:

1. 1. De-asserts TX_EN.
2. 2. Asserts TX_ER.
3. 3. Sets TXD[3:0] to 0x1 (for 100 Mbit/s) or TXD[7:0] to 0x01 (for 1,000 Mbps).
4. 4. Updates the status (TLPIEN bit of LPI control and status register (ETH_MACLCSR) ) and generates an interrupt.

Note: The MAC maintains the same state of the TX_EN, TX_ER, and TXD signals for the entire duration during which the PHY remains in the LPI state.

To bring the PHY out of the LPI state, that is when the software resets the LPIEN bit, the MAC performs the following tasks:

1. 1. Stops transmitting the LPI pattern and starts transmitting the IDLE pattern.
2. 2. Starts the LPI TW TIMER:
   The MAC cannot start the transmission until the wake-up time specified for the PHY expires. The auto-negotiated wake-up interval is programmed in the TWT field of the LPI timers control register (ETH_MACLTCR) .
3. 3. Updates the LPI exit status (TLPIEX bit of the LPI control and status register (ETH_MACLCSR) ) and generates an interrupt.

Figure 1056 shows the behavior of TX_EN, TX_ER, and TXD[3:0] signals during the LPI mode transitions.

Note: The MAC does not stop the TX_CLK clock. The application can stop this clock (as shown in Figure 1056) if the PHY supports it and when the MAC sets the sbd_tx_clk_gating_ctrl_o signal to 1. The sbd_tx_clk_gating_ctrl_o signal is asserted after nine Tx Clock Cycles, one Pulse Synchronizer delay, and one CSR clock cycle. The assertion of the sbd_tx_clk_gating_ctrl_o signal depends on the LPITCSE bit of the LPI control and status register (ETH_MACLCSR) and can be done automatically as shown on Figure 1057.

If RGMII Interface is selected, the Tx clock is required for transmitting the LPI pattern and so the Tx Clock cannot be gated.

If the MAC is in the Tx LPI mode and the Tx clock is stopped, the application should not write to CSR registers that are synchronized to Tx clock domain.

If the MAC is in the LPI mode and the application issues a soft reset or hard reset, the MAC transmitter comes out of the LPI mode.

Figure 1056. LPI transitions (Transmit, 100 Mbs)

Figure 1057. LPI Tx clock gating (when LPITCSE = 1)

Automated entry/exit from LPI mode in transmit path

The MAC transmitter can be programmed to enter and exit LPI Idle mode automatically based on whether it is Idle for a specific period of time or has a packet to transfer. These modes are enabled and controlled by the LPI control and status register (ETH_MACLCSR) .

When LPITXA and LPIEN of LPI control and status register (ETH_MACLCSR) are set, the MAC transmitter enters LPI Idle state when the MAC transmit path (including the MTL layers and DMA layers) are idle. The MAC transmitter exits the LPI Idle state and clears the LPITXEN bit as soon as any of functions in the TX path (DMA, MTL or MAC) becomes non-idle due to initiation of a packet transfer.

In addition, when LPITE is also set, the MAC transmitter enters LPI Idle state only if the Transmit path remains in idle state (no activity) for the time period indicated by the value in LPI entry timer register (ETH_MACLETR) . In this mode also, the MAC transmitter exits the LPI Idle state as soon as any of the functions becomes non-idle. However, the LPIEN bit is not cleared but remains active so that reentry to LPI Idle state is possible without any software intervention when the MAC becomes idle again.

When both LPITE and LPITXA bits are cleared, the application can directly control the entry and exit of LPI Idle state by programming the LPIEN bit.

Receive path functions

The receive path functions include the tasks that the PHY and MAC must perform when the PHY receives signals from the link partner to exit the LPI state.

In the receive path, when the PHY receives the signals from the link partner to enter into the LPI state, the PHY and MAC perform the following tasks:

1. 1. The PHY asserts RX_ER.
2. 2. The PHY sets RXD[3:0] to 0x1 (for 100 Mbit/s) or RXD[7:0] to 0x01 (for 1,000 Mbps).
3. 3. The PHY de-asserts RX_DV.
4. 4. The MAC updates the RLPIEN bit of the LPI control and status register (ETH_MACLCSR) and immediately generates an interrupt.

Note: The PHY maintains the same state of the RX_ER, RXD, and RX_DV signals for the entire duration during which it remains in the LPI state.

If the LPI pattern is detected for a very short duration (that is, less than two cycles of Rx clock), the MAC does not enter the Rx LPI mode.

If the duration between the end of the current Rx LPI pattern and the start of the next Rx LPI pattern is very short (that is, less than two Rx clock cycles), then the MAC exits and enters again the Rx LPI mode. The MAC does not trigger the Rx LPI Exit and Entry interrupts.

When the PHY receives signals from the link partner to exit the LPI state, the PHY and MAC perform the following tasks:

1. 1. The PHY de-asserts RX_ER and returns to a normal inter-packet state.
2. 2. The MAC updates the RLPIEX bit of the LPI control and status register (ETH_MACLCSR) and generates an interrupt immediately. The sideband signal lpi_intr_o (synchronous to Rx clock) is also asserted.

Figure 1058 shows the behavior of RX_ER, RX_DV, and RXD[3:0] signals during the LPI mode transitions.

Figure 1058. LPI transitions (receive, 100 Mbit/s)

Note: If the RX_CLK_stoppable bit (in the PHY register written through MDIO) is asserted when the PHY is indicating LPI to the MAC, the PHY may halt the RX_CLK at any time more than nine clock cycles after the start of the LPI state as shown in Figure 1058 .

If the MAC is in LPI mode and the application issues a soft reset or hard reset, the MAC receiver exits from LPI mode during reset. If the LPI pattern is still received after the reset is de-asserted, the MAC receiver enters again the LPI state.

If the RX clock is stopped in the RX LPI mode, the application should not write to the CSR registers that are being synchronized to the RX clock domain.

When the PHY sends the LPI pattern, if EEE feature is enabled, the MAC automatically enters the LPI state. There is no software control to prevent the MAC from entering the LPI state.

LPI timers

The transmitter maintains the LPI LS TIMER, LPI TW TIMER, and LPI AUTO ENTRY TIMER timers.

The following LPI timers are loaded with the respective values from the LPI timers control register (ETH_MACLTCR) and LPI entry timer register (ETH_MACLETR) :

• • LPI LS TIMER

The LPI LS TIMER counts, in milliseconds, the time expired since the link status is up. You can enable the monitoring of the LUD bit of the PHYIF control status register (ETH_MACPHYCSR) by setting the PLSEN bit of LPI control and status register (ETH_MACLCSR) .

The link status is indicated to the MAC by the LNKSTS bit of the PHYIF control status register (ETH_MACPHYCSR) or the value programmed by the software in the PLS bit of the LPI control and status register (ETH_MACLCSR) . If the link status is not available in the PHYIF control status register (ETH_MACPHYCSR) , the software should get the PHY link status by reading the PHY register and accordingly update the PLS bit.

This timer is cleared every time the link goes down. It starts to increment when the link is up again and continues to increment until the value of the timer becomes equal to the terminal count. Once the terminal count is reached, the timer remains at the same value as long as the link is up. The terminal count is the value programmed in the LST[9:0] bitfield in the LPI timers control register (ETH_MACLTCR) . The GMII interface does not assert the LPI pattern unless the terminal count is reached. This ensures a minimum time for which no LPI pattern is asserted after a link is established with the remote station. This period is defined as 1 second in the IEEE 802.3-az-2010. The LPI LS TIMER is 10-bit wide. The software can program up to 1023 milliseconds.

• • LPI TW TIMER

The LPI TW TIMER counts, in microseconds, the time expired since the de-assertion of LPI. The terminal count should be programmed in Bit[15:0] of LPI timers control register (ETH_MACLTCR) . The terminal count of the timer is the value of resolved Transmit TW that is the auto-negotiated time after which the MAC can resume the normal transmit operation. After exiting the LPI mode, the MAC resumes its normal operation after the TW timer reaches the terminal count.

The MAC supports the LPI TW TIMER in units of microsecond. The LPI TW TIMER is 16-bit wide. Therefore, the software can program up to 65535 micro seconds.

• • LPI AUTO ENTRY TIMER

This timer counts in steps of eight microseconds, the time for which the MAC transmit path has to remain in idle state (no activity), before the MAC transmitter enters the LPI IDLE state and starts transmitting the LPI pattern. This timer is enabled when LPITE bit in LPI control and status register (ETH_MACLCSR) is set.

Note: Program the PLS bit of LPI control and status register (ETH_MACLCSR) to 1'b0 before switching between the GMII and MII modes. This resets the internal timers. If the mode is changed after the LPI LS TIMER or LPI TW TIMER starts, the change in the Tx clock frequency can result in incorrect timeout.

LPI interrupt

The MAC generates the LPI interrupt when the Tx or Rx side enters or exits the LPI state. The interrupt sbd_intr_o is asserted when the LPI interrupt status is set. The LPI interrupt can be cleared by reading the LPI control and status register (ETH_MACLCSR) .

When the MAC exits the Rx LPI state, then in addition to the sbd_intr_o , the sideband signal lpi_intr_o (synchronous to Rx clock) is asserted. The lpi_intr_o signal can be used to trigger the external clock-gating circuitry to restore the application clock to the MAC. The lpi_intr_o signal, synchronous to the Rx clock domain, is provided so that the application clock can be stopped by software when the MAC is in the LPI state. It is ORed with pmt_intr_o signal (see Section : PMT interrupt ) and tied to the EXTI peripheral.

The lpi_intr_o signal is generated in the Rx clock domain. It may not be cleared immediately after the LPI control and status register (ETH_MACLCSR) is read. This is because the clear signal, generated in CSR clock domain, has to cross the Rx clock domain, and then clear the interrupt source. This delay is at least four clock cycles of Rx clock and can be significant when the peripheral is operating in the 10 Mbit/s mode.

Programming guidelines for Energy Efficient Ethernet

For detailed guidelines on the programming guidelines, see Section 76.9.13: Programming guidelines for Energy Efficient Ethernet (EEE) on page 4139 .

76.8 Ethernet interrupts

The Ethernet peripheral generates a single interrupt signal (eth_sbd_intr_it). This signal can be raised as a result of various events. These events are captured in status registers and interrupt enables are provided for each source of interrupt such that the interrupt signal is asserted for an event only when the corresponding interrupt enable is set.

The interrupt status and corresponding enable registers are organized in a hierarchical manner so that it is easier for software to traverse and identify the source of interrupt event quickly. When interrupt is asserted, the Interrupt status register (ETH_DMAISR) register is first level that indicates the major blocks for the interrupt event source. This register is read-only, and it contains bits corresponding to each DMA channel (TX & RX pair), the MTL, and the MAC. The software application must then read one (or more) of the following registers corresponding to the bits that are set:

• • ETH_DMAC0SR: channel 0 status (see Channel x status register (ETH_DMACxSR) )
• • ETH_DMAC1SR: channel 1 status (see Channel x status register (ETH_DMACxSR) )
• • ETH_MTLISR: interrupt status (see Interrupt status register (ETH_MTLISR) )
• • ETH_MACISR: interrupt status (see Interrupt status register (ETH_MACISR) )

76.8.1 DMA interrupts

Interrupt registers description

The ETH_DMAC0SR: Channel 0 Status register (see Channel x status register (ETH_DMACxSR) ) captures all the interrupt events of that TxDMA and RxDMA channel. The ETH_DMAC0IER: Channel 0 Interrupt Enable register (see Channel x interrupt enable register (ETH_DMACxIER) ) contains the corresponding enable bits for each of the interrupt event.

There are two groups of interrupts in the DMA channel namely Normal and Abnormal interrupts. They are indicated by Bits[15:14] of ETH_DMAC0SR register respectively. The normal group is for events that happen during the normal transfer of packets (TI: transmit interrupt, RI: receive interrupt, TBU: Transmit buffer unavailable) while the abnormal interrupt events are for error events.

Interrupts are not queued. If the same interrupt event occurs again before the driver responds to the previous one, no additional interrupts are generated. An interrupt is generated only once for multiple events. The driver must scan the Interrupt status register (ETH_DMAISR) for the cause of the interrupt and clear the source in the respective Status register. The interrupt is cleared only when all the bits of Interrupt status register (ETH_DMAISR) are cleared.

Periodic scheduling of transmit and receive interrupt

It is not preferable to generate interrupts for every packet transferred by DMA (RI and TI) for system throughput performance reasons. The Ethernet peripheral gives the flexibility to schedule the interrupt at regular intervals using two methods:

1. 1. Set Interrupt on Completion bit in Transmit descriptor (TDES2[31] in Table 823: TDES2 normal descriptor (read format) ) once for every “required” number of packets to be transmitted.
2. 2. Similarly, set the IOC (RDES3[30] in Table 836: RDES3 normal descriptor (read format) ) bit only at some specific intervals of Receive descriptors. This way, whenever

a received packet transfer to system memory is complete and any of the descriptors used for that packet transfer has the IOC bit set, only then the RI event is generated.

In addition to above, an interrupt timer (ETH_DMACxRXIWTR: Channel i Rx Interrupt Watchdog Timer) is given for flexible control and periodic scheduling of Receive interrupt. When this interrupt timer is programmed with a nonzero value, it gets activated as soon as the Rx DMA completes a transfer of a received packet to system memory without asserting the Receive interrupt because the corresponding interrupt of completion IOC bit (RDES3[30] in Table 836: RDES3 normal descriptor (read format) ) is not set. When this timer runs out as per the programmed value, RI bit is set and the interrupt is asserted if the corresponding RIE is enabled in ETH_DMAC0IER register (see Channel x interrupt enable register (ETH_DMACxIER) ). The timer is stopped and cleared before it expires, if the RI is set for a packet transfer whose descriptor's IOC was set. The timer is reactivated automatically after the next packet transfer is complete without the RI event being generated.

Per channel transfer complete interrupt

The Transmit Transfer complete interrupt (TI) and Receive Transfer complete interrupt (RI) is reflected in the Channel Status register ( Channel x status register (ETH_DMACxSR) ). The TI bit is set whenever the Tx DMA channel closes the descriptor in which the IOC bit is set (Interrupt On Completion - TDES2[31]). Similarly, the RI bit is set whenever the Rx DMA channel closes the descriptor with the LD bit set and, in any of the descriptors used for transferring that packet, IOC bit is set (Interrupt Enable on completion - RDES3[30]).

The interrupt signal is asserted for the Transfer complete interrupts only when the corresponding interrupts are enabled in the channel interrupt enable register ( Channel x interrupt enable register (ETH_DMACxIER) ).

The behavior of the RI/TI interrupts changes depending on the settings of INTM field (bits[17:16]) in the ETH_DMAMR register ( DMA mode register (ETH_DMAMR) ). Table 820 explains the behavior of the Transfer Complete interrupt.

Table 820. Transfer complete interrupt behavior

76.8.2 MTL interrupts

MTL interrupt events are combined with the events in the DMA to generate the interrupt signal.

The register Interrupt status register (ETH_MTLISR) report the queue number responsible for the event. ETH_MTLQ0ICSR: Queue 0 Interrupt Control Status or ETH_MTLQ1ICSR: Queue 1 Interrupt Control Status must be read for event description.

The MTL interrupts are enabled by default. Each event can be prevented from asserting the interrupt by setting the corresponding mask bits in the Interrupt status register (ETH_MTLISR) register.

MTL interrupt signal is driven by one of these events on Queue 0 and Queue 1:

• • Receive Queue Overflow Interrupt
• • Transmit Queue Underflow

76.8.3 MAC interrupts

MAC interrupt events are combined with the events in the DMA to generate the interrupt signal.

The MAC interrupts are of level type, that is, the interrupt remains asserted (high) until it is cleared by the application or software.

The Interrupt status register (ETH_MACISR) describes the events that can cause an interrupt from the MAC. The MAC interrupts are enabled by default. Each event can be prevented from asserting the interrupt by setting the corresponding mask bits in the Interrupt status register (ETH_MACISR) .

The interrupt register bits only indicate the block from which the event is reported. You must read the corresponding status registers and other registers to clear the interrupt.

MAC interrupt signal is driven by one of these events:

• • Receive status interrupt
• • Transmit status interrupt
• • Timestamp interrupt status
• • MMC interrupt status
  • – MMC receive checksum offload interrupt status
  • – MMC transmit interrupt status
  • – MMC Receive interrupt status
• • LPI interrupt status
• • PMT interrupt status
• • PHY interrupt
• • RGMII interrupt status

Note: Two sidebands signals are generated together with LPI and PMT interrupts: lpi_intr_o and pmt_intr_o. They are used for wake-up event detection at EXTI level.

76.9 Ethernet programming model

This chapter provides the instructions for initializing the DMA or MAC registers in the proper sequence. It contains the following sections:

• • DMA initialization (see Section 76.9.1 )
• • MTL initialization (see Section 76.9.2 )
• • MAC initialization (see Section 76.9.3 )
• • Performing normal receive and transmit operation (see Section 76.9.4 )
• • Stopping and starting transmission (see Section 76.9.5 )
• • Programming guidelines for multichannel multiqueue operation (see Section 76.9.8 )
• • Programming guidelines for GMII link state transitions (see Section 76.9.9 )
• • Programming guidelines for IEEE 1588 timestamping (see Section 76.9.10 )
• • Programming guidelines for AV feature (see Section 76.9.12 )
• • Programming guidelines for energy-efficient Ethernet (see Section 76.9.13 )
• • Programming guidelines for flexible pulse-per-second (PPS) output (see Section 76.9.14 )
• • Programming guidelines for IEEE 1588 auxiliary snapshot (see Section 76.9.15 )
• • Programming guidelines for TSO (see Section 76.9.16 )
• • Programming guidelines for VLAN filtering on the receiver (see Section 76.9.17 )
• • Programming guidelines for extended VLAN filtering and routing on reception (see Section 76.9.18 )
• • Programming guidelines for queue/channel-based VLAN inclusion register (see Section 76.9.19 )
• • Programming guidelines for EST (see Section 76.9.20 )
• • Programming the launch time in time-based scheduling (see Section 76.9.21 )
• • Enabling the frame preemption function (see Section 76.9.22 )

76.9.1 DMA initialization

Complete the following steps to initialize the DMA:

1. 1. Provide a software reset to reset all MAC internal registers and logic (bit 0 of DMA mode register (ETH_DMAMR) ).
2. 2. Wait for the completion of the reset process (poll bit 0 of the DMA mode register (ETH_DMAMR) , which is cleared when the reset operation is completed).
3. 3. Program the following fields to initialize the System bus mode register (ETH_DMASBMR) :
   1. a) AAL, ONEKBBE, RD_OSR_LMT, and WR_OSR_LMT
   2. b) Fixed burst or undefined burst
   3. c) Outstanding requests limit value (OSR_LMT).
   4. d) If fixed length value is enabled, select the maximum burst length possible on the AXI Bus (bits [7:1])
4. 4. Create a transmit and a receive descriptor list. In addition, ensure that the receive descriptors are owned by the DMA (set bit 31 of TDES3/RDES3 descriptor). For more information on descriptors, refer to Section 76.10: Descriptors .

Note: Descriptor address from start to end of the ring should not cross the 4GB boundary.

1. 5. Program ETH_DMAC0TXRLR and ETH_DMAC0RXRLR registers (see Channel x Tx descriptor ring length register (ETH_DMACxTXRLR) and Channel x Rx descriptor ring length register (ETH_DMACxRXRLR) ). The programmed ring length must be at least 4.
2. 6. Initialize receive and transmit descriptor list address with the base address of transmit and receive descriptor ( Channel x Tx descriptor list address register (ETH_DMACxTXDLAR) , Channel x Rx descriptor list address register (ETH_DMACxRXDLAR) ). In addition, program the transmit and receive tail pointer registers that inform the DMA about the available descriptors (see Channel x Tx descriptor tail pointer register (ETH_DMACxTXDTPR) and Channel x Rx descriptor tail pointer register (ETH_DMACxRXDTPR) ).
3. 7. Program ETH_DMAC0CR, ETH_DMAC0TXCR and ETH_DMAC0RXCR registers (see Channel x control register (ETH_DMACxCR) , Channel x transmit control register (ETH_DMACxTXCR) and Channel x receive control register (ETH_DMACxRXCR) ) to configure the parameters such as the maximum burst-length (PBL) initiated by the DMA, descriptor skip lengths, OSP for TxDMA, RBSZ[13:0] for RxDMA, and so on.
4. 8. Enable the interrupts by programming the ETH_DMAC0IER register (see Channel x interrupt enable register (ETH_DMACxIER) ).
5. 9. Start the Receive and Transmit DMAs by setting SR (bit 0) of Channel x receive control register (ETH_DMACxRXCR) and ST (bit 0) of the ETH_DMAC0TXCR (see Channel x transmit control register (ETH_DMACxTXCR) ).
6. 10. Repeat steps 4 to 9 for all the Tx DMA channels selected in the hardware.

76.9.2 MTL initialization

Complete the following steps to initialize the MTL registers:

1. 1. Program the Tx Scheduling (SCHALG) and Receive Arbitration Algorithm (RAA) fields in Operating mode register (ETH_MTL0MR) to initialize the MTL operation when multiple Tx and Rx queues are used.
2. 2. Program the Receive Queue to DMA mapping in Rx queue and DMA channel mapping register (ETH_MTLRXQDMAMR) .
3. 3. Program the following fields to initialize the operating mode in Tx queue x operating mode register (ETH_MTLTXQxOMR) .
   1. a) Transmit Store And Forward (TSF) or Transmit Threshold Control (TTC) if the Threshold mode is used.
   2. b) Transmit Queue Enable (TXQEN) to value 2'b10 to enable Transmit Queue 0.
   3. c) Transmit Queue Size (TQS).
4. 4. Program the following fields to initialize the operating mode in the ETH_MTLRXQxOMR register (see Rx queue x operating mode register (ETH_MTLRXQxOMR) ):
   1. a) Receive Store and Forward (RSF) or RTC if Threshold mode is used.
   2. b) Flow Control Activation and De-activation thresholds for MTL Receive FIFO (RFA and RFD).
   3. c) Error Packet and undersized good Packet forwarding enable (FEP and FUP).
   4. d) Receive Queue Size (RQS).
5. 5. Repeat the previous two steps for all the MTL Tx and Rx queues selected in the configuration

76.9.3 MAC initialization

The MAC configuration registers establish the operating mode of the MAC. If possible, these registers must be initialized before initializing the DMA. The following MAC Initialization operations can also be performed after DMA initialization. If the MAC initialization is complete before the DMA is configured, enable the MAC receiver (last step in the following sequence) only after the DMA is active. Otherwise, received frames fill the Rx FIFO and overflow.

1. 1. Provide the MAC address registers: MAC address x low register (ETH_MACAxLR) , MAC address 0 high register (ETH_MACA0HR) and MAC address x high register (ETH_MACAxHR) .
2. 2. Program the following fields to set the appropriate filters for the incoming frames in the Packet filtering control register (ETH_MACPFR) :
   1. a) Receive All.
   2. b) Promiscuous mode.
   3. c) Hash or Perfect Filter.
   4. d) Unicast, multicast, broadcast, and control frames filter settings.
3. 3. Program the following fields for proper flow control in the Tx Queue 0 flow control register (ETH_MACQ0TXFCR) :
   1. a) Pause time and other Pause frame control bits.
   2. b) Transmit Flow control bits.
   3. c) Flow Control Busy.
4. 4. Program the Interrupt enable register (ETH_MACIER) as required, if it is applicable for your configuration.
5. 5. Program the appropriate fields in the Operating mode configuration register (ETH_MACCR) register. For example, Inter-packet gap while transmission and jabber disable.
6. 6. Set bit 0 and 1 in Operating mode configuration register (ETH_MACCR) register to start the MAC transmitter and receiver.

To support Jumbo Transmit/Receive packets, follow these steps:

• • In the Operating mode configuration register (ETH_MACCR)
  1. a) Set JE bit to 1.
  2. b) Set JD and WD bits to 0 to avoid giant packet error reporting.
  3. c) Set GPSLCE bit to 1
  4. d) Set GPSL bitfield of the Extended operating mode configuration register (ETH_MACECR) to a value > 9026

To support Transmit/Receive packets, up to 16K, follow these steps:

• • In the Operating mode configuration register (ETH_MACCR)
  1. a) Set JD and WD bits to 1 to avoid giant packet error reporting.
  2. b) Set GPSLCE bit to 1.
  3. c) Set GPSL bitfield of the Extended operating mode configuration register (ETH_MACECR) to 16383.

76.9.4 Performing normal receive and transmit operation

For normal operation, complete the following steps:

1. 1. For normal transmit and receive interrupts, read the interrupt status. Then, poll the descriptor by reading the status of the descriptor owned by the Host (either transmit or receive).
2. 2. Set the descriptors to appropriate values. Make sure that transmit and receive descriptors are owned by the DMA to resume the transmission and reception of data.
3. 3. If the descriptors are not owned by the DMA (or no descriptor is available), the DMA goes into Suspend state. The transmission or reception can be resumed by freeing the descriptors and writing the ETH_DMAG0TXDTPR (see Channel x Tx descriptor tail pointer register (ETH_DMAGxTXDTPR) ) and ETH_DMAG0RXDTPR (see Channel x Rx descriptor tail pointer register (ETH_DMAGxRXDTPR) ).
4. 4. In debug mode, the values of the current host transmitter or receiver descriptor address pointer can be read in ETH_DMAG0CATXDR and ETH_DMAG0CARXDR registers (see Channel x current application transmit descriptor register (ETH_DMAGxCATXDR) and Channel x current application receive descriptor register (ETH_DMAGxCARXDR) ).
5. 5. In debug mode, the values of the current host transmit buffer address pointer and receive buffer address pointer can be read in ETH_DMAG0CATXDR and ETH_DMAG0CARXDR registers (see Channel x current application transmit descriptor register (ETH_DMAGxCATXDR) and Channel x current application receive descriptor register (ETH_DMAGxCARXDR) ).

76.9.5 Stopping and starting transmission

Complete the following steps to pause the transmission for some time:

1. 1. Disable the Transmit DMA (if applicable) by clearing Bit 0 (ST) of ETH_DMAG0TXCR register (see Channel x transmit control register (ETH_DMAGxTXCR) ).
2. 2. Wait for any previous frame transmissions to complete. You can check this by reading the appropriate bits of Tx queue x debug register (ETH_MTLTXQxDR) (TRCSTS[1:0] is not 01 and TXQSTS = 0).
3. 3. Disable the MAC transmitter and MAC receiver by clearing RE and TE bits of the Operating mode configuration register (ETH_MACCR) Register.
4. 4. Disable the Receive DMA (if applicable), after making sure that the data in the Rx FIFO is transferred to the system memory (by reading the appropriate bits of Tx queue x debug register (ETH_MTLTXQxDR) , PRXQ=0 and RXQSTS[1:0] = 00).
5. 5. Make sure that both Tx queue and Rx queue are empty (TXQSTS is 0 in Tx queue x debug register (ETH_MTLTXQxDR) and RXQSTS[1:0] is set to 00).
6. 6. To restart the operation, first start the DMAs, and then enable the MAC transmitter and receiver.

Note: Do not change the configuration (such as duplex mode, speed, port, or loopback) when the MAC is actively transmitting or receiving. These parameters are changed by software only when the MAC transmitter and receiver are not active.

Similarly, do not change the DMA-related configuration when transmit and receive DMA are active.

76.9.6 Programming guidelines for switching to new descriptor list in RxDMA

Switching to a new descriptor list is different in the Rx DMA compared to the Tx DMA. Switching to a new descriptor list is permitted when the RxDMA is in Suspend state, as explained below:

• • Generally, RxDMA prepares the descriptors in advance.
• • If the RxDMA goes to Suspend state due to descriptors not being available, a major failure occurs (software is not able to free the filled-up descriptors/buffers). If this issue is not rectified immediately, frames are lost because of an RxFIFO overflow. Therefore, the software is allowed to create a new descriptor list and program the RxDMA to start using it immediately, without going into Stop state.

76.9.7 Programming guidelines for switching the AXI clock frequency

To dynamically change the AXI clock frequency (without applying soft reset or hard reset), follow these steps:

1. 1. Disable the Transmit DMA (if applicable) and wait for any previous frame transmissions to complete. When the frame transmissions is complete, the Tx FIFO becomes empty and the Tx DMA enters Stop state. The Tx FIFO status is given in the Tx queue x debug register (ETH_MTLTXQxDR) and the status of DMA is given in Debug status register (ETH_DMADSR) .
2. 2. Disable the MAC transmitter and the MAC receiver by clearing the appropriate bits in Operating mode configuration register (ETH_MACCR) .
3. 3. Disable the Receive DMA (if applicable) after making sure that the data in the Rx FIFO is transferred to the system memory. The Rx FIFO empty status is given in Rx queue x debug register (ETH_MTLRXQxDR) .
4. 4. Ensure that the application does not perform any register read or write operation.
5. 5. Change the frequency of the AXI clock.
6. 6. Enable the MAC transmitter or the MAC receiver and the Transmit or Receive DMA. These steps ensure that no valid data is present in the Tx FIFO or Rx FIFO at the time of clock frequency switching and prevent any data corruption.

76.9.8 Programming guidelines for multichannel multiqueue operation

Transmit path

1. 1. Program the Transmit queue size in the TQS field in ETH_MTLTXQxOMR register. The size of the queue is determined by the value programmed in the TQS field.

During the Transmit operation, the number of channels is equal to the number of the queues. As a result, the channel to queue mapping is fixed.

1. 2. To use a queue, the queue must be enabled by setting the TXQEN bit in the corresponding ETH_MTLTXQxOMR register. The ST bit in Channel x transmit control register (ETH_DMACxTXCR) and the corresponding TXQEN bit in ETH_MTLTXQxOMR register must be enabled.
2. 3. Program the scheduling method in SCHALG bit of ETH_MTLOMR register.
3. 4. If CBS algorithm is enabled on AV queue 1, ETH_MTLTXQ1ECR, ETH_MTLTXQ1SSCR, ETH_MTLTXQ1HCR and ETH_MTLTXQ1LCR registers also need to be programmed as required.

Receive path

1. 1. Program the Receive queue size in the RQS field in ETH_MTLRXQxOMR register. The size of the queue is determined by the value programmed in the RQS field.
2. 2. Enable the Receive queues 0 to 1 in the RXQ0EN to RXQ1EN fields of ETH_MACRXQ0CR register for AV.
   Enable SR bit of statically or dynamically mapped Channel x receive control register (ETH_DMACxRXCR) and corresponding RXQiEN in Rx queue control 0 register (ETH_MACRXQC0R) .
3. 3. The MAC routes the Rx packets to the Rx queues depending on following packet types:
   1. a) AV PTP packets are routed according to the value of PTPQ in ETH_MACRXQC1R register
   2. b) AV untagged control packets are routed according to the value of AVCPQ in ETH_MACRXQC1R register.
   3. c) VLAN tag priority field in VLAN tagged packets
      Program PSRQ1 and PSRQ0 of the ETH_MACRXQC2R register to configure the routing of tagged packets based on the USP (user priority) field of the received packets to the Rx queues 0 to 1.
   4. d) The AV tagged control and data packets are also routed according to PSRQ field of the ETH_MACRXQC2R register.

Note: The priorities set in PSRQ0 and PSRQ1 must be unique.

1. 4. If multiple RX DMA channels are enabled, the following programming should be done for proper arbitration and mapping:
   1. a) Program the RAA field of Operating mode register (ETH_MTLOMR) to select the arbitration algorithm to decide which Rx queue is read out from the RxFIFO memory.
   2. b) Program the Rx queue x control register (ETH_MTLRXQxCR) to decide the weights and the packet arbitration for each Rx queue.
   3. c) If static mapping is programmed in Rx queue and Rx queue and DMA channel mapping register (ETH_MTLRXQDMAMR) (QiDDMACH is reset to 0), bits QiMDMACH need to be programmed to select the channel for which each queue is mapped.
   4. d) Set RXQiDDMACH bit in Rx queue and Rx queue and DMA channel mapping register (ETH_MTLRXQDMAMR) to select dynamic mapping of packets in each Rx queue.
   5. e) In dynamic channel mapping, the routing of a packet to a specific RxDMA channel is decided by the value of DCS field in the lowest MAC address register.

Programming guidelines for recovering from DMA channel failure

When the DMA channel issues a bus error, follow the steps described below to recover from the failure.

Recovering from the receive DMA channel failure

Follow these steps if a bus error occurred in the Receive DMA channel:

1. 1. Set the RPF bit to 1. This flushes all the packets one after the other. This step is optional. However, setting this bit prevents HOL (head-of-line) blocking in the Rx queues when packets sent to the RXDMA are stopped due to bus error.
2. 2. Reprogram the specific registers of the DMA channel.
3. 3. Start the DMA channel.

Recovering from the transmit DMA channel failure

1. 1. Stop the specific DMA channel, even if it is in active state.
2. 2. Flush the corresponding MTL queue.
3. 3. Reprogram the specific registers of the DMA channel.
4. 4. Start the DMA channel.

Note: Due to the known limitations, reprogramming the DMA channel registers might not always be successful to recover from a bus error. If the peripheral is not fully functional after reprogramming the DMA, as a workaround, issue a soft reset to recover from the bus error.

Programming guidelines for disabling receive queue

Follow these steps to disable specific receive queue:

1. 1. Disable the receiver by setting the RE bit of the Operating mode configuration register (ETH_MACCR) to 0.
2. 2. Read the Debug register (ETH_MACDR) (ensure that RPESTS and RFCFCSTS fields are 0) and Rx queue x debug register (ETH_MTLRXQxDR) of all the Rx queues.
3. 3. When all Rx queue x debug register (ETH_MTLRXQxDR) are read as 0, disable the intended Rx queue by programming the corresponding fields in the Rx queue control 0 register (ETH_MACRXQC0R) .
4. 4. Enable the receiver by setting the RE bit of Operating mode configuration register (ETH_MACCR) to 1.

76.9.9 Programming guidelines for GMII link state transitions

Transmit and receive clocks are running when the link is down

Complete the following steps when the link is down while the transmit and receive clocks are running:

1. 1. Disable the Transmit DMA (if applicable) by clearing bit 0 (ST) of Channel x control register (ETH_DMAxCxCR) .
2. 2. Disable the MAC receiver by clearing RE bit of Operating mode configuration register (ETH_MACCR) .
3. 3. Wait for any previous frame transmissions to complete. You can check this by reading the appropriate bits of Tx queue x debug register (ETH_MTLTXQxDR) (TRCSTS[1:0] is not 01).

or

Flush the Tx FIFO for faster empty operation.

1. 4. Disable the MAC transmitter by clearing TE bit of the Operating mode configuration register (ETH_MACCR) Register.
2. 5. Make sure that both Tx and Rx queues are empty (TXQSTS is set to 0 in Tx queue x debug register (ETH_MTLTXQxDR) and RXQSTS[1:0] to 00 in Rx queue x debug register (ETH_MTLRXQxDR) ).
3. 6. After the link is up, read the PHY registers to identify the latest configuration and program the MAC registers accordingly.
4. 7. Restart the operation by starting the Tx DMA. Then enable the MAC transmitter and receiver.

The Rx DMA does not need to be enabled: since the receiver is disabled, there are no data in the Rx FIFO.

Transmit and receive clocks are stopped when the link is down

Complete the following steps when the link is down and the transmit and receive clocks are stopped:

1. 1. Disable the MAC transmitter and receiver by clearing RE and TE bits in the Operating mode configuration register (ETH_MACCR) . This does not take immediate effect as the clocks are absent.
2. 2. Wait till the link is up and the clocks are restored.
3. 3. Wait until the transfer of any partial frame is complete if any was ongoing when the Transmit/Receive clock is stopped. This can be checked by reading the Debug register (ETH_MACDR) (all bits should be set to 0). Some old packets may still remain in the TXFIFO as the MAC transmitter is stopped.
4. 4. Read the PHY registers to identify the latest operating mode and program the MAC registers accordingly.
5. 5. Restart the MAC transmitter and receiver by setting RE and TE bits.

76.9.10 Programming guidelines for IEEE 1588 timestamping

Initializing the System time generation

The timestamp feature can be enabled by setting bit 0 of the Timestamp control register (ETH_MACTSCR) . However, it is essential that the timestamp counter is initialized after this bit is set. Complete the following steps to perform the peripheral initialization:

1. 1. Mask the Timestamp Trigger interrupt by clearing bit 12 of Interrupt enable register (ETH_MACIER) .
2. 2. Set bit 0 of Timestamp control register (ETH_MACTSCR) to enable timestamping.
3. 3. Program Subsecond increment register (ETH_MACSSIR) based on the PTP clock frequency.
4. 4. If you use the Fine Correction method, program Timestamp addend register (ETH_MACTSAR) and set bit 5 of Timestamp control register (ETH_MACTSCR) .
5. 5. Poll the Timestamp control register (ETH_MACTSCR) until bit 5 is cleared.
6. 6. Program bit 1 of Timestamp control register (ETH_MACTSCR) to select the Fine Update method (if required).
7. 7. Program System time seconds update register (ETH_MACSTSUR) and System time nanoseconds update register (ETH_MACSTNUR) with the appropriate time value.
8. 8. Set bit 2 in Timestamp control register (ETH_MACTSCR) .

The timestamp counter starts as soon as it is initialized with the value written in the timestamp update registers. If one-step timestamping is required:

1. 1. a) Enable one-step timestamping by programming bit 27 of the TDES3 Context Descriptor.
   2. b) Program Timestamp ingress asymmetric correction register (ETH_MACTSIACR) to update the correction field in PDelay_Req PTP messages.
2. 1. 9. Enable the MAC receiver and transmitter for proper timestamping.

Note: If timestamp operation is disabled by clearing bit 0 of Timestamp control register (ETH_MACTSCR), repeat all these steps to restart the timestamp operation.

System time correction

To synchronize or update the system time in one shot (coarse correction method), complete the following steps:

1. 1. Set the offset (positive or negative) in the timestamp update registers ( System time seconds update register (ETH_MACSTSUR) and System time nanoseconds update register (ETH_MACSTNUR) ).
2. 2. Set bit 3 (TSUPDT) of the Timestamp control register (ETH_MACTSCR) .

The value in the timestamp update registers is added to or subtracted from the system time when the TSUPDT bit is cleared.

To synchronize or update the system time to reduce system-time jitter (fine correction method), complete the following steps:

1. 1. With the help of the algorithm described in Section : System time register module , calculate at which rate you intend to increment or decrement the system time.
2. 2. Update the Timestamp addend register (ETH_MACTSAR) with the new value and set bit 5 of the Timestamp control register (ETH_MACTSCR) Register.
3. 3. Wait for the time during which you want the new value of the Addend register to be active. This can be done by enabling the Timestamp Trigger interrupt after the system time reaches the target value.
4. 4. Program the required target time in PPS x target time seconds register (ETH_MACPPSTTSxR) and PPS x target time nanoseconds register (ETH_MACPPSTTNxR) .
5. 5. Enable the Timestamp interrupt in bit 12 of Interrupt enable register (ETH_MACIER) .
6. 6. Set bit 3 in Register Timestamp control register (ETH_MACTSCR) .
7. 7. When this trigger generates an interrupt, read Interrupt status register (ETH_MACISR) .
8. 8. Reprogram Timestamp addend register (ETH_MACTSAR) with the old value and set bit 5 again.

76.9.11 Programming guidelines for PTP offload feature

Programming guidelines to enable automatic periodic generation of PTP sync messages

Follow these steps to enable automatic periodic generation of PTP sync messages:

1. 1. Program SNAPTYPSEL, TSMSTRENA, and TSEVNTENA fields of Timestamp control register (ETH_MACTSCR) to 0, 1, and 1 respectively, to configure the node as Ordinary or Boundary Master (1, 1, and 1 for Transparent Master).
2. 2. Program the PTOEN bit and DN field of PTP offload control register (ETH_MACPOCR) to enable PTP Offload feature and domain number to send in egress PTP Sync message.
3. 3. Program the ASYNCEN bit of PTP offload control register (ETH_MACPOCR) to enable periodic generation of PTP Sync messages.
4. 4. Program the 80-bit Source Port Identity in PTP source port identity 0 register (ETH_MACSPI0R) , PTP Source port identity 1 register (ETH_MACSPI1R) and PTP Source port identity 2 register (ETH_MACSPI2R) to send in egress PTP Sync message.
5. 5. Program the LSI field of Log message interval register (ETH_MACLMIR) to program the periodicity of the PTP Sync messages.

For example, a value of 1 corresponds to \( 2^1 \) which translates to PTP Sync message every 2 seconds, and a value of 0xFF (twos complement of -1) corresponds to \( 2^{-1} \) which translates to PTP Sync message every 0.536 seconds.

1. 6. Program the TSIE bit of Interrupt enable register (ETH_MACIER) to enable generation of Timestamp interrupt.
2. 7. Wait for sbd_intr_o interrupt generated by setting TXTSSIS bit in Timestamp status register (ETH_MACTSSR) . It indicates that the timestamp for PTP Sync message is captured in Tx timestamp status seconds register (ETH_MACTXTSSSR) and Tx timestamp status nanoseconds register (ETH_MACTXTSSNR) .

Programming guidelines to enable periodic generation of PTP Pdelay_Req messages

Follow these steps to enable automatic periodic generation of PTP Pdelay_Req messages

1. 1. Program SNAPTYPESEL, TSMSTRENA and TSEVNTENA fields of Timestamp control register (ETH_MACTSCR) to 1, 0, and 1 respectively to configure the node as Transparent Slave (1, 1, and 1 for Transparent Master OR 3, X, and X for Peer-to-Peer Transparent).
2. 2. Program the PTOEN bit and DN field of PTP offload control register (ETH_MACPOCR) to enable PTP Offload feature and domain number to send in egress PTP Pdelay_Req message.
3. 3. Program the APDREQEN bit of PTP offload control register (ETH_MACPOCR) to enable periodic generation of PTP Pdelay_Req messages.
4. 4. Program the 80-bit Source Port Identity in PTP source port identity 0 register (ETH_MACSPI0R) , PTP Source port identity 1 register (ETH_MACSPI1R) and PTP Source port identity 2 register (ETH_MACSPI2R) to send in egress PTP Pdelay_Req message.
5. 5. Program the LMPDRI field of Log message interval register (ETH_MACLMIR) to program the periodicity of the PTP Pdelay_Req messages.
   For example, a value of 1 corresponds to \( 2^1 \) which translates to PTP Pdelay_Req message every 2 seconds, and a value of 0xFF (twos complement of -1) corresponds to \( 2^{-1} \) which translates to PTP Pdelay_Req message every 0.536 seconds.
6. 6. Program the TSIE bit of Interrupt enable register (ETH_MACIER) to enable generation of Timestamp interrupt.
7. 7. Wait for sbd_intr_o interrupt generated by setting TXTSSIS bit in Timestamp status register (ETH_MACTSSR) . It indicates that the timestamp for PTP Sync message is captured in Tx timestamp status seconds register (ETH_MACTXTSSSR) and Tx timestamp status nanoseconds register (ETH_MACTXTSSNR) .

Programming guidelines to enable the generation of PTP response messages for Ordinary or Boundary Master mode

Follow these steps to enable the generation of PTP response messages for Ordinary or Boundary Master mode (Periodic PTP Sync messages generated and PTP Delay_Resp message generated in response to PTP Delay_Req message):

1. 1. Program SNAPTYPESEL, TSMSTRENA and TSEVNTENA fields of Timestamp control register (ETH_MACTSCR) to 0, 1, and 1 respectively.
2. 2. Program the PTOEN bit and DN field of PTP offload control register (ETH_MACPOCR) to enable PTP Offload feature and domain number to match with ingress PTP Delay_Req message and send in egress PTP Delay_Resp message.
3. 3. Program the 80-bit Source Port Identity in PTP source port identity 0 register (ETH_MACSPI0R) , PTP Source port identity 1 register (ETH_MACSPI1R) and PTP Source port identity 2 register (ETH_MACSPI2R) to match with ingress PTP Delay_Req message and send in egress PTP Delay_Resp message.
4. 4. Program the DRSYNCR and LSI fields in Log message interval register (ETH_MACLMIR) . The sum of both fields is updated in logMinDelayReqInterval field of PTP Delay_Resp message.

Programming guidelines to enable the generation of PTP response messages for Ordinary or Boundary Slave mode

Follow these steps to enable generation of PTP response messages for Ordinary or Boundary Slave mode (PTP Delay_Req message generated in response to PTP Sync message):

1. 1. Program SNAWTYPSEL, TSMSTRENA and TSEVNTENA fields of Timestamp control register (ETH_MACTSCR) to 0, 0, and 1 respectively.
2. 2. Program the PTOEN bit and DN field of PTP offload control register (ETH_MACPOCR) to enable PTP Offload feature and domain Number to match with ingress PTP Sync message and send in egress PTP Delay_Req message.
3. 3. Program the 80-bit Source Port Identity in PTP source port identity 0 register (ETH_MACSPI0R) , PTP Source port identity 1 register (ETH_MACSPI1R) and PTP Source port identity 2 register (ETH_MACSPI2R) to match with ingress PTP Sync message and send in egress PTP Delay_Req message.
4. 4. Program the DRSYNCR field in Log message interval register (ETH_MACLMIR) to indicate one PTP Delay_Req message is generated in response to how many received PTP Sync messages.

Programming guidelines to enable the generation of PTP response messages for Transparent Slave mode

Follow these steps to enable generation of PTP response messages for Transparent Slave mode (PTP Delay_Req message generated in response to PTP Sync message, PTP Pdelay_Resp message generated in response to PTP Pdelay_Req message and Periodic PTP Pdelay_Req messages generated)

1. 1. Program SNAWTYPSEL, TSMSTRENA and TSEVNTENA fields of Timestamp control register (ETH_MACTSCR) to 1, 0, and 1 respectively.
2. 2. Program the PTOEN bit and DN field of PTP offload control register (ETH_MACPOCR) to enable PTP Offload feature and domain Number to match with ingress PTP Sync or Pdelay_Req message and send in egress PTP Delay_Req or Pdelay_Resp or Pdelay_Req message.
3. 3. Program the 80-bit Source Port Identity in PTP source port identity 0 register (ETH_MACSPI0R) , PTP Source port identity 1 register (ETH_MACSPI1R) and PTP Source port identity 2 register (ETH_MACSPI2R) to match with ingress PTP Sync or Pdelay_Req message and send in egress PTP Delay_Req or Pdelay_Resp or Pdelay_Req message.
4. 4. Program the DRSYNCR and LMPDRI fields in Log message interval register (ETH_MACLMIR) to indicate one PTP Delay_Req message is generated in response to how many received PTP Sync messages and periodicity of the PTP Pdelay_Req messages.
5. 5. Program the TSIE bit of Interrupt enable register (ETH_MACIER) to enable generation of Timestamp interrupt.
6. 6. Wait for sbd_intr_o interrupt generated by setting TXTSSIS bit in Timestamp status register (ETH_MACTSSR) . It indicates that the timestamp for PTP Sync message is captured in Tx timestamp status seconds register (ETH_MACTXTSSSR) and Tx timestamp status nanoseconds register (ETH_MACTXTSSNR) for egress PTP Pdelay_Req and Pdelay_Resp messages.

Programming guidelines to enable the generation of PTP response messages for Transparent Master mode

Follow these steps to enable generation of PTP response messages for Transparent Master mode (PTP Delay_Resp message generated in response to PTP Delay_Req message, PTP Pdelay_Resp message generated in response to PTP Pdelay_Req message and Periodic PTP Pdelay_Req or Sync messages generated):

1. 1. Program SNAPTYPSEL, TSMSTRENA and TSEVNTENA fields of Timestamp control register (ETH_MACTSCR) to 1, 1, and 1 respectively.
2. 2. Program the PTOEN bit and DN field of PTP offload control register (ETH_MACPOCR) to enable PTP Offload feature and domain number to match with ingress PTP Delay_Req or Pdelay_Req message and send in egress PTP Delay_Resp or Pdelay_Resp or Pdelay_Req or Sync message.
3. 3. Program the 80-bit Source Port Identity in PTP source port identity 0 register (ETH_MACSPI0R) , PTP Source port identity 1 register (ETH_MACSPI1R) and PTP Source port identity 2 register (ETH_MACSPI2R) to match with ingress PTP Delay_Req or Pdelay_Req message and send in egress PTP Delay_Resp or Pdelay_Resp or Pdelay_Req or Sync message.
4. 4. Program the DRSYNCR, LSI and LMPDRI fields in Log message interval register (ETH_MACLMIR) , the sum of DRSYNCR and LSI is updated in logMinDelayReqInterval field of PTP Delay_Resp message and periodicity of the PTP Sync or Pdelay_Req messages.
5. 5. Program the TSIE bit of Interrupt enable register (ETH_MACIER) to enable generation of Timestamp interrupt.
6. 6. Wait for sbd_intr_o interrupt generated by setting TXTSSIS bit in Timestamp status register (ETH_MACTSSR) . It indicates that the timestamp for PTP Sync message is captured in Tx timestamp status seconds register (ETH_MACTXTSSSR) and Tx timestamp status nanoseconds register (ETH_MACTXTSSNR) for egress PTP Sync, Pdelay_Req and Pdelay_Resp messages.

Programming guidelines to enable the generation of PTP response messages for Peer-to-Peer Transparent mode

Follow these steps to enable generation of PTP response messages for Peer-to-Peer Transparent mode (PTP Pdelay_Resp message generated in response to PTP Pdelay_Req message and Periodic PTP Pdelay_Req messages generated):

1. 1. Program the SNAPTYPSEL, TSMSTRENA and TSEVNTENA fields of Timestamp control register (ETH_MACTSCR) to 3, X, and X respectively.
2. 2. Program the PTOEN bit and DN field of PTP offload control register (ETH_MACPOCR) to enable PTP Offload feature and domain Number to match with ingress PTP Pdelay_Req message and send in egress PTP Pdelay_Resp message.
3. 3. Program the 80-bit Source Port Identity in PTP source port identity 0 register (ETH_MACSPI0R) , PTP Source port identity 1 register (ETH_MACSPI1R) and PTP Source port identity 2 register (ETH_MACSPI2R) to match with ingress PTP Pdelay_Req message and send in egress PTP Pdelay_Resp message.
4. 4. Program the LMPDRI field in Log message interval register (ETH_MACLMIR) to indicate periodicity of the PTP Pdelay_Req messages

1. 5. Program the TSIE bit of Interrupt enable register (ETH_MACIER) to enable generation of Timestamp interrupt
2. 6. Wait for sbd_intr_o interrupt generated by setting TXTSSIS bit in Timestamp status register (ETH_MACTSSR) . It indicates that the timestamp for PTP Sync message is captured in Tx timestamp status seconds register (ETH_MACTXTSSSR) and Tx timestamp status nanoseconds register (ETH_MACTXTSSNR) for egress PTP Pdelay_Req and Pdelay_Resp messages.

76.9.12 Programming guidelines for AV feature

Initializing the DMA

Complete the following steps to initialize the DMA:

1. 1. Provide a software reset to reset all registers and logic (bit 0 in ETH_DMAMR).
2. 2. Wait for the completion of the reset process. Poll bit 0 of the ETH_DMAMR, which is cleared only when the reset operation is completed.
3. 3. Program the fields to initialize the DMA register by setting the values in ETH_DMAMR register.
4. 4. Create a proper descriptor list for transmit and receive. In addition, ensure that the DMA owns the transmit and receive descriptors. When OSF mode is used, at least two TX descriptors are required. For more information about descriptors, refer to Section 76.10: Descriptors .
5. 5. Make sure that your software creates three or more different transmit or receive descriptors in the list before reusing any of the descriptors.
6. 6. Program the transmit and receive Ring length registers ( Channel x Tx descriptor ring length register (ETH_DMACxTXRLR) and Channel x Rx descriptor ring length register (ETH_DMACxRXRLR) ). The ring length programmed must be at least 4.
7. 7. Initialize the receive and transmit descriptor list address with the base address of the transmit and receive descriptor ( Channel x Tx descriptor list address register (ETH_DMACxTXDLAR) , Channel x Rx descriptor list address register (ETH_DMACxRXDLAR) ). In addition, program the transmit and receive tail pointer registers indicating the available descriptors to the DMA ( Channel x Tx descriptor tail pointer register (ETH_DMACxTXDTPR) and Channel x Rx descriptor tail pointer register (ETH_DMACxRXDTPR) ).
8. 8. Program the following fields to initialize the operating mode in the ETH_MTLTXQOMR:
   1. a) Transmit Store And Forward (TSF)
   2. b) Transmit Threshold Control (TTC)
   3. c) Transmit Queue Enable (TXQEN) to value 10 to enable Transmit Queue0
   4. d) Transmit Queue Size (TQS)
9. 9. Enable the interrupts by programming the EH_DMAC0IER.
10. 10. Repeat steps 4 to 9 for all the Tx DMA and RX DMA channels.
11. 11. Program the CBS control register, idleSlope, sendSlope, hiCredit, and loCredit registers of the AV queues.
12. 12. Start the Receive and Transmit DMA by setting bit 0 of the ETH_DMAC0TXCR and bit 0 of the ETH_DMAC0RXCR (see Channel x transmit control register (ETH_DMACxTXCR) and Channel x receive control register (ETH_DMACxRXCR) ).

Enabling slot number checking

You can use the slot number check feature to specify the intervals at which the DMA Channels mapped to AV queues fetches the frames from the AHB/AXI system bus. This feature is useful to ensure a uniform and periodic transfer of the AV traffic from the host memory. It is available only when timestamping is enabled and the Subsecond increment register (ETH_MACSSIR) is programmed. Complete the following steps to enable the slot number checking:

1. Note: The slot number checking steps should be complete after programming the CBS control register, idleSlope, sendSlope, hiCredit, and loCredit registers of the AV queues (step 11 of Section : Initializing the DMA ). and before starting the Receive and Transmit DMA (step 12).
2. 1. 1. Enable timestamping by following the steps described in Section : Initializing the System time generation .
   2. 2. Make sure that the SLOTNUM field (bits 22 to 19) of TDES3 Normal Descriptor (Read Format) contains a valid slot number. To do this, read the current reference slot number from the Channel x slot function control status register (ETH_DMACxSFCSR) .
   3. 3. Set bit 0 (ESC) of Channel x slot function control status register (ETH_DMACxSFCSR) to enable the slot number checking.

Enabling average bits per slot reporting

The CBS Status register of the additional AV channels provides information about the average bits that are transmitted in a slot. The software can asynchronously read this register to retrieve information about the average bits transmitted per slot. Complete the following steps to enable average bits per slot reporting:

1. 1. Enable timestamping by following the steps described in Section : Initializing the System time generation .
2. 2. Program SLC bits of the Tx queue 1 ETS control register (ETH_MTLTXQ1ECR) of a channel with number of slots over which the average transmitted bits per slot need to be computed.
3. 3. Enable ABPSIE of the Queue x interrupt control status register (ETH_MTLQxICSR) of a channel to generate the average bits per slot interrupt.

Note: The frequency of this interrupt depends on the value programmed during previous step. For example, when you program value 0 in the SLC field, the interrupt is generated at every 125 microsecond.

When it is not required, you can disable this interrupt to stop the interrupt flooding.

1. 4. Read ABS bits from Tx queue x ETS status register (ETH_MTLTXQxESR) of a channel on each interrupt.

The software can read the ABS bits in polling mode even if the ABPSIE bit is not enabled. When high, bit 1 (ABPSIS) of Queue x interrupt control status register (ETH_MTLQxICSR) indicates that a new value is updated in the ABS field.

Disabling flow control for AV-enabled queues

Transmit flow

Program the EHFC (Enable Hardware Flow Control) bit of corresponding Rx queue x operating mode register (ETH_MTLRXQxOMR) to 0.

76.9.13 Programming guidelines for Energy Efficient Ethernet (EEE)

Entering and exiting Tx LPI mode

EEE enables the IEEE 802.3 Media Access Control (MAC) sublayer along with a family of physical layers to operate in the Low-power idle (LPI) mode. In the Transmit path, the software must set the LPIEN bit of the LPI control and status register (ETH_MACLCSR) to indicate to the MAC to stop transmission and initiate the LPI protocol.

Complete the following steps during MAC initialization:

1. 1. Read the PHY register through the MDIO interface and check if the remote end has the EEE capability. Then negotiate the timer values.
2. 2. Program the PHY registers through the MDIO interface (including the RX_CLK_stoppable bit that indicates to the PHY whether to stop Rx clock in LPI mode or not).
3. 3. Program bits 25 to 16 and bits 15 to 0 in LPI timers control register (ETH_MACLTCR) .
4. 4. Read the PHY link status by using the MDIO interface and update bit 17 of LPI control and status register (ETH_MACLCSR) .

Update LPI control and status register (ETH_MACLCSR) accordingly. This update should be done whenever the link status in the PHY chip changes.

1. 5. Program One-microsecond-tick counter register (ETH_MAC1USTCR) as per the frequency of the clock used for accessing the CSR slave port.
2. 6. Program the LPIET bit in the LPI entry timer register (ETH_MACLETR) with the IDLE time for which the MAC should wait before entering the LPI state on its own.
3. 7. Set LPITE and LPITXA (bits 20 to 19) of LPI control and status register (ETH_MACLCSR) to enable LPI auto-entry and MAC auto-exit from LPI state.
4. 8. Set bit 16 of LPI control and status register (ETH_MACLCSR) to put the MAC transmitter in LPI state.

The MAC enters the LPI state when all scheduled packets are completed. It remains IDLE for the time indicated by LPIET bits. It sets the TLPIEN (bit 0) after entering LPI state.

1. 9. When a packet transmission is scheduled (when the TxDMA exits IDLE state or when a packet is presented at ATI or MTI interface), the MAC transmitter automatically exits LPI state. It waits for TWT time before setting the TLPIEX interrupt status bit and then resume the packet transmission.
2. 10. The MAC transmitter enters again LPI state if it remains IDLE for LPIET time. It then sets the TLPIEN bit and the entry-exit cycle continues.
3. 11. Reset LPIEN bit if the application needs to override the auto-entry/exit modes and directly exit the MAC transmitter from LPI state.

Note: To make sure the MAC enters the LPI state only after the transmission of all the queued frames in the Tx FIFO is complete, set LPITXA bit in LPI control and status register (ETH_MACLCSR) .

To switch off the GMII Transmit clock during the LPI state, use the sbd_tx_clk_gating_ctrl_o signal to gate the clock input.

To switch off the CSR clock or power to the rest of the system during the LPI state, wait for the TLPIEN interrupt of LPI control and status register (ETH_MACLCSR) to be generated. Restore the clocks before performing step 6 when you want to come out of the LPI state.

Gating Off the CSR Clock in the LPI mode

You can gate off the CSR clock to save the power when the MAC is in the Low-Power Idle (LPI) mode.

Gating off the CSR clock in the Rx LPI mode

The following operations are performed when the MAC receives the LPI pattern from the PHY:

1. 1. The MAC RX enters the LPI mode and the Rx LPI entry interrupt status (RLPIEN interrupt of LPI control and status register (ETH_MACLCSR) ) is set.
2. 2. The interrupt pin (sbd_intr_o) is asserted. The sbd_intr_o interrupt is cleared when the host reads the LPI control and status register (ETH_MACLCSR) .

After the sbd_intr_o interrupt is asserted and the MAC Tx is also in the LPI mode, the CSR clock can be gated off. If the MAC TX is not in LPI mode when the CSR clock is gated off, the events on the MAC transmitter do not get reported or updated in the CSR. To restore the CSR clock, wait for the LPI exit indication from the PHY after which the MAC asserts the LPI exit interrupt on lpi_intr_o (synchronous to clk_rx_i). The lpi_intr_o interrupt is cleared when LPI control and status register (ETH_MACLCSR) is read.

Gating off the CSR clock in the Tx LPI mode

The following operations are performed when bit 16 (LPIEN) of LPI control and status register (ETH_MACLCSR) is set:

1. 1. The Transmit LPI Entry interrupt (TLPIEN bit of LPI control and status register (ETH_MACLCSR) ) is set.
2. 2. The interrupt pin (sbd_intr_o) is asserted. The sbd_intr_o interrupt is cleared when the host reads the LPI control and status register (ETH_MACLCSR) .

After the sbd_intr_o interrupt is asserted and the MAC RX is also in the LPI mode, the CSR clock can be gated off. If the MAC RX is not in LPI mode when the CSR clock is gated off, the events on the MAC receiver do not get reported or updated in the CSR. To restore the CSR clock, switch on the CSR clock when the MAC has exited TX LPI mode. After the CSR clock is resumed, reset bit 16 (LPIEN) of LPI control and status register (ETH_MACLCSR) to exit the MAC from LPI mode.

76.9.14 Programming guidelines for flexible pulse-per-second (PPS) output

Generating a single pulse on PPS

To generate a single pulse on PPS:

1. 1. Program TRGTMODSEL[1:0] bit to 11 or 10 (for interrupt) in PPS control register (ETH_MACPPSCR) . This instructs the MAC to use the Target Time registers ( PPS x target time seconds register (ETH_MACPPSTTSxR) and PPS x target time nanoseconds register (ETH_MACPPSTTNxR) ) as start time of PPS signal output.
2. 2. Program the start time value in the target time registers (register PPS x target time seconds register (ETH_MACPPSTTSxR) and PPS x target time nanoseconds register (ETH_MACPPSTTNxR) ).
3. 3. Program the width of the PPS signal output in PPS x width register (ETH_MACPPSWxR) Register.
4. 4. Program PPSCMD[3:0] of PPS control register (ETH_MACPPSCR) to 0001. This instructs the MAC to generate a single pulse on the PPS signal output at the time programmed in the Target Time registers.

Generating next pulse on PPS

When the PPSCMD is executed (PPSCMD bits = 0), you can cancel the pulse generation by giving the Cancel Start Command (PPSCMD=0011) before the programmed start time has elapsed. You can also program the behavior of the next pulse in advance. To program the next pulse:

1. 1. Program the start time for the next pulse in the Target Time registers. This time should be higher than the time at which the falling edge occurs for the previous pulse.
2. 2. Program the width of the next PPS signal output in PPS x width register (ETH_MACPPSWxR) .
3. 3. Program PPSCMD[3:0] bits of PPS control register (ETH_MACPPSCR) to generate a single pulse after the previous pulse is deasserted. This instructs the MAC to generate a single pulse on the PPS signal output at the time programmed in Target Time registers.

If this command is given before the previous pulse becomes low, then the new command overwrites the previous command and the peripheral may generate only 1 extended pulse.

Generating a pulse train on PPS

To generate a pulse train on PPS:

1. 1. Program TRGTMODSEL[1:0] bits to 11 or 10 (for interrupt) in PPS control register (ETH_MACPPSCR) . This instructs the MAC to use the Target Time registers ( PPS x target time seconds register (ETH_MACPPSTTSxR) and PPS x target time nanoseconds register (ETH_MACPPSTTNxR) ) for start time of the PPS signal output.
2. 2. Program the start time value in the Target Time registers (register PPS x target time seconds register (ETH_MACPPSTTSxR) and PPS x target time nanoseconds register (ETH_MACPPSTTNxR) ).
3. 3. Program the interval value between the train of pulses on the PPS signal output in PPS x interval register (ETH_MACPPSIxR) .
4. 4. Program the width of the PPS signal output in PPS x width register (ETH_MACPPSWxR) .
5. 5. Program PPSCMD[3:0] bits in PPS control register (ETH_MACPPSCR) to 0010. This instructs the MAC to generate a train of pulses on the PPS signal output at the start time programmed in Target Time registers.

By default, the PPS pulse train is free-running unless it is stopped by issuing a 'STOP Pulse train at time' or 'STOP Pulse Train immediately' commands.

1. 6. Program the stop value in the Target Time registers. Ensure that TSTRBUSY bit in PPS x target time nanoseconds register (ETH_MACPPSTTNxR) is reset before programming the Target Time registers again.
2. 7. Program the PPSCMD[3:0] bits in PPS control register (ETH_MACPPSCR) to 0100 to stop the train of pulses on PPS signal output after the programmed stop time specified at step 6 has elapsed.

The pulse train can be stopped at any time by programming 0101 in the PPSCMD[3:0] field.

Similarly, the Stop Pulse train command (given in Step 7) can be canceled by programming PPSCMD[3:0] bits to 0110 before the time (programmed at step 6) has elapsed.

The pulse train generation can be stopped by programming PPSCMD[3:0] to 0011 before the start time programmed at step 2) has elapsed.

Generating an interrupt without affecting the PPS

TRGTMODSEL[1:0] bits in PPS control register (ETH_MACPPSCR) enable you to program the Target Time registers ( PPS x target time seconds register (ETH_MACPPSTTSxR) and PPS x target time nanoseconds register (ETH_MACPPSTTNxR) ) to do any one of the following:

• • Generate only interrupts.
• • Generate interrupts and the PPS start and stop time.
• • Generate only PPS start and stop time.

To program the Target Time registers to generate only interrupt event:

1. 1. Program TRGTMODSEL[1:0] bits of PPS control register (ETH_MACPPSCR) to 00 (for interrupt). This instructs the MAC to use the Target Time registers for target time interrupt.
2. 2. Program a target time value in the Target Time registers. This instructs the MAC to generate an interrupt when the target time elapses.

If TRGTMODSEL[1:0] bits are changed (for example, to control the PPS), then the interrupt generation is overwritten with the new mode and new programmed Target Time register value.

Note: The TSTRGTERRO bit in Timestamp status register (ETH_MACTSSR) is set when the programmed target time is smaller (that is corresponds to a time in the past) compared to the system time in the System time seconds register (ETH_MACSTSR) and System time nanoseconds register (ETH_MACSTNR) .

An interrupt is generated ( sbd_intr_o ) if the TSIE bit in the Interrupt enable register (ETH_MACIER) is set.

Therefore, to avoid unwanted interrupts, the correct writing order is as follows:

1. 1. PPS x target time nanoseconds register (ETH_MACPPSTTNxR) .
2. 2. PPS x target time seconds register (ETH_MACPPSTTSxR) .
3. 3. PPS x interval register (ETH_MACPPSIxR) .
4. 4. PPS x width register (ETH_MACPPSWxR) .
5. 5. PPSCTRL[3:0] and PPSEN0 bitfields of PPS control register (ETH_MACPPSCR) .

76.9.15 Programming guidelines for IEEE 1588 auxiliary snapshot

The IEEE 1588 auxiliary snapshot function is used to capture the auxiliary snapshot for a trigger event received on the ptp_aux_ts_trig_i input.

To program the IEEE 1588 auxiliary snapshot function, complete the following steps:

1. 1. Program the TSIE bit in the Interrupt enable register (ETH_MACIER) to enable interrupt generation when the auxiliary snapshot is captured in the FIFO.
2. 2. Program the ATSENX bit of the Auxiliary control register (ETH_MACACR) to enable the capture of the auxiliary snapshot based on the respective trigger input.
3. 3. If the software does not want the captured auxiliary snapshot to be read, program the ATSFC bit of Auxiliary control register (ETH_MACACR) anytime to clear the auxiliary snapshot FIFO.
4. 4. When TSIS is set or an interrupt is generated (due to TSIE programmed to 1), read the Timestamp status register (ETH_MACTSSR) , Tx timestamp status seconds register

( ETH_MACTXTSSSR ), and Auxiliary timestamp nanoseconds register (ETH_MACATSNR) to access the captured auxiliary snapshot.

Note: When the auxiliary snapshot is captured in the FIFO for a trigger event, the following bitfields are updated:

• • AUXTSTRIG (status bit indicating that an auxiliary snapshot has been captured), ATSSTN (trigger event input source identifying the first available entry in the FIFO), and ATSNS (indicating the number of auxiliary snapshots available in the FIFO) bitfields of the Timestamp status register (ETH_MACTSSR) .
• • TSIS (indicating that an interesting event occurred in the IEEE 1588 timestamp function) bitfield in the Interrupt status register (ETH_DMAISR) .

The AUXTSTRIG bit is cleared on read (or set when the RCWE bit of the CSR software control register (ETH_MACCSRSWCR) is set).

Note: When the captured auxiliary snapshot is ignored because that the FIFO is full, the ATSSTM bit, which indicates that a trigger has been missed, is set.

76.9.16 Programming guidelines for TSO

The TCP segmentation offload (TSO) engine is used to offload the TCP segmentation functions to the hardware. To program the TSO, set the TSE bit to enable TCP packet segmentation, and program descriptor fields to enable TSO for the current packet.

Follow the steps below to program TSO:

1. 1. Program TSE bit of the corresponding Channel x transmit control register (ETH_DMACxTXCR) to enable TCP packet segmentation in that DMA.
2. 2. In addition to the normal transfer descriptor setting, the following descriptor fields must be programmed to enable TSO for the current packet:
   1. a) Enable TSE of TDES3 (bit 18).
   2. b) Program the length of the unsegmented TCP/IP packet payload in bits 17 to 0 of TDES3, and the TCP header in bits 22 to 19 of TDES3.
   3. c) Program the maximum size of the segment in:
      • – MSS[13:0] of Channel x control register (ETH_DMACxCR)
      • – or MSS in the context descriptor
        If MSS[13:0] field is programmed in both Channel x control register (ETH_DMACxCR) and in the context descriptor, the latest software programmed sequence is considered.
3. 3. The unsegmented TCP/IP packet header should be stored in Buffer 1 of the first descriptor. This buffer must not hold any payload bytes. The payload is allocated to Buffer 2 and the buffers of the subsequent descriptors.

Caution: If TSE is enabled in TDES3 for a non-TCP-IP packet, the result is unpredictable.

76.9.17 Programming guidelines to perform VLAN filtering on the receiver

Follow the sequence below to perform VLAN filtering on the receiver:

1. 1. Program VLAN tag Control register (ETH_MACVTCR) for the following bit to select the filtering method:
   • – ETV: Enable 12-bit VLAN Tag Comparison or 16-bit VLAN Tag comparison.
   • – VTHM: VLAN Tag Hash Table Match Enable.
   • – ERIVLT: Enable inner VLAN Tag or outer VLAN Tag (to enable the inner or outer VLAN Tag filtering, Double VLAN Processing should enabled by setting EDVLP)
   • – ERSVLM: Enable Receive S-VLAN Match or C-VLAN match (for S-VLAN processing to be enabled, set ESVL)
   • – DOVLTC: Ignores VLAN Type for Tag Match
   • – VTIM: to enable VLAN Tag Inverse Match instead of the normal VLAN Tag matching
2. 2. Program VL bit in VLAN tag Control register (ETH_MACVTCR) for the 12-bit or 16-bit VLAN tag.
3. 3. If VLAN tag Hash filtering is enabled, program VLAN Hash table register (ETH_MACVHTR) .
   • – When the ETV bit is reset, the upper 4 bits of the calculated CRC-32 of VLAN tag are inverted and used to index the content of the VLAN Hash table register (ETH_MACVHTR) .
   • – When ETV bit is set, the upper 4 bits of the calculated CRC-32 of VLAN tag are used to index the content of VLAN Hash table register (ETH_MACVHTR) .

For example, when ETV bit is set, a hash value of 0b1000 selects bit 8 of the VLAN Hash table. When ETV bit is reset, a hash value of 0b1000 selects bit 7 of the VLAN Hash table.

76.9.18 Programming guidelines for extended VLAN filtering and routing on reception

For the indirect access to the per VLAN Tag registers, follow these steps:

• • Write access
  1. a) Write the required data into the VLAN tag data register (ETH_MACVTDR) .
  2. b) Program the OFS field of VLAN tag Control register (ETH_MACVTCR) with the required filter register offset and command type to the CT field. For a write command, set this bit to 0.
  3. c) Write 1 to the OB field and wait until the OB bit is reset before performing the next write. This is to ensure that the appropriate VLAN Tag Filter Register has been programmed.
• • Read access
  1. a) Program the OFS field of the VLAN tag Control register (ETH_MACVTCR) with the required register offset and command type to the CT field. For a read command, set this bit to 1.
  2. b) Write 1 to the OB field and wait till the OB bit is reset. The appropriate VLAN Tag Filter register value is available in the VLAN tag data register (ETH_MACVTDR) .

76.9.19 Programming sequence for queue/channel-based VLAN inclusion register

Writing to the per queue/channel VLAN inclusion indirect registers

To write to the queue/channel-based VLAN inclusion register, complete the following steps.

Note: Indirect VLAN include registers are not accessed while setting the CBTI bit.

1. 1. Set the CBTI bit of VLAN inclusion register (ETH_MACVIR) to 1, to enable queue/channel based VLAN tag insertion on all transmitted packets. This bit must be set before any indirect access to the queue/channel specific VLAN inclusion register [alternate] (ETH_MACVIR) .
2. 2. Set the RDWR field of VLAN inclusion register (ETH_MACVIR) to 1, to indicate write access.
3. 3. Program the VLAN tag and VLAN type to be inserted in the packets from a particular queue/channel in VLT[15:0] and CSVL fields of VLAN inclusion register (ETH_MACVIR) . The corresponding offset address in ADDR field (0 for queue/channel 0, 1 for queue/channel 1, and so on) must be set. Set the RDWR bit to 1 to indicate write access. The write to byte 0 of VLAN inclusion register (ETH_MACVIR) initiates access to indirect access VLAN inclusion register [alternate] (ETH_MACVIR) .
4. 4. The BUSY bit of VLAN inclusion register (ETH_MACVIR) is set by the peripheral to indicate the progress of access to indirect access VLAN inclusion register [alternate] (ETH_MACVIR) . On completion of the access, the BUSY bit is cleared. The application must not attempt subsequent access to VLAN inclusion register [alternate] (ETH_MACVIR) when the BUSY bit is 1.
5. 5. Repeat step 2 and step 3 to program VLAN tag and VLAN type to be inserted in packets from the remaining queues/channels. The application must ensure that the required VLAN tag and VLAN type for all the queues/channels are programmed; otherwise unintended VLAN tag and VLAN type might be inserted.

Read the per queue/channel VLAN inclusion indirect registers

To read the queue/channel-based VLAN inclusion register, complete the following steps:

1. 1. Set the CBTI field of VLAN inclusion register (ETH_MACVIR) to 1, to enable queue/channel based VLAN tag insertion on all the transmitted packets. This bit must be set before indirect access to the queue/channel specific VLAN inclusion register [alternate] (ETH_MACVIR) .
2. 2. Program the read offset address in the ADDR field (0 for queue/channel 0, 1 for queue/channel 1, and so on).
   Set the RDWR bit to 0 to indicate read access.
3. 3. The BUSY field of VLAN inclusion register (ETH_MACVIR) is set by the peripheral to indicate the progress of access to the indirect access VLAN inclusion register [alternate] (ETH_MACVIR) . On completion of the access, the BUSY field is cleared. Bits[15:0] and bit [19] of VLAN inclusion register (ETH_MACVIR) contain the VLAN tag and VLAN type respectively, from the corresponding queue/channel/offset address.
4. 4. Repeat step 2 and step 3 to read VLAN tag and VLAN type from the remaining queues/channels.

76.9.20 Programming guidelines for EST

Program the gate control values and time intervals in the software owned gate control list (SWOL) along with the other EST related registers that are described in Section 76.11.3: Ethernet MTL registers , to appropriate values. The following subsections provide step-by-step details for programming the GCL and the other EST related registers.

Programming the GCL and GCL-linked registers

Follow these steps to program the gate control list (GCL) and the four other registers implemented per GCL.

1. 1. The GCL and the four other GCL-linked registers should be accessed through indirect addressing using the EST Gate Control List register (ETH_MTLESTGCLCR) and EST Gate Control List Data register (ETH_MTLESTGCLDR) . The SWOL bitfield of the EST Status register (ETH_MTLESTSR) indicates if GCL0 or GCL1 is owned by software.
2. 2. To program the GCL, write the 32-bit write data to EST Gate Control List Data register (ETH_MTLESTGCLDR) . Then program EST Gate Control List Data register (ETH_MTLESTGCLDR) register to write the write address and other control information.
3. 3. In the EST Gate Control List Data register (ETH_MTLESTGCLDR) , writing data consists of 8 bits of gate controls plus 24 bits of time interval. Gate close is indicated by programming a 0 and gate open is indicated by programming a 1. The data should be written in the following format:
   {TC7, TC6, TC5, TC4, TC3, TC2, TC1, TC0, 24-bit time interval} where TCx = 0 or 1.
4. 4. In the EST Gate Control List Data register (ETH_MTLESTGCLDR) , program the SRWO bit to 1 (to start a write operation) and program the address and r/w bitfields appropriately.
5. 5. Poll and check for the SRWO bit to be cleared by hardware to indicate the completion of the previous operation before initiating a new read/write operation using the same indirect addressing mode.
6. 6. Repeat steps 3, 4, 5 until the programming of the GCL is complete.
7. 7. Using the indirect addressing method, program the BTR, CTR, TER and LLR registers. Set the GCRR bit in the EST Gate Control List Data register (ETH_MTLESTGCLDR) appropriately. The GCRR bit interprets the address field as belonging to these registers (instead of the GCL).

After programming the GCL and the related registers, program the EST Control register (ETH_MTLESTCR) to allow the hardware to own and process the GCL. When the List length (as indicated in LLR) is 1, the associated time interval should be smaller than the value of the cycle time register. Otherwise, an error is reported (as detailed in the Error handling section) as a single set of gate controls adds no value in the TSN context.

Note: The time unit in all the GCL related registers is seconds and nanoseconds. In cases where internally generated PTP system time is used, the nanoseconds field must be programmed to use the Digital rollover mode (TSCTRLSSR bitfield of Timestamp control register (ETH_MACTSCR) set to 1).

Programming the EST registers

After completing the steps mentioned in Section : Programming the GCL and GCL-linked registers , program the EST Control register (ETH_MTLESTCR) .

1. 1. Set the current time offset value and time internal left shift bitfields of the EST Control register (ETH_MTLESTCR) appropriately. In addition, set the enable EST (EEST) and switch to SWOL (SWOL) bits.
2. 2. This enables the Ethernet controller to own and process the new GCL and switch to the new GCL at the BTR value. If enabled, the Ethernet controller generates an interrupt when the switch to the new list occurs.
3. 3. Software must address any other interrupts received during the hardware execution of the GCL.

Set the SSWL field in the EST Control register (ETH_MTLESTCR) to hand off to the controller.

The SSWL bit is reset/cleared by the controller when it successfully switches to the new list. The controller also flips the SWOL bit to indicate the new GCL that the software owns.

To install a new GCL, program the GCL it owns (indicated by SWOL bit) as described in Section : Programming the GCL and GCL-linked registers and then program the EST Control register (ETH_MTLESTCR) as described above. Ensure that the new BTR is set to an appropriate value to avoid BTR error that might need software intervention in some cases.

To avoid transmission overruns, the packet length (frame size) information should be available at all times. Therefore, in the DMA configurations, program the packet length in the first descriptor of every Tx frame. Similarly, in the MTL configuration, provide the packet length in the control word.

76.9.21 Programming the launch time in time-based scheduling

The launch time is programmed in the enhanced normal transmit descriptors.

The OSTC and launch time features are mutually exclusive and must not be used together; in case of a conflict (if OSTC = LTV = 1 in MTL configuration), priority is given to OSTC and the launch time is ignored.

If a context descriptor is received with a valid OSTC value immediately before receiving a first normal descriptor with LTV bit set, then the LTV is ignored.

76.9.22 Enabling the frame preemption function

Receive-side programming

1. 1. Enable at least two Rx queues by programming the appropriate values in the Rx queue control 0 register (ETH_MACRXQC0R) ; one queue for express and the other for preemption when preemption receive traffic is expected.
2. 2. Program the Rx queue control 1 register (ETH_MACRXQC1R) , Rx queue control 2 register (ETH_MACRXQC2R) and Rx Queue control register (ETH_MACRXQCR) to

route the received packets to MTL Rx queues. Ensure that the preemptable traffic and express traffic are not routed to the same Rx queue.

As the queue mapping for tagged packets is based on VLAN user-priority field, the priority of preemptable and express packets must be exclusive to each other. In other words, packets of a certain priority (traffic class) are either express or preemptable but cannot be both.

1. 3. Program the preemption residue queue (FPRQ[2:0] bitfield of the Rx queue control 1 register (ETH_MACRXQC1R) ) to route all non-classified received preemptive packets, so that these packets are not routed to the default or residue queue for express packets, which is Rx Queue 0.

Transmit-side programming

1. 1. Enable at least two Tx queues by programming appropriate values in the TXQEN[1:0] bitfield of the Tx queue x operating mode register (ETH_MTLTXQxOMR) , one for express and the other for preemption (by setting the corresponding bit in the PEC bitfield of FPE Frame Preemption Control Status register (ETH_MTLFPECSR) ) when preemption receive traffic is expected.
2. 2. Set the EFPE bit of the FPE control and status register (ETH_MACFPECSR) to enable the preemption function in the transmitter.
3. 3. Program the AFSZ[1:0] bitfield of the FPE Frame Preemption Control Status register (ETH_MTLFPECSR) to set the minimum size of the non-final fragments.
4. 4. When 802.1Qbv/EST (Enhancement to Scheduled Traffic) is also enabled, follow the programming guidelines for EST and GCL.
5. 5. Program the Hold Advance (HADV[15:0]) and Release Advance (RADV[15:0]) bitfields of FPE Frame Preemption Advance register (ETH_MTLFPEAR) with how much early the hold and release, respectively, must be initiated, so that the hold and release happen at exactly the boundaries of GCL rows. The value of HADV[15:0] must be equal to the time required to transmit minimum_fragment_size + IPG/EIPG + Preamble (in nanosecond), so that the packet can be preempted before the hold window starts.

76.10 Descriptors

76.10.1 Descriptor overview

In the Ethernet peripheral, the DMA transfers data based on a linked list of descriptors. The application creates the descriptors in the system memory (SRAM). The following two types of descriptors are supported:

• • Normal descriptors
  The normal descriptors are used for packet data and to provide control information applicable to the packets to be transmitted.
• • Context descriptors
  The context descriptors are used to provide control information applicable to the packet to be transmitted.

Each normal descriptor contains two buffers and two address pointers. These buffers enable the adapter port to be compatible with various types of memory management schemes.

There is no limit to the number of descriptors that can be used for a single packet.

76.10.2 Descriptor structure

The Ethernet peripheral supports the ring structure for DMA descriptors.

Figure 1059. Descriptor ring structure

MSv40392V1

In a ring structure, descriptors are separated by the 64-bit word number programmed in the DSL field of the Channel x control register (ETH_DMACxCR) . The application needs to program the total ring length, that is the total number of descriptors in ring span, in the following registers of a DMA channel:

• • Channel x Tx descriptor ring length register (ETH_DMACxTXRLR)
• • Channel x Rx descriptor ring length register (ETH_DMACxRXRLR)

The Channel x Tx descriptor tail pointer register (ETH_DMACxTXDTPR) or Channel x Rx descriptor tail pointer register (ETH_DMACxRXDTPR) contains the pointer to the descriptor address (N). The base address and the current descriptor pointer decide the address of the current descriptor that the DMA can process. The descriptors up to one location less than the one indicated by the descriptor tail pointer (N – 1) are owned by the DMA. The DMA continues to process the descriptors until the following condition occurs:

Current Descriptor Pointer == Descriptor Tail Pointer;

The DMA enters the Suspend state when this condition occurs. The application must perform a write operation to the descriptor tail pointer register and update the tail pointer so that the following condition is met:

Descriptor Tail Pointer > Current Descriptor Pointer;

Note: When the application sets the descriptors into the end-of-descriptor ring, continues setting from the start of the descriptor list and updating the descriptor tail pointer, the above condition is not satisfied. The DMA detects such a case, processes the descriptors until the

end of the ring and then continues processing from the start of the descriptor list until the current descriptor pointer is equal to the descriptor tail pointer.

When the application programs the descriptor tail pointer beyond the end of the descriptor ring, the DMA interprets this as the availability of one more complete ring of descriptors, and after processing the last descriptor in the ring continues to process descriptors from the start of the descriptor list. If this is not intended, the application must program the descriptor tail pointer to the start of the descriptor list after setting the last descriptor in the ring.

The DMA automatically wraps around the base address when the end of ring is reached, as shown in Figure 1060: DMA descriptor ring .

Figure 1060. DMA descriptor ring

For descriptors owned by the application, the OWN bit of DES3 is reset to 0.

For descriptors owned by the DMA, the OWN bit is set to 1.

At the beginning, if the application has only one descriptor, it sets the last descriptor address (tail pointer) to Descriptor Base Address + 1. The DMA then processes the first descriptor and waits for the application to increment the tail pointer.

Descriptor tail pointer handling examples

Figure 1061. Descriptor tail pointer example 1

When the current descriptor pointer points to descriptor 4 (D4) and the descriptor tail pointer points to descriptor 7 (D7), the last descriptor owned by the DMA is descriptor 6 (D6) and there are three descriptors (D4, D5, D6) available for the DMA, as shown in Figure 1061: Descriptor tail pointer example 1 .

Figure 1062. Descriptor tail pointer example 2

As shown in Figure 1062: Descriptor tail pointer example 2 , the application frees four descriptors (D7, D8, D9 and D0) and updates the descriptor tail pointer to point to descriptor

1 (D1). The last descriptor owned by the DMA is descriptor 0 (D0). The descriptors referenced between the current descriptor pointer (D4) and the descriptor tail pointer (D1) are available to the DMA.

76.10.3 Transmit descriptor

The Ethernet peripheral DMA requires at least one descriptor for a transmit packet. In addition to two buffers, two byte-count buffers, and two address pointers, the transmit descriptor features control fields which can be used to manage the MAC operation on per-transmit packet basis. The Transmit normal descriptor has the following two formats: Read format and Write-back format.

Transmit normal descriptor (read format)

Figure 1063 shows the Read format for Transmit normal descriptor. Table 821 to Table 824 provide a detailed description of all Transmit normal descriptors (read format).

Figure 1063. Transmit descriptor (read format)

• • TDES0 normal descriptor (read format)

Table 821. TDES0 normal descriptor (read format)

• • TDES1 normal descriptor (read format)

Table 822. TDES1 normal descriptor (read format)

• • TDES2 normal descriptor (read format)

Table 823. TDES2 normal descriptor (read format)

Table 823. TDES2 normal descriptor (read format) (continued)

• • TDES3 normal descriptor (read format)

Table 824. TDES3 normal descriptor (read format)

Table 824. TDES3 normal descriptor (read format) (continued)

Table 824. TDES3 normal descriptor (read format) (continued)

Transmit normal descriptor (write-back format)

The write-back format is applicable only for the last descriptor of the corresponding packet. The LD bit (TDES3[28]) is set in the descriptor where the DMA writes back the status and timestamp information for the corresponding Transmit packet.

Figure 1064 shows the write-back format for Transmit normal descriptors. Table 825 to Table 828 provide a detailed description of all Transmit Normal descriptors (Write-Back Format).

Figure 1064. Transmit descriptor write-back format

• • TDES0 normal descriptor (write-back format)

1. This format is only applicable to the last descriptor of a packet.

• • TDES1 normal descriptor (write-back format)

1. This format is only applicable to the last descriptor of a packet.

• • TDES2 normal descriptor (write-back format)

1. This format is only applicable to the last descriptor of a packet.

• • TDES3 normal descriptor (write-back format)