WARP Project Forums - Wireless Open-Access Research Platform

What JTAG programming cable are you using to connect to the board? Are you able to scan and identify the board in iMPACT?

1) There is a linker script provided in the 'w3_OFDM_ReferenceDesign_v18p1\SDK_Workspace\CSMAMAC\src' directory.  You should use those defaults.  Older versions of the the Xilinx tools used to be more sensitive to linker scripts and it was best to regenerate them.  You can still do that but take a look at where everything should go from the provided default.

2) Have you restarted the SDK and tried to program again.  We have occasionally seen that the SDK will get stuck and not be able to find the programming cable.  Usually, I try:  1) unplug the USB programmer from both the computer and WARP board;  if that doesn't work 2) Restart the SDK; if that doesn't work 3) restart the computer.

3) When you ran promgen, where did you run it from?  To run promgen, you need to select:  "Xilinx Tools" --> "Launch Shell".  Then you cd to your *_hw_platform directory and you should be able to run the promgen command.

A couple of things you can try before upgrading the Xilinx tools: 

1) Are you able to program any other reference designs (ie WARPLab or the 802.11 reference design)?  First check that you can program the reference bitstreams using iMPact.   Then try with the SDK. 
2) Check the "Xilinx Tools" --> "Configure JTAG Settings".  I have them set to Type: "Auto Detect" and "Automatically Discover Devices on JTAG Chain".

If you still can't get it to work.  I would go ahead and upgrade to either 14.4 or 14.7.  At least then you will have a clean install.

The OFDM Reference Design uses the DIP switches on the boards to effectively set wireless MAC address. Furthermore, it is hardcoded so that "node 0" sends to "node 1" and vice versa. If your hex displays are showing "01" and "11", then the boards will not talk to one another. They need to show "00" and "01" as described here. You can make these changes by making sure all the DIP switches in the User I/O (left side of WARP v3) are down on one board and the rightmost bit is up on the other.

If you are just getting started and have WARP v3, I suggest moving over to the Mango 802.11 Reference Design. This design is much better than the OFDM Reference Design, and does away with things like the above DIP switch / MAC address stuff.

If you are using the older OFDM Reference Design, then really your only option is to use something like iperf on both of your PCs to measure throughput. That's only going to give you a very coarse measurement of throughput.

If you are using the new 802.11 Reference Design, you can also use iperf, but even better is to use the WLAN Experiments python framework. The design logs all transmissions and receptions into DRAM to allow very fine-grained processing. Using it, it's pretty easy to throughput at any time scale. Check out the Tx/Rx Log Capture and Tx/Rx Log Analysis examples.

The code base for 802.11 is certainly much larger and more sophisticated than the OFDM Reference Design. That said, if you want to do non-standards-compliant MAC behaviors, it would be pretty straightforward. Like the OFDM Reference Design, these would be pure C-only changes.

With knowledge of the OFDM Reference Design, you are well equipped to take on the 802.11 Reference Design. There are a lot of structural similarities. WARPMAC in the OFDM Reference Design is similar to the MAC High Framework in the 802.11 Reference Design. WARPPHY in the OFDM Reference Design is similar to the MAC Low Framework in the 802.11 Reference Design. The most fundamental difference between the two designs is the dual-processor architecture. In the OFDM Reference Design, your top-level code was responsible for everything. In the 802.11 Reference Design, we've drawn a line between time-critical intra-packet behaviors like retransmissions and ACK transmissions and higher inter-packet behaviors like transmission queues, packet encapsulation, and traffic generation. With this architecture, high-level behaviors like association handshakes cannot adversely impact the node's ability to meet the strict timing requirements specified in the DCF of the 802.11 standard. Some more details about this split is here.

The top-level C code you were writing in the OFDM Reference Design is probably most similar to the top-level Access Point and Station projects. In these projects, you could define new non-standards-compliant packet types for your cognitive MAC and define the behaviors that occur when those packets are received or sent.

If you don't want to be modifying two files (AP + STA), another option is ad hoc (also known as IBSS). IBSS is most similar to the OFDM Reference Design -- every node on the network runs the same bitstream. The IBSS code is already in the public SVN, but we haven't zipped up an official release with it yet. We hope to have the v0.96 release with IBSS posted this week.