Re: [Discuss-gnuradio] USRP packet parsing

[Eric Blossom]

On Fri, Mar 23, 2007 at 02:59:37PM -0400, Brian Padalino wrote:
> On 3/23/07, Thibaud Hottelier <address@hidden> wrote:
> >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?
> 
> I was under the impression that if a timestamp is reached that is
> already in the past, but was not able to be sent out, a signal will be
> asserted stating that it could not be processed.  After that, the
> offset of the samples will be added to the read pointer, and the next
> timestamp should be read.  This shouldn't take longer than a few clock
> cycles at most.
> 
> On a related note and to keep processing continuous, should the
> original packet header that starts the packet and identifies the first
> data samples have the actual number of data samples in the entire
> packet to be sent down and not just the current samples length?  That
> way you can have an uninterrupted stream of samples for each
> timestamp.

I was thinking that we could handle that with the S + E flags in the
packet header.  It seems like less state to deal with, and also allows
the host to begin transmitting a frame before it knows the full
length.  Lower latency too.

> There probably won't be any hiccups as long as the output sample rate
> is less than 64e6/3 since we will have to go from SENDING_SAMPLES ->
> CHECK_NEXT_TIMESTAMP -> READ_SAMPLE_LENGTH -> SENDING_SAMPLES in a
> state machine feeding the TX values.
> 
> Brian

Eric