Jim Granville wrote: [Old topic Issues on Shift Register in a Clockless UART ] > That design can be done with a delay line ( which needs baud-precision - not really a common building block...), plus it's not clear how it would manage sync in packed streaming data... >
( I've changed the topic, as that thread was looking like someone's homework.)
I think there is scope to study more what can, and can't be done with delay lines. FPGAs cannot clock above 1GHz, but they CAN resolve time to ~140ps regions, in some cases ( see Peter A's posts ).
Taking the example above, delay line bit sampling is easy enough, but the byte sync is rather harder. I think the only solution is a longer delay line, and wider stop bits - so the data is framed as 8(+) Stop bits, 1 start Bit, 8 data bits... (8 bits is illustrative only)
A capture is triggered only when the delay line taps show
8 stop bits, and one start - otherwise the data 'leaving' the delay line can trigger false captures.
Txmit would be via a register chain/MUX tree, that loads/holds until flipped from 'wait' to 'delaylinego', then data would stream out. Pacing would be done from a slower clock, but the time domain precision of this would be delay element sized (~140ps) This assumes, of course, that access to this detail is possible in the FPGA hardware :)
All up, data rates in the GigaBaud region would appear do-able.
There are benefits to thinking more in time-domain, rather than simple MHz - once the ideas are there, the tools and fabric can follow.
-jg