Re: [Discuss-gnuradio] MAC layer development and USRP2

[Jeff Brower]

George-

>> What I got from your paper is that the matched filter approach for
>> fast packet detection would not work in an OFDM setting. What about
>> fast ACK generation? Would it require an IFFT implementation on the
>> USRP? Would it help much?
>
> It's a good question, and something I haven't explored, and I'm not much of
> a DSP guy.  So, I'll punt the question to everyone else who has more DSP
> experience than me.  Both are all about signal detection, both the
> fast-packet detection and fast ACK generation.  So what you want to do is
> first detect the preamble in the USRP without decoding (because it's complex
> and takes long).  So, we propose using a matched filter on the USRP to
> detect the packet preamble.  In 802.11ab, the preamble was done with BPSK
> (even if the data is sent using OFDM in 802.11a).  With 802.11g, it can be a
> full OFDM preamble. So, with a full OFDM preamble, you can still detect it
> with a matched filter, but I'm a little unclear about how to generate the
> coefficients.  You essentially are detecting in the time domain with the
> matched filter.  It might require an IFFT on the USRP... anyone?  Dan? :)
>
>>
>> > This all said... I really think we need a better interface to reduce
>> > latency.  Some platforms take the: run on the board approach, such as
>> WARP
>> > which puts the MAC on a core on the board.  Good luck conjuring up
>> $10-15k
>> > just for a single WARP board plus frontends though :P
>>
>> Is there anything that would prevent GNUradio developers to push the
>> MAC layer functionality on the USRP?
>>
> The USRP and USRP2, from what I understand, are both tight for space in the
> FPGA.  I'm pretty confident you can't fit an OFDM implementation on the
> USRP.  There are free multipliers and space on the USRP2, but I think it
> would also be tight, leaving you with not much room for the MAC.  Then,
> you'd be building the MAC in verilog which sucks.  Most people who want to
> do MAC development have CS backgrounds, not EE backgrounds, form which
> Verilog is black magic ;)

To cover a wide range of MAC layer standards at fast RF data rates, some type 
of processing element is required in the
front-end data flow; i.e. before the x86 server.  One way is an embedded 
processor core in the FPGA that runs C code
and has a library of useful stuff (matched filtering, iFFT, etc) that look like 
basic function calls, but are
implemented as parallel structures in FPGA logic, outside the processing core.  
C/C++ code calls the function, waits
some number of clock ticks or gets a callback, and it's done (well, more or 
less).  This approach both abstracts the
FPGA logic to the C/C++ programmer and gives the FPGA more flexibility (i.e. 
reduces the number of applications where
people need to reprogram the FPGA).

I would guess that between Matt and NI guys they're planning (if not already 
started) on developing a more powerful
version of the USRP2, with larger FPGA.  My understanding is that Matt 
originally chose Spartan-3 because it was
Xilinx's highest performance FPGA (with reasonable chip cost) that would still 
allow developers to use WebPACK. 
Evidently he had to move to S-3 2000 for more capacity, although WebPACK only 
supports up to S-3 1500.  That means
that GNU radio users who want to modify the FPGA already need the "paid for" 
Xilinx ISE tools...  and I can tell you
from experience that Xilinx holds its tools in high regard and charges 
accordingly.

For these reasons -- not to mention competition from people like Lyrtech and 
Sora, maybe something NI guys pay more
attention to than Matt -- a USRP2 with Virtex 5 or 6 starts to make sense.

-Jeff