FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
All support for Intel NUC 7 - 13 systems has transitioned to ASUS. Read latest update.
6319 Discussions

Clarification of documentation for Align Packet Headers to 32-bit Boundaries option in TS-Ethernet


The Triple Speed Ethernet MAC core (UG-01008, 3/29/2019) has a feature which provides alignment of IP headers on 32-bit boundaries by inserting a 2-byte pad of 0x0000 at the beginning of the packet.  The documentation is unclear on exactly how this works. The description of the feature (enabled with the IP editor) is:

Turn on this option to include logic that aligns all packet
headers to a 32-bit boundary. This helps reduce software
overhead processing in realignment of data buffers.
This option is available for MAC variations with 32 bits wide
internal FIFO buffers and MAC variations without internal FIFO
You must turn on this option if you intend to use the Triple-
Speed Ethernet IP core with the Interniche TCP/IP protocol

The UG also states:

IP Payload Re-alignment
If you turn the Align packet headers to 32-bit boundaries option, the MAC
function removes the additional two bytes from the beginning of Ethernet frames.

What is not indicated here are the following:

  • Does this apply to transmitted packets?
  • Does this apply to received packets?
  • Regarding the second item (IP Payload Re-Alignment), it does not specify if the additional two bytes are removed when the option is enabled, or when the option is disabled.

Also, are there any other compile-time (IP Editor) or run-time (configuration space register) settings that have an effect on this?


Thank you.

0 Kudos
4 Replies

There are also the tx_cmd_stat and rx_cmd_stat registers:


The description for TX_SHIFT16 says "Set this bit if the frames from the user are aligned on a 32-bit boundary."  But the Avalon streaming interface requires the first word of a packet to by a full word (the empty[n-1:0] field is ignored), so it is not clear how the frames could not be aligned on a 32-bit boundary., as the interface is 32 bits wide.


Also, are the TX_SHIFT16 and RX_SHIFT16 bits forced to a specific state by the Align Packet headers to 32-bit boundary option?  The user guide only states what happens if there are no FIFOs in the core.

0 Kudos


This applies to both transmitted and received packets.

Basic Ethernet frame format consists of 7 bytes (preamble), 1 byte (SFD), 6 bytes (Destination Address), 6 bytes (Sources Address), 2 bytes (Length), payload, and so on. The total bytes number before the payload is 22 bytes, in order to make the payload is 32 bits align at the Avalon interface, two bytes has to add before the payload.

For the receiver, MAC adds two-byte zeros at the Avalon ST RX 32 bit interfaces, so that the payload will align to 32 bits boundary.

For the transmitter, the application layer sends the ethernet packet which is payload alignment to the Avalon ST TX 32 bit interfaces, and then MAC removes the additional two bytes (zero) from the beginning of ethernet frames.

From the IP GUI, you have to enable the “Align Packet headers to 32-bit boundary” option, and you can refer to the tx_cmd_stat(bit 18) and rx_cmd_stat(bit 25) command registers to run-time control the payload alignment (if needed) after turn on the “Align packet headers to 32-bit boundaries” option.

Regards -SK 

0 Kudos

Just to add on:


At the Avalon ST interface of TSE IP, the client frame is starting with the destination address (6 bytes), followed by the source address (6 bytes), Type/Length(2 bytes), and then Payload.


Without 32 bits alignment

  • First 32 bits = destination address (6 bytes)  + source address (2 bytes)
  • Second 32 bits = source address(4 bytes) + Type Length (2 bytes) + Payload (2 bytes)


With 32 bits alignment

  • First 32 bits = Zero (2 bytes) + destination address (6 bytes)
  • Second 32 bits = source address (6 bytes) + Type Length (2 bytes)
  • Third 32 bits = payload (8 bytes)

0 Kudos

If further support is needed in this thread, please post a response within 15 days. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.

0 Kudos