Time domain/Delay line UARTs - high speeds

[Jim Granville]

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

 

[Peter Alfke]

Let me describe today's and tomorrow's capabilities.
Inside the FPGS, the general-purpose routing structure makes it difficult to
clock GP logic much faster than 500 MHz, but dedicated functions can be
pushed faster, perhaps to 800 MHz. On-chip clock delay can be completely
eliminated, and global clock skew can (hopefully) be kept below 150 ps.
Clock phase shifting can have <30 ps resolution.
When saving pc-board area and interconnect pins is important, dedicated
transceivers can run (today in SpartanProX) at slightly over 10
gigabits/second (100 picosecond per bit).
These are all fairly realistic parameters for aggressive designs.

Just my personal observations, not an official Xilinx position.
Peter Alfke

From: Jim Granville <no.spam@designtools.co.nz
Organization: TelstraClear
Newsgroups: comp.arch.fpga
Date: Fri, 23 Apr 2004 10:48:59 +1200
Subject: Time domain/Delay line UARTs - high speeds

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

 

[Peter Alfke]

I meant to say that Virtex-IIProX has 10+gigabit/sec dedicated transceivers.
There is and will be no SpartanProX.
Sorry for the typo :-(
Peter Alfke

From: Peter Alfke <peter@xilinx.com
Organization: Xilinx,Inc
Newsgroups: comp.arch.fpga
Date: Thu, 22 Apr 2004 16:50:11 -0700
Subject: Re: Time domain/Delay line UARTs - high speeds

Let me describe today's and tomorrow's capabilities.
Inside the FPGS, the general-purpose routing structure makes it difficult to
clock GP logic much faster than 500 MHz, but dedicated functions can be
pushed faster, perhaps to 800 MHz. On-chip clock delay can be completely
eliminated, and global clock skew can (hopefully) be kept below 150 ps.
Clock phase shifting can have <30 ps resolution.
When saving pc-board area and interconnect pins is important, dedicated
transceivers can run (today in SpartanProX) at slightly over 10
gigabits/second (100 picosecond per bit).
These are all fairly realistic parameters for aggressive designs.

Just my personal observations, not an official Xilinx position.
Peter Alfke

From: Jim Granville <no.spam@designtools.co.nz
Organization: TelstraClear
Newsgroups: comp.arch.fpga
Date: Fri, 23 Apr 2004 10:48:59 +1200
Subject: Time domain/Delay line UARTs - high speeds

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