58. Ethernet (ETH): media access control (MAC) with DMA controller

58.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-2008 standard.

The peripheral is configurable to meet the needs of a large variety of consumer and industrial applications.

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

58.2.1 Standard compliance

The Ethernet peripheral is compliant with the following standards:

• • IEEE 802.3-2008 for Ethernet MAC and media independent interface (MII)
• • IEEE 1588-2008 for precision networked clock synchronization (PTP)
• • IEEE 802.3az-2010 for Energy Efficient Ethernet (EEE)
• • AMBA 2.0 for AHB master and AHB slave ports
• • RMII specification version 1.2 from RMII consortium

58.2.2 MAC features

MAC Tx and Rx common features

• • Separate transmission, reception, and control interfaces to the application
• • 10, 100 Mbps data transfer rates with the following PHY interfaces:
  • – IEEE 802.3-compliant MII interface to communicate with an external Fast Ethernet PHY
  • – RMII interface to communicate with an external Fast Ethernet PHY
• • Half-duplex operation:
  • – CSMA/CD protocol support
  • – Flow control using backpressure (based on implementation-specific white papers and UNH Ethernet Clause 4 MAC Test Suite - Annex D)
• • Standard IEEE 802.3az-2010 for Energy Efficient Ethernet in MII PHYs

• • 32-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 pulse-per-second (PPS) output signal (eth_ptp_pps_out 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

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

58.2.3 Transaction layer (MTL) features

MTL Tx and Rx Common Features

• • 32-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

• • 2048-byte Transmit FIFO with programmable threshold capability
• • Store-and-forward mechanism or threshold mode (cut-through) for transmission to the MAC
• • 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
• • 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

MTL Rx features

• • 2048-byte Receive FIFO with configurable threshold
• • 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

58.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 58.11.2: Ethernet DMA registers ) to control the DMA operations. The DMA block supports the following features:

• • 32-bit data transfers
• • Separate DMA in Transmit path and receive paths
• • 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
• • Start and Stop modes
• • Separate ports for host control (AHB) access and host data interface
• • Tx DMA channel with TCP segmentation offload (TSO) feature enabled
• • Programmable control for Transmit Descriptor posted writes to improve the throughput

58.2.5 Bus interface features

AHB master interface

The AHB master interface features are the following:

• • Interfaces with the application through AHB
• • 32-bit data on the AHB master port
• • Split, Retry, and Error AHB responses
• • AHB 1-Kbyte boundary burst splitting
• • Software-selected type of AHB burst (fixed burst, indefinite burst, or mix of both)

The AHB master interface does not generate the following:

• • Wrap burst
• • Locked or protected transfers

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
• • Error

58.3 Ethernet pins and internal signals

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

Table 523 shows the internal Ethernet signals.

Table 522. Ethernet peripheral pins

Table 522. Ethernet peripheral pins (continued)

Table 523. Ethernet internal input/output signals

58.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 one physical channel for reception and 1 for transmission. It controls the data transfers between MAC and system memory through the AMBA AHB 32-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 PHY Media Independent Interfaces.

Figure 781. Ethernet high-level block diagram

1. 1. For a definition of the internal signals, refer to Table 523 .
2. 2. Refer to RCC chapter "Clock distribution for Ethernet" for a detailed description of the Ethernet clock architecture.

58.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 Tx descriptor list address register (ETH_DMAC TXDLAR) and Channel Rx descriptor list address register (ETH_DMAC RXDLAR) .

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 Tx descriptor ring length register (ETH_DMAC TXRLR) and Channel Rx descriptor ring length register (ETH_DMAC RXRLR) .

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 58.10: Descriptors .

DMA arbitration

The DMA module incorporates an arbiter that performs the arbitration between the Tx and Rx channels accesses from the AHB master interface. The following two types of arbitrations are supported and can be selected through DMA mode register (ETH_DMAMR) :

• • Round-robin arbitration: the arbiter allocates the data bus between Rx and Tx in ratio set by Bits [14:12] of ETH_DMAMR.
• • Fixed-priority arbitration: by default Rx DMA always gets priority over Tx DMA for data access. Setting bit 11 of ETH_DMAMR register gives priority to the Tx DMA.

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. The DMA fetches the descriptor from the application memory.
4. 4. 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.
5. 5. 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.
6. 6. The DMA fetches the Transmit data from the system memory and transfers the data to the MTL for transmission.
7. 7. 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.
8. 8. 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.
9. 9. Bit 0 of Channel status register (ETH_DMACSR) 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.
10. 10. 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 Tx descriptor tail pointer register (ETH_DMACTXDTPR) 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 782. DMA transmission flow (standard mode)

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

DMA transmission in OSP (Operate on Second Packet) mode

In Run state, if bit 4 is set in the Channel transmit control register (ETH_DMACCTXCR) , 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 Transmit Descriptor Tail Pointer register of corresponding channel.

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

Figure 783. DMA transmission flow (OSP mode)

graph TD; StartTxDMA[Start Tx DMA] --> FetchNext[(Re-)fetch next descriptor from Tx Queue]; FetchNext --> OwnBitSet{Own bit set?}; OwnBitSet -- No --> EndRing{End of descriptor ring?}; OwnBitSet -- Yes --> TransferData[Transfer data from Buffer(s)]; TransferData --> PacketReadComplete{Packet read completely?}; PacketReadComplete -- No --> CloseDesc[Close intermediate descriptor]; PacketReadComplete -- 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 --> FetchNext; EndRing -- Yes --> TxDMAQueueSuspended[Tx DMA queue suspended]; TxDMAQueueSuspended --> PrevPacketStatus{Prev. packet status available?}; TxDMAQueueSuspended --> TxDemand{Tx Poll demand?}; PrevPacketStatus -- No --> DMAStopped{DMA Tx stopped?}; PrevPacketStatus -- Yes --> DMAStopped; TxDemand -- No --> DMAStopped; TxDemand -- Yes --> DMAStopped; DMAStopped -- No --> FetchNext; DMAStopped -- Yes --> StopDMA[Stop DMA]; CloseDesc --> FetchNext;

MS40863V1

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 reception sequence for Rx DMA engine is as follows (see also Figure 784: Receive DMA flow ):

1. 1. The application sets up the Rx descriptors (RDES0-RDES3) and the Own bit (RDES3[31]). The application must set the correct value in the Receive descriptor tail pointer register of corresponding DMA channel.
2. 2. When bit 0 of Channel receive control register (ETH_DMACRXCR) 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. 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 increments the channel Receive tail pointer register. The engine proceeds to step 2 and fetches again the next descriptor.

Figure 784. Receive DMA flow

graph TD; Start([Start]) --> Stop[Stop Rx DMA]; Stop --> StartRx[Start Rx DMA]; StartRx --> Fetch[(Re)Fetch next descriptor]; Fetch --> Poll{Receive Poll demand}; Poll --> Stopped{Rx DMA stopped?}; Stopped -- Yes --> Stop; Stopped -- No --> Own{Own bit set?}; Own -- No --> Suspend[Suspend Rx DMA]; Suspend --> Fetch; Own -- Yes --> Pending{Timestamp pending?}; Pending -- Yes --> WriteTS[Write timestamp to RDES0 and RDES1]; WriteTS --> Clear[Clear pending timestamp]; Pending -- No --> Data{Packet data available?}; Data -- No --> Wait[Wait for packet data]; Wait --> Write[Write data to buffer]; Data -- Yes --> Write; Write --> Complete{Packet transfer complete?}; Complete -- No --> CloseInt[Close RDES3 as intermediate descriptor]; CloseInt --> Fetch; Complete -- Yes --> TS{Timestamp present?}; TS -- Yes --> Set[Set pending timestamp]; TS -- No --> CloseLast[Close RDES3 as last descriptor]; Set --> CloseLast; CloseLast --> Stopped2{Rx DMA stopped?}; Stopped2 -- Yes --> Stop; Stopped2 -- No --> End{End of descriptor ring?}; End -- Yes --> CloseLast; End -- No --> Fetch;

