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.
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. 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 the Tx direction, the flow control between the FX2 and the FPGA is implemented with a single pin, "HAVE_SPACE" (I may have the name wrong, but I'm close). This is currently asserted by the FPGA whenever there's room for the FPGA to receive a 512 byte packet from the FX2 across the GPIF. When the FX2 sees this pin asserted, and there's a packet ready in the FX2, it schedules a 512 byte DMA xfer across the GPIF.
Neat - the buffering should be very nice for this.
It's similar in the Rx direction. The FPGA asserts HAVE_PKT_AVAIL when it has something that it wants the FX2 to pull from the FPGA. The GPIF is configured such that it is mastered from the FX2 side.
Nice. Thanks for the answers. Brian _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
