On Sat, Mar 24, 2007 at 01:46:21PM -0400, Thibaud Hottelier wrote: > Eric Blossom wrote: > >On Fri, Mar 23, 2007 at 02:45:54PM -0400, Thibaud Hottelier wrote:
> >I assume that you just copy the received USB packet (including the > >8-byte header) into the channel FIFO. The underrun processing really > >needs to be handled "next to the DACs" and is a function of the > >current state of the channel, the state of the fifo and the S & E > >bits in the header. > > > > What do you mean by "state of the channel" ? > Are the underrun, overrun, S and E flags per channel ? I thought they > were global... S and E are definitely per channel. The indicate whether or not it's OK to run underrun on the channel. You could think of S & E as controlling a per-channel bit of state called "OK to underrun". Consider a frame of 1024 samples (16-bit I & Q), broken up into 9 USB packets: Underrunning anywhere within the span of the 9 packets is an error. Underrunning after the 9th packet is not an error. The S & E bits are used to demarcate the frame boundaries. Note that in a short frame (one that fits in a single USB packet) S & E would both be set. Underrun and overrun are logically per channel, but could be "or'd together" across all channels without much loss of info. > >>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. > > > >Actually, the timestamp specifies the time that the sample is supposed > >to hit the DACs, not the time that it enters the signal processing pipe. > >This may take some thought to implement correctly, since the latency > >through the pipe varies depending on the details of the pipeline and > >the interpolation factor. > > > >>So we end up with (#channel + 1) fifos. > > > > 1 usb_fifo > > 1 cmd_fifo > > N chanX_fifo > > Yes, you are right. > Actually, if I want to be able to skip outdated packets, the N > chanX_fifo will be implemented as RAM blocks, so I can freely access the > whole contents and skip packets. Good. chanX_fifo could also have the read and write ports have different sizes. E.g., 16-bits on the write port, 32-bits on the read port. > > > >>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 don't think it's needed. Can you say more about why you think it's > >needed? Remember that the master clock is running at 64MHz, and the > >packets are coming in at at most 32MB/s. > > So it should be ok. OK. > Thibaud Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