MS40864V1

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. The DMA arbiter supports two types of arbitration: fixed priority and weighted round-robin. The DA bit of the DMA mode register (ETH_DMAMR) specifies the arbitration scheme (fixed or weighted round-robin) between the Tx and Rx DMA of a given channel.

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) . For round-robin arbitration, the weighted priority between the Tx DMA and Rx DMA is configured through the PR field of the DMA mode register (ETH_DMAMR) . Table 524 provides information about the priority scheme between Tx DMA and Rx DMA.

Table 524. Priority scheme for Tx DMA and Rx DMA

58.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 32-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 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 2048 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 Rx queue operating mode register (ETH_MTLRXQOMR) ), 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 2048 bytes.

58.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 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 785: Overview of MAC transmission flow illustrates the MAC transmission process flow.

Figure 785. Overview of MAC transmission flow

graph TD; Start([Start]) --> WaitData[Wait for data & SOP From MTL]; WaitData --> SOPAsserted{SOP asserted by MTL?}; SOPAsserted -- YES --> WaitIPG[Wait for IPG/any back-off delay hal-duplex]; SOPAsserted -- NO --> WaitData; 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 --> WaitData; ConditionD -- NO --> DropData2[Drop all the data received from MTL and abort transmission]; Collision -- NO --> A_EOP{A. EOP asserted by MTL? B. Underflow asserted by MAC?}; A_EOP -- Condition A --> NormalTrans[Normal transmission completed and Transmission status conveyed to MTL]; A_EOP -- Condition B --> DropData2; NormalTrans --> WaitData; DropData1 --> WaitData; DropData2 --> WaitData;

MSv40390V1

MAC reception

A receive operation is initiated when the MAC detects an SFD on MII. 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 MII becomes active, the Receive State Machine (RSM) starts looking for the SFD field (0xD nibble).

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 MII. If this packet is not dropped during MAC filtering, the timestamp is passed to the application. The MAC converts the received nibble data into bytes and forwards the valid packet data to the RFC module.
3. 4. 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. 5. 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. 6. 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 786. MAC reception flow

graph TD; Start([Start]) --> WaitPhy[Wait for phy_rxdv_i from GMII/MII]; WaitPhy --> WaitSFD[Wait until SFD is detected]; WaitSFD --> StartSend[Start sending the received Ethernet packet to the application layer, starting from DA field]; StartSend --> 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 --> LengthTypeGE1536[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]; LengthTypeGE1536 --> CRCStripping{CRC stripping for Type packets enabled?}; CRCStripping -- YES --> ChecksumOffload{Receive checksum Offload engine enabled?}; CRCStripping -- 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;

MSV40391V1

58.5 )Ethernet functional description: MAC

58.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 525: Double VLAN processing features in Tx path describes the features supported by the MAC on the Transmit side.

Table 525. Double VLAN processing features in Tx path

Receive path

Table 526: 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 register (ETH_MACVTR) .

Table 526. Double VLAN processing in Rx path

58.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 58.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 527: VLAN insertion or replacement based on VLTi bit .

Table 527. 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 560: 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.

58.5.3 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 787 shows the filtering sequence for Rx packets.

Figure 787. Packet filtering sequence

graph TD; A[Receive Packet] --> B[Ethernet DA or SA Filter]; B -- Fail --> D[Discard Packet]; B -- Pass --> C[VLAN Filter]; C -- Fail --> D; C -- Pass --> E[IP SA or DA Filter]; E -- Fail --> D; E -- Pass --> F[TCP or UDP SP or DP Filter]; F -- Fail --> D; F -- Pass --> G[Deliver to the Host];

MSv40800V1

The sequence shown in Figure 787 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, VTFE and IPFE 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 529 ). 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 528 and Table 529 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 528. Destination address filtering

Table 528. Destination address filtering (continued)

Table 529. Source address filtering

VLAN filtering

The MAC supports Perfect and Hash VLAN filtering. Refer to Section 58.9.14: Programming guidelines to perform VLAN filtering on the receive 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 register (ETH_MACVTR) . 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 register (ETH_MACVTR) . 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 register (ETH_MACVTR) . 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 register (ETH_MACVTR) .

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 530 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 VTTFE bit is set in Packet filtering control register (ETH_MACPFR) , the packet is dropped if the final VLAN match status is Fail. In Table 530 , value X means that this column can have any value.

When VLAN VID is programmed to 0 in the VL field of VLAN tag register (ETH_MACVTR) , 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 register (ETH_MACVTR) .

Table 530. VLAN match status ⁽¹⁾

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

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

58.5.4 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 531. 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 532 . You can take the snapshot by setting the SNAPTYPESEL bits to 10 in the Timestamp control Register (ETH_MACTSCR) .

Table 532. 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 540 .

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 788 shows the process that PTP uses for synchronizing a slave node with a master node by exchanging PTP messages.

As shown in Figure 788 , 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 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 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 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 789 shows the method to calculate the propagation delay in clocks supporting peer-to-peer path correction.

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

As shown in Figure 789 , 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 (MII 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 MII 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 latency differs based on the active PHY interface (such as MII or RMII) and the operating speed, as shown in Table 534 .
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

The latency differs based on the active PHY interface (RMII, MII, etc.) and the operating speed as shown in Table 534 .

1. 3. CDC synchronization error

The timestamp correction because of synchronization is compensated by adding

Table 534 lists the Egress and Ingress latency values for various PHY interfaces:

Table 534. Egress and ingress latency for 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 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 MII clock domain. This relationship is given by the following equation:

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

PTP processing and control

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

Table 536. 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 537 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 536 .

Table 537. Message format defined in IEEE 1588-2008

Table 537. Message format defined in IEEE 1588-2008 (continued)

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

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

Table 538. IPv6-UDP PTP packet fields required for control and status (continued)

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

PTP packets over Ethernet

Table 539 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 539. Ethernet PTP packet fields required for control and status

Table 539. Ethernet PTP packet fields required for control and status (continued)

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 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 58.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 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 540 indicates the PTP messages for which a snapshot is taken depending on the SNAPTYPSEL field in Timestamp control Register (ETH_MACTSCR) .

Table 540. 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 58.9.9: Programming guidelines for IEEE 1588 timestamping on page 2883 .

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, \( (10^9-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_MACTSCR) .

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

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

Figure 790. System time update using fine correction method

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 790, 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 58.9.9: 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_out 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 target time seconds register (ETH_MACPPSTTSR) and PPS target time nanoseconds register (ETH_MACPPSTTNR) .

The PPS width and interval are programmed in terms of granularity of system time (number of the units of subsecond increment value) through PPS width register (ETH_MACPPSWR) and PPS interval register (ETH_MACPPSIR) , 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 target time seconds register (ETH_MACPPSTTSR) and PPS target time nanoseconds register (ETH_MACPPSTTNR) 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:

• • 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_MACSCR) 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 790).

Refer to Section 58.9.12: 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.

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 target time nanoseconds register (ETH_MACPPSTTNR) 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.

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 541 indicates the PTP message generation criteria.

