[Fpga-synth] Interesting

[Magnus Danielson]

From: Scott Gravenhorst <music.maker at gte.net>
Subject: Re: [Fpga-synth] Interesting
Date: Sun, 18 Nov 2007 15:45:03 -0700
Message-ID: <200711182345.lAINj3wj012322 at linux7.lan>

> Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
> >From: Scott Gravenhorst <music.maker at gte.net>
> >Subject: [Fpga-synth] Interesting
> >Date: Sun, 18 Nov 2007 14:00:09 -0700
> >Message-ID: <200711182200.lAIM09pk020038 at linux7.lan>
> >
> >> Well, I was messing around with trying to reduce the delays in my design to
> >> increase the maximum operating frequency, I just kicked it over 100 MHz!  I
> >> have a bad habit of daisy chaining mux logic.  Pipelining fixes this.  Now
> >> I shall have to think very seriously about using SDRAM since at 100 MHz,
> >> the design would be alot faster (to get to 100 MHz, I only added 8 state
> >> times to the state machine logic, so while there are a few more states to
> >> do, they can be done twice as fast.
> >> 
> >> However, I'll bet using a DCM is probably the usual major PITA.
> >
> >DCMs are nice, but you need to have a low jitter clock to start with or else
> >you will have problem, especially if you use the clock multiplication feature.
> >The DCM will not clean up jitter on the input, it isn't a PLL, but there are
> >similarities in that there is a feedback loop.
> >If you have too high jitter, the DCM may over-react and that results in bigger
> >jitter.
> >If you do frequency multiplication, the period becomes shorter for the same
> >amount of jitter (think about time here).
> >
> >Too high jitter will cut down the allowed delay. So even if the synthesis tools
> >give you thumb up, higher jitter than expected will cause bit errors and those
> >can creep in and cause very strange results. This is especially important for
> >high speed DDR memory interfaces. Some DDR and QDR chips does not handle clock
> >jitter well and blows it up alot. Reducing jitter at the clock source is what
> >makes things manageable.
> 
> Thanks, that's important.  I think Rick Huang's recorder design uses a DCM in 2x mode,
> running at 100 MHz.  I'm thinking the jitter defines how fast the design must be.  The
> faster the design, the more jitter it can tolerate, so it's best to optimize that well. 
> I've gotten it to 109MHz (well, bogus MHz anyway, since it's a calculated estimate, not
> measured), but maybe I can make it faster.  In the meantime, I need to know how much real
> jitter I'm stuck with.
> 
> In the Spartan-3E data sheet PDF, there are a lot of hits when searching for "jitter".  I'll
> have to stare at the numbers for a while.

A few words of advice:

1) Do not stare yourself totally to death on Peak-to-Peak jitter values. Those
   numbers have a high degree of bogusity about them. The reason is that the
   noise part of jitter is following Gaussian law, so if you wait long enought
   the peak-to-peak values will increase. Gaussian jitter can not be measured
   by peak-to-peak, but you want to measure it in terms of RMS. The
   peak-to-peak is a probability function and the rule-of-thumb value of 14
   times the RMS value gives you 1.0E-12 in BER.

2) Don't fool yourself to beleive all jitter is thermal, i.e. having gaussian
   distribution. The total time-error (or peak-to-peak) jitter sum (you can
   calculate it this way for BER/window-size values) will be the random jitter
   plus the deterministic jitter. Deterministic jitter includes stuff like
   Inter-Symbol-Interference (i.e. amplitude skew due to memory function of the
   channel, which adds level to the signal such that propper timing can not be
   acheived) and fixed frequency modulations. The later kind will eat you for
   breakfast if you don't pay attention. Not all crystal oscillators have low
   jitter. You will find that plenty of them for higher frequencies actually
   uses a lower frequency crystal and then uses a DCM or PLL to get the higher
   frequency. Not very supprising will there be a modulation at the comparator
   frequency, and yes, I have tossed such oscillators out of our designs many
   times. There are those that will properly filter in the step-up. Infact,
   some of these cheap oscillators perform better for some frequencies. You can
   however never know until you have measured it at the intended frequency.

3) Messen is wissen.

   Higher speeds do require fancier tools. I have pretty fancy tools. Infact,
   for clock measurement I have fancier tools at home than at work. Maybe that
   is why they sometimes have me measuring things at home from work.

4) Don't forget the step-up relation. The time-jitter you have at the reference
   may remain the same for some setups, so the reference jitter needs to meet
   the end jitter requirement in time, even if the cycle period is much bigger.
   The relative jitter thus changes as the carrier frequency is stepped up.

5) Read up on jitter. The Fibre Channel Jitter Mesurement Methology document is
   a good read. Tektronix has a nice document too. While these are more
   transmission oriented, they are more advanced in analysis than many of the
   digital and FPGA papers are.

6) Don't forget normal signal integrity. The Handbook of black magic, and the
   followup on Advanced black magic should be a good read too. The world is a
   harsh analog world for the poor digital engineers to figure out why their
   0s and 1s isn't commming through properly.

Cheers,
Magnus