4.4. MAC Packet Flow

The MAC frameworks implement a robust packet handling scheme to coordinate flow of Tx and Rx packets between the PHY cores, CPU Low, CPU High, and Ethernet interfaces.

The figure below illustrates the CPUs, peripherals, and interconnects in the FPGA Design which facilitate Tx/Rx packet flow through the MAC. Refer to the FPGA Design page for a more complete description of the hardware design.

Fig. 4.28 Hardware design for Tx/Rx packet flow

Packet Buffers

As illustrated above the MAC software in both CPUs has read/write access to dedicated Tx/Rx packet buffers. The packet buffers are implemented in on-chip FPGA BRAM blocks. The current FPGA design implements 16 Tx packet buffers and 8 Rx packet buffers. Each packet buffer is 4KB.

Packet Buffer Contents

Each 4KB packet buffer is used to store packet payloads and related metadata. The MAC can store arbitrary metadata in each packet buffer before the actual packet bytes. Any metadata must be stored before the packet payload. The PHY must be configured with the size of the metadata so it knows where to read (Tx) and write (Rx) packet payloads. This configuration is handled at boot by the MAC framework.

The MAC framework defines two C structs, tx_frame_info_t and rx_frame_info_t, to store the metadata for Tx and Rx packets. One instance of the metadata struct is stored at the base of each Tx and Rx packet buffer. The CPUs use the frame_info fields to set, store, and communicate per-packet parameters.

The PHY cores are configured to ignore the frame_info structs by setting the “PHY Header Offset” parameter in each PHY. The PHY Header Offset defines the address offset of the first non-metadata byte in each packet buffer. Only the MAC software accesses the frame_info bytes. The PHY cores read/write packet buffer contents starting at the PHY Header Offset.

The MAC software defines PHY_RX_PKT_BUF_PHY_HDR_OFFSET as sizeof(rx_frame_info_t). Similarly, PHY_TX_PKT_BUF_PHY_HDR_OFFSET is defined as sizeof(tx_frame_info_t). These PHY_HDR_OFFSET macros are then used to configure the PHY cores at boot.

The tx_frame_info_t and rx_frame_info_t structs are defined in wlan_mac_pkt_buf_util.h. The frame_info fields can change with each release of the reference design as we add new MAC and PHY features. Refer to the source code for the current struct definitions.

Tx Packet Buffer States

Fig. 4.29 Transmit packet buffer state transitions example

The tx_frame_info_t struct has a tx_pkt_buf_state field used by the upper and lower MAC designs to coordinate access to the packet buffer contents. There are four possible states for a Tx packet buffer:

• UNINITIALIZED: the default state following a reconfiguration of the FPGA. The MAC code never sets a buffer to this state.
• HIGH_CTRL: the buffer is under control of CPU High. The MAC code in CPU Low must not read or write the buffer.
• LOW_CTRL: the buffer is under control of CPU Low and the Rx PHY. The MAC code in CPU High must not read or write the buffer.
• READY: the buffer contains a packet that is ready to be transmitted by the lower MAC and Tx PHY.
• DONE: the buffer contains a packet that has already been transmitted by the lower MAC and Tx PHY.

Each packet buffer transitions between these states in a fixed sequence. Each state transition is implemented by one CPU. These state transitions are carefully desinged to ensure consistency between MAC software states in CPU High and Low, even if one CPU is reset at runtime (i.e. such as reloading a CPU’s program via the SDK debugger).

CPU High:

• HIGH_CTRL → READY: after successful dequeue, immediately before sending TX_PKT_BUF_READY message to CPU Low
• DONE → HIGH_CTRL: after receiving TX_PKT_BUF_DONE message

CPU Low:

• READY → LOW_CTRL: after receipt of TX_PKT_BUF_READY message by CPU Low
• LOW_CTRL → DONE: after return of MAC frame_transmit(), before sending TX_PKT_BUF_DONE message

This architecture is effectively a pipelined ping/pong scheme. Only two packet buffers are ever in the READY and/or LOW_CTRL states, minimizing disruption to the queue priorities implemented in CPU High. CPU High is allowed to dequeue a new packet into a HIGH_CTRL buffer before it runs post-Tx processing on the latest DONE buffer, minimizing the duration where CPU Low might be waiting for a new packet to transmit while CPU High is busy processing previous transmissions.

The figure to the right illustrates the sequence of state transitions and IPC messages for the preparation, transmission, and post-Tx handling of 2 packets.

Rx Packet Buffer States

The rx_frame_info_t struct has a rx_pkt_buf_state field used by the upper and lower MAC designs to coordinate access to the packet buffer contents. There are four possible states for an Rx packet buffer:

• UNINITIALIZED: the default state following a reconfiguration of the FPGA. The MAC code never sets a buffer to this state.
• HIGH_CTRL: the buffer is under control of CPU High. The MAC code in CPU Low must not read or write the buffer.
• LOW_CTRL: the buffer is under control of CPU Low and the Rx PHY. The MAC code in CPU High must not read or write the buffer.
• READY: the buffer contains a packet that has been processed by the lower MAC and is ready for further processing by the upper MAC. CPU Low must send a RX_PKT_BUF_READY message to CPU High after setting an Rx buffer to this state.

Following at-boot initialization, there are 3 valid state transitions for Rx packet buffers. Each transition is only implemented by one CPU.

CPU High:

• READY → HIGH_CTRL: CPU High takes ownership of an Rx buffer after receiving the RX_PKT_BUF_READY message from CPU Low
• HIGH_CTRL → LOW_CTRL: CPU High finishes processing a reception and returns the buffer to control of CPU Low for use by a future reception

CPU Low:

• LOW_CTRL → READY: CPU Low releases ownership of an Rx buffer after completing processing of a new reception, immediately before sending the RX_PKT_BUF_READY message to CPU High

Tx Packet Flow

The flow of Tx packets is illustrated below.

Fig. 4.30 Transmit packet flow

All wireless transmissions follow this packet flow:

1. Packet payload is received or created by MAC

   1. Ethernet: packet is received from Ethernet MAC into DRAM, then encapsulated for wireless transmission
   2. Management: the MAC code creates a management packet for transmission (e.g. Probes, Beacons, etc)
   3. Application: the MAC application creates a packet for transmission (e.g. LTG)

2. MAC application examines new packet contents (type, addresses, etc.). Packets are either enqueued for transmission or discarded.

   1. Packets destined to an associated node are added to queue assigned to destination node
   2. Management packets are added to the dedicated management queue
   3. Multicast packets are added to the dedicated multicast queue
   4. Packets with unrecognized types or addresses are discarded

3. When the upper MAC is notified a Tx packet buffer is available, the upper MAC dequeues the next packet into the Tx packet buffer and notifies the lower MAC via the mailbox

4. The lower MAC transmits the packet according to the MAC protocol, then notifies the upper MAC upon completion

Rx Packet Flow

The flow of Rx packets is illustrated below.

Fig. 4.31 Receive packet flow

All wireless receptions follow this packet flow:

1. Rx PHY receives new packet into an empty Rx packet buffer

2. The lower MAC examines the new packet

   1. If configured for non-promiscuous mode the drops packets with unrecognized types or addresses
   2. Otherwise the lower MAC notifies the upper MAC via the mailbox

3. The upper MAC examines the new packet type and addresses.

   1. Data packets with recognized addresses are de-encapsulated and submitted to the Ethernet DMA for transmission over-the-wire
   2. Management packets are processed by the upper MAC (e.g. Probe Request triggers Probe Response)
   3. The upper MAC can also convert the received packet into a new packet for wireless transmission (e.g. AP re-transmitting multicast packet from STA)