Adding a FFT to USRP2 design


i’m traying to add an FFT module to the the “base” design of the usrp2.

I’ve found, in my opinion, where is the best place to add it. Between
the module dsp_core_rx_old and the module rx_control.
If i am right, the dsp_core_rx_old takes the input from the adc and
takes out (doing decimation and other stuff) i & q in 16 bit, placed
together in the output signal sample[31:0].
This the goes in the rx_control module which is , in a semplified way
to say it, a rx buffer with some fifos, before all goes in the big
buffer pool to be sent with eth.

Now, my idea is to place a FFT pipelined module cloked with dsp_clock,
between this two modules, so as soon as i have i & q i can transform
them in “ffti” & “fftq”, keeping the same dimension of 16 bit (it’s a
scaled fft, for space & design reason).
The fft module is a xilinx ip core module, that can, after a
calculation latency, stream the result to ouput and in the same time
do calculation and get other input sample.

So, with this kind of module, i get some 0’s in the sample wire during
the calculation latency, then the data streams out normally without
“damaging” the whole structure. So i have, in the first simple design,
i & q that are sent to host as usual, but they are implicity “packed”
in N fft result, [0------0], 0…N-1, 0…N-1, with the numbers of
0’s that are placed before the the first good fft result.

The first (easy) application is only to send this modified data to
host, then if this works i will see how to do some selection on the

Is this possible? From simulation, it’s easy to see the results, but i
can’t simulate the whole design of course, so i’m asking if, knowing
flow of data, this is a feasible structure.
Another thing i want to ask is, when the usrp2 send data to host, the
dsp_rst (a reset) is not activated during the stream, right? It’s a
continuous flow of sample until it is stopped, if i have understood

Thank you


Hi Matteo,

It sounds like you are using one of the BLOCK I/O xilinx FFT cores. As
said, the core loads the
input i & q values, performs computation, then outputs the i & q FFT
results. And yes, during the load
and computation latency periods, there will be the lack of useable
samples. The problem with this,
is there may be no way of determining when the first actual fft output
sample exists in the sample stream.
Unless you put in logic to force some recognizable pattern prior to the
output. I’m not sure if your
blocks of 0’s will be easy enough for you to find the first fft output
sample, but if it works for you, excellent.

Also, due to the non-streaming operation of the block i/o fft core, you
most likely miss blocks of
input samples from the ADC.

Xilinx has a nice app note on the FFT LogicCores, and in there is timing
all the ffts, including streaming
ffts if you require them.

Sorry, I am not familiar with the fpga design well enough to advise as
the placement of the fft, or its timimg.


Matteo Carucci wrote:

This the goes in the rx_control module which is , in a semplified way


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

View this message in context:
Sent from the GnuRadio mailing list archive at