[Top][All Lists]

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

Re: [Discuss-gnuradio] USRP packet parsing

From: Brian Padalino
Subject: Re: [Discuss-gnuradio] USRP packet parsing
Date: Thu, 22 Mar 2007 16:51:10 -0400

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.

You are correct on that one unless you setup an internal linked list
of starting packets and their start times, then you can possibly read
the values with slight offsets for clock latencies out of the same

This, I would argue, is a bit too complicated for the beginning of the
design but may want to be revisited later on.  Maybe I should expand
on this idea.

If we keep a mapping of pointers to packets along with their
respective times of interest to start, even if we had something going
out at the same timestamp, we could theoretically read the data in a
staggered fashion such that if there are multiple packets to process
at once, we read one of the pieces of data at a time for each packet
and send it along the signal chain until that packet no longer needs
servicing.  This would cause us to have a finite number of packets we
could process at one time (# of channels + control) since we would
need 1 clock cycle to read the next packet location for each of the
packets, register them all, then send out the "ship these samples off"
signal.  For packets that have different sizes, we will have to keep
track of how many bytes of data are left to read and take them out of
the queue when it is all finished.  This wouldn't really be a FIFO,
but really a RAM mapping that we would manipulate pretty heavily.

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'll think about this method and what problems there may be, but give
me feedback.  What do you think of this?  See how you can get the
reads all done in one large FIFO instead of needing all the little
ones?  See how much extra complexity it adds to the FSM that reads and
feeds the TX chain?

Yes, currently 39 out of 52 M4K blocks are used. A fifo of 8192 bytes
takes up 16 M4K whereas a fifo of 32 bytes takes up 2 M4K.

How many TX and RX chains does that include?  Can we make a table of
how many M4K blocks are used per TX and per RX channel that is added
to the USRP?  That would be helpful in defining constraints.

Then the two unknown are how many channels there are and how much data
to we want to be able to burst.

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?

Any ideas Eric?


reply via email to

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