wiki:802.11/MAC/Support_HW

Version 12 (modified by murphpo, 8 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
wlan_mac_set_postTx_timer1(d);
wlan_mac_set_postTx_timer2(d);
wlan_mac_set_postRx_timer1(d);
wlan_mac_set_postRx_timer2(d);

// 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
wlan_mac_postTx_timer1_en(x);
wlan_mac_postTx_timer2_en(x);
wlan_mac_postRx_timer1_en(x);
wlan_mac_postRx_timer2_en(x);

// 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 during which the MAC expects an immediate response to its transmission. 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 described in the table below.

Tx Controller A FSM - Transitions from IDLE

if(new_tx) {

    if(wait_for_postRxTimer1 | wait_for_postTxTimer1) {
        //Tx fixed interval after previous Tx/Rx
        // Ignore medium and backoff states
        st_next = ST_PRE_TX_WAIT;

    } else if(backoff_A_done & idle_for_difs) {
        //Previous backoff already finished, medium idle
        // Transmit immediately
        st_next = ST_DO_TX;

    } else if(!backoff_A_done) {
        //Backoff already running - use it to defer
        st_next = ST_DEFER; 

    } else if(backoff_A_done & !idle_for_difs) {
        //No backoff running, but medium is busy
        // Start new backoff
        st_next = ST_START_BO;
    }
} else {
    //No new Tx this cycle; keep waiting in IDLE
    st_next = ST_IDLE;
}

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_A_done: The A 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
wlan_mac_tx_ctrl_A_start(1);
wlan_mac_tx_ctrl_A_start(0);

The Tx Controller A state machine is implemented as an m-code block in the wlan_mac_hw core. The m source code is in the repository at mac_tx_ctrl_a_fsm.m

MAC Tx Controller B

Tx Controller B is a simpler state machine that can schedule its transmission relative to post Tx/Rx timers. The reference DCF implementation uses Tx Controller B for two transmissions:

  1. Transmission of CTS frames a SIFS after an RTS Rx
  2. Transmission of ACK frames a SIFS after a DATA Rx

This controller is unique in being able to cancel its transmission based on the node's NAV value. This behavior is required when transmitting a CTS frame. When the DCF receives an RTS it schedules a CTS transmission a SIFS interval later. However if the NAV is non-zero at the end of the SIFS, the CTS frame is not transmitted.

Implementation Details

The Tx Controller B 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 described in the table below.

Tx Controller B FSM - Transitions from IDLE

if(new_tx) {

    if(pre_wait_for_postRxTimer1 | pre_wait_for_postRxTimer2 | pre_wait_for_postTxTimer1 ) {
        //Tx fixed interval after previous Tx/Rx
        // Ignore medium and backoff states
        st_next = ST_PRE_TX_WAIT;

    } else {
        // Transmit immediately
        st_next = ST_DO_TX;
} else {
    //No new Tx this cycle; keep waiting in IDLE
    st_next = ST_IDLE;
}

Notice that the state transitions depend on the postRx_Timer1 (SIFS timer). The state machine can also be conditioned on postRx_Timer2 and postTx_Timer1 for other MAC protocol extensions.

Inputs from software:

  • reset: Forces FSM back to IDLE state
  • new_tx: Triggers new execution of FSM
  • req_nav_zero: Require NAV be zero at time of Tx, cancel Tx otherwise
  • pre_wait_for_postRxTimer1: Wait before Tx until postRx Timer 1 is done
  • pre_wait_for_postRxTimer2: Wait before Tx until postRx Timer 2 is done
  • pre_wait_for_postTxTimer1: Wait before Tx until postTx Timer 1 is done

Inputs from MAC hardware:

  • nav_nonzero: NAV is nonzero
  • postRxTimer1_done: postRx Timer 1 is done
  • postRxTimer2_done: postRx Timer 2 is done
  • postTxTimer1_done: postTx Timer 1 is done
  • phy_tx_done: PHY Tx has completed

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

// Configure Tx Controller B
//  pktBuf: Tx packet buffer index (passed directly to PHY at TX_START)
//  antMask: antenna selection mask  (passed directly to PHY at TX_START)
//  req_zeroNAV: require NAV=0 at Tx time, must be 0 or 1
//  preWait_postRxTimer1: param for FSM, must be 0 or 1
//  preWait_postRxTimer2: param for FSM, must be 0 or 1
//  preWait_postTxTimer1: param for FSM, must be 0 or 1
wlan_mac_tx_ctrl_B_params(pktBuf, antMask, req_zeroNAV, preWait_postRxTimer1, preWait_postRxTimer2, preWait_postTxTimer1);

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

// Start Tx Controller B
wlan_mac_tx_ctrl_B_start(1);
wlan_mac_tx_ctrl_B_start(0);

The Tx Controller B state machine is implemented as an m-code block in the wlan_mac_hw core. The m source code is in the repository at mac_tx_ctrl_b_fsm.m

Attachments (7)

Download all attachments as: .zip