Changes between Version 19 and Version 20 of 802.11/PacketFlow


Ignore:
Timestamp:
Apr 15, 2016, 2:39:27 PM (8 years ago)
Author:
murphpo
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 802.11/PacketFlow

    v19 v20  
    1414
    1515The MicroBlaze DC (cached memory access port) for both CPUs are attached to a shared AXI4 interconnect. The data cache is disabled in the Reference Design; all memory access via the DC ports access a slave memory device via the AXI4 interconnect. Both CPU DC ports are masters on this interconnect. The primary slave devices on this interconnect are the block RAMs used to implement the packet buffers (discussed below). Both CPUs can read and write any location in both memories. The AXI4 interconnect is a 64-bit crossbar clocked at 160MHz, which provides sufficient throughput to avoid contention between the CPUs.
    16 
    17 == Packet Buffers ==
    18 
    19 The 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.
    20 
    21 The 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.
    2216
    2317== Tx Packet Flow ==
     
    4539 * '''Wireless Tx''': as explained above, some MAC applications may re-transmit received packets via the wireless interface
    4640
     41= Packet Buffers =
     42
     43The 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.
     44
     45The 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.
     46
    4747== Packet Buffer Contents ==
    4848
     
    6464{{{PHY_TX_PKT_BUF_PHY_HDR_OFFSET}}} is defined as {{{sizeof(tx_frame_info_t)}}}. 
    6565
    66 When 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.
     66When MAC code accesses the packet buffers 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.
    6767
    68 The {{{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.
     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]. The {{{frame_info}}} fields 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.
    6969
    70 == Tx Ping-Pong Scheme ==
     70
     71== Tx Packet Buffer States ==
    7172The 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.
    7273
     
    8081
    8182The upper-level MAC framework calls an application-specific callback function upon receipt of the {{{IPC_MBOX_TX_MPDU_DONE}}} message. The MAC application can use this callback to manage internal state, create log entries, update statistics, etc.
     83
     84== Rx Packet Buffer States ==
     85The {{{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:
     86 * {{{UNINITIALIZED}}}: the default state following a reconfiguration of the FPGA. The MAC code never sets a buffer to this state.
     87 * {{{HIGH_CTRL}}}: the buffer is under control of CPU High. The MAC code in CPU Low must not read or write the buffer.
     88 * {{{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.
     89 * {{{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_MPDU_READY}}} message to CPU High after setting an Rx buffer to this state.
     90
     91Following at-boot initialization, there are 3 valid state transitions for Rx packet buffers:
     92 * {{{LOW_CTRL → READY}}}: CPU Low releases ownership of an Rx buffer after completing processing of a new reception, immediately before sending the {{{RX_MPDU_READY}}} message to CPU High
     93 * {{{READY → HIGH_CTRL}}}: CPU High takes ownership of an Rx buffer after receiving the {{{RX_MPDU_READY}}} message from CPU Low
     94 * {{{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
     95
     96