Table 541. PTP message generation criteria

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

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 542. Common PTP message header fields

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

• • 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_Resp and Delay_Resp use the same sequenceId field from received Pdelay_Req and Delay_Req 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 543 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 543. MAC Transmit PTP mode and one-step timestamping operation

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

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

1. 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. 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. 3. OSTC represents OSTC bit of TDES3 transmit context descriptor
4. 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.

58.5.5 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 operating mode Register (ETH_MTLTXQOMR)

PBL corresponds to the TxPBL bitfield of Channel 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 565: 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 565: 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 544 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.

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 register (ETH_MACVTR) 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 operating mode register (ETH_MTLRXQOMR) 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 545: 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 545. Receive checksum offload engine functions for different packet types

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

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

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

Figure 791. TCP segmentation offload overview

graph LR; TCP[TCP packet] --> TSD[TSD engine]; TSD --> Segments["Seg N | ... | Seg 2 | Seg 1"]; Segments --> MTL["MTL Tx queue #"]; TSD --> DMA["DMA Tx Channel #"];

Figure 792 shows the TSO 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.

1. • – 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).
2. 1. 4. The DMA calculates the number of segments from the TCP payload length (TDES3[17:0]) and the MSS value.
   2. 5. The DMA goes through channel arbitration to fetch the data buffers. The DMA fetches the header and payload separately.
   3. 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.
   4. 7. The required fields in the header bytes are modified/updated as per the segmentation requirements and written into the corresponding MTL Tx queue.
   5. 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.
   6. 9. The DMA jumps to Step 3 and repeats the process until the last segment is written into the Tx queue.
   7. 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 546 describes how the TCP and IP headers are updated.

Table 546. 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 546: TSO: TCP and IP header fields . Figure 793: 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 793. Header and payload fields of segmented packets

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 58.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 interrupt enable register (ETH_DMAIER) ).

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

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

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_DMAACR (see Channel control register (ETH_DMAACR) ) 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_DMACTXCR register (see Channel transmit control register (ETH_DMACTXCR) ) should be lesser than the Tx queue size programmed in TQS field of ETH_MTLTXQOMR register (see Tx queue operating mode Register (ETH_MTLTXQOMR) ). 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).

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

58.5.8 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_mii_tx_clk) and read on every read clock (eth_mii_rx_clk). At the start of each packet read from the FIFO, the write and read pointers are reinitialized to have an offset of four (in 10/100 Mbps 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 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 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 mii_txd signal. Preemption is not supported in Loopback mode.

58.5.9 Flow control

The transmit flow control involves transmitting Pause packets in Full-duplex mode and backpressure 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 547 describes the fields of a Pause packet.

Table 547. 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 548 describes the flow control in the Tx path based on the setting of the following bits:

• • TFE bit of Tx Queue flow control register (ETH_MACQTXFCR)
• • DM bit of Operating mode configuration register (ETH_MACCR)

Flow control is similar for all queues.

Table 548. Tx MAC flow control

Transmit flow control

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

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 flow control register (ETH_MACQTXFCR) .

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 549 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_MACCCR)

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

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

58.5.10 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 58.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:

• • 6 registers used for collision, error and good packets counters:
  • – Tx single collision good packets register ( Tx single collision good packets register (ETH_TX_SINGLE_COLLISION_GOOD_PACKETS) )
  • – Tx multiple collision good packets register ( Tx multiple collision good packets register (ETH_TX_MULTIPLE_COLLISION_GOOD_PACKETS) )
  • – Tx packet count good register ( Tx packet count good register (ETH_TX_PACKET_COUNT_GOOD) )
  • – Rx CRC error packets register ( Rx CRC error packets register (ETH_RX_CRC_ERROR_PACKETS) )
  • – Rx alignment error packets register ( Rx alignment error packets register (ETH_RX_ALIGNMENT_ERROR_PACKETS) )
  • – Rx unicast packets good register ( Rx unicast packets good register (ETH_RX_UNICAST_PACKETS_GOOD) )
• • 4 registers to record LPI mode transition:
  • – Tx LPI microsecond timer register ( Tx LPI microsecond timer register (ETH_TX_LPI_USEC_CNTR) )
  • – Tx LPI transition counter register ( Tx LPI transition counter register (ETH_TX_LPI_TRAN_CNTR) )
  • – Rx LPI microsecond counter register ( Rx LPI microsecond counter register (ETH_RX_LPI_USEC_CNTR) )
  • – Rx LPI transition counter register ( 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 Mbps only)
  • – Length error (non-Type packet only)
  • – Out of range (non-Type packet only, longer than 1518 bytes)
• • 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 550 .

Table 550. Size of the maximum receive packet

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

58.5.12 MAC and MMC register descriptions

Refer to Section 58.11.4: Ethernet MAC and MMC registers .

58.6 Ethernet functional description: PHY interfaces

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

Figure 794. 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)

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

Figure 795. 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 551. 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 796 shows the structure of a Clause 45 MDIO packet, while Table 552 provides a detailed description of the packet fields.

Figure 796. MDIO packet structure (Clause 45)

Table 552. 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 797 shows the structure of a Clause 22 MDIO packet, while Table 553 provides a detailed description of the packet fields.

Figure 797. MDIO packet structure (Clause 22)

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

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 798 illustrates the flow for a write operation from the SMA module to the PHY registers.

Figure 798. 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
    C -.- J[Management packet format used as
specified in GMII specifications (as
per IEEE 802.3-2002, Section
22.2.4.5)]
  

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 MII management Interface using the management packet format specified in the MII 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 performed 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 799. Write data packet

MSv40807V1

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 MII management interface using the management packet format specified in the 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 800. 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.

58.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 801: Media independent interface (MII) signals .

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

58.6.3 Reduced media independent interface (RMII)

The reduced media independent interface (RMII) specification reduces the pin count between Ethernet PHYs and STM32 MCU. 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 Mbps and 100 Mbps operating rates. It does not support the 1000 Mbps operation.
• • Provides independent 2-bits wide Transmit and Receive paths by sourcing two clock references externally.

RMII block diagram

Figure 802: 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.

• • 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 803: Transmission bit order . The lower order bits (D1 and D0) are transmitted first followed by higher order bits (D2 and D3).

Figure 803. Transmission bit order

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 804: Receive bit order . The lower order bits (D0 and D1) are received first, followed by the higher order bits (D2 and D3).

Figure 804. Receive bit order

58.7 Ethernet low-power modes

58.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 idle (Sleep mode) and has to be woken up only at the reception of specific packets from the Ethernet network. In Sleep mode, the power to the host logic along with the majority of the peripheral (except the MAC receiver logic), can be shut down. On receiving the specific packets from the network, the MAC provides the trigger to restore the power to the host system and come back to normal state.

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 bursty 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 PWRDOWN 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 554: Remote wake-up packet filter register .

Table 554. Remote wake-up packet filter register

The remote wake-up filter fields are described in Table 555: Description of the remote wake-up filter fields .

Table 555. Description of the remote wake-up filter fields

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 556 lists the remote wake-up scenarios in which PMT interrupt is generated.

Table 556. Remote wake-up packet and PMT interrupt generation ⁽¹⁾

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 (line 86).

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 Mbps mode. When the application clears the PWRDOWN 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 transmit control register (ETH_DMACTXCR) .
• • 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 debug register (ETH_MTLTXQDR) 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 debug register (ETH_MTLRXQDR) 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.

58.7.2 Energy Efficient Ethernet (EEE)

