Version 8 (modified by murphpo, 6 years ago) (diff)


MAC Support Core

The software implementation of the lower-level MAC in CPU Low operates in real time. A key requirement of the lower-level MAC is to monitor the medium and react to Tx and Rx events on precise time boundaries relative to medium events. In order to simplify the MAC software implementation we use a small core in the FPGA. This core implements various timers and simple state machines which facilitate real-time operation of the lower-level MAC.

The MAC support core is not a fixed DCF implementation. All behaviors in the MAC core are defined by software. The primitives implemented in the core enable our DCF implementation, but the same primitives can be used for a wide variety of specialized MAC protocols.

The core is named wlan_mac_hw and is designed in System Generator. The source model is in the repository at /ReferenceDesigns/w3_802.11/sysgen/wlan_mac_hw.

A few of the key subsystems in the wlan_mac_hw core are described in detail below.

Post Tx/Rx Timers

Many MAC algorithms require precise scheduling of transmissions relative to some preceding transmission or reception event. Examples in the DCF include the following:

  • ACK and CTS transmissions must occur a SIFS period after previous qualified receptions
  • Contention windows must begin a timeout interval after a previous unsuccessful transmission

The wlan_mac_hw core implements dedicated post Tx/Rx timers. There are 4 times total, 2 each for post-Tx and post-Rx. The timers start automatically following Tx/Rx event. The timer durations are programmed from software in CPU Low. When a timer expires it can trigger Tx events via the Tx Controllers described below.

The MAC Low Framework provides macros for configuring the 4 timers and checking whether a timer is currently running:

// Set the "count to" value for the post Tx/Rx timers
//  Argument d is in units of 100nsec

// Enable/Disable post Tx/Rx timers
//  Argument x should be 0 (disable) or 1 (enable)
//  A timer only runs if it is enabled and has a non-zero "count to" value

// Check if a post Tx/Rx timer is running
wlan_mac_get_tx_ctrl_status() & WLAN_MAC_TXCTRL_STATUS_MASK_POSTTX_TIMER1_RUNNING;
wlan_mac_get_tx_ctrl_status() & WLAN_MAC_TXCTRL_STATUS_MASK_POSTTX_TIMER2_RUNNING;
wlan_mac_get_tx_ctrl_status() & WLAN_MAC_TXCTRL_STATUS_MASK_POSTRX_TIMER1_RUNNING;
wlan_mac_get_tx_ctrl_status() & WLAN_MAC_TXCTRL_STATUS_MASK_POSTRX_TIMER2_RUNNING;

The reference DCF implementation uses two timers:

  • postTx_timer2: timeout timer, indicates timeout following RTS and DATA transmissions
  • postRx_timer1: SIFS timer, triggers CTS/DATA/ACK Tx following RTS/CTS/DATA receptions

MAC Core Tx Controllers

A key function of the lower MAC is implementing the MAC protocol's transmit state machines. The MAC protocol defines when packets can be transmitted. For example the DCF requires an ACK transmission a SIFS interval after receiving a DATA packet. The DCF also requires a random backoff period before an RTS or DATA transmission if the medium was recently busy. The wlan_mac_hw core implements 3 transmit state machines to facilitate these various protocol requirements. The 3 Tx controllers differ in their state machine inputs/outputs, each tailored to a different MAC protocol task. Each controller is configured from software.

MAC Tx Controller A

Tx Controller A is capable of honoring a post-Tx timeout interval in which a reception is expected by the MAC state.

The DCF implementation uses Tx Controller A for three transmission scenarios:

  1. Transmission of MPDU frames which do not require RTS ("short" frames)
  2. Transmission of RTS frames
  3. Transmission of "long" MPDU frames following reception of a CTS

Implementation Details

The Tx Controller A state machine is illustrated below. Each box is a state. Each arrow is a state transition, with the arrow's label specifying the input conditions that trigger the transition. The conditions for the color-coded arrows from the IDLE state are listed in the pseudo-code blocks to the right.

No image "tx_core_a.png" attached to 802.11/MAC/Support_HW

Notice that the state transitions depend on the postRx_Timer1 (SIFS timer) and postTxTimer2 (timeout timer), as discussed above.

The Tx Controller A state machine depends on various input signals. These inputs are either parameters set by the MAC software or signals driven by other parts of the MAC support core.

Inputs from software:

  • reset: Forces FSM back to IDLE state
  • new_tx: Triggers new execution of FSM
  • pre_wait_postRxTimer1: Wait for postRx_Timer1 before transmitting
  • pre_wait_postTxTimer1: Wait for postTx_Timer1 before transmitting
  • post_wait_postTxTimer2: Wait for postTx_Timer2 after transmitting

Inputs from MAC hardware:

  • postRxTimer1_done: postRx_Timer1 has expired
  • postTxTimer1_done: postTx_Timer1 has expired
  • postTxTimer2_done: postTx_Timer2 has expired
  • backoff_done: The backoff counter has reached zero
  • idle_for_difs: The medium has been idle for a DIFS interval
  • phy_tx_done: The Tx PHY has finished transmitting
  • phy_rx_start: The Rx PHY has detected a new reception

The lower MAC framework provides macros for configuring the software parameters above:

// Configure Tx Controller A
//  pktBuf: Tx packet buffer index (passed directly to PHY at TX_START)
//  antMask: antenna selection mask  (passed directly to PHY at TX_START)
//  preTx_backoff_slots: number of backoff slots (passed to backoff counter in START_BO state)
//  preWait_postRxTimer1: param for FSM, must be 0 or 1
//  preWait_postTxTimer1: param for FSM, must be 0 or 1
//  postWait_postTxTimer2: param for FSM, must be 0 or 1
wlan_mac_tx_ctrl_A_params(pktBuf, antMask, preTx_backoff_slots, preWait_postRxTimer1, preWait_postTxTimer1, postWait_postTxTimer2);

The Tx Controller A state machine is started by toggling its enable bit in the MAC support core's register bank:

// Start Tx Controller A

MAC Tx Controller B

The Tx Controller B is simpler than Tx Controller A. After a transmission is complete, the controller is done and does not need to start any kind of post-Tx timeout interval. Optionally, Tx Controller B can condition its transmission on medium idleness. The DCF implementation uses this controller for two purposes:

  1. Transmission of CTS frames
  2. Transmission of ACK frames

Both of the above transmissions have the common trait of being "fire and forget." They are slightly different from one another in that ACK frames must be transmitted regardless of perceived medium busyness. This is not the case for CTS frames, which are only sent when the medium is deemed idle.

Implementation Details

No image "tx_core_b.png" attached to 802.11/MAC/Support_HW

Like Tx Controller A, the green section of the above state machine forces the controller to wait for a deterministic amount of time prior to a transmission. The DCF uses this to schedule CTS and ACK transmissions a SIFS interval after the previous reception. The CTS case additionally instructs the controller to condition transmission on medium idleness.

Attachments (7)

Download all attachments as: .zip