pulse jitter due to clock

A correction to my previous post

Al wrote:
> The reference you pick this definition from is most likely the same one 
> which says:
> "Jitter is composed of both deterministic and Gaussian"
> 
I didn't read the whole document 
(http://wavecrestcorp.com/technical/VISI_6_Getting_Started_Guides/6understanding.PDF), 
but still it goes through data and clock receiving matters which are far 
away this topic (InterSymbol interference, duty cycle distorsion, etc.).
Sorry about that
Al

-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

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

If you pass your trigger through the FPGA, your measurement can be off 
by +/- hundreds of picoseconds from one measurement to the next.  Over 
many measurements your gaussian jitter will be increased by a 
substantial amount only because of the jitter.

Using a complex trigger condition through an FPGA doesn't mean you have 
to measure the signal coming out of the FPGA.  Generate the mask in the 
FPGA and use it to gate the original (always on) trigger signal the 
measurement is performed on.  You chooses the edge(s) to analyze but 
through a very clean external gate unaffected by the jitter-laden mask 
signal coming from the FPGA.

If you insist on analyzing the signal leaving the FPGA, please let me 
know the company you're working for so I can avoid considering your 
products for any future needs.

"Al" <alessandro.basili@cern.ch> wrote in message 
news:ejul8l$iv7$1@cernne03.cern.ch...
> Symon wrote:
>
>> You might like to consider a crosspoint switch solution. I think 
>> Mindspeed and Vitesse might have something you could use.
>
> Maybe this is a good alternative, which maight have been used. 
> Unfortunately the power consumption is something like 2.5 Watts for a 500 
> MHz BW chip. Consider that our DSP boards which holds 2 FPGAs, a DSP, a 
> Ram chip and a Flash chip and run with 4 simultaneous link at 100 Mbits 
> each will reach up to 1.2 Watts only.
> Unfortunately power budget is mandatory in our case, moreover we need have 
> 5 channels per board and 20 boards, so it will soon reach a power budget 
> that is not really acceptable.
>
Hi Al,
Well, after thinking about your requirements, I guess the best solution to 
you is to switch the signals with PIN diodes. Like this:-

http://www.radio-electronics.com/info/circuits/diode_simple_attenuator/diode_attenuator.php

The diode's resistance when it's on is of the order of an ohm or two, so 
they're very low noise, much better than GaAs fets. (My microwave engineer 
buddy has a big downer on GaAs switches, they blow up too easily and they're 
more noisy.) You can probably get away with connecting a whole bunch of PIN 
diode switches together as you're only looking for a one shot type deal, so 
reflections aren't too big a problem. As only one diode will be on at any 
one time, the others being reverse biased, it'll be the only one using 
current, so you only need about 5ma or so.
I guess PIN diodes are good at radiation, what's to go wrong?
HTH, Syms.

Symon wrote:
> Hi Al,
> Well, after thinking about your requirements, I guess the best solution to 
> you is to switch the signals with PIN diodes. Like this:-
> 
> http://www.radio-electronics.com/info/circuits/diode_simple_attenuator/diode_attenuator.php
> 
> The diode's resistance when it's on is of the order of an ohm or two, so 
> they're very low noise, much better than GaAs fets. (My microwave engineer 
> buddy has a big downer on GaAs switches, they blow up too easily and they're 
> more noisy.) You can probably get away with connecting a whole bunch of PIN 
> diode switches together as you're only looking for a one shot type deal, so 
> reflections aren't too big a problem. As only one diode will be on at any 
> one time, the others being reverse biased, it'll be the only one using 
> current, so you only need about 5ma or so.
> I guess PIN diodes are good at radiation, what's to go wrong?
> HTH, Syms.
> 
> 

I think that could be a good solution too, maybe next project!
Regards

Al


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

John_H wrote:
> Al wrote:
> 
> If you pass your trigger through the FPGA, your measurement can be off 
> by +/- hundreds of picoseconds from one measurement to the next.  Over 
> many measurements your gaussian jitter will be increased by a 
> substantial amount only because of the jitter.

Could you tell me why and how the FPGA will affect this measurement? I 
didn't understand it, as simple as that.
> 
> Using a complex trigger condition through an FPGA doesn't mean you have 
> to measure the signal coming out of the FPGA.  Generate the mask in the 
> FPGA and use it to gate the original (always on) trigger signal the 
> measurement is performed on.  You chooses the edge(s) to analyze but 
> through a very clean external gate unaffected by the jitter-laden mask 
> signal coming from the FPGA.

