On 03/02/2012 01:55 PM, Panda Resistor wrote:

You might try the gnuradio list archives as well. I've seen this topic
mentioned many times in the past.

See
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt#L29

http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/usrp2/custom

-Josh

On 02/03/12 22:31, Josh Blum wrote:

Thanks for that, it looks like people have enquired but no real positive
results mentioned. Will have to have a look through the FPGA code and
see how it looks. Time to dig into some verilog! Any other helpful
pointers would be gratefully received.

IN addition to Josh's links I'll try to address some of that for you:
The amount of FPGA resources used will directly correspond to a) the rate at which the FFT needs to run b) How many points the FFT is. A 4096 point FFT is clearly going to be way more complex than a 64 point one. And running it one a mili-second is very different than sustaining 100MHz sample rate operation.

Both the N200 and N210 have significantly larger FPGA's that are much more DSP capable than the USRP2 did, so it's reasonable to expect that the N200 can handle this, and I'd say certain that the N210 could handle a fairly large FFT in addition to all it's default logic. If you remove the unused time domain DSP logic then lots of additional resources will be freed up also.

The first step to estimate this would be to generate an FFT from Xilinx's coregen tool to the approximate parameters you desire add it to the USRP data base crudely (i.e connect it to signals so it's not optimized away!) and see how many resources it uses. That will be a good sanity check that's only a hours work before you need to work out the exact details of control.

An FFT in general is going to produce approximately as much result data as sample data it consumes, (however if you use an overlapping window then it's going to produce an even greater rate of results than raw off air samples proportionate to how much window overlap there is) . The results will be complex just like the input data, and there's no reason why you couldn't feed the bin data downstream through the UHD and ethernet logic, you'll just need to provide enough elastic buffering on input and output to prevent over/under run. For the N200/210 your golden rule will be that 100MB/Sec is the ceiling of the ethernet link, so if you want to run an FFT on the 100MHz raw input data then you'll perhaps want to integrate the results over time or only run it intermittently as you will have approximately 4x the datarate that can be sustained by 1G Ethernet otherwise.

On Mar 2, 2012, at 1:55 PM, Panda Resistor wrote:

Here is a paper that is really good for understanding the USRP architecture and also deals with FFT implementations:
"Analysis and Architectural Mapping of an FFT Algorithm into an Already Existing FPGA Firmware of a Low-cost COTS SDR Peripheral" by Sune Vendelbo Enevoldsen, Jeppe Græsdal Johansen, Vincent Pucci
http://vbn.aau.dk/files/52688059/final.pdf