EEE is an operational mode that enables the IEEE 802.3 Media Access Control (MAC) sub layer along with a family of physical layers to operate in the Low-Power Idle (LPI) mode. The EEE operational mode supports the IEEE 802.3 MAC operation at 100 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.

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 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 805 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 805) 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 806.

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 805. LPI transitions (Transmit, 100 Mbds)

Figure 806. 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 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 807 shows the behavior of RX_ER, RX_DV, and RXD[3:0] signals during the LPI mode transitions.

Figure 807. LPI transitions (receive, 100 Mbps)

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

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

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 (line 86).

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

Programming guidelines for Energy Efficient Ethernet

For detailed guidelines on the programming guidelines, see Section 58.9.11: Programming guidelines for Energy Efficient Ethernet (EEE) on page 2888 .

58.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_DMACSR: Channel Status (see Channel status register (ETH_DMACSR) )
• • ETH_MTLISR: Interrupt Status (see Interrupt status Register (ETH_MTLISR) )
• • ETH_MACISR: Interrupt Status (see Interrupt status register (ETH_MACISR) )

58.8.1 DMA interrupts

Interrupt registers description

The ETH_DMACSR: Channel Status register (see Channel status register (ETH_DMACSR) ) captures all the interrupt events of that TxDMA and RxDMA channel. The ETH_DMAIER: Channel Interrupt Enable register (see Channel interrupt enable register (ETH_DMAIER) ) 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_DMACSR 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 560: 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 573: 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_DMACRXIWTR: Channel 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 573: 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_DMACIER register (see Channel interrupt enable register (ETH_DMACIER) ). 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.

Channel transfer complete interrupt

The Transmit Transfer complete interrupt (TI) and Receive Transfer complete interrupt (RI) is reflected in the Channel Status register ( Channel status register (ETH_DMACSR) ). 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 interrupt enable register (ETH_DMACIER) ).

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 557 explains the behavior of the Transfer Complete interrupt.

Table 557. Transfer complete interrupt behavior

58.8.2 MTL interrupts

MTL interrupt events are combined with the events in the DMA to generate the interrupt signal.

Interrupt status Register (ETH_MTLISR) reports the queue number responsible for the event. ETH_MTLQICSR: Queue 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:

• • Receive Queue Overflow Interrupt
• • Transmit Queue Underflow

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

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.

58.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 58.9.1 )
• • MTL initialization (see Section 58.9.2 )
• • MAC initialization (see Section 58.9.3 )
• • Performing Normal Receive and Transmit Operation (see Section 58.9.4 )
• • Stopping and Starting Transmission (see Section 58.9.5 )
• • Programming Guidelines for MII Link State Transitions (see Section 58.9.8 )
• • Programming Guidelines for IEEE 1588 Timestamping (see Section 58.9.9 )
• • Programming Guidelines for Energy Efficient Ethernet (see Section 58.9.11 )
• • Programming Guidelines for flexible pulse-per-second (PPS) output (see Section 58.9.12 )
• • Programming Guidelines for TSO (see Section 58.9.13 )
• • Programming Guidelines for VLAN filtering on Receive (see Section 58.9.14 )

58.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
   2. b) Fixed burst or undefined burst
   3. c) Burst mode values in case of AHB bus interface.
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 58.10: Descriptors .

Note: Descriptor address from start to end of the ring should not cross the 4GB boundary.

1. 5. Program ETH_DMAC TXRLR and ETH_DMAC RXRLR registers (see Channel Tx descriptor ring length register (ETH_DMAC TXRLR) and Channel Rx descriptor ring length register (ETH_DMAC RXRLR) ). 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 Tx descriptor list address register (ETH_DMAC TXDLAR) , Channel Rx descriptor list address register (ETH_DMAC RXDLAR) ). In addition, program the transmit and receive tail pointer registers that inform the DMA about the available descriptors (see Channel Tx descriptor tail pointer register (ETH_DMAC TXTPR) and Channel Rx descriptor tail pointer register (ETH_DMAC RXTPR) ).
3. 7. Program ETH_DMAC CR, ETH_DMAC TXCR and ETH_DMAC RXCR registers (see Channel control register (ETH_DMAC CR) , Channel transmit control register (ETH_DMAC TXCR) and Channel receive control register (ETH_DMAC RXCR) ) 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.

1. 8. Enable the interrupts by programming the ETH_DMACIER register (see Channel interrupt enable register (ETH_DMACIER) ).
2. 9. Start the Receive and Transmit DMAs by setting SR (bit 0) of Channel receive control register (ETH_DMACRXCR) and ST (bit 0) of the ETH_DMACTXCR (see Channel transmit control register (ETH_DMACTXCR) ).

58.9.2 MTL initialization

Complete the following steps to initialize the MTL registers:

1. 1. Program the following fields to initialize the operating mode in Tx queue operating mode Register (ETH_MTLTXQOMR) .
   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).
2. 2. Program the following fields to initialize the operating mode in the ETH_MTLRXQOMR register (see Rx queue operating mode register (ETH_MTLRXQOMR) ):
   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).

58.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 flow control register (ETH_MACQTXFCR) :
   1. a) Pause time and other Pause frame control bits.
   2. b) Transmit Flow control bits.
   3. c) Flow Control Busy.

1. 4. Program the Interrupt enable register (ETH_MACIER) as required, if it is applicable for your configuration.
2. 5. Program the appropriate fields in the Operating mode configuration register (ETH_MACCR) register. For example, Inter-packet gap while transmission and jabber disable.
3. 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.

58.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_DMACCTXDTPR (see Channel Tx descriptor tail pointer register (ETH_DMACCTXDTPR) ) and ETH_DMACRXDTPR (see Channel Rx descriptor tail pointer register (ETH_DMACRXDTPR) ).
4. 4. In debug mode, the values of the current host transmitter or receiver descriptor address pointer can be read in ETH_DMACCATXDR and ETH_DMACCARXDR registers (see Channel current application transmit descriptor register (ETH_DMACCATXDR) and Channel current application receive descriptor register (ETH_DMACCARXDR) ).
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_DMACCATXDR and ETH_DMACCARXDR registers (see Channel current application transmit descriptor register (ETH_DMACCATXDR) and Channel current application receive descriptor register (ETH_DMACCARXDR) ).