This is correct, but unfortunately the system has a very wide 
distributed trigger, so this operation has to be done in many places and 
will result in a components overload.
> 
> If you insist on analyzing the signal leaving the FPGA, please let me 
> know the company you're working for so I can avoid considering your 
> products for any future needs.

Very kind, but no worries I will not bother you with some 
time-measurement product, I will mostly bother you with some other 
questions, waiting for some other useful answers


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al,

I am concerned you may not have the skills to do this right.  I suggest 
you have an engineering review of the proposed architecture with those 
who know this field.

See below,

Austin

-snip-

> I'm sorry Austin I didn't get your point at all. I'm not talking about 
> delay (and I think you got this), so how can a signal-in signal-out add 
> 35 picoseconds jitter? You said peak to peak but maybe I didn't explain 
> what jitter is to me:

I use the ITU definition, jitter is the deviation from a perfect 
reference in the zero crossing(s) of a signal.

Into, and out of, any circuit adds white noise.  If the signal has a 
finite rise time (which they all do), the this noise creates timing 
uncertainty (jitter).

> Given a fixed source that we know is stable in time (no matter how)

Good trick.  How do you define stable?  A native rubidum cell?  A double 
oven crystal resonator?  A SAW oscillator?  What frequency?  What is the 
reference's time interval error (TIE)? A stable reference is an oxymoron 
(contradiction in terms), as with any reference, there are imperfections.

  and
> a signal produced from this source with some combinational logic and 
> delay (like cables and I/O delay), the output distribution will be 
> gaussian if we have a white-noise environment. The jitter I'm talking 
> about will be (basically) the sigma of this distribution.

Averaging over time will allow you to get a better measurement, but only 
if you can obtain many such samples, and there are no deterministic 
causes of jitter (of which there are many, such as power supply noise, 
or other signals switching, or pattern jitter from inter-symbol 
interference, and the list never seems to end).

>> 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.
> 
> Is that mean that all these ASIC TDC you find around are just junk? They 
> are ASIC, nothing more, just dedicated device to measure Time. There are 
> basically two types of TDC AFAIK:

If someone has something that already works, and is proven, by all means 
use it and stop trying to re-invent the wheel.

> 1) time expantion based: which is an amplitude measurement that is 
> proportional to a time measurement
> 2) Calibrated standard-cell delay to shift in the value.
> 
> In the latest the measurement is quite more precise because typically 
> the time-expansion circuitry is an analogue circuit which has a much 
> worse stability then an integrated standard-cell delay.

As I said, if you already have something that works, please don't use a 
FPGA as your level of understanding appears to be a recipe for disaster.

Building such circuits is an art form.

> Sorry I didn't understand this as well, what do you mean by
> 
>> Jitter is the result of converting amplitude variations into
>> phase variations

Since every signal has a rise time, and every circuit switches at some 
threshold, and every circuit has noise, and every signal also has noise, 
the instant at which the circuit switches varies from rising edge to 
rising edge.  Thus any individual edge has uncertainty.

Variations in amplitude (the noise), creates variation in time (phase).

>>
>> To resolve the time you desire, it requires very high speed design
>> (PECL), and virtually perfect power distribution, and signal integrity.
> 
> 
> I do agree power distribution has a major effect on the time 
> measurement, but that's why "calibration procedures" have been invented. 
> You basically subtract (is a deconvolution operation to be precise, even 
> though many physicists deny it) the environment noise from the 
> meauserements. This operation is quite complicated because you need to 
> insure that power consumption doesn't vary so that will affect the 
> measurement.

Yes.  And then, magic occurs (?).  Signal processing may remove many 
noise like signatures, but you obviously recognize that not all noise is 
random, and it is those components that add the ultimate uncertainty.

Again, I thought you had to time stamp events, and as such, you did not 
have millions to average over.  If you have millions of events, then you 
may use any technology you like, as long as you are able to 
remove/preveent the deterministic components, and there are enough 
samples to obtain the required certainty (resolution).

I prefer to start with as good a signal as I can, and as good a 
reference as I require, rather than try to fix something when I am done.

(?) If not everyone agrees that this works, then you have a much larger 
problem.  It also confrims my suspicion that you are lacking some 
fundamental understanding of signals and noise.

"Al" <alessandro.basili@cern.ch> wrote in message 
news:ejv6de$rrt$1@cernne03.cern.ch...
> John_H wrote:
>> Al wrote:
>>
>> If you pass your trigger through the FPGA, your measurement can be off by 
>> +/- hundreds of picoseconds from one measurement to the next.  Over many 
>> measurements your gaussian jitter will be increased by a substantial 
>> amount only because of the jitter.
>
> Could you tell me why and how the FPGA will affect this measurement? I 
> didn't understand it, as simple as that.

