copyright 2005 1

2005 Signal Consulting, Inc. All rights reserved. Xilinx is a registered

trademark, and Virtex-4 a trademark, of Xilinx, Inc. All other company and
product names may be trademarks of their respective companies.
Jitter Effects in Modern System Designs
Prepared for Xilinx
Tech On-Line
October 4, 2005
By
Dr. Howard Johnson
Theory, Measurement, and Mitigation
This is the third in a series of tech online
presentations about Xilinx FPGA components and
their packaging.
This presentation is best viewed using the Adobe
reader at 100% viewing size on a screen of at least
1024x768 resolution.
Its wonderful to be back talking about my favorite
subject. Thanks to Xilinx for setting up this event,
and thanks also to Mark Alexander for his help
building the circuitry for these experiments.
version 8
copyright 2005 2
Jitter Effects in Modern System Designs
!What is Jitter
!Causes of Jitter
!Measuring Jitter
!Mitigating Jitter
This talk is about jitterwhat it is, what causes it,
how you measure it, and what to do about it.
The application I have in mind, which I will use as
an example during this talk, uses the Virtex-4
Digital Clock Management (DCM) circuit, the
internal clock routing structure known as the
"BUFG" circuit, and LVDS input and output drivers.
During the talk I'll show you the test setup I used
recently to characterize jitter in this application,
and discuss the conclusions I draw from that work.
Before I get too deep into the measurements, Im
going to spend a little time discussing
measurement technique, because there are at least
four different ways to define jitter, each intended
for a different application, and each returning
different answers. If someone quotes you a jitter
number, the first question you need to ask is, How
was that jitter defined?
copyright 2005 3
What is Jitter
Abrupt, spurious variations in [time, amplitude,
frequency, or phase]
" IEEE Standard Dictionary of Electrical and
Electronics Terms
Unwanted pulse position modulation
" Patrick Trischitta, Jitter,
Deviation from the ideal timing of an event
" NCITS: Methodology of Jitter Specification
But what do you consider ideal?
From the IEEE Standard Dictionary of Electrical and
Electronics Terms, Abrupt, spurious variations in
[time, amplitude, frequency, or phase]. This
definitions is very general and somewhat obtuse. I
had great hopes for this reference book with I first
saw the title. Unfortunately, this is just an unedited
collection of definitions from all the IEEE standards
developed over the years. In a open standard,
anybody can join the process, and anybody can
propose a definition. No matter how poorly worded
the definition may be, if it doesnt break the
standard, it gets voted in on the theory of, Why fix
something that isnt broken?
Heres a definition more relevant to our cause
today, Unwanted pulse position modulation.
Patrick Trischitta and Eve Varma, Jitter (in
Digital Transmission Systems), Artech House,
1989, extremely relevant to SONET and similar
systems with multiple stages of propagation;
very mathematical.
OK, now lets get down to a definition written by a
group of people who actually made a lot of high-
speed digital system measurements: the Fibre
Channel committee.
.
That group was among the
first to write an explicit document about jitter.
Methodology of Jitter Specification, NCITS
(National Committee for Information
Technology Standars), T11.2. This document is
referred to as the MJS.
In this committee Wavecrest, HP, and numerous
other companies battled out the details of how
jitter should be defined and characterized.
If you havent read this piece of work, I highly
recommend it. Steve Joiner of HP did the technical
editing for the document, and he included this
definition for jitter: Deviation from the ideal timing
of an event.
I like Steves definition best because it is clear, succinct,
and makes a very important point about the necessity of
knowing what you determine to be the ideal outcome
before making a measurement.
Lets explore that concept of the ideal reference. For this
section of the talk I will direct your attention to some deep
insights about complex system behavior, and Id like you to
have a good idea in your head before we start of how
tracking systems behave.
The best tracking system I can think of to use as an
analogy is one with which you are very familiar: driving.
copyright 2005 4
Racing Game Analogy
Your car drafts at 100 mph, inches behind the next driver.
http://www.brackeen.com/home/race3d/
Lets play a high-performance racing game.
Imagine you are drafting at 100 mph just inches
behind the next driver on a long, straight section of
interstate highway. Its your job to follow (track)
the movements of the other vehicle as precisely as
possible. The other driver is turning his wheel this
way and that, trying to throw you off his tail.
If your opponent moves his wheel gradually, you
have no difficulty tracking his movements. You see
and respond to the graceful movements of his
vehicle and have no difficulty following where hes
going. This is your tracking behavior.
If your opponent grabs his wheel and violently
shakes it, without changing the overall average
direction of his vehicle, it makes almost no
difference to your strategy. His car may vibrate
terribly, but as long as you follow his average
direction, youll still probably be close enough to
draft effectively. This is your filtering behavior. You
dont even try to duplicate the shaking motion, you
just filter it out.
This is the way tracking systems behave. They have
a tracking behavior and a filtering behavior, plus
they add some jitter of their own.
In this context, lets try to define jitter. My main
point here is simple: your definition of jitter
must depend on what problem you are trying
to solve.
copyright 2005 5
JitterPoint of Reference
Car Car- -to to- -road road
Car Car- -to to- -car car
http://www.brackeen.com/home/race3d/
If, for example you are playing a James Bond
game, and you plan to jump from the hood of your
car onto the roof of your opponent, then what
matters is the car-to-car jitter. That is, you hope
your driving algorithm is designed to limit the peak-
to-peak jitter (measured car-to-car). That would
ensure that you could jump, at any time, without
risk.
On the other hand, if you concerned with staying
on the road, as these cars seem to have difficulty
doing, then what matters is the jitter measured
from your car to the center of the roadway. If this
car-to-road jitter exceeds a certain number, you fall
into the lake.
Depending on what you are doing, one measure or
the other becomes necessary. I hope that much is
clear.
Now we come to my first observation about jitter:
Car-to-car jitter is much smaller than the car-to-
road jitter. Assuming you have any reasonable
tracking behavior, this will always be the case.
Lets expand this discussion now to include
different types of tracking systems.
copyright 2005 6
Tracking Bandwidth
Bobby Unser
!Fast & jerky motion
(high bandwidth)
!Low tracking jitter (follows
next car very well)
!High jitter with respect to
road
Limousine driver
!Smooth, slow action
(low bandwidth)
!High tracking jitter (car
cant react)
!Low jitter with respect to
road
I classify tracking systems into HIGH bandwidth
and LOW bandwidth systems. The two categories
are intended for different applications. In the
context of our car discussion, the application
question of interest is this: what do you want to do,
follow the road or the car ahead of you?
Comparing two types of drivers, we see that Bobby,
taken together with his professional racing car,
comprises a very high bandwidth control system.
However the car in front moves, Bobby follows. His
jitter (measured car to car) will be very low. Thats
Bobbys good point. On the other hand, his jitter,
measured car-to-road, might be very high if the car
he tracks behaves erratically. A high value of car-
to-road jitter might be considered desirable if your
main objective is to closely follow the car ahead.
A limousine driver, on the other hand, follows a
smooth, contiguous path. He is paid specifically to
not jostle his riders. When following another car, if
the car ahead suddenly dives sideways, the limo
driver reacts slowly and calmly, without jerking. He
comprises a low-bandwidth tracking system. As a
result, his car-to-car jitter, in a racing situation, will
be terrible, but his car-to-road jitter is terrific. He
stays mostly in the center of his lane. This behavior
is the opposite of Bobbys fast, quick actions.
Which is better? Depends on what you need.
OK, lets wrap up this analogy section with one final
slide. This next slide illustrates the four main
systems of jitter specification in use today.
copyright 2005 7
Definitions of Jitter
Edge-to-Edge
Edge-to-Golden
Edge-to-Average
Edge-to-Ref
External
timing
reference
Average of
previous
values
Most recent
value
Golden
driver
The left side of this figure depicts the edge-to-
reference measurement, where we compare the
current position against a fixed, known reference
(in the automobile problem the reference is the
center of the road).
The second method is called edge-to-average. In
this situation, we suppose that for some reason you
can't see the center of the road. Maybe the stripes
have been worn off. What you do, then, is take a
lot of samples of the car's past positions, average
them, and ASSUME that average must be the
centerline position. All deviations are reported with
respect to that average. This method always
returns a lower jitter deviation than the edge-to-
reference method, as it is a fundamental property
of the average function that it returns that value
which minimizes the expected squared deviations
(this is actually how the term "average" is defined).
The third method uses a golden reference source,
some sort of "ideal" driver that dynamically tracks
the leader of the pack in a known, pre-defined
manner. To the extent the tracking is any good, we
expect the deviations between the lead car and the
golden car to be reduced.
The last method is "edge-to-edge", where you
simply compare yourself to the last previous value.
As your last value is in many cases a very good
predictor of your next position, this method usually
returns the smallest measured values.
The differences between methods can be
substantial.
copyright 2005 8
Jitter: a New Dimension
Late
transitions
Early
Late
Voltage
Jitter track
Jitter
histogram
Edge-to-edge
jitter
Early
Late
Late
Now let's transfer our knowledge from the
mechanical to the electrical domain. This picture
shows a jittery signal waveform (purple) laid out in
time (the time axis is horizontal). Vertical
displacement corresponds to voltage.
On a comb of perfectly spaced timing intervals, I
compare the jittery waveform to that comb, and
gather two pieces of information: (1) The
amplitude, and (2) The edge timing (early or late).
I lay the timing numbers out sideways, in a
dimension separate from voltage or time. This new
signal is called the jitter track. Its a signal,
sampled once at each edge, whose amplitude
records the earliness or lateness of that particular
edge.
Ive drawn the jitter track for a sample waveform in
this slide. Moving from left to right, you can see
that the first ten or so edges all arrive early, then it
slips over to the late side. Theres three late guys in
a row, then it moves back to the early side again.
We are used to seeing plots of voltage versus time.
I want you to begin thinking about plots of early-
or-lateness versus time.
The sideways motions of the jitter track are exactly
analogous to the motions of the cars in our racing
game. Everything you just learned about cars
applies the same to jitter.
When you see a histogram of jitter, it usually
represents a histogram of values taken from the
jitter track.
Suppose I construct another signal, one that
represents just the difference in timing from edge
to edge. This signal is called the edge-to-edge
jitter track. I have marked one sample of the
edge-to-edge jitter track on this chart.
In this signal the differences between successive
excursions are generally smaller than the peak values of
the excursions themselves. That is typical for any
correlated process, and jitter can be a highly correlated
process. If one edge is early, the next is likely to be early
as well. What I would like you to remember from this
discussion is quite simple:
Edge-to-edge jitter is much smaller than edge-to-reference
jitter. In our discussion today Im thinking about DDR
clocks, and for that application all that matters is the edge-
to-edge jitter, so thats what we will measure.
Now that Ive got all the preliminaries out of the way, lets
look at how jitter is measured.
copyright 2005 9
Four Ways to Measure Jitter
A B
Edge-to-Golden
Edge-to-Edge
Golden track
Edge-to-Ref Edge-to-Average
Average over [A,B]
Ref
This chart illustrates all four jitter measurement
ideas.
The circles (dots) represent the jitter track of some
jittery signal, as sampled at the edge locations.
This is a clock, as you can see from the fact that it
has jitter samples at regular intervals. Data signals
have gaps in the jitter track where there are no
edges.
The horizontal line marked "Ref" depicts the ideal
reference position, or zero-line, for jitter.
Deviations from the ideal reference position are
termed "Edge-to-Reference" jitter. This is very
difficult to measure unless you have access to the
original source clock for the application. The
difficulty of making true edge-to-reference
measurements renders this technique more of a
theoretical curiosity than a practical alternative.
If you sampled the jitter track over a limited period
of time, perhaps from point A to point B as marked
on the chart, you can attempt to estimate the
reference position by the method of averaging.
Edge-to-average measurements are defined with
respect to this estimate of the reference position.
In my diagram, you can see that I obviously didn't
take enough points to form a clear picture of the
true reference position. The line marked "Average
over [A,B]" indicates my estimate of the reference
line. It's way off. That often happens. Do not
assume, unless you know a lot about the statistics
of your signal, that your average value, the
estimate of the true reference, is accurate. In many
systems (such as those with 1/f noise), there is no
averaging period sufficiently long to guarantee
convergence of your estimate with the reference.
The third method is the "golden PLL" method. In
blue (because gold doesn't show well against a
white background) I show the jitter track of a
golden PLL as it attempts to track wander in the
input signal. The bandwidth of this PLL is high
enough that it tracks most of the large sinusoidal
variations, but not the quicker, shorter, variations
in the input jitter track. Also note that there is
some tracking error due to the phase delay of the
tracking system. The solid blue curve is offset a few points to the right of the
data points.
Deviations between the blue PLL track and the actual data constitute "Edge-
to-golden-PLL" jitter. I use the golden PLL method when I'm working with a
clock recovery unit that has a fixed PLL tracking bandwidth. If I set the
tracking bandwidth and "Q" of may golden PLL to mimic the tracking behavior
of the PLL inside my clock recovery unit then the "golden PLL" method
returns jitter numbers that correspond exactly to the actual tracking errors
internal to my clock recovery subsystem.
The last method is the "edge-to-edge" method. This method just compares
the differences in phase measured between successive edges, a process
identical to just looking at the width of every high or low pulse in the clock
waveform. For simple synchronous logic, like a source-synchronous bus, the
edge-to-edge method makes the most sense. If you aren't tracking
something with a PLL, the golden-PLL method, and other methods, are
unnecessary.
copyright 2005 10
DDR Application
Plan: Use Xilinx DCM for clock timing adjustment
Measure jitter on clock
DATA DATA DATA
Write clock splits each data cell
CLOCK
266 MHz clock
533 Mb/s data
1875 ps
350 ps 350 ps
When setting up this talk I had in mind a high-
speed DDR application running at 533 Mb/s. The
clock for this application is supposed to split dead
center in the middle of each bit cell. To accomplish
that timing adjustment, Im thinking of using the
Xilinx DCM.
On a write cycle (Xilinx FPGA writing out to the DDR
bus), the timing of each bit cell is 1875 ps, out of
which you must reserve 350 ps setup time, plus
350 ps hold time, for the other devices on the bus.
That leaves only 1175 ps for everything else,
including waveform distortion, skew in the
transmission path, and jitter in the clock. I think
you get the idea that in this application even a few
hundred picoseconds of jitter may be
impermissible.
So that we can be concrete in our discussion, I will
set our absolute outer limits for edge-to-edge jitter
in the clock waveform at +/- 200 ps (400 ps peak-
to-peak).
copyright 2005 11
How a DLL Works
1. PD (phase detector) observes all delays and
determines which tap number best represents the
phase delay you requested
2. Control module then switches the appropriate delay
tap to the output
Control
Clock input
PD
MUX
Phase-shifted
output
The Virtex-4 DCM is an example of a HIGH-
bandwidth tracking system. It is intended to track
the input clock signal very closely. As you can see,
the output is just a delayed version of the input,
with no other modification.
The clock feeds through a long chain of delay
elements, called taps.
The PD (phase detector) observes all delays and
determines which tap number best represents the
degree of phase shift you requested.
The control module then switches the appropriate
delay tap to the output.
The control system makes only occasional
adjustments to the signal tap selector, now and
then adjusting a little bit one way or the other to
account for variations in temperature and aging.
Because the output timing is directly affected,
edge-to-edge, by each and every transition at the
input this circuit is said to have a very high tracking
bandwidth.
copyright 2005 12
Causes of Jitter
Jitter accumulates from several sources
This talk addresses the DCM jitter transfer function, the influence of
intrinsic jitter, and the effect of AUX power supply noise.
Jitter in
clock
source
Input crosstalk
DCM & BUFG
AUX supply noise
Output crosstalk
IO supply noise

