You are not logged in.
It appears that timing definition values appear more than once in the wlan_mac_dcf code. It would be really helpful if these were set in a single place in the future so that most of the core reference design code can remain untouched when changing MAC functionality. Specifically, SIFS:
//In wlan_mac_dcf.c in mac_dcf_init(..) wlan_mac_set_SIFS(10*10); wlan_mac_auto_tx_params(0, (20*10));
//In wlan_mac_dcf.c in frame_receive(..) wlan_mac_auto_tx_params(TX_PKT_BUF_ACK, 48);
I understand that there is an RX SIFS counter and then a slightly different value required for Tx SIFS to account for hardware delays, but is there a reason the value is reset each time an ACK is transmitted?
It seems like each of those values will eventually be #defines, but it would make sense for the Tx SIFS timer to simply be: RxSIFS - Rx delay - Tx delay explicitly.
Hugs & Kisses
Last edited by NuisanceParameter (2013-Nov-11 11:12:32)
Offline
Yeah, those will all be #defines eventually, once we're done tweaking. We're actually working on the tweaking now, trying to calibrate away our implementation-specific latencies to align medium events vs. commercial devices. The values in the 0.5 release work pretty well, but are definitely suboptimal (easily seen by comparing unidirectional vs. head-to-head throughput tests over a wire with a commercial device).
Offline
The fact that it works so well as-is is quite impressive.
Will these all be hard-coded delay counts or will they be calculated in some manner based upon values like, say, 6.5.4.2 PLME-CHARACTERISTICS.confirm(...) primitives to interoperate different MACs and PHYs?
Offline
They'll be hard coded in the reference design software, using all the "magic" values we find that calibrate away our implementation- and hardware-specific latencies. But the underlying hardware doesn't care if the values are static. A more advanced MAC could change any of the timing values per-packet. Choosing meaningful alternate MAC timing values is a whole other task - we're still learning to appreciate the subtle interdependencies of hardware latencies and the IFS/slot times (i.e. 802.11-2012 Figure 9-14).
Offline
Yeah, no kidding--I think we're actually working on the same thing right now. The reason I ask is because I have a set of magic timing values of my own that I'd like to port to release 0.6 when it comes out. I will say, however, that software porting shouldn't be very hard at all.
If I had one request, it would be the addition of a additional IO port to the next WLAN_PHY_RX pcore revision that accepts an external packet detect signal OR-ed with the existing packet detect signals that would allow integration with additional pcores without modifying anything in the pcore.
By the way, DCF working over custom radio hardware is also a magical thing. In my short experience, I'm already seeing the 802.11 reference work miles better than the OFDM reference ever did. :)
Offline
Another question about timing:
aSignalExtension is defined in 802.11-2012 Table 20-25 as 6 us in 2.4 GHz and 0 us in 5.8 GHz. My understanding is that this is meant to allow the Viterbi decoder time to process the received frame, while keeping SIFS consistent for legacy 802.11b equipment. The corresponding SIFS time is 10 us in 2.4 GHz and 16 us in 5.8 GHz.
wlan_phy_tx_set_extension(120) is set once in wlan_phy_util.c to 6 us, and your default SIFS time appears to be 10 us.
At the end of the day, I'm not sure it matters: there will be a 16 us gap between frames on the air either way. My question is if anything else in the standard will break if you handle the timing this way. Was this intentional?
Offline
If I had one request, it would be the addition of a additional IO port to the next WLAN_PHY_RX pcore revision that accepts an external packet detect signal OR-ed with the existing packet detect signals that would allow integration with additional pcores without modifying anything in the pcore
Sure, that's easy- I'll add it in the next export.
At the end of the day, I'm not sure it matters: there will be a 16 us gap between frames on the air either way. My question is if anything else in the standard will break if you handle the timing this way. Was this intentional?
Yeah, it's designed that way on purpose. In the worst case (64QAM, 3/4 rate code, payload bytes filling last OFDM symbol) our Rx core needs around 5.5usec after the last sample enters the pipeline to decode the final byte. Without the extension the PHY would be required to declare RXEND before it had finished decoding. This, btw, is the same reason the de-interleaver has the 2-bits-at-once architecture; anything else was too slow for the worst case reception.
Once calibrated (in progress) the Rx(payload) -> Tx(ACK) process will leave a 16usec gap on the air, composed of the 6usec Rx extension and the SIFS. From the hardware's perspective the gap is actually shorter, since it must initiate the radio_controller Tx state machine and PHY Tx process early enough so the ACK waveform starts at the SIFS boundary (the spec requires the first sample to be at SIFSħ(slot*0.1), if I recall correctly).
Offline
Also, I should probably mention that wlan_mac_set_SIFS() doesn't actually do anything. The DCF core has a register for the SIFS interval but it's ignored (it was used in early versions, before we built the auto_tx logic). Only the auto_tx delay parameter controls the DATA-ACK time. We'll probably rename the auto_tx delay TxSIFS in the next release.
Offline
Hey NuisanceParameter,
Just FYI, we posted v0.6 of the 802.11 Reference Design. It includes the new timing values that line up with commercial 802.11 devices (we'll post some characterizations that show that soon). Also, the release makes an attempt to make setting and changing those values more sane (like removing the red herring of the SIFS register in the DCF core and separating the standard-specified timing parameters from the hardware-specific latencies).
Also, this release fixes the bug the PHY bug that sadiaq found in this thread as well as some other fixes.
Last edited by chunter (2013-Nov-18 16:31:37)
Offline