discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] USRP packet parsing


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] USRP packet parsing
Date: Fri, 23 Mar 2007 11:01:46 -0700
User-agent: Mutt/1.5.9i

On Fri, Mar 23, 2007 at 10:15:12AM -0400, Brian Padalino wrote:
> On 3/23/07, Eric Blossom <address@hidden> wrote:
> >I think I steered us down the wrong path with the shared RAM idea.
> >We really do want a dedicated read port for each channel in the Tx
> >direction.  This is easy if we assigned a FIFO (or dedicated RAM) per
> >channel.
> 
> Sounds good.  It really should make it much more trivial to instantiate.
> 
> >I'm not following why you want to reduce the resolution of the clock
> >from the full ADC clock speed (64 MHz)...
> 
> I don't know the timing within a Cyclone device, and I know you are
> already using Gray counters within the FPGA, so I was getting worried
> that a 32-bit accumulator running at 64MHz might cause timing closure
> issues.  It probably isn't an issue, but those carry chains are only
> so long - and the propagation delay really adds up.  I suppose we
> could always just run them as smaller adders with a pipelined carry
> signal instead of having to have the carry asynchronously propagate
> through the chain.

Good observation re pipelining the carry if reqd.  I don't think we're
going to have many counters running at full speed (1 ?), so I'm not
too worried about this.

> >All the TX data comes down a single FX2 endpoint, as does the RX data.
> >Each endpoint is dual or quad buffered in the FX2.  Right now, we're
> >quad-buffering, though to reduce latency (useful for some MACs) we may
> >want to consider going to double buffering.
> 
> Can you have double-buffering for the RX and quad-buffering for the
> TX?  In the TX case, I am not sure double-buffering would allow for a
> lower latency.

Yes, the buffering is independent on Tx and Rx.

> Since everything will be ordered in time, it would seem (to me) to be
> better to have queued up more packets on the outgoing stream.  Correct
> or incorrect?

In both directions, we need enough buffer space to cover any jitter in
the driver and user-space host s/w.

I agree that more on the outgoing stream makes more sense.

Eric




reply via email to

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