Jitter
transfer

Xilinx FPGA Package
Jitter at output
intrinsic jitter
This diagram is called a "noise model". It
represents the flow of jitter from stage to stage in
my DDR clock application. The form of the noise
model is similar for many other types of
applications.
Starting on the left, the diagram shows the jitter
signal emanating from your clock source. To that
jitter, you must add jitter picked up at the input
stage of the FPGA receiver.
This jitter propagates into the DCM and BUFG
circuits within the FPGA. These circuits may modify
the jitter in some way. That modification is called
the "jitter transfer function". We will look at how
the jitter transfer function operates a little later in
this presentation. Internal to the FPGA there are
two other significant sources of noise: the AUX
supply, which powers the DCM circuits, and other
jitter intrinsic to the FPGA. Both contribute to the
total jitter coming out of the DCM stage.
After the DCM stage, more jitter is added by the
final IO stage, either due to the influence of noise
on the IO supply, or crosstalk from nearby
aggressive signals.
Composite jitter at the output is the sum of all
these contributions.
This presentation deals with only a few portions of
the overall noise model. In the remainder of this
talk I will focus on the operation of just the portions
of the diagram internal to the FPGA, showing the
DCM jitter transfer function, the influence of
intrinsic jitter, and the effect of AUX power supply
noise.
copyright 2005 13
Measuring Jitter
LeCroy SDA 6000
20 Gs/s sample rate
Acquires 10 million samples per
record
For DDR clock measurements it
makes a complete record of
both high and low intervals
T[LOW] T[HIGH]
Jitter for digital applications is rated in units of unit
intervals, or U.I., where one U.I. is the data
interval of your system. Beware the units in DDR
applications, as it is sometimes unclear whether a
U.I. refers to one data bit cell or one full clock
period (which is twice as long).
Jitter in radians is the same as jitter in U.I., except
bigger by a factor of 2*pi. One radian of jitter
equals 0.159154943092 U.I. of jitter, or
57.2957795131 degrees of jitter.
When comparing jitter quantities look to see if the
jitter is rated as peak-to-peak jitter (at a certain
BER, like 1E-6 or 1E-12), or as an RMS jitter.
Conversion from RMS to peak-to-peak jitter is
accomplished using tables of Gaussian probability
amplitudes.
Example: The conversion factor for 1E-6 BER is
about 9.8, meaning that for a Gaussian random
variable, the peak-to-peak width of the histogram
skirts at the 1E-6 BER level is 9.8 times the
standard deviation. Rj is often listed as a "standard
deviation" value, so when adding it to deterministic
jitter (Dj), which is already in peak-to-peak units
we use the conversion Total jitter (Tj) = Dj +
9.8*Rj. At different BER levels different conversion
factors apply. The conversion factor for 1E-12 BER
is approximately 14.3.
For this talk I used a LeCroy SDA 6000 to perform
the jitter measurements and report values of total
jitter. This scope has a sample rate of 20 Gs/s and
can acquire 10 million samples in a single,
contiguous record.
copyright 2005 14
Test Setup
Mark and Howie it he lab
LeCroy LeCroy
SDA 6000 SDA 6000 Agilent Agilent
E4438C E4438C
LVDS LVDS
buffer buffer
Test card Test card
We set up the measurements at my lab in Eastern
Washington state. Going clockwise from the upper
left corner, you can see an Agilent E4438C
sinewave generator. We selected this because it
can produce calibrated, very accurate amounts of
random jitter. The digitizing oscilloscope was
provided by LeCroy. At top right, I am holding the
LVDS buffer, which I will tell you about in a minute.
Bottom right, that's the Virtex-4 component under
test, and the view at bottom left shows two of our
test cards. The bottom half of each card (nearest
you) is a noise-generating circuit used for some
power-system tests. The upper portion of each card
contains the devices under test.
copyright 2005 15
LVDS Clock Buffer
Ten-turn potentiometer R1
tweaks the output duty cycle to
precisely 50.00 percent.
E4438
266 MHz
+6 dBm
CH2 100 mV/div
CH3 100 mV/div
LVDS Buffer
R1
2K
Local 2.5V reg.
from battery
+

