From: Larry Miller ([email protected])
Date: Thu Apr 19 2001 - 06:33:39 PDT
Replies below -->>
From: Daniel, Erik S. [mailto:[email protected]]
Sent: Wednesday, April 18, 2001 12:06 PM
To: [email protected]
Cc: [email protected]; Daniel, Erik S.
Subject: Re: ADC jitter specs (formerly Diff clocks length matching)
Part of my confusion may have been that you were apparently mixing the
separate 10 bit 10 MHz case and the 7.5 bit 1.5 GHz case that Tom mentioned.
Also, I do not understand why you bring the ADC amplitude into it -- as is
evident by the equations, the LSB-limited jitter spec depends only on the
sampled frequency and the effective number of bits, as the LSB is defined
relative to the ADC full scale. In any event, it sounds like we agree on
-->> I am sure we agree on the equations. I think we probably do not agree
on the attainability of some of the numbers you get by just assigning a
sampling frequency and number of bits. And the ADC full scale is important
in a mixed digital-analog signal system because of the fixed sizes of other
nearby noises in the system. I'm sure that Maxim would be happier with a +/-
1-volt input range.
A few years ago in my pre-networking days I worked on CT Scanner data
acquisition systems (rather the other corner of the playing field from what
we have been talking about, 24-bit dynamic range at low audio frequencies)
and the same equations held.
Your approach is mathematically correct, but it smacks a bit of legislating
reality-- to me, anyway. Saying "...we require 10 fs of jitter...." and
actually getting it are not the same thing.
Regarding the followng comment:
> [Larry Miller] -->> Yes, I get that number. And you are talking p-p jitter
> noise bandwidth of at least 0.75 GHz.
--->> Sorry, gotta break this apart for discussion:
I'm not sure exactly what you mean by "p-p jitter with a noise bandwidth of
at least 0.75 GHz".
By noise bandwidth I mean the upper range of frequencies where the system
has a (possible) noise sensitivity (gain, if you like) of more than 1. This
is an old thing from George Philbrick and Analog Devices op-amp methodology.
(Anyone else around here remember "The Lightning Empiricist?") It is
directly related to the bandwidth of what you would use to measure such a
system (like scope bandwidth) and not surprisingly is exactly equivalent to
what you say below.
Jitter specs seems to be somewhat fleeting. I'm more
comfortable with jitter defined as an integration of phase noise spectral
density over some frequency range of carrier offsets -- the particular
choice of offset frequency range is very much application specific and is
somewhat independent of the sampled frequency.
-->> You are in good company in this. Some oscillator manufacturers, such as
Valpey-Fisher, use this method (with, I think, Aeroflex equipment).
Unfortunately, the answers we got with this method never matched up with
what we saw in our real systems in our lab (at a major Canadian Telco
manufacturer). Typically, the results from V-F were 1/10 of what we saw with
the best oscilloscopes we had and also similarly disagreed with our Time
Interval Analyzer (TIA) readings. Since V-F made good stuff and we wanted to
buy it, we basically had to make our own measurements in our own (jitterly)
way to get correlation with other manufacturers who do use jitter
specifications (which is most of them, actually).
The telecommunications industry seems to have settled on jitter and eye
openings as a way of evaluating high speed systems.
Phase noise methods and equipment were popular in evaluating radar local
oscillators (especially ones like YIG oscillators manufactured by
Watkins-Johnson, for example, and used in frequency-agile microwave
receivers for radar direction finders like those in the P-3 recently
acquired by the Chinese government).
I do consider phase noise testing an out-of-date measurement technique for
digital data transmission systems. I myself am out-of-date on analog
Typically, the high end of
the integration would be the clock frequency (relating to deviations in
timing from one clock cycle to the very next one), and the low end would be
dictated by the longest coherent time cycle required by the system (relating
to deviations in timing from one clock cycle to another one very much later
-- perhaps 1 millisecond => 1 kHz offset frequency for our applications of
interest). If this integration over the desired frequency range yields a
"jitter" that is larger than ~ 2^(-N)/(2 Pi f), then this will appear as
broadband noise which will limit an ADC's effective number of bits to less
than N for sampled frequencies f for that application.
-->> "Noise bandwidth of 0.75 GHz"....
-->> "high end of the integration would be the clock frequency"...
-->> The clock frequency is 0.75 GHz
-->> Works for me, just two ways to get the (hopefully) same answer, just
depends on how you hold your mouth when you say it.
Regarding fs jitter clock sources and our results to date on the 16
effective bit, 350 MHz center frequency ADC system, I can't tell you too
much as many of the details are proprietary to one of our collaborators, but
I can tell you they have developed a custom clock source that has low enough
jitter for the target system (again, on the order of 10 fs), and system
demonstrations to date have shown about 13 effective bits at a 350 MHz
center frequency, believed not to be limited by timing jitter.
Commercially, the best low phase noise sources seem to be made by Poseiden
(www.psi.com.au). The specs on their web page are given in terms of phase
noise spectral density instead of jitter, as the definition of "jitter" is
somewhat loose as I mentioned above, but integrated jitters in the 10s of fs
are possible, again depending on your required integration band.
-->> Are you SURE that the timing jitter is not limiting you? 16 bits minus
13 bits = 3 bits which is a factor of 8. 8 times 10 fs = 800 fs or about 1
ps which is about as good a clock as I ever saw (and a very expensive one at
that). You know I had to say it...(blush)
Regarding measurements of "jitter" of this order, I agree one would never
try to measure it with a scope. In my opinion, the best way to measure
phase noise is with a (aptly named) phase noise test set, which measures
phase noise spectral density versus frequency offset from the carrier for a
clock source input.
-->> My problem with measuring this way is this:
It is not directly related to what you are interested in for a digital
system. Integration always gives you a 1/f roll-off and this makes it very
hard to see its effects.
The clocked data input to a digital device (flip-flop, memory,
what-have-you) only cares about peak timing excursions. If a clock violates
the input setup requirement (is late) or hold requirement (is early) you
either get an outright error or, what is worse from a problem solving
viewpoint, metastability. With digital system speeds getting so high, the
margin for error is very small, so you cannot rely on rms style measurements
unless you have a very fault-tolerant system. An oscilloscope displays what
you (and the circuit, to lapse into a teleological vein) are directly
I have one thing to say in defense of this: it works. Multi-GHz systems
perform with vanishingly small error rates, and this is necessary. Gigabit
and higher data systems with performance worse than 10^-13 to 10^-15 error
rates produce errors often enough to be annoying to humans.
Jitter numbers can vary a lot, depending upon your sampling interval. You
can get just about any answer you want out of a TIA by tweaking the data
acquisition parameters. However, there are standard jitter testing
methodologies and test setups that have evolved (like the ones in the ANSI
and IEEE standards) and these give repeatable answers that agree very well
with what you see on high quality test instruments, and, more importantly,
agree with measured performance (error rates) of the resulting systems.
Anyway, good luck with your exotic A/D. I think we have tried the patience
of the members of this reflector enough; I see posts appearing about how to
implement "spam filters" on the reflector. I can take a hint....
**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected] In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
This archive was generated by hypermail 2b29 : Thu Jun 21 2001 - 10:11:39 PDT