Changes between Version 5 and Version 6 of 802.11/Usage/UserIO

Timestamp:

Aug 18, 2016, 11:46:28 AM (8 years ago)

Author:

murphpo

Comment:

--

802.11/Usage/UserIO

@@ -35 +35 @@
 
 
-== Debug Header Signals ==
-The 802.11 Reference Design routes various internal MAC/PHY signals to the 16-pin debug header on the WARP v3 node. These signals allow monitoring of MAC/PHY state at run time using an oscilloscope or logic analyzer. The current pin assignments are listed below. These may change between releases, depending on what we're debugging at the time.
+== Debug Header ==
+The WARP v3 hardware provides a 16-pin debug header tied directly to 16 FPGA IO pins. The 802.11 Reference Design uses the debug header for real time monitoring of internal MAC and PHY state. These signals can be observed with an oscilloscope or logic analyzer.
 
-You can confirm the current pin assignments by looking at the {{{PORT debughdr = ...}}} line in the system.mhs file.
+Starting in release v1.5.3 the 802.11 Reference Design uses the updated '''w3_userio''' core to manage the 16-pin debug header on the WARP v3 hardware. The w3_userio core's debug header logic supports runtime selection of hardware or software control of each debug pin.
 
-Refer to the [wiki:HardwareUsersGuides/WARPv3/DebugHeader WARP v3 user guide] for the numbering of pins on the header.
+When a pin is configured for '''hardware control''' the debug pin is driven directly by design-specific logic in the FPGA. See the table below for the list of MAC/PHY signals tied to the hardware-controlled outputs.
 
-'''Pin Map for design v1.5:'''
+When a pin is configured for '''software control''' the debug pin can be used as an output whose state is controlled from C code or as an input whose state is readable by C code. The control source (hardware vs software) and direction (input vs output for software-controlled pins) are configured by C code using the w3_userio driver.
+
+'''Important Update:''' As of v1.5.3 both CPUs can access the software-controlled debug I/O via the single w3_userio core. The state of a debug output is stored in the w3_userio core. Either CPU can set or unset each software-controlled output at any time. This is a changed from previous releases where the software-controlled outputs were driven by an OR of values written by each CPU.
+
+By default the 802.11 Reference Design configures:
+ * Pins '''15, 14, 13, 12''': software-controlled outputs, used for real-time debug and characterization of C code in CPU High or Low
+ * Pins '''11 to 0''': hardware-controlled outputs, tied to various MAC and PHY status signals (see below)
+
+The 802.11 Reference Design hardware project routes 16 MAC/PHY status signals to the w3_userio debug port. By default (see above) only 12 of these hardware status signals are routed to the debug header, reserving the top 4 pins for software-controlled I/O. The table below lists all 16 status signals. To access the status signals on pins '''15, 14, 13, 12'''  the corresponding pins must be re-configured as hardware-controlled outputs in the C code.
+
+'''Hardware debug signals design release v1.5.3:'''
+||=  Pin  =||=  Signal Description  =||
+||  0  ||'''Tx PHY Active''': asserts when the Tx PHY begins transmitting a frame and de-asserts after the last sample is transmitted ||
+||  1  ||'''OFDM Rx PHY Active''': asserts when the first FFT is started and de-asserts when the Rx PHY completes processing ||
+||  2  ||'''DSSS Rx PHY Active''': asserts when the DSSS receiver is processing a frame ||
+||  3  ||'''OFDM Packet Detect''': asserts when the OFDM Rx PHY attempts a reception. A packet detection event does not always result in an Rx PHY active event ||
+||  4  ||'''DSSS Packet Detect''': asserts when the DSSS Rx PHY attempts a reception. A packet detection event does not always result in an Rx PHY active event ||
+||  5  ||'''LTS Timeout''': asserts briefly when the Rx PHY fails to correlate the preamble LTS following a packet detection event ||
+||  6  ||'''FCS Good''': asserts briefly after the PHY writes the last byte of a received frame to the packet buffer and the checksum calculation indicates no errors ||
+||  7  ||'''RSSI Det''': asserts when the instantaneous RSSI exceeds a programmed threshold (debug only - does not indicate actual PHY state) ||
+||  8  ||'''Tx A Pending''': asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller A by the MAC software, de-asserts when the Tx PHY completes the transmission ||
+||  9  ||'''Idle for DIFS''': asserted whenever the MAC observes the medium has been idle longer than  DIFS interval ||
+||  10  ||'''Backoff A Active''': asserted whenever the backoff counter for Tx Controller A is non-zero, indicating the MAC hardware will defer a transmission ||
+||  11  ||'''NAV Active''': asserted whenever the MAC is enforcing backoff due to virtual carrier sense after reception of a frame with a valid duration field ||
+||  12  ||'''Tx B Pending''': asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller B by the MAC software, de-asserts when the Tx PHY completes the transmission ||
+||  13  ||'''Backoff C Active''': asserted whenever the backoff counter for Tx Controller C is non-zero, indicating the MAC hardware will defer a transmission ||
+||  14  ||'''Tx C Pending''': asserted by the MAC hardware when a new Tx MPDU is submitted to Tx Controller C by the MAC software, de-asserts when the Tx PHY completes the transmission ||
+||  15  ||'''EIFS Sel''': asserted whenever the MAC is using the EIFS interval instead of DIFS, required when the most recent medium busy event is a reception with bad FCS ||
+
+----
+
+The tables below list the debug header pin map for previous releases of the 802.11 Reference Design.
+
+'''Pin Map for design v1.5.0 - v1.5.2:'''
 ||=  Pin  =||=  In/Out  =||=  Signal Description  =||
 ||  0  ||  Out  || '''Tx PHY Active''': asserts when the Tx PHY begins transmitting a frame and de-asserts after the last sample is transmitted ||