100 100
100 100
650 mV p-p
differential
2 ns/div
The Agilent E4438 RF sine wave generator is in
many ways a very flexible piece of equipment, but
it only produces sine waves. Measuring jitter
directly on the sine wave output, the relatively slow
edges of the sine wave shape exacerbate the effect
of noise in the LeCroy front end. To circumvent this
difficulty, and also to provide a faster rise/fall time
for my FPGA circuit, I had Mark build up some LVDS
buffers. With the buffer in place, the LeCroy is able
to better measure the true jitter from the Agilent
E4438.
Sinewaves enter the left side of the circuit from the
E4438 on a single-ended 50-ohm coaxial cable.
They propagate through the buffer to the scope (or
FPGA input). Potentiometer R1 adjusts the input
threshold of the LVDS buffer. This feature tweaks
the duty cycle of the output to precisely 50.00
percent.
Mark was a little uncertain about the efficacy of
bolting a "home brew" solution onto the output of
his Agilent E4438C sinewave source, but when he
saw the result he was all smiles. The ten-turn
potentiometer dials out the last few picoseconds of
duty-cycle distortion (DCD), as you can see in the
next picture.
copyright 2005 16
LVDS Buffer Edge-to-Edge Jitter Histogram
28.7 ps
@1E-12 BER
5 ps/div
The LVDS buffer, driven by the Agilent E4438 RF
sinewave generator, makes a more than adequate
clock source for our experiments.
The system, as recorded by the LeCroy scope,
shows a total jitter (Tj) of 28.7 ps peak-to-peak at
a BER of 1E-12. This source is more than adequate
for our experiments today.
The data for this measurement were recorded at 20
Gs/s, taken in continuous records of 10,000,000
samples. That gives you 133,000 clock edges in
each record.
Each record was analyzed for edge-to-edge jitter,
showing a composite histogram of both positive
and negative pulse widths, proving that we have
brought the DCD down to a very low level.
The machine accumulated histogram points until
we stopped it after seeing 1.3 million edges.
Based on the number of edges captured, the
machine then extrapolates the sides of the
probability distribution down to a very low value of
BER=1E-12.
The specific LeCroy features necessary for this
setup are located under [Analysis], [Clocks], [Half-
Period Jitter], [Use Both Edges].
copyright 2005 17
395
400
405
410
415
420
425
430
435
Tj (ps)
peak-to-
peak
BER=1E-06
Series1 408 422 431 432 434 431 421 427 411 417
1 2 3 4 5 6 7 8 9 10
Repeatability of Jitter Measurements
90%
confidence
+/- 12 ps
Edge-to-edge jitter
To develop further my measurement methodology,
I set up the Agilent E4438C to create an
intentionally jittery source. It had as much or more
jitter than anything I plan to measure.
I then used the LeCroy SDA 6000 to observe the
peak-to-peak jitter of that source. Using a total of
200K samples for each measurement, I recorded
these observations of Tj.
To circumvent issues regarding the method of jitter
histogram extrapolation, I chose for this talk to not
extrapolate very far. I measured a minimum of
200,000 edges in each case, and projected the
histogram to a normalized peak-to-peak width of
only 1E-6 BER. This simplification allowed me to
make literally hundreds of measurements quickly,
showing many different possible configurations, in a
reasonable period of time. Your measurements, if
you are verifying a final design, should use more
points and project down to at least a BER of 1E-12.
The variance of this series of measurements
suggests that I have 90% confidence measurement
accuracy limits of +/- 12 ps Tj using this method,
meaning that 90% of the time the reported result is
likely to fall within +/- 12 ps of the true value.
Any differences in my measured data greater than
24 ps I will therefore consider to be statistically
significant differences.
Please take careful note that the LeCroy scope, as
much as I like using it, re-scales the jitter
histogram axis on each measurement. I have
painstakingly re-sized all the output pictures to
place their horizontal and vertical scales on a
comparable footing.
As a result, you will see in the photos some
variation in the pixel quality and background
division marks of some of the pictures. I want to
assure you that these re-scaling operations were
done to improve the picture comparability, not to
degrade it.
copyright 2005 18
Xilinx DCM Test Setup
The DCM configuration is very simple. It uses the BUFG
clock distribution net internal to the FPGA.
E4438
266 MHz
+6 dBm
LVDS
Clock in
DCM
90
CH2 100 mV/div
CH3 100 mV/div
Splitter
CH4 100 mV/div
Clock out
D.U.T.
Heres how I configured the DCM. Its very simple. I
just come in on the left side with a 266 MHz clock,
pass it through the DCM, and exit through the
BUFG clock distribution tree and LVDS I/O on the
right side.
The clock input is differential LVDS. The clock
output is also differential, using an LVDS driver
standard. Thats the type of cell normally used for
DDR applications.
The DCM is set for a fixed, arbitrary amount of
delay (90 degrees).
In some cases I may use an even simpler
arrangement, whereby the DCM is not even
present. In that case the signal passes through the
FPGA with no processing, just coming in one side
and exiting the other. I call that the BUFG case,
because that is the name of the internal clock tree
propagation feature used to implement this simple
pass-through.
Note that I pass a version of the clock over to the
scope. For edge-to-edge measurements the
external trigger is not necessary, but for edge-to-
reference measurements (and eye patterns) I can
sometimes use this external clock as the reference
(trigger).
copyright 2005 19
Duty Cycle Distortion
Both designs easily fell within the DCD limit.
Sample DCD (ps)
peak-to-
peak
Xilinx BUFG 26
Xilinx DCM 82
My limit on Tj
400 ps
I checked both my sample designs for duty-cycle
distortion (DCD).
Both have some amount of DCD, but both are
capable of rendering an acceptable 533 Mb/s DDR
clock (266 MHz).
For the purpose of studying forms of jitter other
than DCD, I have chosen to subtract from my
reported results the value of DCD relevant to each
setup. My reported results in the sensitivity studies
at the end of this talk will therefore show (TjDCD).
copyright 2005 20
Jitter Performance of Virtex 4 BUFG
Jitter at input
passes straight
through the
BUFG

