WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2014-Jan-09 17:27:15

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Announcing Mango 802.11 Reference Design v0.7 for WARP v3

We have just released the 802.11 Reference Design v0.7 beta. This design includes fixes for a few PHY bugs and significant improvements to the AP/STA implementations and underlying MAC frameworks.

Please post any questions about the design below.

Offline

 

#2 2014-Jan-13 21:06:53

MoeJoseph
Member
Registered: 2013-Aug-30
Posts: 23

Re: Announcing Mango 802.11 Reference Design v0.7 for WARP v3

Hi,

I am noticing that the total available packets (whether free or queued for broadcast or unicast transmission) is gradually decreasing over time. For example, in the UART menu, if I Print Queue status, I will find:
Queue Status:
FREE || BCAST|
  2794||     0|

After some time (say 20 secs), If I Print Queue status again, I will find:
Queue Status:
FREE || BCAST|
  2791||     0|

and so on. I checked the code and the only place where I find the queue being checked out without eventually being checked back in again is in wlan_eth_dma_update function. Could that be the reason or is it something that is unique to my setup?

Thanks,

Offline

 

#3 2014-Jan-13 22:19:31

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Announcing Mango 802.11 Reference Design v0.7 for WARP v3

Thank you for reporting this. I'm sure Chris (author of all that code) will have suggestions tomorrow AM. A few details that will help us debug:
-Do you see this on the STA or AP (or both)?
-Was the node connected to Ethernet?
-Which role (STA or AP) was running for the example above?
  -If it was the AP how many clients were associated? I'm guessing none, based on the UART output.
  -If it was the STA was it associated with an AP?

Offline

 

#4 2014-Jan-14 08:36:22

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Announcing Mango 802.11 Reference Design v0.7 for WARP v3

Thanks for finding this. I was able to reproduce the problem -- it's clearly a bug in my code. I'll update this post once I get to the bottom of it.

Offline

 

#5 2014-Jan-14 10:14:03

MoeJoseph
Member
Registered: 2013-Aug-30
Posts: 23

Re: Announcing Mango 802.11 Reference Design v0.7 for WARP v3

I saw this while operating the board in AP mode and this was on its UART menu. The AP was connected to Ethernet and no clients were associated. However, even if clients are associated, the situation still occurs.

Offline

 

#6 2014-Jan-14 13:39:12

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Announcing Mango 802.11 Reference Design v0.7 for WARP v3

Okay, I found the problem. I will post a new zip file with the fix, but it's actually just one line of code to add so you can do it yourself if you want. Just add the following line:

Code:

packet_is_queued = 0;

to Line 494 of wlan_mac_eth_util.c. (Add is just after the "for(i=0;i<bd_count;i++){")

The packet_is_queued variable is used by the WLAN MAC High Framework to decide whether or not the queue element used by the Ethernet DMA buffer descriptor should be added back to the free pool or not. Sometimes, the user code (AP or STA) will enqueue the packet for transmission. Other times the user code doesn't know what to do with the packet (e.g. a unicast packet to an address that is not to an associated device). In the former case, the framework doesn't check anything back in because the packet has moved into an outgoing wireless transmit queue. In the latter case, the framework needs to check the packet_bd back in explicitly so it can re-enter the free pool.

The bug manifested under a pretty unlikely set of circumstances that had to all be true:

1) A burst of Ethernet receptions occurred such that the for loop in Line 493 was executed multiple times.
2) At least one time the loop was executed, the AP decided it was a packet worth transmitting and enqueued the packet. It then set packet_is_queued = 1.
3) Following the previous enqueueing, the framework parsed an Ethernet reception that it didn't know how to deal with (Neither ARP nor IP). wlan_eth_encap() returned 0.

Unfortunately, the packet_is_queued variable was "sticking" from the previous iteration of the loop, causing that packet_bd to not be given back to the free pool.

Thanks for catching this. I think it's a very old bug and might have been present in earlier releases as well. I'll post an update to the design shortly.