58.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_DMACCTXCR register (see Channel transmit control register (ETH_DMACCTXCR) ).
2. 2. Wait for any previous frame transmissions to complete. You can check this by reading the appropriate bits of Tx queue debug register (ETH_MTLTXQDR) (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 debug register (ETH_MTLTXQDR) , 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 debug register (ETH_MTLTXQDR) 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.

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

58.9.7 Programming guidelines for switching the AHB clock frequency

To dynamically change the AHB 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 debug

register (ETH_MTLTXQDR) and the status of DMA is given in Debug status register (ETH_DMADSR) .

1. 2. Disable the MAC transmitter and the MAC receiver by clearing the appropriate bits in Operating mode configuration register (ETH_MACCR) .
2. 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 debug register (ETH_MTLRXQDR) .
3. 4. Ensure that the application does not perform any register read or write operation.
4. 5. Change the frequency of the AHB clock.
5. 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.

58.9.8 Programming guidelines for MII 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 control register (ETH_DMACCR) .
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 debug register (ETH_MTLTXQDR) (TRCSTS[1:0] is not 01).
   or
   Flush the Tx FIFO for faster empty operation.
4. 4. Disable the MAC transmitter by clearing TE bit of the Operating mode configuration register (ETH_MACCR) Register.
5. 5. Make sure that both Tx and Rx queues are empty (TXQSTS is set to 0 in Tx queue debug register (ETH_MTLTXQDR) and RXQSTS[1:0] to 00 in Rx queue debug register (ETH_MTLRXQDR) ).
6. 6. After the link is up, read the PHY registers to identify the latest configuration and program the MAC registers accordingly.
7. 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.

58.9.9 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 target time seconds register (ETH_MACPPSTTSR) and PPS target time nanoseconds register (ETH_MACPPSTTNR) .
5. 5. Enable the Timestamp interrupt in bit 12 of Interrupt enable register (ETH_MACIER) .
6. 6. Set bit 4 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.

58.9.10 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 SNAPTYPESEL, 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.

1. 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.
2. 6. Program the TSIE bit of Interrupt enable register (ETH_MACIER) to enable generation of Timestamp interrupt.
3. 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 TSEVTNENA 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 SNAWTYPSEL, 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.

1. 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.
2. 5. Program the TSIE bit of Interrupt enable register (ETH_MACIER) to enable generation of Timestamp interrupt.
3. 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
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.

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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 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.

58.9.12 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 target time seconds register (ETH_MACPPSTTSR) and PPS target time nanoseconds register (ETH_MACPPSTTNR) ) as start time of PPS signal output.
2. 2. Program the start time value in the Target Time registers (register PPS target time seconds register (ETH_MACPPSTTSR) and PPS target time nanoseconds register (ETH_MACPPSTTNR) ).
3. 3. Program the width of the PPS signal output in PPS width register (ETH_MACPPSWR) 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 width register (ETH_MACPPSWR) .
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

target time seconds register (ETH_MACPPSTTSR) and PPS target time nanoseconds register (ETH_MACPPSTTNR) for start time of the PPS signal output.

1. 2. Program the start time value in the Target Time registers (register PPS target time seconds register (ETH_MACPPSTTSR) and PPS target time nanoseconds register (ETH_MACPPSTTNR) ).
2. 3. Program the interval value between the train of pulses on the PPS signal output in PPS interval register (ETH_MACPPSIR) .
3. 4. Program the width of the PPS signal output in PPS width register (ETH_MACPPSWR) .
4. 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 target time nanoseconds register (ETH_MACPPSTTNR) 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 target time seconds register (ETH_MACPPSTTSR) and PPS target time nanoseconds register (ETH_MACPPSTTNR) ) 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 interrupt, the correct writing order is as follow:

1. 1. PPS target time nanoseconds register (ETH_MACPPSTTNR) .
2. 2. PPS target time seconds register (ETH_MACPPSTTSR) .
3. 3. PPS interval register (ETH_MACPPSIR) .
4. 4. PPS width register (ETH_MACPPSWR) .
5. 5. PPSCTRL[3:0] and PPSEN0 bitfields of PPS control register (ETH_MACPPSCR) .

58.9.13 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 transmit control register (ETH_DMACCTXCR) 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 control register (ETH_DMACCR)
      • – or MSS in the context descriptor
      If MSS[13:0] field is programmed in both Channel control register (ETH_DMACCR) 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.

58.9.14 Programming guidelines to perform VLAN filtering on the receive

Follow the sequence below to perform VLAN filtering on the receiver:

1. 1. Program VLAN tag register (ETH_MACVTR) 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)
   • – DOV LTC: 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 register (ETH_MACVTR) 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.

58.10 Descriptors

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

58.10.2 Descriptor structure

The Ethernet peripheral supports the ring structure for DMA descriptors.

Figure 808. Descriptor ring structure

In a ring structure, descriptors are separated by the 32-bit word number programmed in the DSL field of the Channel control register (ETH_DMACCR) . 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 Tx descriptor ring length register (ETH_DMACCTXRLR)
• • Channel Rx descriptor ring length register (ETH_DMACRXRLR)

The Channel Tx descriptor tail pointer register (ETH_DMACCTXDTPR) or Channel Rx descriptor tail pointer register (ETH_DMACRXDTPR) 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:

Current Descriptor Pointer < Descriptor Tail Pointer;

The DMA automatically wraps around the base address when the end of ring is reached, as shown in Figure 809: DMA descriptor ring .

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

58.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 810 shows the Read format for Transmit normal descriptor. Table 558 to Table 561 provide a detailed description of all Transmit normal descriptors (read format).

Figure 810. Transmit descriptor (read format)

• • TDES0 normal descriptor (read format)

Table 558. TDES0 normal descriptor (read format)

• TDES1 normal descriptor (read format)

Table 559. TDES1 normal descriptor (read format)

• TDES2 normal descriptor (read format)

Table 560. TDES2 normal descriptor (read format)

Table 560. TDES2 normal descriptor (read format) (continued)

• • TDES3 normal descriptor (read format)

Table 561. TDES3 normal descriptor (read format)

Table 561. TDES3 normal descriptor (read format) (continued)

Table 561. 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 811 shows the write-back format for Transmit normal descriptors. Table 562 to Table 565 provide a detailed description of all Transmit Normal descriptors (Write-Back Format).

Figure 811. 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)

1. This format is only applicable to the last descriptor of a packet.

Transmit context descriptor

The Transmit context descriptor can be provided any time before a packet descriptor. The context is valid for the current packet and subsequent packets. The context descriptor is used to provide the timestamps for one-step timestamp correction, and VLAN Tag ID for VLAN insertion feature. Write-back is only done on a context descriptor to reset the OWN bit.

Note: The VLAN tag IDs and MSS values, which are provided by the application in a context descriptor with their corresponding Valid bits set, are stored internally by the DMA.
When the outer or inner VLAN tag is provided with the Valid bit set, the DMA always passes the last valid VLAN tag to the MTL. The application cannot invalidate the valid VLAN tag

stored by the DMA. The VLAN tag is inserted or replaced based on the control inputs provided for the packet.

The Inner VLAN Tag Control input is used only for the packet that immediately follows the context descriptor. The application must provide a context descriptor before the normal descriptor of each packet for which the DMA should use the inner VLAN Tag control input.

Figure 812 shows the format for Transmit context descriptors. Table 566 to Table 569 provide a detailed description of all Transmit context descriptors.

Figure 812. Transmit context descriptor format

• • TDES0 context descriptor (read format)

Table 566. TDES0 context descriptor

• • TDES1 context descriptor (read format)

Table 567. TDES1 context descriptor

• • TDES2 context descriptor (read format)

Table 568. TDES2 context descriptor

• • TDES3 context descriptor (read format)

Table 569. TDES3 context descriptor

Table 569. TDES3 context descriptor (continued)

Table 569. TDES3 context descriptor (continued)

58.10.4 Receive descriptor

The DMA in the Ethernet peripheral attempts to read a descriptor only if the Tail pointer is different from the Base pointer or current pointer. It is recommended to have a descriptor ring with a length that can accommodate at least two complete packets received by the MAC; otherwise, the performance of the DMA is greatly impacted because of the unavailability of the descriptors. In such a situation, the MTL RxFIFO becomes full and starts dropping packets.

The following Receive descriptors are present:

• • Normal descriptors with read and write-back formats
• • Context descriptors

All received descriptors are prepared by the software and given to the DMA as “normal” descriptors (see Figure 813: Receive normal descriptor (read format) for a description of their content). The DMA reads this descriptor and, after transferring a received packet (or part of it) to the buffers indicated by the descriptor, the Rx DMA closes the descriptor with the corresponding packet status. The status format is given in Figure 814: Receive normal descriptor (write-back format) .