Input jitter
RMS
(UI)
100 ps/div
Xilinx BUFG
DCD
0.000
0.001
0.003
0.01
0.03
Here is our first measurement. It is a simple pass-
through circuit. The input clock arrives in LVDS
format, passes through the BUFG clock distribution
tree internal to the FPGA, and comes out another
LVDS output. The operation of this circuit is quite
straightforward -- whatever jitter you feed it passes
straight through.
On the left we show the histogram (edge-to-edge,
both edges) of our source clock. We have the
ability to dial in pre-programmed amounts of jitter
with this source. The corresponding Xilinx outputs
appear on the right side.
Since we are measuring both positive and negative
pulse durations, duty cycle distortion produces a
bimodal histogram. That is typical for any LVDS
output. The scale marked at the bottom shows 100
ps/div, so you can see the duty cycle distortion is
not very large. At 266 MHz (533 Mb/s) one UI
equals about 2000 ps (1875 to be exact), so +/-
100 ps would be just +/-5% DCD. This circuit
produces +/- 13 ps (26 peak-to-peak), a very small
value indeed.
For now I'm going to show the complete
histograms, as they illustrate some interesting
features of the circuit. Later, when I make
sensitivity graphs showing the sensitivity to noise
on the AUX supply, the supply that runs the DCM
circuit, I will subtract the nominal value of DCD so
we can concentrate on other components of total
jitter.
copyright 2005 21
Xilinx DCM
DCD
0.000
0.001
0.003
0.01
0.03
400 ps
100 ps/div
Input jitter
RMS
(UI)
Xilinx DCM
Jitter
In this figure you see the performance of the Xilinx
DCM in response to input jitter. The input clock
arrives in LVDS format, passes through the DCM,
then on to the BUFG clock distribution tree internal
to the FPGA, and then finally comes out an LVDS
output.
At the top of the figure I show the case with very
little input jitter. The jitter output from the DCM
exceeds the input jitter. This reflects the inevitable
result of all circuitry added to your clock chain:
every stage adds jitter. Fortunately, the amount of
jitter added (the "noise floor" of the DCM) is not
very great.
One interesting feature of the way the DCM works,
is that it always maintains a consistent half-period
in one half-cycle. If there are variations in the input
clock, all those variations are lumped into the other
half-cycle of the DCM output. In other words, the
DCM looks only at the positive edges of the input
signal (or negative edges, depending on how you
have wired up your differential inputs).
You can see this behavior in the bimodal
distribution of the histogram. The right-hand mode
shows a consistent width regardless of the input
jitter. All output jitter is lumped into the left-hand
mode.
Note also that whatever jitter comes in must go
out. A DLL circuit does not filter jitter, it just passes
it through. This is the normal behavior of any DLL.
Point to Remember: With this, or indeed any DLL
or PLL circuit, if you expect to meet a tight jitter
specification at the output, you must supply a
good-quality, low-jitter input clock at the input.
copyright 2005 22

