You are not logged in.
Hi. Using this page for reference: http://www.xilinx.com/support/answers/17966.html
Is it possible to design a pcore using System Generator for DSP 14.7 linked to Matlab 2013a, then copy this in to a project (i.e. 802.11 ref design downloaded from you) which is built using ISE 14.4 and it will compile?
The pcore is a vhdl/verilog description of the hardware, so it shouldn't matter which version of the tools it came from?
I am trying not to upgrade your 14.4 project because of compiler problems (http://warpproject.org/forums/viewtopic.php?id=2472) but use a more modern Matlab/Simulink.
Offline
Also, at any point, do you ever calculate TXTIME as per 18.4.3 of 802.11-2012, specifically in hardware.
Do you ever calculate a point at which you expect the frame reception to end? Based on the SIGNAL field.
Last edited by horace (2015-Jan-21 03:43:43)
Offline
Hi. Using this page for reference: http://www.xilinx.com/support/answers/17966.html
Is it possible to design a pcore using System Generator for DSP 14.7 linked to Matlab 2013a, then copy this in to a project (i.e. 802.11 ref design downloaded from you) which is built using ISE 14.4 and it will compile?
The pcore is a vhdl/verilog description of the hardware, so it shouldn't matter which version of the tools it came from?
I think this will work. And if it doesn't I'm pretty sure the error will be explicit (an error during XPS implementation) and not subtle bad behaviors at run time.
Also, at any point, do you ever calculate TXTIME as per 18.4.3 of 802.11-2012, specifically in hardware. Do you ever calculate a point at which you expect the frame reception to end? Based on the SIGNAL field
The Rx PHY implements this in the "/Sync & Antenna Sel/PHY CCA/Rate*Length" subsystem. This subsystem takes the rate and length values from the Rx SIGNAL field and runs for the full expected duration of the reception. This happens independent of any Rx PHY processing. This subsystem asserts the RX_END output to the MAC, giving the MAC a reliable time reference for its IFS counters that is independent of any processing latencies in the Rx PHY.
Offline
Hi, thanks for the reply. I saw this subsystem and thought that's what it might do. But isn't this signal timed from when the SIGNAL field is decoded, rather than the true on-the-air time of the frame. The time from SIGNAL field reception -> FFT, decoding, etc -> calculating this end point is not zero. Hence the rx_end signal will be after the true RF end of the frame by some amount?
Offline
My post above is accurate, but incomplete. The Rate*Length block (let's call it RL) uses the values from the decoded SIGNAL field. But the block actually starts running before the SIGNAL field is decoded. The RL block counters start when the LTS correlator detects the second correlation peak, corresponding to the second LTS sequence in the preamble. The correlator operates in the time domain and is accurate to ±1-2 sample periods in most cases. Thus, the timing of the RL block is tied to the detection of the preamble in the time domain and is independent of any frequency-domain decoding/processing latencies.
When the RL block starts it assumes only the SIGNAL field will be received (i.e. 24 bits @ 6Mbps, occupying exactly 1 OFDM symbol). If a valid SIGNAL field is decoded the rate/length values are updated and the RL block keeps its BUSY output asserted until the actual RX_END. If the SIGNAL field is not decoded successfully, the PHY resets and the BUSY output de-asserts after the single OFDM symbol.
Offline
Thanks for your reply. That makes it much clearer. So the only difference between the end of the last data symbol and de-assertion of rx_end is the programmable extension period. Thanks.
Offline