Re: [Discuss-gnuradio] USRP packet parsing

[Eric Blossom]

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

Agreed.

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

Yes.

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

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

Yep.

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

Eric