Re: [Discuss-gnuradio] inband timestamp issues

[Brian Padalino]

On Thu, Aug 21, 2008 at 5:04 PM, Eric Schneider
<address@hidden> wrote:
> Just thinking out loud here...
>
> Given your suggested solution (which I like):
>
> N RX Sample Streams -> N Packet Builders -> N Packet FIFOs -> N:1 FIFO MUX
> -> FX2 USB Interface
>
> The FIFO MUX could be a module that implements a virtual FIFO output, and
> automatically selects (and emulates) the input FIFO based on fullness, so
> that the fullest FIFO always gets read first.  A tie would default to
> natural ordering.  There should also be a minimum size (128?) or a
> channel_ready input to prevent premature FX2 transfer.  Sounds pretty simple
> and should just drop-in to the existing design.

There is already a FIFO which has the master_clock on one side, and
the FX2 on the other side.  I was thinking we connect the output of
the packet_builder to those FIFOs.  They already have a have_pkt
output which can be fed into the FIFO mux.  The mux can cycle through
the have_pkt signals of each of the FIFOs without giving precedence to
one or the other and signal the FX2 there is a packet ready to
transfer - muxing the USB data lines for the DMA transfer.  I believe
this is similar to what you're talking about, but I also think the
packet_builder has to have some changes since it is not a streaming
module.

Ideally I'd like to see the packet_builder turn into something that
just inserts headers at the appropriate times in the stream and can
have a mechanism to build an indefinite number of packets (infinite
receive) or a specific number (possibly a 16 or 32-bit count?).

> What about moving the Packet FIFO into packet_builder?  It seems like we are
> just be wasting cycles by pushing headers to an external FIFO when we could
> handle that with some read logic.  In this way, the first "FIFO" reads from
> packet_builder actually output internally generated/stored header values,
> then later the internal FIFO with the channel data.  But maybe it's more
> trouble than it's worth.
>
> --ets

Brian