Utility IP Cores¶
In addition to the PHY Tx/Rx and MAC IP cores, the 802.11 FPGA design utilizes a number of custom IP cores.
MAC Time Core¶
The 802.11 MAC design relies on two timebases, System Time and MAC Time. The wlan_mac_time_hw core implements the hardware counters which realize these two timebases.
The wlan_mac_time_hw core implements two AXI4-Lite slave interfaces. One interface (S_AXI_H) must be connected to the peripheral interconnect for CPU High; the other (S_AXI_L) must be connected to the peripheral interconnect of CPU Low.
System Time¶
The System Time is a free-running microsecond-resolution counter which resets only at FPGA configuration. The MAC software can rely on System Time as a monotonic time base which always increments at regular microsecond intervals. The System Time logic is clocked by by the AXI slave clock for the CPU High interface (S_AXI_H). This clock may be asynchronous to the PHY sampling clock. The MAC software configures wlan_mac_time_hw core with the actual frequency at boot so the System Time counter increments once per microsecond.
MAC Time¶
The MAC Time logic implements two counters. The first increments on every cycle of the PHY processing clock (typically a multiple of the sampling clock). This counter resets to zero when it reaches a specific limit set by software. The second counter increments every time the first counter resets. The MAC software configures the first counter’s limit to be the number of clock cycles in one microsecond. Thus, the second counter realizes the microsecond-accurate MAC Time, while the first counter acts as a “fractional” MAC Time.
The instantaneous integer and fractional MAC Time signals are connected to the MAC IP Core. The MAC Core captures the current MAC Time on every Tx and Rx event. These captured values are read by the MAC Software and used as the timestamps when logging Tx/Rx activity.
The MAC Time can be set to an arbitrary value by the MAC Software at runtime. The reference STA/IBSS code uses this capability to implement the 802.11 Timing Synchronization Function (TSF). The DCF STA/IBSS code updates the current MAC Time microsecond counter upon receiving a valid beacon.
It is possible that this MAC Time update will result in a non-monotonic MAC Time sequence. The MAC code should use the System Time when it needs a timebase that is guaranteed to never decrement.
AD9361/AD9364 Radio Control¶
The wlan_ad936x_controller core implements the control interface to the ADI AD9361/AD9364 RF transceiver.
SPI Master¶
The wlan_ad936x_controller core implements a custom SPI master subsystem. The SPI master supports transactions initiated from the C code in CPU Low, and real-time transactions initiated by the MAC Tx state machine.
The SPI master software interface implements 1-byte reads (rc_spi_read()) and writes (rc_spi_write()) of any register in the AD9361. The 802.11 Design includes a version of the ADI AD9361 no-os driver which is modified to use these SPI read/write functions.
The wlan_ad936x_controller SPI master also writes registers in real time on every Tx event. These writes are necessary to achieve the fast Rx/Tx switching times required by the 802.11 MAC. The hardware-triggered SPI writes occur automatically in the core - the MAC software does not need to initiate the writes or monitor their status.
Control Signals¶
The wlan_ad936x_controller core also implements interfaces for the dedicated control signals on AD9361, including:
| AD9361 Signal | Description | Use in 802.11 Design |
|---|---|---|
EN_AGC |
Restarts the AGC state machine | Connected to Rx PHY to start AGC following packet detection |
RESETB |
Chip reset | Connected to software register for radio initialization |
CTRL_OUT[7:0] |
Status outputs from radio | Connected to software registers and Rx PHY for monitoring AGC state |
SYNC |
Multi-chip synchronization | Unused |
CTRL_IN[3:0] |
Real-time radio control inputs | Unused |
ENABLE |
Controls Tx/Rx transitions | Unused |
Hardware Platform Controllers¶
Each hardware platform has unique peripheral interfaces. The 802.11 design includes a custom IP core named wlan_hw_controller for each platform which manages these unique interfaces.
User I/O Control¶
The wlan_hw_controller cores implement interfaces to any LEDs, buttons, switches, and debug headers provided by the hardware platform.
The 802.11 MAC software uses LEDs for real-time indication of Tx/Rx activity and node state and uses switches/buttons for runtime configuration of MAC behaviors. The user I/O options vary with hardware platform; refer to the user I/O section of the hardware guide for your platform.
The wlan_hw_controller cores implements two AXI4-Lite slave interfaces. The 802.11 design connects one interface to the peripheral interconnect of each CPU. The two slave interfaces read/write a common set of registers which are mapped to the FPGA pins for user I/O devices on the board.
User Inputs¶
User inputs (buttons, switches) are digitally debounced in the FPGA fabric, then captured in a software-accessible register. The register updates on every clock cycle. Either CPU can read a user input at any time.
The wlan_hw_controller core also implements interrupt generation logic. The core has a single interrupt output which can be connected to an interrupt controller (axi_intc instance) in the FPGA design. The interrupt logic supports masking individual inputs. Interrupt configuration and status is managed via the software interface.
User Outputs¶
User outputs (LEDs, hex displays) are driven from software-controlled registers in the wlan_hw_controller core. The core does not implement a mutex - the MAC software must implement whatever mutual exclusion it needs to coordinate use of the user outputs. By default the 802.11 MAC software allocates each LED to a single CPU. The specific mapping depends on the hardware platform.
Debug Header¶
The wlan_hw_controller core provides utility logic for using a debug header on the FPGA development board. The core supports reading the state of any debug header pin from either CPU.
Each debug pin can be configured as an input or output. When configured as an input either CPU can read the state of the pin at any time. When configured as an output, each pin can be further configured as a hardware-controlled or software-controlled output.
Hardware-controlled outputs are controlled by the corresponding signal in the usr_dbg_hdr_in port of the core. By default the 802.11 FPGA design connects a number of useful MAC/PHY status signals to the usr_dbg_hdr_in port, enabling real-time, unobtrusive monitoring and measurement of MAC/PHY state.
Software-controlled outputs act as standard GPIO signals whose state is set from software. Combined with an oscilloscope, these software-controlled digital outputs are useful for measuring software latencies with minimal impact on performance.