WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2015-Jan-21 03:24:19

horace
Member
Registered: 2014-Jul-16
Posts: 63

Sysgen and ISE versions

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

 

#2 2015-Jan-21 03:43:13

horace
Member
Registered: 2014-Jul-16
Posts: 63

Re: Sysgen and ISE versions

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

 

#3 2015-Jan-21 09:55:58

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

Re: Sysgen and ISE versions

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

 

#4 2015-Jan-21 11:08:21

horace
Member
Registered: 2014-Jul-16
Posts: 63

Re: Sysgen and ISE versions

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

 

#5 2015-Jan-21 21:19:02

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

Re: Sysgen and ISE versions

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

 

#6 2015-Jan-22 02:50:01

horace
Member
Registered: 2014-Jul-16
Posts: 63

Re: Sysgen and ISE versions

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

 

Board footer