[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Putting a correlator in the FPGA

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Putting a correlator in the FPGA
Date: Fri, 2 Mar 2007 18:48:33 -0800
User-agent: Mutt/1.5.9i

On Fri, Mar 02, 2007 at 03:33:40PM -0800, Dan Halperin wrote:
> Eric Blossom 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.

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

> >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.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]