Re: [Discuss-gnuradio] USRP packet parsing

[Thibaud Hottelier]

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

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