pulse jitter due to clock

Hi to everyone,
I'm developing some electronics to make a time measurement with a 
resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving 
the signals to the ASIC through an FPGA.
The way is very simple, basically I have some signals coming to my fpga 
which I will mask with some combinatorial logic and a configurable 
register so that I can allow some measurements or some others. The 
output of this "masking" will go to the ASIC.
They assert (and here is the question) that a clocked device as an FPGA 
may add some jitter to the signals due to the substrate  current 
overload (for the presence of the clock) that will lead to some 15 ps 
jitter over the signals. I don't know how they could resolve this value 
but I'm assuming they were telling the truth about numbers (at least, 
while I have some doubts about explanation of those numbers).
Can anyone say something about this? Does it sound reasonable?

Al

-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al,

Passing a signal through an FPGA, and then expecting to resolve 25 ps is
not a good idea.

The FPGA may add as much as thousands (yes thousands) of picoseconds of
jitter:  it all depends on the number of clocks running, their
frequencies, if they are asynchronous or not, the number of CLB flip
flops toggling (internal simultaneous switching), and the number of
external IOs switching (SSO noise).

Additionally, since jitter is caused by anything being less than
perfect, this also includes the power distribution network, and the
signal integrity of all the traces (rise times, fall times, reflections,
etc.).

The jitter floor for a FPGA that is doing nothing at all (signal in,,
signal out) is probably around 35 picoseconds peak to peak.  A
completely synchronous design with everything done perfectly will
probably come in at around 150 picoseconds, peak to peak jitter.

An ASIC is probably the last thing I would choose to do jitter
measurement.  As I have said, you do anything wrong (at all), and you
will fail.  Jitter is the result of converting amplitude variations into
phase variations.  AM to PM is the bane of our existence:  it can not be
prevented, only minimized.  Miss one contributor, and you fail to meet
your specification (and delay your project by many months).

To resolve the time you desire, it requires very high speed design
(PECL), and virtually perfect power distribution, and signal integrity.

I hope others here on the newsgroup will provide you with some better
guidance, as all I have done is explained the problems.

Austin



Al wrote:
> Hi to everyone,
> I'm developing some electronics to make a time measurement with a
> resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving
> the signals to the ASIC through an FPGA.
> The way is very simple, basically I have some signals coming to my fpga
> which I will mask with some combinatorial logic and a configurable
> register so that I can allow some measurements or some others. The
> output of this "masking" will go to the ASIC.
> They assert (and here is the question) that a clocked device as an FPGA
> may add some jitter to the signals due to the substrate  current
> overload (for the presence of the clock) that will lead to some 15 ps
> jitter over the signals. I don't know how they could resolve this value
> but I'm assuming they were telling the truth about numbers (at least,
> while I have some doubts about explanation of those numbers).
> Can anyone say something about this? Does it sound reasonable?
> 
> Al
> 

"Austin Lesea" <austin@xilinx.com> wrote in message 
news:ejkndb$kkj1@cnn.xsj.xilinx.com...
>
> phase variations.  AM to PM is the bane of our existence:  it can not be
> prevented, only minimized.  Miss one contributor, and you fail to meet
> your specification (and delay your project by many months).
>
Hi Austin,
I guess using differential signals is a good way to reduce AM to PM 
modulation. Is it true that the Virtex4 BUFIO regional clock is a truly 
differential signal from the BUFIO to the IOB clock pins?

I read 
http://www.xilinx.com/publications/xcellonline/xcell_52/xc_v4xesium52.htm
QUOTE:-
Each of these input pins or input pin pairs can connect to a BUFIO that 
drives a high-speed differential I/O clock network, which is dedicated to 
the I/O circuits and is ideally suited for source-synchronous data capture 
using the built-in serializer/deserializer (SerDes).
END QUOTE


So, that's a cool thing. Did you guys do any measurements on the jitter 
performance of this? I.e. how much jitter is added to a differential data 
signal coming out of an IOB clocked by a BUFIO driven from a differential 
clock coming to the FPGA 'Clock Capable' pins.?

Cheers, Syms.

p.s. I think 1000ps is a lot of jitter even for an FPGA. Low 100's of ps is 
probably nearer to the mark. 

Al <alessandro.basili@cern.ch> wrote:

