pulse jitter due to clock

John_H wrote:
> 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.
> 

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

-- 
Alessandro Basili
CERN, PH/UGC
Hardware Designer

"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 asynchronous signal routing or 
measurement of said signals.

Al wrote:
> John_H wrote:
>> 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.
>>
> 
> 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
>