[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 15:33:08 -0400

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.

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

What do you think of all that?


reply via email to

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