[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 05:51:07 -0700
User-agent: Mutt/1.5.9i

On Thu, Mar 22, 2007 at 04:51:10PM -0400, Brian Padalino wrote:
> On 3/22/07, Thibaud Hottelier <address@hidden> wrote:
> >So the fpga would only use fifo and push the data to next one. It does
> >not work if shared RAM is used to avoid copy between buffers; or I am
> >completely wrong and I fail to understand your point.

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

> It's an interesting idea, and can probably be engineered to be pretty
> cool.  It will also be conducive to lowering the resolution of the
> 32-bit timestamp to do things since we'll have to multiplex the
> pulling of data out of the RAM.

I'm not following why you want to reduce the resolution of the clock
from the full ADC clock speed (64 MHz)...

> Right - that somewhat becomes a latency issue.  How quickly can we get
> data down once a flag is sent to the host saying "a FIFO is half full
> - requesting more data".  Does this control really need to be in
> there?  How much memory is within the FX2 for USB endpoints?  Could
> that be a temporary place to store packets and from there is where the
> request for more data comes?

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.

In the Tx direction, the flow control between the FX2 and the FPGA is
implemented with a single pin, "HAVE_SPACE" (I may have the name
wrong, but I'm close).  This is currently asserted by the FPGA
whenever there's room for the FPGA to receive a 512 byte packet from
the FX2 across the GPIF.  When the FX2 sees this pin asserted, and
there's a packet ready in the FX2, it schedules a 512 byte DMA xfer
across the GPIF.

It's similar in the Rx direction.  The FPGA asserts HAVE_PKT_AVAIL
when it has something that it wants the FX2 to pull from the FPGA.
The GPIF is configured such that it is mastered from the FX2 side.

I glad we're having this discussion!


reply via email to

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