[Top][All Lists]
[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
- Re: [Discuss-gnuradio] USRP packet parsing, (continued)
- Re: [Discuss-gnuradio] USRP packet parsing, Thibaud Hottelier, 2007/03/22
- Re: [Discuss-gnuradio] USRP packet parsing, Brian Padalino, 2007/03/22
- Re: [Discuss-gnuradio] USRP packet parsing, Thibaud Hottelier, 2007/03/22
- Re: [Discuss-gnuradio] USRP packet parsing, Brian Padalino, 2007/03/22
- Re: [Discuss-gnuradio] USRP packet parsing, Thibaud Hottelier, 2007/03/22
- Re: [Discuss-gnuradio] USRP packet parsing, Brian Padalino, 2007/03/22
- Re: [Discuss-gnuradio] USRP packet parsing, Thibaud Hottelier, 2007/03/22
- Re: [Discuss-gnuradio] USRP packet parsing, Eric Blossom, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Eric Blossom, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Brian Padalino, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing,
Eric Blossom <=
- Re: [Discuss-gnuradio] USRP packet parsing, Eric Blossom, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Eric Blossom, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Thibaud Hottelier, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Brian Padalino, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Thibaud Hottelier, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Eric Blossom, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Eric Blossom, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Eric Blossom, 2007/03/23
- Re: [Discuss-gnuradio] USRP packet parsing, Thibaud Hottelier, 2007/03/24
- Re: [Discuss-gnuradio] USRP packet parsing, Thibaud Hottelier, 2007/03/24