Official bladeRF forum

Hi all, my interest is in using the bladeRF in an embedded setup with a high powered ARM device such as the Odroid-XU as the host. This gives you a physically small, low power consumption setup which could for example be located near the antennas and interfaced over either USB or Ethernet.
I'm using Gnuradio based code to do signal processing for reception and decoding of a BPSK modulated data signal and whilst the Odroid performance is respectable (and very good for an ARM device), its still quite a bit slower than an Intel i5 / i7 etc and will struggle at higher bandwidths.
The obvious thing to do is to push the front end DSP filtering and decimation processes onto the FPGA and pass the Odroid a part processed stream for demodulation and decoding at lower sample rates. So I was looking for a bit of guidance on the following questions:

1. Where to put the additional DSP in the signal chain? Based on the stock hosted system, I would think this would be added downstream of the existing modules, just before the FX3 connection - so, between the rx_sample fifo and the FX3? Is this the best location?

2. I want to be able to frequency shift and change the filter characteristics whilst the system is running, so need to able to control the frequency of my (new) FPGA based mixer, and change the FIR filter tap coefficients, rather than have these hard coded in. This could be done by hooking up additional data streams to the mixer / FIR filter respectively. It would seem logical to achieve this by passing the data from the Nios II soft processor, interfacing with the Nios II from the Odroid over USB - for example, Gnuradio has a block which generates FIR filter tap coefficients, these could be generated on the Odroid, and passed via the Nios II to the filter. Does this make sense, or might it be better to try to interface the filter directly via the FX3? Has anyone had any experience of going down this route?

3. Is there likely to be more guidance forthcoming on how to go about implementing DSP on the FPGA? For example, I understand with the Ettus USRPs that pass through modules are already implemented in the FPGA, and therefore to add custom DSP you just have to re-write those modules rather than replumbing the whole FPGA.

Regards

Brian

1. Where to put the additional DSP in the signal chain? Based on the stock hosted system, I would think this would be added downstream of the existing modules, just before the FX3 connection - so, between the rx_sample fifo and the FX3? Is this the best location?

For TX, the FX3 pushes samples into the FPGA at a 100MHz clock rate, and those samples go directly into a FIFO. A fifo_reader then streams those out and separates them into the I and Q streams from a 32-bit value. Each one of these values is read out of the FIFO every other clock cycle on the TX clock domain since the LMS requires 2 clocks per sample at the DAC. This would be the place to have a signed real/imag input with a valid signal, and expect data to be pushed into you once every other clock cycle.

For RX, the same is true, but in reverse. The LMS is giving I data on one clock edge, then Q data. This data is aligned internally to a 32-bit bus which is valid every other clock cycle. There is an IQ correction block that lives right there after this RX section. After this IQ correction block, I would place your custom DSP logic.

2. I want to be able to frequency shift and change the filter characteristics whilst the system is running, so need to able to control the frequency of my (new) FPGA based mixer, and change the FIR filter tap coefficients, rather than have these hard coded in. This could be done by hooking up additional data streams to the mixer / FIR filter respectively. It would seem logical to achieve this by passing the data from the Nios II soft processor, interfacing with the Nios II from the Odroid over USB - for example, Gnuradio has a block which generates FIR filter tap coefficients, these could be generated on the Odroid, and passed via the Nios II to the filter. Does this make sense, or might it be better to try to interface the filter directly via the FX3? Has anyone had any experience of going down this route?

Using the NIOS to do it sounds like a good idea. You will need to cross clock domains from the NIOS domain of 80MHz to the RX or TX clock domains. You can make your filter a custom Qsys block, similar to what the time_tamer is for timestamps, and use some address space of the peripherals (similar to the IQ correction block) to give you some register space.

I want to modify the packets going over to the FPGA to have 1 bit for read versus write, and expand the peripheral addressing to 3 bits. This would leave some extra peripheral space allocated for users and their custom logic in designs. I haven't had time to go and rip through that, but we would gladly take modifications.

3. Is there likely to be more guidance forthcoming on how to go about implementing DSP on the FPGA? For example, I understand with the Ettus USRPs that pass through modules are already implemented in the FPGA, and therefore to add custom DSP you just have to re-write those modules rather than replumbing the whole FPGA.

Make sure you testbench your design. Unit test it. The whole exercise shouldn't require re-plumbing the whole FPGA, either. You just need to create a pass-through block which takes in samples, modifies them in some way, and outputs them again. Check the IQ correction block for something similar.

Lastly, make sure to ask lots of questions. If we don't have the correct documentation for you, we should and we should create it for you. Let us know where we can help you and we'll be glad to do so.

Have fun and good luck!

Brian

Dear all,

Could someone explain what the 'meta_fifo' are used for and how they relate to the RX and TX FIFOs?

Thanks!

Hi,
the metadata_fifo is a buffer for the metada information corresponding to the Samples. The rx metadata are created every 504 Samples (USB 2.0) and the main part of the metadata ist Timestamp, that keeps the value of the intern counter at time the sample has been read from lms. In the TX path the timestamp is used to start reading the samples from tx_fifo after the counter reach the value of the timestamp.

Thanks!

kartar wrote:Hi,
the metadata_fifo is a buffer for the metada information corresponding to the Samples. The rx metadata are created every 504 Samples (USB 2.0) and the main part of the metadata ist Timestamp, that keeps the value of the intern counter at time the sample has been read from lms. In the TX path the timestamp is used to start reading the samples from tx_fifo after the counter reach the value of the timestamp.