pulse jitter due to clock

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.

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:-

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

Could you tell me why and how the FPGA will affect this measurement? I didn't understand it, as simple as that.

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.

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

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 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).

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

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).

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

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.

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).

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.

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.

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.

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.

That's why I post the topic in the first place.

agree.

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.

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 :-)

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

I agree and I'm not such an artist, that's why I ask questions and follow reasonable suggestions.

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.

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.

There are some issues which is important to have them fixed before, some others can easily be fixed later, as time-walk for instance.

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

Al schrieb:

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

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.

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.

MAX9378EUA

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

I do see the warning and I do am worried, just because this part of the design is already been designed by somebody else and I didn't want to take over it again. Tipically my approach is such that if someone did something he had his motivations to do that, the same as all these replies, that's why I'm trying to evaluate why and most important how much this will affect my project. That's why I'm reading carefully all these posts and try to evaluate somebody else's experience, I cannot simply trust (at least it's out of my attitudes). Thanks for your explanation, by the way "why and how the FPGA will affect this measurement" is still an open issue to me. Thanks

Al

"why and how the FPGA will affect this measurement"

Why does FPGA add jitter to combinational paths?

As someone else pointed out: rise times and thresholds.

Not only those of IO pins but also those of every path taken by the relevant signals within the routing fabric and logic cells within the FPGA. Each of these nodes has both an input and output. Every input will have its own threshold voltage and every output will also have a slightly different slew rate. Both parameters will be affected to some extent to variations in operating parameters including internal power distribution noise, minute junction temperatures fluctuations, fabrication process variations, etc.

From input to output, your signal goes through an IOB, at least one H-line and one V-line to reach the logic cell, then it goes through the cell's input S-box, LUT inputs, LUT outputs, the cell's output S-box, at least another pair of H-V routes and finally the output IOB.

In-to-out delay may be over 500ps but as you said, this can be overcome by calibration. However, due to all the routing nodes your signal passes through within the FPGA, jitter around this (hypothetical) 500ps delay can easily exceed 100ps.

Achieving 25ps jitter may be possible if you cherry-pick your IOBs, routing and logic cells through trial-and-error to find a path that meets your requirements and do some supercooling. However, electromigration as the de device ages may also ruin your initial efforts at some point in the future.

IIRC, IOB bandwidth on V4 is 625MHz. Imagine how much jitter you would be getting right here by relying on edges that fall so far beyond the IOB's capabilities.

FPGAs are not meant for ultra-high-speed asynchr> John_H wrote: