Changes between Version 5 and Version 6 of 802.11/MAC/Support_HW


Ignore:
Timestamp:
Jun 19, 2015, 2:15:28 PM (9 years ago)
Author:
chunter
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • 802.11/MAC/Support_HW

    v5 v6  
    11[[TracNav(802.11/TOC)]]
    22
    3 = MAC Config Hardware =
     3= MAC Support Core =
    44
    5 In addition to the state implemented in the CPU_LOW processor, certain time critical MAC behaviors are implemented directly in the FPGA fabric via the MAC Config Hardware core. This core was designed to meet the needs of the DCF implementation of 802.11 while still remaining flexible for custom applications. There are three basic components to the peripheral: Timers, MAC CFG Tx Core A, MAC CFG Tx Core B.
     5In addition to the state implemented in the CPU_LOW processor, certain time critical MAC behaviors are implemented directly in the FPGA fabric via the MAC Support Core. This core was designed to meet the needs of the DCF implementation of 802.11 while still remaining flexible for custom applications. There are three basic components to the peripheral: Timers, MAC Tx Controller A, MAC Tx Controller B.
    66
    77== Timers ==
    … …  
    19191.  '''postTxTimer2'''
    2020
    21 These timers each independently begin after the prior transmission or reception. They count until a user-specified interval of time has elapsed and then assert an output to the MAC CFG Tx Core A and MAC CFG Tx Core B subsystems. In the stock DCF implementation of the Mango 802.11 Reference Design, only '''postTxTimer2''' and '''postRxTimer1''' are used. Their durations are set to a ACK timeout and a SIFS respectively. One future straightforward extension to the design would be to use '''postTxTimer1''' to enable the "burst" transmission capabilities introduced in the 802.11e amendment where each transmission is separated by a deterministic SIFS or RIFS interval.
     21These timers each independently begin after the prior transmission or reception. They count until a user-specified interval of time has elapsed and then assert an output to the MAC Tx Controller A and MAC Tx Controller B subsystems. In the stock DCF implementation of the Mango 802.11 Reference Design, only '''postTxTimer2''' and '''postRxTimer1''' are used. Their durations are set to a ACK timeout and a SIFS respectively. One future straightforward extension to the design would be to use '''postTxTimer1''' to enable the "burst" transmission capabilities introduced in the 802.11e amendment where each transmission is separated by a deterministic SIFS or RIFS interval.
    2222
    23 == MAC CFG Tx Core A ==
     23== MAC Tx Controller A ==
    2424
    25 Tx Core A is capable of honoring a post-Tx timeout interval in which a reception is expected by the MAC state. The DCF implementation uses this core for three different purposes:
     25Tx 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 this controller for three different purposes:
    2626
    27271. Transmission of "short" MPDU frames (i.e. MPDUs that required no RTS medium reservation)
    … …  
    3535[[Image(tx_core_a.png, width=1000)]]
    3636
    37 The above image gives a more detailed view on the state machine implemented in Tx Core A. Prior to actually transmitting, the core is capable of starting a backoff or deferring to an already running backoff when the medium is not idle. Alternatively, it can wait for a deterministic interval before transmitting. This interval is defined by either the '''postRxTimer1''' or '''postTxTimer1''' timers described above.
     37The above image gives a more detailed view on the state machine implemented in Tx Controller A. Prior to actually transmitting, the controller is capable of starting a backoff or deferring to an already running backoff when the medium is not idle. Alternatively, it can wait for a deterministic interval before transmitting. This interval is defined by either the '''postRxTimer1''' or '''postTxTimer1''' timers described above.
    3838
    3939For the DCF implementation, short MPDU and RTS transmissions do not employ the green deterministic-wait state. These transmission do employ the purple and blue backoff deferral states. Long MPDU transmissions, however, must occur a deterministic SIFS interval after the previous CTS reception. As such, these transmissions use the green deterministic-wait states.
    4040
    41 == MAC CFG Tx Core B ==
     41== MAC Tx Controller B ==
    4242
    43 The Tx Core B is simpler than Tx Core A. After a transmission is complete, the core is done and does not need to start any kind of post-Tx timeout interval. Optionally, Tx Core B can condition its transmission on medium idleness. The DCF implementation uses this core for two purposes:
     43The 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:
    4444
    45451. Transmission of CTS frames
    … …  
    5252[[Image(tx_core_b.png, width=1000)]]
    5353
    54 Like Tx Core A, the green section of the above state machine forces the core 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 core to condition transmission on medium idleness.
     54Like 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.