This is your input signal:
___________.------------------
This is your input signal through an FPGA (scope with persistence):
________........---------------
Sometimes it's this:
________.---------------------
Sometimes it's this:
_____________.----------------

You cannot use a signal that's all over the place to measure time intervals 
precisely.


>> Using a complex trigger condition through an FPGA doesn't mean you have 
>> to measure the signal coming out of the FPGA.  Generate the mask in the 
>> FPGA and use it to gate the original (always on) trigger signal the 
>> measurement is performed on.  You chooses the edge(s) to analyze but 
>> through a very clean external gate unaffected by the jitter-laden mask 
>> signal coming from the FPGA.
>
> This is correct, but unfortunately the system has a very wide distributed 
> trigger, so this operation has to be done in many places and will result 
> in a components overload.

If the master edge that you want to measure is one of a very large number, 
you're sunk.  If the master edge is one very clean signal that you only want 
to look at occasionally based on the wide, distributed trigger, you can 
generate that mask in the FPGA and use a clean external switch - such as 
Symon's PIN diode switches - to bring the edge to your analog phase 
latch/measurement circuit.  The jitter in the gate will affect your 
measurement little.  The uncertainty on the signal passed by the gate is 
what you're concerned about.


>> If you insist on analyzing the signal leaving the FPGA, please let me 
>> know the company you're working for so I can avoid considering your 
>> products for any future needs.
>
> Very kind, but no worries I will not bother you with some time-measurement 
> product, I will mostly bother you with some other questions, waiting for 
> some other useful answers


It seems the lot here is convinced that you shouldn't use FPGAs to generate 
a signal to do precision time measurements.  You should have expertise 
within your organization that can help underscore the issues you'e facing. 
If the number of responses on this newsgroup telling you not to go down the 
road you're travelling without reevaluating your path doesn't convince you 
that you should reevaluate your path, you need the face-to-face interaction 
that will help you understand that you cannot achieve your goals without 
rethinking your approach.

FPGAs are *exceptional* logic devices.  They are NOT designed as analog 
elements.  If you need a clean edge, you need analog level functionality 
that FPGAs are not designed to deliver.


> -- 
> Alessandro Basili
> CERN, PH/UGC
> Hardware Designer 

Austin Lesea wrote:
> Al,
> 
> I am concerned you may not have the skills to do this right.  I suggest 
> you have an engineering review of the proposed architecture with those 
> who know this field.
> 
That's why I post the topic in the first place.
> 
> I use the ITU definition, jitter is the deviation from a perfect 
> reference in the zero crossing(s) of a signal.
> 
> Into, and out of, any circuit adds white noise.  If the signal has a 
> finite rise time (which they all do), the this noise creates timing 
> uncertainty (jitter).
> 
agree.

>> Given a fixed source that we know is stable in time (no matter how)
> 
> 
> Good trick.  How do you define stable?  A native rubidum cell?  A double 
> oven crystal resonator?  A SAW oscillator?  What frequency?  What is the 
> reference's time interval error (TIE)? A stable reference is an oxymoron 
> (contradiction in terms), as with any reference, there are imperfections.

I misused the term "stable" but any time measurements need a reference 
in time and what i meant was supposed to fix to time zero this source 
signal.
>> a signal produced from this source with some combinational logic and 
>> delay (like cables and I/O delay), the output distribution will be 
>> gaussian if we have a white-noise environment. The jitter I'm talking 
>> about will be (basically) the sigma of this distribution.
> 
> 
> Averaging over time will allow you to get a better measurement, but only 
> if you can obtain many such samples, and there are no deterministic 
> causes of jitter (of which there are many, such as power supply noise, 
> or other signals switching, or pattern jitter from inter-symbol 
> interference, and the list never seems to end).
> 
Any measurement needs statistics and for not related events the error 
that you will have over a distribution of points is 1/(number of points) 
no matter what tool you have to measure it.
Starting from the point that my signal source will not have such 
deterministic noises (that is just to reduce the parameters, but the 
source will have noises) all my electronics to measure it will add some 
gaussian and not-gaussian noise to the ultimate value and this is quite 
straight forward.
But I don't see how the inter-symbol interference will affect my 
one-shot system (as someone called it), not even pattern jitter. Power 
supply is an issue, surely, but we can get rid of it :-)

> 
> If someone has something that already works, and is proven, by all means 
> use it and stop trying to re-invent the wheel.

