Synchronizing Clocks
I'm concentrating right now on signal integrity issues for a new digital project.
Our system includes one particular board with a multitude of clocks. The various clocks toggle various buses (and devices), which are connected to each other through FIFO interfaces.
I'm in doubt if it is desirable to try to synchronize these clocks as much as possible, so there will be no noise at the critical setup times. With this approach I might have different clocks but they will all be derived from the same oscillator and have a minimal skew between their rising edges. I see 2 problems with this approach: One is that our flexibility in choosing bus and processor speeds will be limited, and the second is that it seems very difficult to actually sufficiently synchronize a large clock tree, given the (comparatively) large skew between 2 or more clock drivers.
So, my question is: what should I do to prevent noise problems if I choose not to synchronize the whole clock tree. What I thought to do is first to segregate signals associated with the different clocks on different layers, with a reference plane between them. In case this is not possible, I will keep such signals at a sufficient distance from each other. But what about ground (or supply) bounce? What are your recommendations regarding this issue?
Thanks for your interest in High-Speed Digital Design.
Whether the clocks are synchronized or not, you can obtain arbitrarily good PCB crosstalk performance by merely separating them in the layout. Two parallel traces 500 mils apart, running at a height of 5 mils above the nearest reference plane, produce worst-case crosstalk of only about 1 part in 10,000 (80 dB). That's way more than good enough.
The thing that will create most of your noise on the CLOCK inputs is ground bounce created by other outputs located within the same chip. If particularly low jitter is required in your application, you could use differential clock signaling to minimize this source of interference. Even with differential clocks you will still need to keep other traces away from the clock traces to control crosstalk.
In an un-synchronized design the data inputs are also susceptible to ground bounce (also called simultaneous-switching-output or SSO noise). It's usually not feasible to implement differential inputs on every data input so what is normally done for a chip that must deal with unsynchronized inputs is to either provide additional power and ground pins on the package, or use a split-power architecture. The split-power architecture internally divides the chip's power and ground nets into different regions (called power and ground rings), with each ring dedicated to the outputs associated with one clock.
A significant disadvantage of non-synchronized operation that you did not mention is metastability. Every non-synchronous FIFO circuit has a certain probability of failure, determined by the input clock rate, the output clock rate, and the internal construction of the part. The probability of failure may be low, but it never really goes away. Fully synchronized systems avoid this problem.
Even if you do go with an un-synchronized design, it's a good idea to rig up a TEST system with the clock artificially synchronized. I like to set up the clocks so they are all at the same FREQUENCY, but with manually adjustable PHASE.
I then very slowly scan through all possible clock phases checking for any metastability or ground bounce noise problems that may occur only at one particular phase. With the clocks un-synchronized, such problems only occur infrequently, making them difficult to detect and cure.
My last comment is that you should take a close look at some of the new delay-compensated clock repeaters. It is now possible to buy a 1:8 clock repeater with a delay specification of zero, plus or minus 50 pico-seconds, from the input to any output. Such parts might allow you to build a completely synchronous system. If you do, you'll sleep better at night.
Best Regards,
Dr. Howard Johnson