For some packets, the normal descriptor bits are not sufficient to write the complete status. For such packets, the Rx DMA writes the extended status to the next descriptor (without processing or using the Buffers pointers embedded in that descriptor). The format and content of this write-back descriptor is described in Figure 815: Receive context descriptor .

Receive normal descriptor (read format)

Figure 813 shows the read format for Receive normal descriptors. Table 570 to Table 573 provide a detailed description of all Receive normal descriptors (read format).

Figure 813. Receive normal descriptor (read format)

Note: In the Receive descriptor (read format), if the Buffer Address field contains only 0s, the MAC does not transfer data to this buffer and skips to the next buffer or next descriptor.

• • RDES0 normal descriptor (read format)

Table 570. RDES0 normal descriptor (read format)

• • RDES1 normal descriptor (read format)

Table 571. RDES1 normal descriptor (read format)

• • RDES2 normal descriptor (read format)

Table 572. RDES2 normal descriptor (read format)

• • RDES3 normal descriptor (read format)

Table 573. RDES3 normal descriptor (read format)

Receive normal descriptor (write-back format)

Figure 814 shows the write-back format for Receive normal descriptors. Table 574 to Table 577 provide a detailed description of all Receive normal descriptors (write-back format).

Figure 814. Receive normal descriptor (write-back format)

MSv40398V2

• • RDES0 normal descriptor (write-back format)

Table 574. RDES0 normal descriptor (write-back format)

• • RDES1 normal descriptor (write-back format)

1. The Status fields in write-back format are valid only for the last descriptor (RDES3[28] is set).

• • RDES2 normal descriptor (write-back format)

Table 576. RDES2 normal descriptor (write-back format)

Table 576. RDES2 normal descriptor (write-back format) (continued)

• • RDES3 normal descriptor (write-back format)

Table 577. RDES3 normal descriptor (write-back format)

Table 577. RDES3 normal descriptor (write-back format) (continued)

Table 577. RDES3 normal descriptor (write-back format) (continued)

Receive context descriptor

This descriptor is read-only for the application. This descriptor can be written only by the DMA.

The context descriptor provides information about the extended status related to the last received packet. Bit 30 of RDES3 indicates the context type descriptor.

Figure 815 shows the format for Receive context descriptors. Table 578 to Table 581 provide a detailed description of all Receive context descriptors.

Figure 815. Receive context descriptor

• • RDES0 context descriptor

Table 578. RDES0 context descriptor

• • RDES1 context descriptor

Table 579. RDES1 context descriptor

• • RDES2 context descriptor

Table 580. RDES2 context descriptor

• • RDES3 context descriptor

Table 581. RDES3 context descriptor

58.11 Ethernet registers

58.11.1 Ethernet register maps

This section provides the following register maps:

• • DMA registers (see Section 58.11.2: Ethernet DMA registers )
• • MTL registers (see Section 58.11.3: Ethernet MTL registers )
• • MAC registers including MMC register (see Section 58.11.4: Ethernet MAC and MMC registers )

58.11.2 Ethernet DMA registers

DMA mode register (ETH_DMAMR)

Address offset: 0x1000

Reset value: 0x0000 0000

The DMA mode register establishes the bus operating modes for the DMA.

Bits 31:18 Reserved, must be kept at reset value.

Bits 17:16 INTM[1:0] : Interrupt Mode

This field defines the interrupt mode of the Ethernet peripheral.

The behavior of the interrupt signal and of the RI/TI bits in the ETH_DMACSR register changes depending on the INTM value (refer to Table 557: Transfer complete interrupt behavior ).

Bit 15 Reserved, must be kept at reset value.

Bits 14:12 PR[2:0] : Priority ratio

These bits control the priority ratio in weighted round-robin arbitration between the Rx DMA and Tx DMA. These bits are valid only when the DA bit is reset. The priority ratio is Rx:Tx or Tx:Rx depending on whether the TXPR bit is reset or set.

000: The priority ratio is 1:1

001: The priority ratio is 2:1

010: The priority ratio is 3:1

011: The priority ratio is 4:1

100: The priority ratio is 5:1

101: The priority ratio is 6:1

110: The priority ratio is 7:1

111: The priority ratio is 8:1

Bit 11 TXPR : Transmit priority

When set, this bit indicates that the Tx DMA has higher priority than the Rx DMA during arbitration for the system-side bus.

Bits 10:2 Reserved, must be kept at reset value.

Bit 1 DA : DMA Tx or Rx Arbitration Scheme

This bit specifies the arbitration scheme between the Transmit and Receive paths of all channels:

0: Weighted Round-Robin with Rx:Tx or Tx:Rx

The priority between the paths is according to the priority specified in Bits[14:12] and the priority weight is specified in the TXPR bit.

1: Fixed priority

The Tx path has priority over the Rx path when the TXPR bit is set. Otherwise, the Rx path has priority over the Tx path.

Bit 0 SWR : Software Reset

When this bit is set, the MAC and the DMA controller reset the logic and all internal registers of the DMA, MTL, and MAC. This bit is automatically cleared after the reset operation is complete in all clock domains. Before reprogramming any register, a value of zero should be read in this bit.

Note: The reset operation is complete only when all resets in all active clock domains are deasserted. Therefore, it is essential that all PHY inputs clocks (applicable for the selected PHY interface) are present for software reset completion. The time to complete the software reset operation depends on the frequency of the slowest active clock.

System bus mode register (ETH_DMASBMR)

Address offset: 0x1004

Reset value: 0x0000 0000

The System bus mode register controls the behavior of the AHB master. It mainly controls burst splitting and number of outstanding requests.

Bits 31:16 Reserved, must be kept at reset value.

Bit 15 RB: Rebuild INCRx Burst

When this bit is set high and the AHB master gets SPLIT, RETRY, or Early Burst Termination (EBT) response, the AHB master interface rebuilds the pending beats of any initiated burst transfer with INCRx and SINGLE transfers. By default, the AHB master interface rebuilds pending beats of an EBT with an unspecified (INCR) burst.

Bit 14 MB: Mixed Burst

When this bit is set high and the FB bit is low, the AHB master performs undefined bursts transfers (INCR) for burst length of 16 or more. For burst length of 16 or less, the AHB master performs fixed burst transfers (INCRx and SINGLE).

Bit 13 Reserved, must be kept at reset value.

Bit 12 AAL: Address-Aligned Beats

When this bit is set to 1, the master performs address-aligned burst transfers on Read and Write channels.

Bits 11:1 Reserved, must be kept at reset value.

Bit 0 FB: Fixed Burst Length

When this bit is set to 1, the AHB master will initiate burst transfers of specified length (INCRx or SINGLE).

When this bit is set to 0, the AHB master will initiate transfers of unspecified length (INCR) or SINGLE transfers.

Interrupt status register (ETH_DMAISR)

Address offset: 0x1008

Reset value: 0x0000 0000

The application reads this Interrupt Status register during interrupt service routine or polling to determine the interrupt status of DMA channels, MTL queues, and the MAC.

Bits 31:18 Reserved, must be kept at reset value.

Bit 17 MACIS: MAC Interrupt Status

This bit indicates an interrupt event in the MAC. To reset this bit to 1'b0, the software must read the corresponding register in the MAC to get the exact cause of the interrupt and clear its source.

Bit 16 MTLIS: MTL Interrupt Status

This bit indicates an interrupt event in the MTL. To reset this bit to 1'b0, the software must read the corresponding register in the MTL to get the exact cause of the interrupt and clear its source.

Bits 15:1 Reserved, must be kept at reset value.

