[Top][All Lists]

[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: Fri, 23 Mar 2007 14:45:54 -0400
User-agent: Thunderbird 2.0b2 (X11/20070319)

Eric Blossom wrote:
On Thu, Mar 22, 2007 at 03:33:08PM -0400, Brian Padalino wrote:
On 3/22/07, Thibaud Hottelier <address@hidden> wrote:
I can copy the sample to a fifo, but I still have 3 processes that want
to use the RAM a the same time: One to progressively store the packets
coming from the usb bus, one to copy the samples into the corresponding
channel fifo and one to copy the subcommands to be executed now. So, if
I am not mistaken I will have to find a way to synchronize the two last
processes, right?
The FX2 will be writing into a FIFO that stores all packets
intermingled with each other - be it either channel data or control


A read process on that FIFO can separate out the channel data to be
stored into separate channel FIFOs - one FIFO per channel that is
implemented.  That same process can also put the control data into a
control FIFO.  Only one of those is needed.

That's 1 writer and 1 reader on the direct FX2 -> FPGA link.


So, let me summarize:

One dual clock fifo (usb_fifo) to buffer the packet from the FX2. One process store the data from the usb while one other process read them and splits commands (stored in cmd_fifo) from data (stored in chan0_fifo, chan1_fifo, etc). The data in chanX_fifo would be stored like this:

:            :
|  sample 2  |
|  sample 1  |
|  #samples  |
| timestamps |

For each channel fifo, a process would wait for the timestamps to match the time register and then write the next <#samples> to the corresponding channel transmit chain at every tx_clock tick. So we end up with (#channel + 1) fifos.

The problem I see is that between to block of samples in the fifo, there will be some processing delay to read the next timestamps and the #samples. That's why I added a fifo between the usb_fifo and the chanX_fifo in the diagram on the wiki. Is that a real problem?

That also means that only one of the FIFO's (the first one) needs to
use two separate clocks, which is good.  Thibaud, if you haven't
already, be sure to take a look at "Cyclone Device Handbook", Section
III, "Memory".  It spells out the RAM/FIFO/clock configurations

Ok, thanks.

On the RX end, the FX2 can just read from a separate RX FIFO - that is
easy enough to do with a mux at the IO pins and tri-stating the pins.


I can write and read from the fifo at the same time, so one process
would be in charge of filling the channel fifo. Two states: either wait
for the timestamps to match the time, or proceed a copy of the samples
>from the ram to the fifo. The problem is if there are more than one
channels, then this process can be busy filling in channel 1 fifo while
channel 2 fifo is empty. I don't know how to solve that.
Just do it in parallel.  If you are busy filling in channel 1 FIFO and
channel 2 FIFO is empty, then (inherently) channel 2 didn't have
anything that needs to go out any time soon - right?

Can you come up with a sequence of channel packets that would be sent
that you are confused about?  You should be looking at each channel as
an independent source of information to be sent to each channel.
There is a bandwidth limitation that we all have to funnel from the
same USB spigot, but once it's separated out - we have a ton of
bandwidth to handle all the rest of the processing.

I can see an issue where you may have channel 1 and channel 2 start
sending both of their packets at the exact same time.  In this case,
you would want to interleave the data on the 512-byte boundary of the
packet.  Therefore, the USB would receive a TX packet N for channel 1,
TX packet N for channel 2, TX packet N+1 for channel 1, TX packet N+1
for channel 2, ...

Does that make sense?

For instance the packets for one channel can stack up in ram until it's
full, preventing any other channel to receive data.
If you are sending all data in the timed order that they have to be
sent, then you shouldn't have a super rough time keeping up with the
data samples.  8MSPS is about the speed we can send over USB - which
gives us 8 clock cycles per sample to be able to shuffle them around
and do what we need with them.

Did you ever compile the design with Quartus II to get a report of how
many resources we can use for these FIFOs?  It might be a good idea to
see how much space we have in block RAM to distribute and use between
all the channels (just for an estimated target).

FWIW, there are 53 M4K blocks in the EP1C12.  Each one can implement a
256 x 16 FIFO (or 128 x 32 FIFO), enough to hold a single USB packet.  We
use a bit of ram other places, but there should be plenty to go around.

Assume you've got one fifo, perhaps 2x packet length, for the FX2
FIFO, then work it out so that the rest of the channels have at least
say, 2x packet length.

reply via email to

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