>Hi to everyone,
>I'm developing some electronics to make a time measurement with a 
>resolution of 25 ps. I'm using a dedicated ASIC to do so 

Let me guess an Acam part?

>Can anyone say something about this? Does it sound reasonable?

If you are trying to measure signals with 25ps resolution you have to be
extremely careful with *everything* those signals pass through. 

Passing them through as little as possible would be a good starting
approach. 
-- 

Symon,

See below,

Austin

-snip-

> I guess using differential signals is a good way to reduce AM to PM 
> modulation. Is it true that the Virtex4 BUFIO regional clock is a truly 
> differential signal from the BUFIO to the IOB clock pins?

V4 has an LVDS input, and LVDS output buffer.  The signals are single
ended inside the IOB, and IOB logic.  Where they interface to the global
buffers, they go differential again.

V4 improves the AM to PM over V2 and V2P, but it is still not perfect
(there is that little bit of single ended still there to be influenced,
and the differential balance is also never perfect).

-snip-

> So, that's a cool thing. Did you guys do any measurements on the jitter 
> performance of this? I.e. how much jitter is added to a differential data 
> signal coming out of an IOB clocked by a BUFIO driven from a differential 
> clock coming to the FPGA 'Clock Capable' pins.?

Yes, we have performed a great deal of characterization.  And the clock
capable pins, or even a plain IOB has no real difference in jitter
performance.

-snip-

> p.s. I think 1000ps is a lot of jitter even for an FPGA. Low 100's of ps is 
> probably nearer to the mark. 

I agree.  Just that we have seen cases where the customer did a number
of things that conspired to ruin their day.  And, we have seen cases
where even with a great deal of jitter, all timing margins were still
met, and the design still worked perfectly.  For example, if you provide
a forwarded clock (source synchronous system) with your data, the clock
is likely to jitter around exactly at the same time and direction as the
data, and the receiving chip has no trouble at all, even with completely
awful peak to peak jitter!

I have posted before that in the past, if you connected every single CLB
DFF to a global clock bus, and clocked all DFF at the same time (and
they all changed state, as in a 0101.. pattern) the device would shut
down due to the simultaneous nature of switching everything all at once
collapsing the power rails.

Virtex 4 SparseChevron(tm) packages were the first family where you
could do that, and the rails didn't collapse.  Now, this is a
pathological case (IMO), but it still makes my point:  you can do things
that will not work.  We are here to help you with techniques that will work.

Al wrote:
> Hi to everyone,
> I'm developing some electronics to make a time measurement with a 
> resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving 
> the signals to the ASIC through an FPGA.
> The way is very simple, basically I have some signals coming to my fpga 
> which I will mask with some combinatorial logic and a configurable 
> register so that I can allow some measurements or some others. The 
> output of this "masking" will go to the ASIC.
> They assert (and here is the question) that a clocked device as an FPGA 
> may add some jitter to the signals due to the substrate  current 
> overload (for the presence of the clock) that will lead to some 15 ps 
> jitter over the signals. I don't know how they could resolve this value 
> but I'm assuming they were telling the truth about numbers (at least, 
> while I have some doubts about explanation of those numbers).
> Can anyone say something about this? Does it sound reasonable?
> 
> Al
> 

For time measurements of this order, you'll need a *very* stable and low 
jitter clock source. I would suggest a PECL differential, or even 
perhaps a truly stabilised (thermally) oscillator.

There's an old saw that the measuring equipment should be at least 5 
times better than the measurement, so you're looking at 5ps of jitter in 
the _entire_ measurement system. If, however, you can live with 25ps of 
total jitter in the measurement system, then it may be do-able, but you 
are aiming for resolution in the order of 20GHz (assuming one edge to be 
captured is a half of a cycle).

Keep in mind that you will have jitter introduced for:

1. Clock / signal input indeterminacy. At some point, you have to 
capture your signal. The FF will switch somewhere in the indeterminate 
region. The slower your input source, the worse this is. You can't 
expect a FF to switch at the same level two consecutive times either, 
although usually adjacent clocks will switch at a close level. 
Estimation of that jitter depends on the technology you are using.

2. Oscillator jitter. There will always be jitter on an oscillator. It 
might be low, but you can't get rid of it.

3. Possible metastability. This afflicts all FFs, and although it can be 
worked around, you should be aware of it. (It's not a high level issue, 
but it does exist - there was a thread on it recently)

