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: Thibaud Hottelier
Subject: Re: [Discuss-gnuradio] USRP packet parsing
Date: Thu, 22 Mar 2007 18:44:01 -0400
User-agent: Thunderbird 2.0b2 (X11/20070319)

A quick update while I am understanding your previous message.

It looks like each Rx chain takes up 3 blocks, but the Tx chains does not use any memory block. (Actually Tx0 uses one block but not Tx1).

The Rx and Tx buffers use 16 blocks each.


Thibaud

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.

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

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?

Brian






reply via email to

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