Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Jitter Problems in a High Speed Circuit.

Status
Not open for further replies.

sreevenkjan

Full Member level 5
Joined
Nov 4, 2013
Messages
268
Helped
27
Reputation
54
Reaction score
26
Trophy points
1,308
Location
Germany
Activity points
3,115
Hi Guys,

I have a general question regarding Jitter issues and problems. The old circuit consisted of a 25Mhz crystal clock oscillator. The 25Mhz clk was increased to 125Mhz clk and given to the transmitter of the FPGA. However there are jitter issues in the circuit and the jitter needs to be lesser than the reference value.

The solution which I suggested/decided was to use a 125Mhz LVDS clk and give it as input directly to the transmitter of the fpga. I decided on this solution because I read that PLL add on some jitter to the already input jitter. So the LVDS Osci has a jitter of about 0.1ps and crystal clock osci has jitter of 0.3ps.

My question is will my approach help in reducing jitter??

regards,
Sreeni
 

What do you mean "the jitter needs to be lesser than the reference value." What's the reference value? Do you mean the 25MHz clock? There are devices called "jitter cleaners" that might be what you want-they are basically PLLs with very narrow filters. Look at TI, IDT, etc.

Is your proposal to use two synchronous clocks? If they're not synchronous, you're going to need to deal with clock-domain-crossing issues.
 

What do you mean "the jitter needs to be lesser than the reference value." What's the reference value? Do you mean the 25MHz clock? There are devices called "jitter cleaners" that might be what you want-they are basically PLLs with very narrow filters. Look at TI, IDT, etc.

Is your proposal to use two synchronous clocks? If they're not synchronous, you're going to need to deal with clock-domain-crossing issues.

Hi Barry,

Thank you for the answer. Well when I say reference value, it is the threshold value. I mean if the reference value is 25ps then my jitter measured is about 40ps or 30ps.

The clocks are synchronous, instead of increasing the 25Mhz input clk to 125Mhz and giving it to transmitter, I have used a separate clock for the FPGA transmitter which has about 0.2ps less jitter as compared to 25Mhz. My decision for using such a solution was to reduce the jitter amplified due to the usage of PLLs.

I have tested the board with a old slower clock and a new faster clock. However both are working fine but I hope there is some change in the jitter measured in both the circuits.
 

You can never do better than incoming jitter in a straight-through
signal chain. You have the incoming jitter and the contributed
jitter, adding. The only method I'm aware of to clean it up is
a PLL approach, a "flywheel" if you will. You can find "jitter
cleaner" products at TI and elsewhere. But they often, in the
fine print of the datasheet, demand you use a very clean clock
in order to receive the advertised output quality still. Cleaner
(heh) than the numbers you state.

But you want to spend some time on the bench making sure
your measurement setup is itself up to the task - I'd want no
more than maybe 10% of target jitter, indicating on a self:self
eye or edge long-persistence sample. If you can't get the 'scope
clean then your other efforts are doomed.

By way of anecdote, I designed a 480MHz clock section for a
timing unit which we got down to about 10pS "contributed
jitter" with about 7pS 'scope artifact jitter baseline. But that
came at the expense of weeks of nights in the lab slabbing
the load board with high quality caps, and designing the clock
dividers and tree "analog style" with careful signal routing and
mucho on-chip decoupling (and still the larger ASIC managed
to ruin one signal pair, critical and in the core, by autorouting
two odd-divisor products adjacent and at minimum spacing
for 2500um of run). This was a DJ, not random, so easy (-ish)
to track down and only another $100K or so worth of masks
to fix.
 

Hi,

the problem is that I do not have a powerful oscilloscope to measure the jitter. As its a costly instrument and we cannot afford it. So the solution was to give a less jitter producing clock to transmitter and send it to our partners who would measure the jitter in the circuit and send us the details. I am new to the jitter and PCB design stuff. So after having researched on the internet checking for factors which causes jitter, we decided to go for a better clock oscillator instead of using PLLs to increase the reference input clock.

1. Is there a way to measure jitter in the circuit without using a powerful and expensive oscilloscope??

2. Could you tell me how can I identify the causes for Jitter?? I mean what causes jitter in high speed communication circuits??

regards,
Sreeni
 

1. Is there a way to measure jitter in the circuit without using a powerful and expensive oscilloscope??
I presume, yes. Creative circuit design required. E.g. combinations of fast digital logic and variable analog delay.

You can generally assume that a FPGA PLL adds considerable jitter amount to the input crystal clock. If you don't want it for critical applications, e.g. digital RF receivers, use a high frequency crystal clock or external clock generator.

Though the jitter parameters of a FPGA PLL are not optimal, they are normally sufficient for digital high speed interfaces. Not quite clear what your problem is. The expectable PLL jitter in normal operation can be estimated from the PLL datasheet. There may be additional avoidable jitter sources like insufficient power supply bypassing of analog PLL supplies, or ground bounce picked up by single ended input clocks.
 

Hi,

Exactly for this reason I am using a higher clock frequency 125Mhz instead of a 25Mhz as input to the FPGA transmitter. Previously I used 25Mhz input clk and then using FPGA PLLs increased the frequency to 125Mhz before giving it to the transmitter.

I hope it was just a problem. Anyway the bigger problem is :

I need to identify which part of the circuit is causing jitter?? My input crystal clock osci 25Mhz has a jitter of about 0.3ps. But the jitter measured in the end is about 43ps. The output jitter should be lesser than 32ps.
 

Hi,
1. Is there a way to measure jitter in the circuit without using a powerful and expensive oscilloscope??

