Hi,
I’m trying to put the Barker correlator in the FPGA. This should greatly
improve the SNR of the BBN 802.11 code.
The plan is:
64Msps complex w/11MHz info -> Barker Correlator -> Decim by 16 -> 4Msps
complex with 1MHz info
instead of
64Ms complex w/11MHz info -> Decim by 8 -> 8Msps complex with 11MHz info
-> Barker Correlator
.
I resampled the 11-bit Barker code to 64 taps (is this even the right
thing to do? MATLAB still gave me all real numbers) and used the Altera
IP FIR compiler to build a multiplier-less FIR. However, this FIR, when
I set everything to bit-width 16 (dropping all but the most significant
16 of the output), uses ~1/3 of the LEs of the FPGA. Is this expected or
did I do something grossly wrong?
In any case, I’m going to need at least 2 of them, one for TX and one
for RX, and quite possibly 4 if I have to stick one each on the input
and output I and Q paths. I definitely don’t have that much room, and
I’ve already removed the secondary RX and TX paths in the core.
If I let the FIR do some of the decimation, I can make it smaller, but I
don’t understand the DSP enough to know that that’s ok.
Also, I’m currently planning on inserting the FIR after the CORDIC and
before the CIC decimation filter. Is that the right place? If I put it
before the CORDIC then maybe I would only have to use 1 FIR on the RX
path?
-Dan
On Fri, Mar 02, 2007 at 10:27:44AM -0800, Dan H. wrote:
instead of
16 of the output), uses ~1/3 of the LEs of the FPGA. Is this expected or
Also, I’m currently planning on inserting the FIR after the CORDIC and
before the CIC decimation filter. Is that the right place? If I put it
before the CORDIC then maybe I would only have to use 1 FIR on the RX path?
Disclaimer: I haven’t actually looked at how to implement what you’re
trying to do 
I think you’re going to want the CORDIC and CIC in place. Otherwise
you’re looking at the full IF passband of the daughterboard (I’m not
sure how wide the unmodified RFX-2400 IF is.) In any event,
decimating by two is going to make your job easier and you won’t lose
any useful info. Maybe you just want a fixed decimate by 2 CIC (it
would take up fewer resources than the general one that’s currently in
the FPGA).
There are no hardware multipliers in the Cyclone. However, I think
you’re falling victim to the “I used MATLAB and then some other piece
of magic code generator software” syndrome. This can probably all be
made to fit. Why do you think you need 16-bit coefficients? How
about 8-bit, or even 1-bit (I’m not kidding). You’ll also probably want
to
take a look at the Altera App Note on techniques for synthesizing
multipliers. There are lots of options, particularly if you have
cycles or RAM available.
Before diving in, you may want to spend a bit of time searching the
IEEE, etc pubs for 802.11 implementation articles.
Eric
Eric B. wrote:
I think you’re going to want the CORDIC and CIC in place. Otherwise
What do you mean by “in place”? I was planning on leaving them there,
and inserting the correlator between them. Do you mean I don’t want to
jump in the middle?
you’re looking at the full IF passband of the daughterboard (I’m not
sure how wide the unmodified RFX-2400 IF is.) In any event,
decimating by two is going to make your job easier and you won’t lose
any useful info. Maybe you just want a fixed decimate by 2 CIC (it
would take up fewer resources than the general one that’s currently in
the FPGA).
Are you perhaps proposing
64Msps complex w/11MHz info -> fixed CIC decim x2 -> fixed Barker
Correlator/Decim x 8 -> 4Msps complex w/1MHz info?
When I said that I might push some of the decimation to the FIR, I was
thinking
64Msps complex w/11MHz info -> fixed Barker Correlator/Decim x{2,4?} ->
(current, variable) CIC decim x{8,4} -> 4Msps complex w/1MHz info.
There are no hardware multipliers in the Cyclone. However, I think
you’re falling victim to the “I used MATLAB and then some other piece
of magic code generator software” syndrome. This can probably all be
made to fit. Why do you think you need 16-bit coefficients? How
about 8-bit, or even 1-bit (I’m not kidding). You’ll also probably want to
This is clearly a better idea. I just made the coefficients match the
input width, but there’s no real reason to do this. With using only 8-
or 6-bit coefficients the space more than halves. And yes, I’m looking
into throwing some of the data into RAM. There’s not a lot of that on
the Cyclone though.
Before diving in, you may want to spend a bit of time searching the
IEEE, etc pubs for 802.11 implementation articles.
Definitely. The one thing I’ve learned so far is that there’s no
standard pulse shaping filter. Brilliant.
-Dan
On Fri, Mar 02, 2007 at 03:33:40PM -0800, Dan H. wrote:
any useful info. Maybe you just want a fixed decimate by 2 CIC (it
64Msps complex w/11MHz info -> fixed Barker Correlator/Decim x{2,4?} ->
(current, variable) CIC decim x{8,4} -> 4Msps complex w/1MHz info.
Perhaps. I just didn’t see any reason to run your correlator at the
higher rate, when there’s a very cheap way to cut the rate in 1/2.
Cutting the rate in half gives you twice as many cycles to execute
your correlator. That is, you can consider implementations that take
2 clocks to produce a single output (ignoring the decimation of the
correlator).
the Cyclone though.
I was thinking of the table lookup multipliers mentioned in the Altera
App Note. IIRC they do a 16 x 12 in 2 cycles with a relatively small
amount of ram for table lookup.
I’m pretty sure the current code is allocating way more RAM for the
FIFO’s than it really needs. We weren’t doing anything with it, so we
assigned it to the FIFOs. They’re currently configured to use 4k
16-bit lines. That’s enough to hold 16 packets. Cutting it in half
should definitely work. Cutting it down to 1k lines might work too.
Before diving in, you may want to spend a bit of time searching the
IEEE, etc pubs for 802.11 implementation articles.
Definitely. The one thing I’ve learned so far is that there’s no
standard pulse shaping filter. Brilliant.
Isn’t engineering fun
BTW, it will be great to have this available in the FPGA.
Eric