Changes between Version 18 and Version 19 of 802.11/PacketFlow


Ignore:
Timestamp:
Apr 15, 2016, 11:14:40 AM (8 years ago)
Author:
murphpo
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • 802.11/PacketFlow

    v18 v19  
    1717== Packet Buffers ==
    1818
    19 The 802.11 Reference Design uses two dual-port 32KB RAMs as Tx and Rx packet buffers. One port of each RAM is attached to a BRAM interface controller (axi_bram_ctrl), which maps the RAM onto the address space of the two CPUs. The other port of each RAM is attached directly to the corresponding PHY core. These direct PHY connections do not traverse an AXI interconnect. Instead both PHY cores (Tx and Rx) implement native 64-bit BRAM interfaces in logic.
     19The 802.11 Reference Design uses two dual-port 32KB on-chip RAMs as Tx and Rx packet buffers. One port of each RAM is attached to a BRAM interface controller (axi_bram_ctrl), which maps the RAM onto the address space of the two CPUs. The other port of each RAM is attached directly to the corresponding PHY core. These direct PHY connections do not traverse an AXI interconnect. The Tx and Rx PHY cores implement native 64-bit BRAM interfaces in logic.
    2020
    21 The PHY cores divide each 32KB BRAM into 8 4KB buffers. The PHY numbers these buffers ![0:7]. The low-level MAC code provides the packet buffer index to the PHY for each Tx and Rx event.
     21The PHY cores divide each 32KB BRAM into 8 4KB buffers. Each 4KB buffer is referred to as a "packet buffer" in the MAC source code. The MAC and PHY number these buffers ![0:7]. Each packet buffer has a fixed memory address which can be computed using the {{{TX_PKT_BUF_TO_ADDR(x)}}} and {{{RX_PKT_BUF_TO_ADDR(x)}}} macros. The packet buffers are accessible by both MicroBlaze CPUs and the central DMA (axi_cmda) controller. The Rx packet buffers are also accesible to the DMA controller (axi_dma) for the ETH A Ethernet interface.
    2222
    2323== Tx Packet Flow ==
    2424
    25 The flow of packets leading to wireless transmissions are illustrated below. All wireless transmissions pass through the upper-level MAC framework's [wiki:../MAC/Upper/MACHighFramework/TX_queue Tx queuing system]. The framework individually dequeues packets and copies them to a PHY packet buffer for processing and transmission by the lower-level MAC.
     25The flow of packets leading to wireless transmissions is illustrated below. All wireless data transmissions pass through the upper-level MAC framework's [wiki:../MAC/Upper/MACHighFramework/TX_queue Tx queuing system]. The framework individually dequeues packets and copies them to a Tx packet buffer for processing and transmission by the lower-level MAC.
    2626
    2727[[Image(wiki:802.11/files:wlan_tx_pkt_flow.png)]]
    … …  
    2929There are three sources of transmit packets in the 802.11 Reference Design:
    3030 * '''Ethernet Rx''': data packets received on the ETH A interface may be [wiki:../MAC/Upper/MACHighFramework/EthEncap encapsulated] and enqueued for transmission if the address and packet types match filters implemented in the upper-level MAC code.
    31  * '''Local''': the upper-level MAC application can generate traffic internally. This includes management frames (beacons, probe request/response, etc) and arbitrary traffic generated by the framework's [wiki:../MAC/Upper/MACHighFramework/LTG LTG system].
     31 * '''Local''': the upper-level MAC application can generate traffic internally. This includes management frames (probe request/response, etc) and arbitrary traffic generated by the framework's [wiki:../MAC/Upper/MACHighFramework/LTG LTG system].
    3232 * '''Wireless Rx''': packets received from the wireless interface can be enqueued for transmission. This path is used by the AP to relay packets from one associated STA to another.
     33
     34Wireless transmissions may also originate in CPU Low. For the DCF MAC, control packets (RTS, CTS, ACK) and beacon packets are transmitted directly by the lower MAC without passing through CPU High's queuing framework.
    3335
    3436== Rx Packet Flow ==
    3537
    36 The flow of packets received wirelessly is illustrated below. All wireless receptions are written to a receive packet buffer by the PHY. The lower-level MAC evaluates the received packet and may pass it up to the upper-level MAC for additional processing.
     38The flow of packets received wirelessly is illustrated below. All wireless receptions are written to an Rx packet buffer by the Rx PHY. The lower-level MAC evaluates the received packet and may pass it up to the upper-level MAC for additional processing.
    3739
    3840[[Image(wiki:802.11/files:wlan_rx_pkt_flow.png)]]
    … …  
    4547== Packet Buffer Contents ==
    4648
    47 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. The PHY must be configured with the size of the metadata so it knows where to read (Tx) and write (Rx) packet payloads. This is done from [browser:/ReferenceDesigns/w3_802.11/c/wlan_mac_low_framework/wlan_mac_low.c wlan_mac_low.c]:
     49Each 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 in [browser:/ReferenceDesigns/w3_802.11/c/wlan_mac_low_framework/wlan_mac_low.c wlan_mac_low.c]:
     50
     51The reference MAC code 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 a 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.
     52
     53The PHY cores are configured to ignore the {{{frame_info}}} structs by setting "PHY Header Offset". In this context the "PHY Header" represents the first byte of the Tx or Rx packet buffer that is access by the PHY hardware.
    4854
    4955{{{
    … …  
    5561}}}
    5662
    57 The {{{PHY_RX_PKT_BUF_PHY_HDR_OFFSET}}} constant is defined as {{{sizeof(rx_frame_info)}}}.  Similarly,
    58 {{{PHY_TX_PKT_BUF_PHY_HDR_OFFSET}}} is defined as {{{sizeof(tx_frame_info)}}}. 
     63The {{{PHY_RX_PKT_BUF_PHY_HDR_OFFSET}}} constant is defined as {{{sizeof(rx_frame_info_t)}}}.  Similarly,
     64{{{PHY_TX_PKT_BUF_PHY_HDR_OFFSET}}} is defined as {{{sizeof(tx_frame_info_t)}}}. 
    5965
    60 When using the packet buffers in CPU High, it is also necessary to know where the MPDU starts.  In order to determine where the MPDU starts within the packet buffer, the constants {{{PHY_RX_PKT_BUF_MPDU_OFFSET}}} and {{{PHY_TX_PKT_BUF_MPDU_OFFSET}}} must be used.  These include the PHY_HDR_OFFSET plus the PHY_HDR_SIZE (which is 8 for both the TX and RX PHY).
     66When using the packet buffers in CPU High, it is also necessary to know where the MAC payload (referred to as the MPDU) starts.  In order to determine where the MPDU starts within the packet buffer, the constants {{{PHY_RX_PKT_BUF_MPDU_OFFSET}}} and {{{PHY_TX_PKT_BUF_MPDU_OFFSET}}} must be used.  These include the PHY_HDR_OFFSET plus the PHY_HDR_SIZE.
    6167
    62 The Tx and Rx packet buffer contents for the reference design are described below.
     68The {{{tx_frame_info_t}}} and {{{rx_frame_info_t}}} structs are defined in [browser:/ReferenceDesigns/w3_802.11/c/wlan_mac_common/include/wlan_mac_pkt_buf_util.h wlan_mac_pkt_buf_util.h]. Refer to the source code for the current struct definitions.
    6369
    64 '''Tx Pkt Buffers'''
    65 The struct definitions for {{{tx_frame_info}}} are below. These structs are defined in [browser:/ReferenceDesigns/w3_802.11/c/wlan_mac_common/include/wlan_mac_misc_util.h wlan_mac_misc_util.h].
    66 
    67 {{{
    68 #!c
    69 typedef struct{
    70         u8      rate;                   ///< PHY rate index
    71         u8      antenna_mode;   ///< Tx antenna selection
    72         s8      power;                  ///< Tx power (in dBm)
    73         u8              flags;                  ///< Flags affecting waveform construction
    74 } phy_tx_params; //4 bytes
    75 
    76 typedef struct{
    77         u8              num_tx_max;             ///< Maximum number of transmission attempts
    78         u8              flags;                  ///< Flags affecting waveform construction
    79         u8              reserved[2];
    80 } mac_tx_params; //4 bytes
    81 
    82 typedef struct{
    83         phy_tx_params phy; ///< PHY Tx params
    84         mac_tx_params mac; ///< Lower-level MAC Tx params
    85 } tx_params; //8 bytes
    86 
    87 typedef struct{
    88         u64 timestamp_create;   ///< MAC timestamp of packet creation
    89         u32 delay_accept;               ///< Time in microseconds between timestamp_create and packet acceptance by CPU Low
    90         u32 delay_done;                 ///< Time in microseconds between acceptance and transmit completion
    91         u64     unique_seq;                     ///< Unique sequence number for this packet (12 LSB used as 802.11 MAC sequence number)
    92         u8 state;                               ///< Packet buffer state - TX_MPDU_STATE_EMPTY, TX_MPDU_STATE_TX_PENDING or TX_MPDU_STATE_READY
    93         u8 tx_result;                   ///< Result of transmission attempt - TX_MPDU_RESULT_SUCCESS or TX_MPDU_RESULT_FAILURE
    94         u8 QID;                                 ///< Queue ID from which this packet was taken
    95         u8 num_tx;                              ///< Number of actual PHY transmissions of this packet, including all re-transmissions
    96         u8 flags;                               ///< Bit flags en/disabling certain operations by the lower-level MAC
    97         u8 padding1[3];
    98         u16 length;                             ///< Number of bytes in MAC packet, including MAC header and FCS
    99         u16 AID;                                ///< Association ID of the node to which this packet is addressed
    100         u8 padding2[4];
    101         tx_params params;               ///< Additional lower-level MAC and PHY parameters
    102 } tx_frame_info; 48 bytes
    103 }}}
    104 
    105 The MAC must write the packet payload immediately after the {{{tx_frame_info}}}, starting with the SIGNAL field. The lower-level MAC code should use the {{{wlan_phy_set_tx_signal(pkt_buf, rate, length)}}} macro to write the SIGNAL field to the appropriate offset.
    106 
    107 '''Rx Pkt Buffers'''
    108 The struct definition for {{{rx_frame_info}}} are below. This struct is defined in [browser:/ReferenceDesigns/w3_802.11/c/wlan_mac_common/include/wlan_mac_misc_util.h wlan_mac_misc_util.h].
    109 
    110 The {{{channel_est}}} field reserves space for the channel estimates generated by the Rx PHY during reception. The PHY writes the estimates directly to the Rx packet buffer. The offset for writing channel estimates is set via the {{{wlan_phy_rx_pkt_buf_h_est_offset(offset)}}} macro.
    111 
    112 {{{
    113 #!c
    114 typedef struct{
    115         u8 state;                       ///< Packet buffer state - RX_MPDU_STATE_EMPTY, RX_MPDU_STATE_RX_PENDING, RX_MPDU_STATE_FCS_GOOD or RX_MPDU_STATE_FCS_BAD
    116         u8 rate;                        ///< PHY rate index
    117         u16 length;                     ///< Number of bytes in MAC packet, including MAC header and FCS
    118         s8 rx_power;            ///< Rx power, in dBm
    119         u8 rf_gain;                     ///< Gain setting of radio Rx LNA, in [0,1,2]
    120         u8 bb_gain;                     ///< Gain setting of radio Rx VGA, in [0,1,...31]
    121         u8 channel;                     ///< Channel index
    122         u8 flags;                       ///< Bit flags
    123         u8 ant_mode;            ///< Rx antenna selection
    124         u8 reserved[2];
    125         u32 additional_info;///< Field to hold MAC-specific info, such as a pointer to a station_info
    126         u64 timestamp;          ///< MAC timestamp at time of reception
    127         u32 channel_est[64];///< Rx PHY channel estimates
    128 } rx_frame_info;
    129 }}}
    130 
    131 The PHY begins writing received bytes immediately after the {{{rx_frame_info}}}. The received SIGNAL and SERVICE fields are written to the first 5 bytes following the {{{rx_frame_info}}}. The PHY then skips 3 bytes and writes the next received byte (the first byte of the MAC header) to 8 bytes past the rx_frame_info. This convention aligns received payloads to a 64-bit boundary, easing access by the MAC software and DMAs. Generally the MAC software ignores the SIGNAL and SERVICE fields in the Rx packet buffer, instead relying on the rate/length values provided by the MAC core.
    132 
    133 === Tx Ping-Pong Buffers ===
     70== Tx Ping-Pong Scheme ==
    13471The lower-level MAC and PHY process a single Tx packet at any given time. While a packet is being transmitted the upper-level MAC prepares the next packet for transmission. Two buffers from the Tx packet buffer RAM are used for this ping-pong approach.
    13572