0.000 50 MHz 0.000 50 MHz
refclk Xilinx DCM
0.03 UI rms jitter
0-40 MHz
Jitter pass-through
(normal DLL)
Jitter Propagation
Noise floor
The following frequency-domain charts give you
another view of jitter. These plots illustrate the
jitter filtration capabilities of the Xilinx DCM. Both
plots display the spectral power density (20 dB/div)
of the jitter "trace" in "edge-to-average" mode,
with a VERY long averaging time (10 million
samples).
On the left you see the Agilent E4438C, when it is
commanded to produce random jitter with a
bandwidth of 40 MHz.
On the right, you see the same clock after DCM
processing. The Xilinx DCM passes the jitter
through almost perfectly. The DCM plot shows a
slightly higher noise floor in the region around 50
MHz, that's the only artifact. In the time domain,
this equates to the minimum "fatness" of the
histogram peaks in the previous chart the DCM
noise floor is at about 11.5 ps Rj (RMS).
copyright 2005 23
Xilinx DCM: Noise on AUX Pin
Noise at +/-5% on the AUX supply
increases DCM jitter by 50 ps.
0 50 100 200 300
0
200
400
Injected noise mV p-p
T
j
-
D
C
D

(
p
s
)
5% AUX supply
What Ill do next is inject some intentional noise
into the AUX pin of the Xilinx FPGA, while the DCM
is running. The AUX pin is the supply voltage that
feeds the DCM circuits. This new noise causes a
slight increase in jitter.
This horizontal scale in this picture is noise voltage,
peak-to-peak. The noise waveform is a repetitive
signal at 134 MHz, the result of switching noise in
another circuit. I have the ability to control the
level of noise, and took several data points.
With the noise set at 250 mV peak-to-peak, which
amounts to about +/-5% of the AUX supply voltage
of 2.5 volts, the DCM jitter is increased. The AUX
supply is specified with maximum tolerances of +/-
5%, so thats as much noise as I chose to inject.
The vertical scale in this picture, as we discussed
before, shows Total jitter (Tj) less duty-cycle
distortion (Dj), peak-to-peak at 1E-6 BER. At rest,
with no noise, the Tj amounts to 60 ps (not
counting DCD). The amount of increase in Tj due to
AUX noise of this particular type is about 50 ps.
During the experiments I tried wiggling around the
frequency of the AUX noise source, but was unable
to find any particularly more or less sensitive
frequencies. This seems to be a pretty simple,
edge-by-edge interference effect.
copyright 2005 24
Mitigating Jitter
!Check your input
clock
!Check for noise on
AUX Pin
!Crosstalk!
In this talk we have covered three main sources of
jitter:
-- The input clock
-- Intrinsic jitter
-- AUX supply noise
Of these three issues, you can't do anything about
intrinsic jitter. Fortunately, the intrinsic jitter is
pretty low (11 ps RMS), so it doesn't present much
of a problem.
Regarding the input clock, it is crucial that you
supply a good, low-jitter input clock to any DCM
circuit. If you ever have trouble with jitter, always
check the quality of your source clock as that is one
of the more common difficulties in high-speed
systems. Remember that its not only the quality of
the source clock, but also the routing of that clock
over to your chip that matters. Keep clock traces
away from other noisy signals (including noisy
power planes) to minimize the crosstalk they pick
up.
Next, we are reminded to check the noise on the
AUX pin to be sure it doesn't exceed the safe
operating limits. Provided that you stay within the
specified +/- 5% tolerance, jitter from that source
is almost negligible. This is easily done by: (1)
keeping the AUX power patch next to ground, not
next to another noisy power plane, and (2) placing
bypass capacitors from the AUX power patch to
ground.
Checking these two sources of noise takes only a
few minutes, and can save lots of hassles later.
One other source of jitter we havent talked about
today, but which is quite important, is crosstalk.
This is one place where the Xilinx Virtex-4 package
with the Sparse Chevron power and ground pin
array really shines. You get a lot less crosstalk
moving through this package than with other
packages, as we discussed in my previous tech
online presentations.
Not only does the Sparse Chevron array minimize
crosstalk directly on the signal output pins, it also
minimizes the crosstalk picked up on the clock input
pins, and the AUX power pins.
copyright 2005 25
For Further Study
Xilinx
! www.xilinx.com/signalintegrity Resources useful for high-speed
designers
! www.xilinx.com/virtex4/si My SI tutorials for Xilinx RocketIOserial
transceivers, also BGA Crosstalknow available on DVD
Website: www.sigcon.com
! Full schedule of seminars,
! Seminar course outlines,
! SiLab films,
! Newsletters,
! Article archives, and much more.
That's all the time we have today. I would like to
thank Mark Alexander for his help with this project,
and thanks also to LeCroy for providing the
equipment that made these measurements
possible.
I hope the raw data we have provided about the
jitter noise floor and the jitter transfer functions in
the Virtex-4 FPGA are helpful to you.
If our program has stimulated your interest in
further research, the Xilinx signal integrity site
www.xilinx.com/signalintegrity holds a number of
resources useful for high-speed designers, including
information about my new SI tutorial for
RocketIO serial transceivers, now available on
DVD at www.xilinx.com/virtex4/si .
At my web site www.sigcon.com you will find a
treasure trove of additional publications (285 at last
count), plus a full schedule of my High-Speed
Digital Design seminars, complete course outlines,
other films, newsletters, an article index, and much
more.
Thanks also to all of you for your constant stream
of fascinating letters and emails, and dont forget
tell a friend what you learned.
copyright 2005 26
Jitter Effects in Modern
System Designs
Ill be doing courses open to
the public in
San Jose, CA
January 30 Feb. 3, 2006
www.sigcon.com
Dr. Howard Johnson
Questions?
At this time I would be pleased to consider any
questions or comments you may have.