RE: [Discuss-gnuradio] inband timestamp issues

[Eric Schneider]

> -----Original Message-----
> From: Brian Padalino [mailto:address@hidden
> 
> You're generating significantly less muxing at the interface to the
> FX2.  In the pull design, you have 2 muxes per channel and at least 2
> channels (one control, one data).  Increasing the number of channels
> grows significantly faster using this method.

I'll have to ponder this.  I don't see much of a difference.  For push, you
are muxing input to the packet FIFO.  For pull I'm muxing the output to
usbdata.  It seems pretty equivalent to me.

> Moreover, you're not eliminating packet FIFOs - you're creating 2 sets
> of FIFOs.  Header FIFOs and Data FIFOs.  Your inband metadata goes
> into the header FIFO where the samples go into the data FIFO.

The current design has channel and packet FIFOs.  Either push or pull will
be an improvement IMO, either/or.  The pull will have an extra FIFO per
channel, but no packet FIFO.  Push, only the packet FIFO.

> In the push design, you have one set of packet FIFOs for each channel
> and no data FIFOs since the packets are built as the samples come in.
> I believe this design has the most efficient use of BRAM as you will
> never use any more than 4 16-bit words per packet depth of data FIFO
> in the pull method.

I think that you are correct that push is better in terms of memory
utilization, but I'm not sure of the importance.  The metadata FIFO would be
minimal.  2*16*256 / channel would be more than enough, wider with more
metadata like RSSI.

> The push design works for the USRP and the inherent limitations of the
> platform without increasing the complexity significantly.  I don't
> believe your assertion that the pull design can run at full-speed on
> both sides.  You still have data insertion going on - which slightly
> increases your data rate for that period of time.  You WILL overflow
> at some point in time.  For any inband signaling, you can never run at
> full speed since you're generating more data than can ever get sent
> over the channel.

In the USRP, there is no way to run at master_clock rates, just because of
the architecture.  However, using pull, the rx_buffer_inband module could,
simply because we can always absorb samples as fast as they come (no pauses
to generate headers).  Obviously, in order to continuously stream, the
usbdata bus would have to run faster/wider than master_clock channel rates
to deal with the extra header data; which in the USRP, it doesn't.  But that
is a limitation the module's use, not the module itself.  Even in the USRP,
pull could sample at maximum channel rates, for short durations of time,
limited only by FIFO capacity.

> But, as I said before, feel free to implement what you believe is the
> better design.

Just to be clear, I am only trying to figure out the best design.  If pull
has problems that I am not accounting for, then I'd rather find out now,
prior to spending the design time.  I am the newcomer here, and greatly
value your opinion.  I hope I don't come across otherwise.  I suspect that
either design would work well.

--ets