Re: [Discuss-gnuradio] Gigabit Design Proposal

[John Gilmore]

A critical parameter will be the response time (latency) required on the
host.  This is largely controlled by the amount of bufferring on
the GITD.  Pushing in the opposite design direction is the desire to
minimize latency and cost on the GITD itself.

A memory-mapped interface is great for software but adds to the 
complexity and bus bandwidth requirements when designing for hardware. 
The memory bus has to handle simultaneous packet reads & writes, etc.

It would be a very much simpler design if it had only a single packet
buffer for xmit (and another for rcv).  Everything would be serial
(FIFO) rather than random access, and the data would just flow thru.
The catch is that when the last sample of a packet was sent to the
DAC, the host would have a very short time in which to send the next
packet containing the next sample.

Adding a simple FIFO on the DAC side barely increases the complexity
but lowers the required latency (adding sampleperiod x fifosize nanoseconds
of latency). This is the approach taken on the USRP, as I understand it.

If the Ethernet core can steer each received packet into an
appropriate fifo (based on its UDP port number, for example) then
multiple DACs, ADCs, up- or down-converters can be accommodated.

(Even if this set of FIFOs ends up implemented with an external RAM,
it maybe best to conceptualize it as FIFOs rather than random access
memory.  A better FPGA or tighter latency spec could result in
sucking that function entirely into the FPGA.)

    John