WARP Project Forums - Wireless Open-Access Research Platform

I'm not sure, you will need to dig in an try to see how much time you expect each operation to take.

Just remember, that, for WARPv3, this code is running on an single threaded processor running at 160 MHz and does not use interrupts.  This means that the processor executes 160 clock cycles per microsecond, which can do a lot but you have to take that into account when you are thinking about timing.  Also, the fact that the processor is single threaded and does not use interrupts means that everything is executed serially.  If you poll for a register to change, the processor doesn't do anything else until that poll completes.  In a fully polled system, like the OFDM reference design, you should always just do the minimum amount to check that something needs to be done and not block the processor execution until that something needs to be done (ie use a loop to wait on a condition).

warpmac_carrierSense() should be fast. It's just a single register read (see source). Each of the steps you have listed above can be characterized to figure out exactly how much time each is taking. You'll need to perform that characterization to narrow down what is going on. One option would be to use the "warpmac_setDebugGPIO()" function and explicitly measure the duration of each step using an oscilloscope probing the debug pins of the board. Another option is to instantiate a timer core and explicitly timestamp the moments in between those steps and then print them out. Either of those two approaches will help you figure out which step is taking the most time.

If you look in the XPS project, you can see that the OFDM reference design uses an XPS timer.  Therefore, it is easy to find the timer documentation to see how to read the current value of the timer.

To help debug, you should first start by having both PCs on a common switch (ie take the wireless link out of the equation) and make sure that the two PCs can communicate.  For your OS, there are a number of on-line resources to help resolve communication issues.  Once the two PCs can successfully communicate, then add in the wireless link and see if they still able to communicate.  If they cannot, then you need to be careful that you are not filtering out IMCP messages or changing the packet as it flows through the node.

You have to look at the clock that is being fed to the timer itself.  There are a number of clocks within the design (160 MHz, 80 MHz, 40 MHz, etc.  see clock_generator_ProcBusSamp_Clocks in the MHS file).

Inside the system.mhs file for the OFDM reference design, you can see how the timer is connected:

BEGIN xps_timer
 PARAMETER INSTANCE = xps_timer_0
 PARAMETER HW_VER = 1.02.a
 PARAMETER C_BASEADDR = 0x83c00000
 PARAMETER C_HIGHADDR = 0x83c0ffff
 BUS_INTERFACE SPLB = plb_secondary_80MHz
END

Given that you are not explicitly connecting the clock port, the timer defaults to the speed of the bus interface (i.e. 80 MHz).  Therefore, the cycles per usec is 80.