Changes between Version 10 and Version 11 of 802.11/PacketFlow


Ignore:
Timestamp:
Oct 14, 2014, 3:27:25 PM (10 years ago)
Author:
murphpo
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • 802.11/PacketFlow

    v10 v11  
    99As packets move through the 802.11 reference design, the packet contents must be accessible by CPU High, CPU Low and the PHY cores. The design achieves this using the interconnects illustrated in the figure blow.
    1010
    11 [[Image(wiki:802.11/files:wlan_ref_des_interconnects.png)]]
     11[[Image(wiki:802.11/files:wlan_ref_des_interconnects.png,width=350)]]
    1212
    1313Each MicroBlaze has access to two AXI interconnects. For both CPUs the MicroBlaze DP port (non-cached peripheral memory access port) is connected to an AXI4 Lite interconnect. The peripheral cores connected to each AXI4 Lite interconnect are accessible by only one CPU. The cores are divided between CPUs based on which part of the MAC needs to access them. For example the radio_controller, w3_ad_controller and PHY configuration registers are all attached to the interconnect for CPU Low. Similarly the Ethernet cores are attached to the peripheral bus for CPU High. The mailbox and mutex ports for each CPU are also attached to their corresponding peripheral busses.
    … …  
    1717== Packet Buffers ==
    1818
    19 The 802.11 Reference Design uses two dual-port 64KB 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 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.
    2020
    21 The PHY cores divide each 64KB BRAM into 16 4KB buffers. The PHY numbers these buffers ![0:15]; 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. 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.
    2222
    2323=== Packet Buffer Contents ===
    2424
    25 Each packet buffer stores more than just the raw Tx/Rx bytes for the PHY. The MAC uses each buffer to store other metadata. The contents of each packet buffer are shown in the below table:
     25Each 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]:
    2626
    27 || ||= TX Packet Buffer =||= RX Packet Buffer =||
    28 || frame_info ||  32 bytes  ||  272 bytes  ||
    29 || PHY Header ||  8 bytes  ||  8 bytes  ||
    30 || MAC Header||  24 bytes  ||  24 bytes  ||
    31 || Payload ||  [0 to 1980] bytes  ||  [0 to 1740] bytes  ||
    32 || FCS ||  4 bytes  ||  4 bytes  ||
     27{{{
     28#!c
     29//Move the PHY's starting address into the packet buffers by PHY_XX_PKT_BUF_PHY_HDR_OFFSET.
     30//This accounts for the metadata located at the front of every packet buffer (Xx_mpdu_info)
     31wlan_phy_rx_pkt_buf_phy_hdr_offset(PHY_RX_PKT_BUF_PHY_HDR_OFFSET);
     32wlan_phy_tx_pkt_buf_phy_hdr_offset(PHY_TX_PKT_BUF_PHY_HDR_OFFSET);
     33}}}
    3334
    34 The MAC code utilizes the first section of each packet buffer for metadata about the packet contained in that buffer. This metadata is stored in the {{{tx_frame_info}}} and {{{rx_frame_info}}} structs, defined in [source:ReferenceDesigns/w3_802.11/c/wlan_mac_common/include/wlan_mac_misc_util.h wlan_mac_misc_util.h]. This metadata includes the per-subcarrier channel estimates from the RX PHY.
     35The {{{PHY_RX_PKT_BUF_PHY_HDR_OFFSET}}} constat is defined as {{{PHY_TX_PKT_BUF_PHY_HDR_SIZE + PHY_RX_PKT_BUF_PHY_HDR_OFFSET}}}, where {{{PHY_RX_PKT_BUF_PHY_HDR_SIZE}}} is 8 (for the PHY header) and {{{PHY_TX_PKT_BUF_PHY_HDR_SIZE}}} is {{{sizeof(rx_frame_info)}}}.
    3536
    36 The second section is the PHY header. For Tx packets the MAC must populate this section with a valid SIGNAL field. When a new transmission is initiated the Tx PHY will read these bytes first to determine the modulation/coding rates and payload length. The Tx PHY will terminate immediately if the SIGNAL bytes are invalid. For Rx packets the PHY will write the raw SIGNAL field bytes to the PHY header area. This is useful for debugging; for normal Rx processing the MAC will be notified of the Rx length and rate via registers in the DCF MAC core.
     37Similarly {{{PHY_TX_PKT_BUF_PHY_HDR_OFFSET}}} is defined as {{{PHY_TX_PKT_BUF_PHY_HDR_SIZE + PHY_TX_PKT_BUF_PHY_HDR_OFFSET}}}.
    3738
    38 The final section of each packet buffer is the packet payload (a.k.a. the MPDU, for data frames, MMPDU for management frames). The Rx PHY does not interpret these bytes in any way. The MAC code must ensure this section of the packet buffer contains a valid MAC header and corresponding payload.
     39The Tx and Rx packet buffer contents for the reference design are described below.
     40
     41'''Tx Pkt Buffers'''
     42The 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].
     43
     44{{{
     45#!c
     46typedef struct{
     47        u8      rate;                   ///< PHY rate index
     48        u8      antenna_mode;   ///< Tx antenna selection
     49        s8      power;                  ///< Tx power (in dBm)
     50        u8              flags;                  ///< Flags affecting waveform construction
     51} phy_tx_params; //4 bytes
     52
     53typedef struct{
     54        u8              num_tx_max;             ///< Maximum number of transmission attempts
     55        u8              flags;                  ///< Flags affecting waveform construction
     56        u8              reserved[2];
     57} mac_tx_params; //4 bytes
     58
     59typedef struct{
     60        phy_tx_params phy; ///< PHY Tx params
     61        mac_tx_params mac; ///< Lower-level MAC Tx params
     62} tx_params; //8 bytes
     63
     64typedef struct{
     65        u64 timestamp_create;   ///< MAC timestamp of packet creation
     66        u32 delay_accept;               ///< Time in microseconds between timestamp_create and packet acceptance by CPU Low
     67        u32 delay_done;                 ///< Time in microseconds between acceptance and transmit completion
     68        u64     unique_seq;                     ///< Unique sequence number for this packet (12 LSB used as 802.11 MAC sequence number)
     69        u8 state;                               ///< Packet buffer state - TX_MPDU_STATE_EMPTY, TX_MPDU_STATE_TX_PENDING or TX_MPDU_STATE_READY
     70        u8 tx_result;                   ///< Result of transmission attempt - TX_MPDU_RESULT_SUCCESS or TX_MPDU_RESULT_FAILURE
     71        u8 QID;                                 ///< Queue ID from which this packet was taken
     72        u8 num_tx;                              ///< Number of actual PHY transmissions of this packet, including all re-transmissions
     73        u8 flags;                               ///< Bit flags en/disabling certain operations by the lower-level MAC
     74        u8 padding1[3];
     75        u16 length;                             ///< Number of bytes in MAC packet, including MAC header and FCS
     76        u16 AID;                                ///< Association ID of the node to which this packet is addressed
     77        u8 padding2[4];
     78        tx_params params;               ///< Additional lower-level MAC and PHY parameters
     79} tx_frame_info; 48 bytes
     80}}}
     81
     82The 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.
     83
     84'''Rx Pkt Buffers'''
     85The 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].
     86
     87The {{{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.
     88
     89{{{
     90#!c
     91typedef struct{
     92        u8 state;
     93        u8 rate;
     94        u16 length;
     95        s8 rx_power;
     96        u8 rf_gain;
     97        u8 bb_gain;
     98        u8 channel;
     99        u8 flags;
     100        u8 ant_mode;
     101        u8 reserved[2];
     102        u32 additional_info;
     103        u64 timestamp;
     104        u32 channel_est[64];
     105} rx_frame_info; //280 bytes (24 bytes for scalar fields + 256 bytes for channel estimates)
     106}}}
     107
     108The 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.
    39109
    40110=== Checksums ===
    … …  
    46116The Rx PHY automatically calculates the checksum of every received frame and provides an FCS_GOOD indication to the MAC hardware core immediately upon reception of the final byte of a packet. The received FCS bytes are written to the Rx packet buffer; these can be safely ignored by the MAC code.
    47117
     118=== Tx Ping-Pong Buffers ===
     119The 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.
     120
     121The handshake between the upper and lower level MACs to initiate new packet transmissions is illustrated below. The handshake uses three IPC messages:
     122 * {{{IPC_MBOX_TX_MPDU_READY(pkt_buf_index)}}}: indication from CPU High that the packet in {{{pkt_buf_index}}} is ready for transmission
     123 * {{{IPC_MBOX_TX_MPDU_ACCEPT(pkt_buf_index}}}: indication from CPU Low that the packet in {{{pkt_buf_index}}} is currently being transmitted by the lower-level MAC and PHY. This message always follows the corresponding {{{IPC_MBOX_TX_MPDU_READY}}}
     124 * {{{IPC_MBOX_TX_MPDU_DONE(pkt_buf_index)}}}: indication from CPU Low that transmission of the packet in {{{pkt_buf_index}}} is complete.
     125
     126It is critical that CPU High not modify the contents of any packet buffer for which it has sent {{{IPC_MBOX_TX_MPDU_READY}}} until it receives the corresponding {{{IPC_MBOX_TX_MPDU_DONE}}} message. Likewise CPU Low must only modify packet buffers for which it as received {{{IPC_MBOX_TX_MPDU_READY}}}, and before it sends {{{IPC_MBOX_TX_MPDU_DONE}}}.
     127
     128[[Image(wiki:802.11/files:wlan_tx_ping_pong_msgs.png)]]
     129
    48130=== Mutexes ===
    49131