Bit 0 DC0IS: DMA Channel Interrupt Status

This bit indicates an interrupt event in DMA Channel. To reset this bit to 0, the software must read the corresponding register in DMA Channel to get the exact cause of the interrupt and clear its source.

Debug status register (ETH_DMADSR)

Address offset: 0x100C

Reset value: 0x0000 0000

The Debug status register gives the Receive and Transmit process status for DMA Channel for debugging purpose.

Bits 31:16 Reserved, must be kept at reset value.

Bits 15:12 TPS0[3:0] : DMA Channel Transmit Process State

This field indicates the Tx DMA FSM state for Channel:

• 000: Stopped (Reset or Stop Transmit Command issued)
• 001: Running (Fetching Tx Transfer Descriptor)
• 010: Running (Waiting for status)
• 011: Running (Reading Data from system memory buffer and queuing it to the Tx buffer (Tx FIFO))
• 100: Timestamp write state
• 101: Reserved for future use
• 110: Suspended (Tx Descriptor Unavailable or Tx Buffer Underflow)
• 111: Running (Closing Tx Descriptor)

The MSB of this field always returns 0. This field does not generate an interrupt.

Bits 11:8 RPS0[3:0] : DMA Channel Receive Process State

This field indicates the Rx DMA FSM state for Channel:

• 000: Stopped (Reset or Stop Receive Command issued)
• 001: Running (Fetching Rx Transfer Descriptor)
• 010: Reserved for future use
• 011: Running (Waiting for Rx packet)
• 100: Suspended (Rx Descriptor Unavailable)
• 101: Running (Closing the Rx Descriptor)
• 110: Timestamp write state
• 111: Running (Transferring the received packet data from the Rx buffer to the system memory)

The MSB of this field always returns 0. This field does not generate an interrupt.

Bits 7:1 Reserved, must be kept at reset value.

Bit 0 AXWHSTS : AHB Master Write Channel

When high, this bit indicates that the write channel of the AHB master FSMs are in non-idle state.

Channel control register (ETH_DMACCR)

Address offset: 0x1100

Reset value: 0x0000 0000

The DMA Channel control register specifies the MSS value for segmentation, length to skip between two descriptors, and also the features such as header splitting and 8xPBL mode.

Bits 31:21 Reserved, must be kept at reset value.

Bits 20:18 DSL[2:0] : Descriptor Skip Length

This bit specifies the 32-bit word number to skip between two unchained descriptors. The address skipping starts from the end of the current descriptor to the start of the next descriptor.

When the DSL value is equal to zero, the DMA takes the descriptor table as contiguous.

Bit 17 Reserved, must be kept at reset value.

Bit 16 PBLX8 : 8xPBL mode

When this bit is set, the PBL value programmed in Bits[21:16] in Channel transmit control register (ETH_DMACTXCR) is multiplied eight times. Therefore, the DMA transfers the data in 8, 16, 32, 64, 128, and 256 beats depending on the PBL value.

Bits 15:14 Reserved, must be kept at reset value.

Bits 13:0 MSS[13:0] : Maximum Segment Size

This field specifies the maximum segment size that should be used while segmenting the packet. This field is valid only if the TSE bit of Channel transmit control register (ETH_DMACTXCR) is set.

The value programmed in this field must be more than the configured Data width in bytes. It is recommended to use a MSS value of 64 bytes or more.

Channel transmit control register (ETH_DMACTXCR)

Address offset: 0x1104

Reset value: 0x0000 0000

The DMA Channel Transmit Control register controls the Tx features such as PBL, TCP segmentation, and Tx Channel weights.

Bits 31:22 Reserved, must be kept at reset value.

Bits 21:16 TXPBL[5:0] : Transmit Programmable Burst Length

These bits indicate the maximum number of beats to be transferred in one DMA data transfer. This is the maximum value that is used in a single block Read or Write. The DMA always attempts to burst as specified in PBL each time it starts a burst transfer on the application bus. You can program PBL with any of the following values: 1, 2, 4, 8, 16, or 32. Any other value results in undefined behavior.

To transfer more than 32 beats, perform the following steps:

1. Set the PBLx8 mode in ETH_DMACCR.
2. Set the TXPBL[5:0].

Note: The maximum value of TXPBL must be less than or equal to half the Tx Queue size (TQS field of Tx queue operating mode Register (ETH_MTLTXQOMR) ) in terms of beats. This is required so that the Tx Queue has space to store at least another Tx PBL worth of data while the MTL Tx Queue Controller is transferring data to MAC. The total locations in Tx Queue of size 2048 bytes is 512, TXPBL and 8xPBL needs to be programmed to less than or equal to 512/2.

Bits 15:13 Reserved, must be kept at reset value.

Bit 12 TSE : TCP Segmentation Enabled

When this bit is set, the DMA performs the TCP segmentation for packets in Channel x. The TCP segmentation is done only for those packets for which the TSE bit (TDES0[19]) is set in the Tx Normal descriptor. When this bit is set, the TxPBL value must be greater than or equal to 4.

Bits 11:5 Reserved, must be kept at reset value.

Bit 4 OSF : Operate on Second Packet

When this bit is set, it instructs the DMA to process the second packet of the Transmit data even before the status for the first packet is obtained.

Bits 3:1 Reserved, must be kept at reset value.

Bit 0 ST : Start or Stop Transmission Command

When this bit is set, transmission is placed in the Running state. The DMA checks the Transmit list at the current position for a packet to be transmitted.

The DMA tries to acquire descriptor from either of the following positions:

• – The current position in the list: this is the base address of the Transmit list set by the ETH_DMACTXDLAR register.
• – The position at which the transmission was previously stopped

If the DMA does not own the current descriptor, the transmission enters the Suspended state and the TBU bit of the ETH_DMACSR is set. The Start Transmission command is effective only when the transmission is stopped. If the command is issued before setting the ETH_DMACTXDLAR register, the DMA behavior is unpredictable.

When this bit is reset, the transmission process is placed in the Stopped state after completing the transmission of the current packet. The Next Descriptor position in the Transmit list is saved, and it becomes the current position when the transmission is restarted. To change the list address, you need to program ETH_DMACTXDLAR register with a new value when this bit is reset. The new value is considered when this bit is set again. The stop transmission command is effective only when the transmission of the current packet is complete or the transmission is in the Suspended state.

Channel receive control register (ETH_DMACRXCR)

Address offset: 0x1108

Reset value: 0x0000 0000

The DMA Channel Receive Control register controls the Rx features such as PBL, buffer size, and extended status.

Bit 31 RPF: DMA Rx Channel Packet Flush

When this bit is set to 1, the Ethernet peripheral automatically flushes the packet from the Rx queues destined to DMA Rx Channel when the DMA Rx Channel is stopped after a system bus error has occurred. When this bit remains set and the DMA is re-started by the software driver, the packets residing in the Rx Queues that were received when this RxDMA was stopped, are flushed out. The packets that are received by the MAC after the RxDMA is re-started are routed to the RxDMA. The flushing happens on the Read side of the Rx queue. When this bit is set to 0 the Ethernet peripheral does not flush the packet in the Rx queue destined to DMA Rx Channel after the DMA is stopped due to a system bus error. This might cause head-of-line blocking in the corresponding RxQueue.

Note: The stopping of packet flow from a Rx DMA Channel to the application by setting RPF works only when there is one-to-one mapping of Rx Queue to Rx DMA channels. In Dynamic mapping mode, setting RPF bit in ETH_DMACRXCR register might flush packets from unintended Rx Queues which are destined to the stopped Rx DMA Channel.

