On Fri, Mar 23, 2007 at 02:59:37PM -0400, Brian Padalino wrote: > On 3/23/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote: > >So, let me summarize: > > > >One dual clock fifo (usb_fifo) to buffer the packet from the FX2. One > >process store the data from the usb while one other process read them > >and splits commands (stored in cmd_fifo) from data (stored in > >chan0_fifo, chan1_fifo, etc). The data in chanX_fifo would be stored > >like this: > > > >: : > >| sample 2 | > >| sample 1 | > >| #samples | > >| timestamps | > >+------------+ > > > >For each channel fifo, a process would wait for the timestamps to match > >the time register and then write the next <#samples> to the > >corresponding channel transmit chain at every tx_clock tick. So we end > >up with (#channel + 1) fifos. > > > >The problem I see is that between to block of samples in the fifo, there > >will be some processing delay to read the next timestamps and the > >#samples. That's why I added a fifo between the usb_fifo and the > >chanX_fifo in the diagram on the wiki. Is that a real problem? > > I was under the impression that if a timestamp is reached that is > already in the past, but was not able to be sent out, a signal will be > asserted stating that it could not be processed. After that, the > offset of the samples will be added to the read pointer, and the next > timestamp should be read. This shouldn't take longer than a few clock > cycles at most. > > On a related note and to keep processing continuous, should the > original packet header that starts the packet and identifies the first > data samples have the actual number of data samples in the entire > packet to be sent down and not just the current samples length? That > way you can have an uninterrupted stream of samples for each > timestamp.
I was thinking that we could handle that with the S + E flags in the packet header. It seems like less state to deal with, and also allows the host to begin transmitting a frame before it knows the full length. Lower latency too. > There probably won't be any hiccups as long as the output sample rate > is less than 64e6/3 since we will have to go from SENDING_SAMPLES -> > CHECK_NEXT_TIMESTAMP -> READ_SAMPLE_LENGTH -> SENDING_SAMPLES in a > state machine feeding the TX values. > > Brian Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
