Re: [Discuss-gnuradio] USRP packet parsing

[Eric Blossom]

On Sat, Mar 24, 2007 at 01:46:21PM -0400, Thibaud Hottelier wrote:
> Eric Blossom wrote:
> >On Fri, Mar 23, 2007 at 02:45:54PM -0400, Thibaud Hottelier wrote:

> >I assume that you just copy the received USB packet (including the
> >8-byte header) into the channel FIFO.  The underrun processing really
> >needs to be handled "next to the DACs" and is a function of the
> >current state of the channel, the state of the fifo and the S & E
> >bits in the header.
> >
> 
> What do you mean by "state of the channel" ?
> Are the underrun, overrun, S and E flags per channel ? I thought they 
> were global...

S and E are definitely per channel.  The indicate whether or not it's
OK to run underrun on the channel.  You could think of S & E as
controlling a per-channel bit of state called "OK to underrun".

Consider a frame of 1024 samples (16-bit I & Q), broken up into 9 USB
packets:

Underrunning anywhere within the span of the 9 packets is an error.
Underrunning after the 9th packet is not an error.  The S & E bits are
used to demarcate the frame boundaries.  Note that in a short frame
(one that fits in a single USB packet) S & E would both be set.

Underrun and overrun are logically per channel, but could be "or'd
together" across all channels without much loss of info.

> >>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. 
> >
> >Actually, the timestamp specifies the time that the sample is supposed
> >to hit the DACs, not the time that it enters the signal processing pipe.
> >This may take some thought to implement correctly, since the latency
> >through the pipe varies depending on the details of the pipeline and
> >the interpolation factor.
> >
> >>So we end up with (#channel + 1) fifos.
> >
> >  1 usb_fifo
> >  1 cmd_fifo
> >  N chanX_fifo
> 
> Yes, you are right.
> Actually, if I want to be able to skip outdated packets, the N 
> chanX_fifo will be implemented as RAM blocks, so I can freely access the 
> whole contents and skip packets.

Good.  chanX_fifo could also have the read and write ports have different
sizes.  E.g., 16-bits on the write port, 32-bits on the read port.

> >
> >>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 don't think it's needed.  Can you say more about why you think it's
> >needed?  Remember that the master clock is running at 64MHz, and the
> >packets are coming in at at most 32MB/s.
> 
> So it should be ok.

OK.

> Thibaud

Eric