[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] inband timestamp issues

From: Brian Padalino
Subject: Re: [Discuss-gnuradio] inband timestamp issues
Date: Tue, 26 Aug 2008 17:08:34 -0400

On Tue, Aug 26, 2008 at 3:21 PM, Eric Schneider
<address@hidden> wrote:

 -- snip --

> What do you see as the advantage of the push design?

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.

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.

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.

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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]