Channelization

Discussions related to modulation techniques, filtering, error correction and detection, wireless link layer implementations, etc
Post Reply
kd5pev
Posts: 2
Joined: Fri Aug 09, 2013 5:34 pm

Channelization

Post by kd5pev »

What is the most efficient way to do channelization inside the blade's FPGA?
I want to split about 10 channels, each with a bandwidth of about 100khz, out of the LM chip when it is operating in its 30mhz BW mode.
I have a few ideas on how to accomplish this:
-- 10 Digital Down Converters ->10 Low pass filters -> 10 Digital Up Converters then sum them together, and then push it to the cypress chip.
-- 1 big FFT on the input signal, then take the channels that I want, and feed them to a smaller IFFT, then push the output to the cypress.

The Digital Up Converters may not be needed, if I put offsets on the DDCs.

I like the first option because I could change where each channel is dynamically by changing each channel's DDS phase increment.
The second one would probably take less resources, but is less re-configurable (each change would require a new FPGA bitstream)

I want to do this on the FPGA, so I can do processing on the cypress chip (I want to make a standalone device).
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: Channelization

Post by bpadalino »

The most efficient way is a method mentioned by fred harris called polyphase filterbanks. It's a single filter (running at the sample rate), but only a single FFT instead of an FFT followed by IFFT's. It's also the least configurable. The most configurable is definitely the DDC approach, but also more resource intensive.

How much rejection do you want in your filter? What samplerates?
kd5pev
Posts: 2
Joined: Fri Aug 09, 2013 5:34 pm

Re: Channelization

Post by kd5pev »

bpadalino wrote:The most efficient way is a method mentioned by fred harris called polyphase filterbanks. It's a single filter (running at the sample rate), but only a single FFT instead of an FFT followed by IFFT's. It's also the least configurable. The most configurable is definitely the DDC approach, but also more resource intensive.
Looks interesting. Thanks for the link.
bpadalino wrote: How much rejection do you want in your filter? What samplerates?
I don't know yet. Still experimenting, but I would like to have as much performance as possible.
I want to make this bladerf into a receiver for 10 low power wireless sensor boards, each on its own channel and without synchronization to each other.
Haven't decided on a modulation mode, or data rate yet; but I do know that I want each sensor board to use 100khz or less of bandwidth.

From what I read in that paper you linked to,it seemed like it is designed for a one to one communication link.
Would it work for a many to one link?

Do you know how much space a complex multiplier takes inside the FPGA? Or, if Altera has DDC IP core? (my experience is with Xilinx FPGAs)
bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: Channelization

Post by bpadalino »

Complex multiply by be done either using the 3 multiplier or 4 multiplier method - up to 18x18 multipliers. Altera has lots of IP available, but I am not sure how much of it is free. We're looking to expand the IP offerings in pure HDL to make sure we don't run into issues where people need to pay for licenses.

In the end, it sounds like you want to carve out 1MHz (10 channels * 100kHz/channel) out of a 30MHz swath? The mix, filter and decimate mode may end up working pretty well - especially given the large disparity in sample rates (30MHz -> 100kHz). Maybe the best way is:

RX Samples -> Mix to BB -> Decimating CIC Filter (R=50?) -> Decimating FIR Filter (R=6?) -> Output

The CIC filter is very efficient since it's only additions/subtractions and can give you a decent rejection off the bat. The decimating FIR filter can have extra clock cycles, after the CIC, to time division multiplex the multipliers required for filtering - so storage would really be the biggest penalty. If you could get it so the number of taps in your (hopefully symmetric) FIR filter is less than the number of clock cycles between output samples that have to go somewhere, you may be able to get away with 2 multipliers for the whole filter (one for I, one for Q - large accumulator at the end).

The only real issue with the CIC is the big side lobes. A quick google search found a paper on the design of CIC decimators which looks like it could be a great read for this.
Montezuma
Posts: 39
Joined: Fri Mar 01, 2013 6:42 am

Re: Channelization

Post by Montezuma »

bpadalino wrote:Complex multiply by be done either using the 3 multiplier or 4 multiplier method - up to 18x18 multipliers. Altera has lots of IP available, but I am not sure how much of it is free. We're looking to expand the IP offerings in pure HDL to make sure we don't run into issues where people need to pay for licenses.

In the end, it sounds like you want to carve out 1MHz (10 channels * 100kHz/channel) out of a 30MHz swath? The mix, filter and decimate mode may end up working pretty well - especially given the large disparity in sample rates (30MHz -> 100kHz). Maybe the best way is:

RX Samples -> Mix to BB -> Decimating CIC Filter (R=50?) -> Decimating FIR Filter (R=6?) -> Output

The CIC filter is very efficient since it's only additions/subtractions and can give you a decent rejection off the bat. The decimating FIR filter can have extra clock cycles, after the CIC, to time division multiplex the multipliers required for filtering - so storage would really be the biggest penalty. If you could get it so the number of taps in your (hopefully symmetric) FIR filter is less than the number of clock cycles between output samples that have to go somewhere, you may be able to get away with 2 multipliers for the whole filter (one for I, one for Q - large accumulator at the end).

The only real issue with the CIC is the big side lobes. A quick google search found a paper on the design of CIC decimators which looks like it could be a great read for this.
As to the bold:

That is the ridiculous part, isn't it? We have paid for the FPGA, so we should have full use of all the IP attached to the FPGA. To infer that we need to look for what IP is "free" for us to use would infer that we received the FPGA for free, which we haven't. Ridiculously, such IP restrictions are rampant across many IC manufacturers.
Post Reply