> From: Brian Padalino [mailto:[EMAIL PROTECTED] > > On Thu, Aug 21, 2008 at 3:11 AM, Eric Schneider > <[EMAIL PROTECTED]> wrote: > > 1. Is it true that there are N RX Sample FIFOs? It seems that the > channels > > are already muxed by the time they get to the packet_builder, no? > > The packet builder itself actually does the muxing: > > http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_li > b/packet_builder.v
I only see one chan_fifodata input to packet builder: http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_lib/pac ket_builder.v#L8 It would appear that the muxing is between the fifos and the packet builder at: http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_lib/rx_ buffer_inband.v#L205 Not a big difference, but it might make your "N Packet Builders" solution that much easier. > The N RX sample FIFOs are built here: I was looking at RTL schematics on a 1Rx1Tx configuration, which oddly enough only has 1 RX FIFO, go figure! *blush* > > 2. Can we just subtract the FIFO size (usedw?) from the timestamp in > the > > packet builder? > > Sure, but what for? I suppose I am not sure what this is addressing? I'm assuming that at least some of the rx timestamp inaccuracy is due to the variable latency introduced by the rx_chan_fifo(s). If usedw represents the number of samples currently in a FIFO, then the actual timestamp of the sample read out of the fifo is current_timestamp - usedw, correct? I do think that building the packets before buffering is a better idea, but adjusting the timestamps might be a quick interim fix. > > 3. When checking timestamps for expired command/data packets, is an > > overflow/wraparound on the timestamp_clock handled? (ref > cmd_reader.v:107, > > chan_fifo_reader.v:145) > > I don't think it's explicitly being taken care of, but I am also not > sure if the logic just ends up working out. This should probably be > looked at and a testbench written. If timestamp_clock is near its max (every ~67s), and a packet is scheduled such that its future time will cause wraparound (making it a smallish number), then the reader will detect that pkt_timestamp < timestamp_clock and discard the packet even though in a "few" ticks timestamp_clock would be 0 again. > > --ets > > Brian --ets _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
