On Fri, Mar 23, 2007 at 10:15:12AM -0400, Brian Padalino wrote: > On 3/23/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > >I think I steered us down the wrong path with the shared RAM idea. > >We really do want a dedicated read port for each channel in the Tx > >direction. This is easy if we assigned a FIFO (or dedicated RAM) per > >channel. > > Sounds good. It really should make it much more trivial to instantiate. > > >I'm not following why you want to reduce the resolution of the clock > >from the full ADC clock speed (64 MHz)... > > I don't know the timing within a Cyclone device, and I know you are > already using Gray counters within the FPGA, so I was getting worried > that a 32-bit accumulator running at 64MHz might cause timing closure > issues. It probably isn't an issue, but those carry chains are only > so long - and the propagation delay really adds up. I suppose we > could always just run them as smaller adders with a pipelined carry > signal instead of having to have the carry asynchronously propagate > through the chain.
Good observation re pipelining the carry if reqd. I don't think we're going to have many counters running at full speed (1 ?), so I'm not too worried about this. > >All the TX data comes down a single FX2 endpoint, as does the RX data. > >Each endpoint is dual or quad buffered in the FX2. Right now, we're > >quad-buffering, though to reduce latency (useful for some MACs) we may > >want to consider going to double buffering. > > Can you have double-buffering for the RX and quad-buffering for the > TX? In the TX case, I am not sure double-buffering would allow for a > lower latency. Yes, the buffering is independent on Tx and Rx. > Since everything will be ordered in time, it would seem (to me) to be > better to have queued up more packets on the outgoing stream. Correct > or incorrect? In both directions, we need enough buffer space to cover any jitter in the driver and user-space host s/w. I agree that more on the outgoing stream makes more sense. Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