Even if sometimes this is the approach of some collegues of mine, I 
surely won't reinvent the wheel and that's why I'm using an HPTDC with 
24.4 ps bin resolution, but still someone has to feed this guy with some 
signals and this is the reason of my post.
> 
> 
> As I said, if you already have something that works, please don't use a 
> FPGA as your level of understanding appears to be a recipe for disaster.
> 
> Building such circuits is an art form.
> 
I agree and I'm not such an artist, that's why I ask questions and 
follow reasonable suggestions.

> Since every signal has a rise time, and every circuit switches at some 
> threshold, and every circuit has noise, and every signal also has noise, 
> the instant at which the circuit switches varies from rising edge to 
> rising edge.  Thus any individual edge has uncertainty.
> 
> Variations in amplitude (the noise), creates variation in time (phase).
> 
I would say is one component of time variations, moreover there is even 
bulk voltage variations which may involve different time variations and 
even local temperature distribution which may affect time measurement.
> Yes.  And then, magic occurs (?).  Signal processing may remove many 
> noise like signatures, but you obviously recognize that not all noise is 
> random, and it is those components that add the ultimate uncertainty.
> 
> Again, I thought you had to time stamp events, and as such, you did not 
> have millions to average over.  If you have millions of events, then you 
> may use any technology you like, as long as you are able to 
> remove/preveent the deterministic components, and there are enough 
> samples to obtain the required certainty (resolution).
> 
A time measurement, as any measurement to me, needs a lot of event to 
get rid of many effects. The number of measurements you need to do is 
directly related to the binning you want to make on any value.

> I prefer to start with as good a signal as I can, and as good a 
> reference as I require, rather than try to fix something when I am done.
> 
There are some issues which is important to have them fixed before, some 
others can easily be fixed later, as time-walk for instance.

> (?) If not everyone agrees that this works, then you have a much larger 
> problem.  It also confrims my suspicion that you are lacking some 
> fundamental understanding of signals and noise.

I can confirm you I lack of many fundamentals. Thanks for your warnings
Al


-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

Al schrieb:
> Of course all this logic is a combinational logic and has nothing to do
> with clock, but is it true that this logic cell delay will be changed by
> the presence of the clock inside the chip? even if this clock will not
> be connected to the combinational cell?

Yes. That is were the INL in the HPTDC comes from. The delay elements
are sensitive to the power supply voltage and the power supply voltage
inside the chip changes when a lot of flip-flops are switching.

I found that very interesting because this effect usually is next to
impossible to measure in an IC. With the HPTDC you get a very detailed
waveform view of the power supply voltage under stress ;-)

Kolja Sulimma
www.cronologic.de

Al schrieb:
> Kolja Sulimma wrote:

>[...]
>> 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/
> Exactly!
> 
>>
>>
>>>> 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.
> 
> 
> The big problem is that, as in all time measurements in physics, there
> will be a "trigger" configuration which will allow the time conversion.
> This will need to be implemented in an FPGA, because different "trigger"
> configurations will be needed.
> Because of that all the signals will come from an FPGA or from a
> combinational logic anyway.

Why is that? You can fan out the signals and perform the trigger
decision based on a copy of the signals.
If you data rate does not saturate the HPTDC you can do what we do:
We digitize everything and then let the FPGA do the trigger decision
on the measurement data.

> After that we can use all the drivers we want to minimize later sigma
> increase on the measurement, but still the source will jitter.
> My initial question was about the jitter increase due to the presence of
> a clock signal running through the FPGA, not that this clock source will
> have anything logically related to the output signals to be measured.
> We are getting signals from PMTs (PhotoMultiplierTubes), so they are
> single ended signals and there is no such a gain to convert them in LVDS
> signal and then convert them again to TTL inside the HPTDC. All these
> intermediate stages will drammatically add their sigma worsening the
> overall measurement.
It depends on the distance the signals run externally. The noise induced
in the LVDS signals will be much lower than that on the TTL signals. At
a certain point this outweights the converter jitter. Actually the
converter jitter is low if the power supply is good. As the HPTDC inputs
are not very good in our case the results got MUCH better with the
converters added in front.

> I saw your PCI board with the  HPTDC installed, wich type of LVDS
> drivers did you inserted in between NIM and HPTDC?
MAX9378EUA

> We are using a configuration such that to use the TTL port of the HPTDC
> and a fast comparator with a configurable threshold and an
> amplitude-time correction algorithm to correct the time-walk errors on
> different amplitude signals.
No constant fraction discriminator? What do you get the amplitude from?
Pulse length?

I guess now we are getting OT, maybe we should continue in a private
conversation.

Kolja Sulimma
www.cronologic.de