Jitter is a time-domain measurement. The frequency-domain equivalent is "phase noise". Spectrum analysers are very good tools for analysing phase noise.

Consult any good RF or communications textbook for the causes, effects and measurement of jitter/phase noise.
 

You still haven't told us what your target jitter is, or what the jitter from your old method was, so we can't really say whether a given solution will work or not.

Using an external PLL+VCO instead of the ones integrated in the FPGA should surely improve your results, sure, but beyond that we need more info.
 

I would caution that spectrum analyzer based, phase noise
measurement is liable to hide sparse events and give you a
different impression of goings-on, than (say) an Infiniband
'scope with infinite persistance left capturing outlier and normal
edges overnight. You may, or may not, get to a happy place
basing your criticism of clock integrity on the sort of averaged,
RMS picture you'll get from a spectrum analyzer and post-
analysis of those results; analysis often presumes some
relation between RMS and total (max-min) jitter, which is
actually a thing to be proven, by you, in your bench reality.
Particularly if your "noise" is not gaussian and random (do you
know this, case at hand?), beware simple conversion formulae
for PN <-> jitter.

Now a fantastic 'scope also stands a chance of making you
more sad and desperate, rather than less. It may show you
things you can't unsee. But at least you'll have a clear picture
of the rocks below as you hurtle over the cliff. And who wouldn't
enjoy that?
 

You still haven't told us what your target jitter is, or what the jitter from your old method was, so we can't really say whether a given solution will work or not.

Using an external PLL+VCO instead of the ones integrated in the FPGA should surely improve your results, sure, but beyond that we need more info.


Hi,

I have mentioned the target jitter in my messages earlier. Target jitter is 25ps and the measured jitter is about 40ps. What more info do you want??

regards,
Sreeni
 

Hi,

I have mentioned the target jitter in my messages earlier. Target jitter is 25ps and the measured jitter is about 40ps. What more info do you want??

regards,
Sreeni

You should re-read your own posts...
Thank you for the answer. Well when I say reference value, it is the threshold value. I mean if the reference value is 25ps then my jitter measured is about 40ps or 30ps.
This says to everyone else (that isn't inside your head) that you have a reference clock with 25ps jitter, but the clock you are generating based on that reference has 30-40ps of jitter (which is actually pretty good, only adding 15ps of jitter).

To improve jitter you can't use an FPGA for any part of the loop. An external low jitter VCO/(VCXO?) will be required with a good loop filter. You might get away with a simple XOR comparator in the FPGA, but it might not be worth the hassle.
 

It's said in FPGA datasheet that the internal PLL operated in low bandwidth mode can be used to reduce clock jitter. But that's only true for very bad input clocks. Surely not for 25 ps jitter. In most cases, the FPGA clock networks and particularly the PLLs will increase jitter.

By the way, you didn't tell how you measure jitter. Is it pulse-to-pulse?
 

It's said in FPGA datasheet that the internal PLL operated in low bandwidth mode can be used to reduce clock jitter. But that's only true for very bad input clocks. Surely not for 25 ps jitter. In most cases, the FPGA clock networks and particularly the PLLs will increase jitter.

Typical numbers from a Kintex-7 with a 125 MHz input clock with 25 ps of input jitter:
Capture2.JPG

using mmcm:
Capture.JPG

using pll:
Capture3.JPG

as you can see the output jitter gets worse (using minimize output jitter).

Finally here is with maximizing input jitter tolerance:
Capture.JPG
 

Well I never said my crystal clock oscillator is generating 25ps Jitter. I guess I have created a confusion here. Let me clarify it once again.

RMS Jitter of 25Mhz crystal clock is 0.3ps, this is the input jitter. Jitter measured at the output interface terminals is 40ps. Jitter to be needed/desired is less than 32ps. So I need to remove atleast 8ps jitter to reach my goal.

So my hope is to use a higher clock that is 125Mhz clock with a 0.1ps jitter at the input. FPGA transmitter is connected to this clock. Previously FPGA transmitter was supplied with a PLL generated 125Mhz clock using 25Mhz crystal clock. So now FPGA transmitter has its own clock oscillator that is 125Mhz with a RMS jitter of 0.1ps.

My idea of choosing this method was to reduce the Jitter caused by PLL circuit to generate 125Mhz. I hope I can reach my goal of 25ps Jitter at the ouput. What do you guys suggest of using this method??

- - - Updated - - -

Its the peak to peak time measured. Eye Diagram has a UI of 160ps.

- - - Updated - - -

How did u obtain the diagram where you are able to calculate the Jitter outputted for a particular input frequency??
 
Last edited:

How did u obtain the diagram where you are able to calculate the Jitter outputted for a particular input frequency??

From the IP Catalog Clocking Wizard in Vivado, the Port Renaming tab has that summary.
ISE has a similar summary report.
 

Thanks. We use Altera FPGA's, is there a similar option in Altera Mega wizard Plug-in manager?? I use a Arria-II GX FPGA from Altera.
 

Last time I used Altera I recall that info was given someplace, but I don't have or use Altera tools at my current job, so I can't check.
 

Hi Guys,

The output jitter is reduced as hoped. The output jitter measured for the old circuit was about 42ps and it has reduced to 25/26 ps which is also lesser than the reference jitter of 32ps. My solution was to give a new clock signal to the FPGA transmitter instead of using PLLs to increase the input clk from 25Mhz to 125Mhz. As assumed that the PLLs were amplifying the jitter passed on from the input clock (slower).
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top