Hello,
Recently, Brian told me that the FFT-IFFT processing is handled by the
host side. Can I know how this is done exactly? Is there any relevant
documentation for this on the Wiki?
Thanks a lot.
Regards,
Kuntal
2007/3/7, Kuntal M. [email protected]:
Recently, Brian told me that the FFT-IFFT processing is handled by the host
side. Can I know how this is done exactly? Is there any relevant
documentation for this on the Wiki?
Did you read this:
http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html? The
document is a bit old, but still give a very good introduction to the
basics of GNU Radio.
I read in an earlier thread that you want to do the (I)FFT processing
in the FPGA. This is not how it is intended to be used. GNU Radio is a
software radio framework, and the goal is to move as much of the
signal processing as possible onto the host computer. Moving the FFT
back to the FPGA would therefore be a step backward in the software
approach. This is just my personal opinion, so feel free to spank me
with a 10 foot monopole if your view is different 
–
Trond D.
Trond D. wrote:
I read in an earlier thread that you want to do the (I)FFT processing
in the FPGA. This is not how it is intended to be used. GNU Radio is a
software radio framework, and the goal is to move as much of the
signal processing as possible onto the host computer. Moving the FFT
back to the FPGA would therefore be a step backward in the software
approach. This is just my personal opinion, so feel free to spank me
with a 10 foot monopole if your view is different
An interesting debate. FPGA is indeed hardware, but I’d argue that if
the (I)FFT can be done faster on the FPGA and can use the appropriate
window sizes, etc (eg on-the-fly reconfigurable) that it would still
technically meet the definition of ‘software’. If it frees up USB
bandwidth somehow or frees up host-CPU and lets the host have more
resources left to do its job and we’re not really doing a mode-specific
function that locks us into MIMO or GMSK or OFDM, etc that it would be
OK by me as a consumer.
That Cyclone FPGA was awfully full last I checked- I don’t know enough
about this type of thing to say it wouldn’t fit, but it seems at least
possible that the amount of real-estate required to do the FFT might be
more than the current generation USRP could handle?
IANAE (expert), but I thought the debate was interesting enough to risk
embarassment 
Brett L. Trotter wrote:
That Cyclone FPGA was awfully full last I checked- I don’t know enough
about this type of thing to say it wouldn’t fit, but it seems at least
possible that the amount of real-estate required to do the FFT might be
more than the current generation USRP could handle?
On that note, does anyone how much of the Cyclone we’re currently using?
This whole discussion may be moot for the time being…
-Roshan
“Brett L. Trotter” [email protected] wrote: Trond D. wrote:
I read in an earlier thread that you want to do the (I)FFT processing
in the FPGA. This is not how it is intended to be used. GNU Radio is a
software radio framework, and the goal is to move as much of the
signal processing as possible onto the host computer. Moving the FFT
back to the FPGA would therefore be a step backward in the software
approach. This is just my personal opinion, so feel free to spank me
with a 10 foot monopole if your view is different
An interesting debate. FPGA is indeed hardware, but I’d argue that if
the (I)FFT can be done faster on the FPGA and can use the appropriate
window sizes, etc (eg on-the-fly reconfigurable) that it would still
technically meet the definition of ‘software’. If it frees up USB
bandwidth somehow or frees up host-CPU and lets the host have more
resources left to do its job and we’re not really doing a mode-specific
function that locks us into MIMO or GMSK or OFDM, etc that it would be
OK by me as a consumer.
That Cyclone FPGA was awfully full last I checked- I don’t know enough
about this type of thing to say it wouldn’t fit, but it seems at least
possible that the amount of real-estate required to do the FFT might be
more than the current generation USRP could handle?
IANAE (expert), but I thought the debate was interesting enough to risk
embarassment
…
yes, as Brett said that the FFT can be done on FPGA faster. Because it
will provide us the benefit that we can process task parallaly in the
host computer(DSP) and FPGA… earlier we were trying to use a Xilinx
board but later saw USRP with more features compared to xilinx one…
so we thought of implementing OFDM processing function,
Thats why we thought, lets start with mainly, Up conversion,
Downconversion and FFT /IFFT…
but things does not look so easy, because in this the first task is to
change the RBF file generated for our purpose and accordingly we need to
make change in the USRP documentation, for example Python and C
program…
but really we have got stucked to this point… so if you people can
help us…
Thank you
pankaj
On 3/8/07, Roshan B. [email protected] wrote:
On that note, does anyone how much of the Cyclone we’re currently using?
This whole discussion may be moot for the time being…
There’s some space in there if you disable some portions of the RX
chain.
Plus there is a good amount of RAM still left over in the entire design.
-Roshan
Brian