On Thu, Aug 21, 2008 at 5:04 PM, Eric Schneider <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