Bits 30:22 Reserved, must be kept at reset value.

Bits 21:16 RXPBL[5:0]: Receive Programmable Burst Length

These bits indicate the maximum number of beats to be transferred in one DMA data transfer. This is the maximum value that is used in a single block Read or Write. The DMA always attempts to burst as specified in PBL each time it starts a burst transfer on the application bus. You can program PBL with any of the following values: 1, 2, 4, 8, 16, or 32. Any other value results in undefined behavior.

To transfer more than 32 beats, perform the following steps:

1. Set the PBLx8 mode in the ETH_DMACCCR.
2. Set the RXPBL[5:0].

Note: The maximum value of RXPBL must be less than or equal to half the Rx Queue size (RQS field of Rx queue operating mode register (ETH_MTLRXQOMR)) in terms of beats. This is required so that the Rx Queue has space to store at least another Rx PBL worth of data while the MTL Rx Queue Controller is transferring data to MAC. The total locations in Rx Queue of size 2048 bytes is 512, RXPBL and 8xPBL needs to be programmed to less than or equal to 512/2.

Bit 15 Reserved, must be kept at reset value.

Bits 14:1 RBSZ[13:0] : Receive Buffer size

This field indicates the size of the Rx buffers specified in bytes. The maximum buffer size is limited to 16 Kbytes.

Note: The buffer size must be a multiple of 4. This is required even if the value of buffer address pointer is not aligned to bus width. If the buffer size is not a multiple of 4, it may result into an undefined behavior.

The LSB bits (1:0) are ignored and the DMA internally takes the LSB bits as all-zero. Therefore, these LSB bits are read-only (RO).

Bit 0 SR : Start or Stop Receive

When this bit is set, the DMA tries to acquire the descriptor from the Receive list and processes the incoming packets.

The DMA tries to acquire descriptor from either of the following positions:

• – The current position in the list: this is the address set by the Channel Rx descriptor list address register (ETH_DMOCRXDLAR) .
• – The position at which the Rx process was previously stopped

If the DMA does not own the current descriptor, the reception is suspended and the RBU bit of the ETH_DMACSR is set. The Start Receive command is effective only when the reception is stopped. If the command is issued before setting the Channel Rx descriptor list address register (ETH_DMOCRXDLAR) , the DMA behavior is unpredictable.

When this bit is reset, the Rx DMA operation is stopped after the transfer of the current packet. The next descriptor position in the Receive list is saved, and it becomes the current position after the Rx process is restarted. The Stop Receive command is effective only when the Rx process is in the Running (waiting for Rx packet) or Suspended state.

Address offset: 0x1114

Reset value: 0x0000 0000

Channel Tx Descriptor List Address register points the DMA to the start of Transmit descriptor list. The descriptor lists reside in the physical memory space of the application and must be word-aligned. The DMA internally converts it to bus width aligned address by making the corresponding LSB to low.

You can write to this register only when the Tx DMA has stopped, that is, the ST bit is set to zero in ETH_DMACTXCR register. When stopped, this register can be written with a new descriptor list address. When you set ST bit to 1, the DMA takes the newly-programmed descriptor base address. If this register is not changed when ST bit is set to 0, the DMA takes the descriptor address where it was stopped earlier.

Bits 31:0 TDESLA[31:0] : Start of Transmit List

This field contains the base address of the first descriptor in the Transmit descriptor list. The DMA ignores the LSB bits (1:0) for 32-bit bus width and internally takes these bits as all-zero. Therefore, these LSB bits are read-only (RO).

Channel Rx descriptor list address register (ETH_DMACRXDLAR)

Address offset: 0x111C

Reset value: 0x0000 0000

The Channel Rx Descriptor List Address register points the DMA to the start of Receive descriptor list.

This register points to the start of the Receive Descriptor List. The descriptor lists reside in the physical memory space of the application and must be word-aligned. The DMA internally converts it to bus width aligned address by making the corresponding LS bits low. Writing to this register is permitted only when reception is stopped. When stopped, this register must be written to before the receive Start command is given. You can write to this register only when Rx DMA has stopped, that is, SR bit is set to zero in ETH_DMACRXCR register. When stopped, this register can be written with a new descriptor list address.

When you set the SR bit to 1, the DMA takes the newly programmed descriptor base address.

Bits 31:0 RDESLA[31:0] : Start of Receive List

This field contains the base address of the first descriptor in the Rx Descriptor list. The DMA ignores the LSB bits (1:0) for 32-bit bus width and internally takes these bits as all-zero. Therefore, these LSB bits are read-only (RO).

Channel Tx descriptor tail pointer register (ETH_DMACTXDTPR)

Address offset: 0x1120

Reset value: 0x0000 0000

The Channel Tx Descriptor Tail Pointer register points to an offset from the base and indicates the location of the last valid descriptor.

Bits 31:0 TDT[31:0] : Transmit Descriptor Tail Pointer

This field contains the tail pointer for the Tx descriptor ring. The software writes the tail pointer to add more descriptors to the Tx channel. The hardware tries to transmit all packets referenced by the descriptors between the head and the tail pointer registers.

Channel Rx descriptor tail pointer register (ETH_DMACRXDTPR)

Address offset: 0x1128

Reset value: 0x0000 0000

The Channel Rx Descriptor Tail Pointer Points to an offset from the base and indicates the location of the last valid descriptor.

Bits 31:0 RDT[31:0] : Receive Descriptor Tail Pointer

This field contains the tail pointer for the Rx descriptor ring. The software writes the tail pointer to add more descriptors to the Rx channel. The hardware tries to write all received packets to the descriptors referenced between the head and the tail pointer registers.

Channel Tx descriptor ring length register (ETH_DMACTXRLR)

Address offset: 0x112C

Reset value: 0x0000 0000

The Tx Descriptor Ring Length register contains the length of the Transmit descriptor ring.

Bits 31:10 Reserved, must be kept at reset value.

Bits 9:0 TDRL[9:0] : Transmit Descriptor Ring Length

This field sets the maximum number of Tx descriptors in the circular descriptor ring. The maximum number of descriptors is limited to 1K descriptors. It is recommended to put a minimum ring descriptor length of 4.

For example, you can program any value up to 0x3FF in this field. This field is 10 bits wide, if you program 0x3FF, you can have 1024 descriptors. If you want to have 10 descriptors, program it to a value of 0x9.

Address offset: 0x1130

Reset value: 0x0000 0000

The Channel Rx Descriptor Ring Length register contains the length of the Receive descriptor circular ring.

Bits 31:24 Reserved, must be kept at reset value.

Bits 23:16 ARBS[7:0] : Alternate Receive Buffer Size

Indicates size in bytes for Buffer 1 when ARBS[7:0] is programmed to a non-zero value.

When ARBS[7:0] = 0, Rx Buffer1 and Rx Buffer2 sizes are based on RBSZ[13:0] field of Channel receive control register (ETH_DMACRXCR) .

Bits 15:10 Reserved, must be kept at reset value.

Bits 9:0 RDRL[9:0] : Receive Descriptor Ring Length

This register sets the maximum number of Rx descriptors in the circular descriptor ring. The maximum number of descriptors is limited to 1K descriptors.

For example, you can program any value up to 0x3FF in this field. This field is 10-bit wide. If you program 0x3FF, you can have 1024 descriptors. If you want to have 10 descriptors, program it to a value of 0x9.

Address offset: 0x1134

Reset value: 0x0000 0000

The Channel Interrupt Enable register enables the interrupts reported by the Status register.