Edit: We have posted the updated design that has this fix and have incremented the version to 0.71. The new design is available here.

Last edited by chunter (2014-Jan-14 14:00:30)

Offline

 

#7 2014-Jan-15 11:50:32

NuisanceParameter
Member
Registered: 2012-Apr-19
Posts: 54

Re: Announcing Mango 802.11 Reference Design v0.7 for WARP v3

Good morning,

I wanted to ask about the following additional changes in the wlan_phy_tx and model for version 2.00.n.

=== Transmit Sample Clock Rate Selection ===

In the "Start Ctrl" section, an additional input port called DAC_TX_CLK has been added in place of the "constant up-sampled by 8" circuit to generate the pulse latching in new IQ samples to the IFFT. This signal is now called TX_IQ_SAMP_CE and the source DAC clock appears to be running at 20 MHz. Functionally, the new method should be identical to the old, except now the actual DAC clock (DAC_TX_CLK) and the BB sample clock (TX_IQ_SAMP_CE) should have a guaranteed phase relationship.

We've been using WARP with another DAC running at a 40 MHz sampling rate and using the old implementation of the wlan_phy_tx sample clock to drive our DAC with "up-sampled by 4", "up-sampled by 8", "up-sampled by 16", and "up-sampled by 32" constants (w.r.t. the 160 MHz AXI clock), resulting in the ability to change the transmit channel bandwidth to 40, 20, 10, and 5 MHz. We have not yet tested this with WARP's DACs; however, I believe it would be nice to have this work seamlessly with both our DAC and WARP's DAC, since our architecture could switch between them very easily or even use both simultaneously.

Ignoring the potential for 40 MHz operation for now since modifying the clock rate is a non-standard method of channel bonding and requires other hacks, do you foresee any problem going forward with the same down-sampling approach using this new TX_IQ_SAMP_CE sample clock? In this case, we would pass TX_IQ_SAMP_CE for 20 MHz operation, divide TX_IQ_SAMP_CE by two for 10 MHz operation, and divide TX_IQ_SAMP_CE by 4 for 5 MHz operation.

More specifically, might there be other locations in the PHY design that depend (explicitly or implicitly) on the timing of DAC_TX_CLK?

I'll update with whether this approach works later today, but I wanted to get your reaction just in case it didn't. Thanks!


-NP

Offline

 

#8 2014-Jan-15 12:18:27

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Announcing Mango 802.11 Reference Design v0.7 for WARP v3

I added the DAC_TX_CLK port to replace the internal 1/8 clock-enable generator. The posedge(DAC_TX_CLK) signal drives the clock enables of all logic that cares about the actual sampling rate. Using the external port assures a constant phase relationship between the sysgen_clk (160MHz) and the ad_bridge.tx_clk (20MHz). Previously this phase was random-per-download, since the internal 1/8 CE generator wasn't tied to the MMCM's 20MHz clock output. I don't think this was a serious problem, but wasn't entirely comfortable with it.

The frequency of the DAC_TX_CLK signal must be <= freq(sysgen_clk)/8, since parts of the pipeline require at lest 8 clock cycles per sample. Arbitrary rates lower than 1/8 should just work.

Offline

 

#9 2014-Jan-15 12:29:35

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Announcing Mango 802.11 Reference Design v0.7 for WARP v3

Ignoring the potential for 40 MHz operation for now since modifying the clock rate is a non-standard method of channel bonding and requires other hacks, do you foresee any problem going forward with the same down-sampling approach using this new TX_IQ_SAMP_CE sample clock?

Nope- that should work fine. You can probably ignore the DAC_TX_CLK input entirely on custom hardware (not sure how your equivalent to the ad_bridge works). The <8x frequency is the only PHY requirement.

More specifically, might there be other locations in the PHY design that depend (explicitly or implicitly) on the timing of DAC_TX_CLK?

I think I fixed all the blocks in the Tx that assumed (or generated locally) the T=8 CE. Let me know if I missed any.

Offline

 

Board footer