[[TracNav(802.11/TOC)]]

= 802.11 Reference Design: Usage =

By default, the Reference Design implements an 802.11 compatible access point with SSID "WARP". To use the design in this configuration:

1. Plug ETH A from a WARP v3 board into a router whose WAN port is connected to the Internet. The 802.11 Reference Design is not a router -- it does not have a DHCP server to issue IP addresses to associated stations. It will, however, pass DHCP requests and responses through its Ethernet portal, so connecting WARP v3 to a router will allow DHCP to occur on client stations.
1. Download the 802.11 Reference Design and program a WARP v3 board with the provided bitstream.
1. Use any 802.11 device (such as a computer or smartphone) to join the unsecured network with SSID of "WARP." At this point, the 802.11 device should be able to access the network.

== Creating the SDK Workspace ==

1. Ensure your Xilinx tools match the version used to create the reference design (see the [wiki:../Downloads downloads] page for the current versions)
1. Ensure your local copy of the WARP edk_user_repository is up to date and in the repository search path of XPS (see [wiki:edk_user_repository edk_user_repository] for details)
1. Download the 802.11 Reference Design archive and expand the inner .zip archive in {{{<ref_design_archive>/EDK_Projects/w3_802.11_EDK_vXXX.zip}}}.
  * Be sure the expanded EDK project path has no spaces; {{{C:/work/w3_802.11_EDK/}}} works, {{{C:/Documents and Settings/user/w3_802.11_EDK/}}} does not
  * The text below assumes your expanded EDK project is in {{{<xps_proj>/}}}. 
1. Launch Xilinx SDK and select {{{<xps_proj>/SDK_Workspace}}} as the active workspace
1. Select Xilinx Tools -> Repositories. In Local Repositories click New, then select {{{<xps_proj>/}}} and click OK.
1. Import the 5 SDK projects provided by the reference design
  1. Select File -> Import
  1. Expand General -> Existing Projects into Workspace, click Next
  1. Click Browse and navigate to {{{<xps_proj>/SDK_Workspace}}}
  1. Five projects will be listed:
{{{
wlan_bsp_cpu_high
wlan_bsp_cpu_low
wlan_mac_ap
wlan_mac_dcf
wlan_xps_v00_hw_platform  <- the version number in this project name will change between releases
}}}
  1. Ensure all 5 projects are checked and click Finish
  1. In the SDK Project Explorer:
    1. Right click on the {{{wlan_mac_ap}}} project and select Change Referenced BSP. In the dialog box select {{{wlan_bsp_cpu_high}}} then click OK
    1. Right click on the {{{wlan_mac_dcf}}} project and select Change Referenced BSP. In the dialog box select {{{wlan_bsp_cpu_low}}} then click OK
    1. Right click on the {{{wlan_mac_ap}}} project and select Clean Project
    1. Right click on the {{{wlan_mac_dcf}}} project and select Clean Project
1. Both software projects should now build to completion. Watch the console for the message {{{elfcheck passed}}}


== Debugging Software ==

The dual-processor architecture of the 802.11 Reference Design presents some challenges in debugging the software applications.

The usual debugging tools in the Xilinx SDK work fine with dual-processor designs. The Reference Design includes one instance of the mdm pcore. The mdm is connected to both MicroBlaze debug ports. The PC-side debug tools can connect to either MB via the mdm and xmd.

Each MicroBlaze processor has an xps_uartlite peripheral mapped to stdin/stdout. The WARP v3 hardware has only USB-UART transceiver. The Reference Design includes a uart_mux core which allows either xps_uartlite to connect to the USB-UART transceiver. By default the mux is controlled by the LSB of the user DIP switch on the WARP v3 board. A 0 (switch down) selects the UART for CPU Low. 


== Debug Signals ==
The 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. Refer to the [wiki:HardwareUsersGuides/WARPv3/DebugHeader WARP v3 user guide] for the numbering of pins on the header.

||=  Pin  =||=  Signal  =||
||  0  || '''OFDM Rx PHY running''': asserts when the first FFT is started and de-asserts when the Rx PHY completes processing ||
||  1  || '''Rx Packet Detect''': asserts when the Rx PHY attempts a reception. A packet detection event does not always result in an Rx PHY started event ||
||  2  || '''LTS Timeout''': asserts briefly when the Rx PHY fails to correlate the preamble LTS following a packet detection event ||
||  3  || '''Tx Pending''': asserted by the MAC hardware when a new Tx MPDU is provided by the MAC but has not yet been submitted to the Tx PHY ||
||  4  || '''RSSI Det''': asserts when the instantaneous RSSI exceeds a programmed threshold (debug only - does not indicate actual PHY state) ||
||  5  || '''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 ||
||  6  || '''Tx PHY Running''': asserts when the Tx PHY begins transmitting a frame and de-asserts after the last sample is transmitted ||
||  7  || '''DSSS Rx PHY Running''': asserts when the DSSS receiver is processing a frame ||
||  8  || '''NAV Active''': asserted whenever the MAC is enforcing backoff due to virtual carrier sense after reception of a frame with a valid duration field ||
||  9  || '''Idle for DIFS''': asserted whenever the MAC observes the medium has been idle longer than  DIFS interval ||
||  10  || '''EIFS Sel''': asserted when the MAC is enforcing an EIFS interval of idle time ||
||  11  || '''Backoff Active''': asserted whenever the MAC is deferring to a busy medium; the MAC will not transmit when backing off ||
||  12:15  || '''Sw Debug''': General debug outputs controlled by software via a register in the Rx PHY; useful for unobtrusively measuring software execution times ||