4. PCB routing. All PCBs will exhibit deterministic jitter (which can be 
calculated). This will be made worse if you have vias on highspeed nets 
(which can be alleviated somewhat with differential techniques I won't 
go into here). Unless you are using waveguide or optical techniques (and 
even they suffer from jitter too) you'll have a low pass filter 
introducing jitter. Then there's track adjacency, impulse response of 
the power etc.
Last, but not least, is impedance mismatch. There's always some, however 
small you may be able to get it.

I have seen a single via add 50ps of deterministic jitter on fast 
signals (edge rate about 10^4V/us) on FR4-13. I have no idea what PCB 
material you are using or intend to use, but keep this in mind.

Another issue of importance is which form of jitter is your biggest 
issue: Cycle to cycle? rms? peak to peak? long term (sometimes known as 
frequency drift)

Some food for thought.

Cheers

PeteS

"Austin Lesea" <austin@xilinx.com> wrote in message 
news:ejkus8$kkk1@cnn.xsj.xilinx.com...
>
>> So, that's a cool thing. Did you guys do any measurements on the jitter
>> performance of this? I.e. how much jitter is added to a differential data
>> signal coming out of an IOB clocked by a BUFIO driven from a differential
>> clock coming to the FPGA 'Clock Capable' pins.?
>
> Yes, we have performed a great deal of characterization.  And the clock
> capable pins, or even a plain IOB has no real difference in jitter
> performance.
>
Hi Austin,
Thanks for getting back! Your reply surprised me; I now wonder just what 
does the diff clock routing bring to the party if not better jitter 
performance? BTW, are the regular global clock networks differential?
Thanks, Syms. 

nospam schrieb:
> Al <alessandro.basili@cern.ch> wrote:
> 
> 
>>Hi to everyone,
>>I'm developing some electronics to make a time measurement with a 
>>resolution of 25 ps. I'm using a dedicated ASIC to do so 
> 
> 
> Let me guess an Acam part?
Could also be from MSC in Darmstadt, but as he has a CERN email address
I am sure he is using the HPTDC developed at CERN. The HPTDC homepage
has vanished, but we use it in one of our TDC boards:
http://cronologic.de/products/time_measurement/hptdc/

>>Can anyone say something about this? Does it sound reasonable?

Slow input slopes create crosstalk in the HPTDC. Therefore it makes
sense to have extremely fast LVDS input buffers in front of the chip
anyway. If you use buffers with enable (or an AND-gate) you can control
that from the FPGA to mask the signals. No need to route the signals
through the FPGA.

You can contact us directly if you have more detailed questions
regarding the HPTDC and FPGAs.

Kolja Sulimma

PeteS schrieb:

> I have seen a single via add 50ps of deterministic jitter on fast
> signals (edge rate about 10^4V/us) on FR4-13. I have no idea what PCB
> material you are using or intend to use, but keep this in mind.

This applies for serial datastreams were reflections from previous edges
add jitter to the following edges. In time measurement applications
the edges are extremly rare. Before the next edge any reflections will
long have settles. Therefore you do not care about any pulse form
modification as long as it is deterministic.

Kolja Sulimma

Symon,

Well, yes they are differential across the chip.

And, what they accomplish is less jitter than if they had been single ended.

It is quite a battle:  voltage goes down, distances get longer (for 
smaller wires), more stuff is switching, etc.  Gains made may not appear 
to be substantial, yet without them, the result would have been far 
worse (no small gain, but a huge loss of performance).

Austin


Symon wrote:

> "Austin Lesea" <austin@xilinx.com> wrote in message 
> news:ejkus8$kkk1@cnn.xsj.xilinx.com...
> 
>>>So, that's a cool thing. Did you guys do any measurements on the jitter
>>>performance of this? I.e. how much jitter is added to a differential data
>>>signal coming out of an IOB clocked by a BUFIO driven from a differential
>>>clock coming to the FPGA 'Clock Capable' pins.?
>>
>>Yes, we have performed a great deal of characterization.  And the clock
>>capable pins, or even a plain IOB has no real difference in jitter
>>performance.
>>
> 
> Hi Austin,
> Thanks for getting back! Your reply surprised me; I now wonder just what 
> does the diff clock routing bring to the party if not better jitter 
> performance? BTW, are the regular global clock networks differential?
> Thanks, Syms. 
> 
>