Re: [Discuss-gnuradio] inband timestamp issues

[Brian Padalino]

On Tue, Aug 26, 2008 at 12:03 PM, Eric Schneider
<address@hidden> wrote:
> Okay, so to elaborate on the design options a little more...
>
> I see to primary topologies: packet push, and packet pull.  Both designs
> have a slimmed down packet_builder for each channel.  The multichannel
> multiplexing would be similar in either design.
>
> ### Packet Push:
>
> Packet buffers only, packets built on channel input.
>
> This design pushes preformed packets into a packet FIFO, simply to be to be
> read out via USB as is.
>
> Multiple rxclk ticks would be required while writing the header information
> to the FIFO, which limits our maximum sample speed.
> (I think) Without any channel buffering, the maximum sample rate would be
> 1/6 master clock, since we need 4 additional master cycles to push out the
> header before the first sample of a packet.  Maybe that is an issue, maybe
> not.

Maximum throughput for 16-bit IQ is a decimation by 8, so 6 clock
cycles for header setup should be fine.  Even for decimation rates of
4, which drops IQ down to 8-bits each, the scheme should probably work
fine if you write both I and Q in the same clock cycle.

> 1. New packet begins, I/Q samples waiting, save metadata, write headerH
> 2. Write headerL
> 3. Write timestampH
> 4. Write timestampL
> 5. write I
> 6. write Q

You need the time the first sample comes out of the halfband filter as
the timestamp on the whole packet, so you really have to write the
header, and then wait for the first sample.  When the first sample is
strobed in, get and write the timestamp and then write the IQ sample.
Do this until the entire packet has been filled and repeat N times or
infinitely (depending on setting).

Note that you can make 32-bit wide FIFOs - or even a FIFO with 16-bits
on one side and 32-bits on the other (as long as each side is fully
synchronous to each other).

> ### Packet Pull:
>
> Channel buffering only, packets built on USB read.
>
> This design uses a separate FIFO/s for packet metadata (timestamp, etc)
> parallel to the channel FIFO.  The actual packets are constructed via the
> USB read process.  The metadata FIFO/s would be pretty shallow, as they are
> 1 write per packet.
>
> This design should theoretically be able to read samples at master_clock
> rates.  While the USB/host couldn't stream that, if operated on short burst
> reads (less than the FIFO capacities), it could increase our maximum
> sampling speeds.

This sounds like a decent idea, but the smallest block RAM in the FPGA
is 256x16.  If you wanted to make this just in the fabric, you'll have
to deal with crossing clock domains and that can get a bit hairy with
just flops used as memory.

Even in the previous design, I don't think there is a debilitating
limit to the flow of samples to the host.  Requiring 2 clocks per
sample (and a small buffer per channel) doesn't seem that limiting
with regards to performance.

> Also, since the header isn't built until read, there is the possibility to
> include information in the header that is not available at the first sample.
> E.g.:
>
> * Packet size: don't need to know size in advance, read could be
> interrupted, and the size can be adjusted on USB read.
> * RSSI: e.g. peak, avg, last, etc.
> * Padding: padding would be virtual space, not FIFO space.  Just send 0,
> don't store them.

The packet size is always the same size since the ADC is always
running.  There won't ever really be a lack of samples to be pushed to
the host.  The RSSI might be interesting, but since it's reported with
every packet, you can get a granularity at the packet level which
should be pretty sufficient.  For the padding, I don't think that will
be required since the ADC is always running and there isn't a lack of
samples to send to the host.

This is kind of why I wanted to be able to send down a command to say
"At time=X, receive N packets and then stop" as it builds in the
limiting factor to the command.

> In general, it seems to me that the packet pull design offers more
> performance and flexibility.  Unless someone points out some flaws in my
> reasoning, I will proceed on that path.

The last issue I have is when dealing with sample overruns.  Can this
scheme easily recover if the sample FIFO is full when a new sample
comes in, but the metadata FIFO has header information pushed into it?
 In the packet push situation, there will be a discontinuity in the
timestamps inherently within the system.

I prefer the packet pushing idea, but feel free to do what you feel is
the better idea.

Brian