This is the basic problem I'm trying to avoid: http://en.wikipedia.org/wiki/Metastability_in_electronics The problem is this: all logic devices which must "decide" on the state of an input on line A at a clock edge on a signal CLK will, under the right circumstances, exhibit a condition where the output will either oscillate or "hang out" at some voltage between logic low and logic high. This condition is called a metastable state, since it persists for some time but eventually recovers to either a 0 or a 1. All edge-triggered devices have some non-zero probability of remaining in this metastable state for any given amount of time. In other words, it is not possible to say for absolute certain that it could not remain there for 1 microsecond, 1 millisecond, or even 1 second. The longer you wait, the lower the probability is that it will still be in that metastable state. Depending on the design of the device, the probability can be made to decay very quickly, so that the probability of, say, remaining in this state for more than 1 microsecond is vanishingly small. This property comes from the fact that all circuits exhibit temporal dynamics (i.e., cannot switch instantly) and noise. When this is put together with positive feedback (used by all sequential logic circuits in order to maintain the stored state), metastability can result. The specific set of conditions which can cause this are that the input signal is changing during the metastability window, which is some window of time of a certain width and a certain offset from the clock edge. This is one reason why flip-flops have a set-up and hold time requirement. For example, if a FF has a set-up time requirement of 10 nanoseconds, and a hold time requirement of 1 nanosecond, this means that you are required to make sure that the input signal is stable and unchanging from 10 ns before the clock edge until 1 ns after. If you obey this condition, metastability cannot happen. If you violate this condition, it may or may not happen. In every FF, there is some actual window of time within this set-up/hold time where a changing input signal WILL cause metastability. In a well designed FF, the window is very small, typically 10s to 100s of picoseconds, but because of a high dependence on manufacturing variation, the set-up/hold time window is made several times larger than the typical metastability window. In a synchronous digital design, you rely on the combination of FF clock to output delay and signal propagation delay to meet set-up and hold requirements. For example, if FF A's output goes into FF B, and both are triggered from the same clock, you consider the maximum skew in the clock between them (call it t1), the required set-up time for FF B (t2), the required hold time for FF B (t3), FF A's minimum clock to output delay (t4), FF A's maximum clock to output delay (t5), minimum clock period (T), and the min and max propagation delay in the trace from FF A's output to FF B's input (t6 and t7, respectively). You then make sure that the following conditions are met: After the clock edge hits FF A, minimum total delay doesn't allow input to FF B to change before the hold time is up (t4+t6-t1 > t3) AND After the clock edge hits FF A, maximum total delay doesn't cause the input of FF B to continue to change after 1 set-up time before the next clock rising edge (t5+t7+t1 < (T-t2)) If you have an asynchronous system, then it is not the case that you do not assume ANY relationship between various clocks in the system - it is actually the case that you assume a random relationship. The standard practice is to first synchronize input signals to the local device's clock before using the result. This allows you to ignore set-up and hold concerns due to the input signal beyond the synchronizer itself. The synchronizer itself can never be completely free of metastability. Instead, usually two or more FFs are cascaded which roughly raises the probability of metastability to the Nth power (where N is the number of FF stages in the synchronizer). Even if the first one goes metastable, it is unlikely to remain metastable at the second clock edge, when the second stage tries to grab the value. However, this probabilistic system relies on the idea that each input sampling is a statistically-independent event. That is to say, that the time difference between the input signal changing and the clock edge is fairly uniformly distributed over at least a good fraction of the clock period. It must at least be distributed over more than the metastability window. If the source of the "asynchronous" input signal is in fact clocked by the same clock as the receiver of the signal, then the delta-T between the signal edge and the clock edge will be very tightly grouped from transition to transition, since the only variation will be the change in the clock skew and the propagation delays over time. Even clock jitter cancels out because the same oscillator is driving both devices. If the skew and propagation delay values happen to line up the signal edge to always happen (whenever the signal does change) within the metastability window of the first input FF of the receiving device, then almost every transition of the input signal will result in the output of this first FF going metastable. Now, instead of having a two-stage synchronizer, you have, at best, only one stage, and really it is worse than that because the signal edges seen by the second FF's input are rarely going to be clean edges at all. The probability of latching the wrong value is greatly increased and there is now some non-negligible probability that even the output of the second FF may go metastable, which could wreak havoc with other parts of the chip which may be looking for changes in the signal to trigger various events. Granted, it may be that when all of this is worked out for my particular circuit, something conspires to make a problem very unlikely. However, answering that question depends on a lot of info which I don't have. I have certainly seen this be a major problem within FPGA designs. The margins are tighter there, but the FFs are also designed to be metastability-resistant (i.e., very narrow metastability window). I have no such guarantee about those found in the input synchronizers of the various micros. Sean On Fri, Jul 1, 2011 at 1:08 AM, Jesse Lackey wr= ote: > What clock speeds are we talking about here? 10Mhz? 25Mhz? 100Mhz? > > As far as comms go, since SPI/UART/I2C/etc all make no assumption about > the state of the devices communicating, I can't see how it would matter > if said devices all have their master clocks from one source. Its not > like a SPI clock edge will be 'missed' ever... > > If you've got any leftover inverters/gates you could have your source > osc drive several of them and have each one drive just the input of the > CPUs, avoiding fanout and long traces problems. > > J > > > Sean Breheny wrote: >> Hi all, >> >> I thought I could find something about this via a Google search but so >> far I have not found exactly what I need. >> >> I'm having a disagreement with someone about how to handle a situation >> where there are several processors (two NXP ARM-type microcontrollers, >> a DSP, and two Freescale Power-PC microprocessors) on one PCB. To save >> money, he wants to use one oscillator for all of these and distribute >> it to them using clock distribution ICs. >> >> I think that this is unwise unless he takes great care to length-match >> the clock traces, control propagation velocity, etc. Otherwise, we >> could end up with metastability problems because we will likely have >> all of the processors operating in a pseudosynchronous mode and they >> intercommunicate with each other. At boot time there will be a fixed >> timing relationship established between them, and it could well be >> that this ends up with two of them clocking together except for a tiny >> amount of variation due to different propagation delays. It could then >> be that every single bit communicated between them ends up right in >> the middle of the metastability window, with the result that the >> probability of bit errors is relatively high. >> >> I am advocating that each processor be run with separate clocks. Even >> if they are at the same frequency, the drift and jitter among them are >> almost certain to be greater than the difference in propagation delays >> so that instances where a transition violates setup and hold times for >> the input synchronizers will be only rare, random events rather than >> potentially every single transition. >> >> He agrees that in principle I am right but he thinks that this is >> really only a risk if you are trying to set up a synchronous digital >> system. >> >> My main question for all of you is this: where can I find some web >> reference material which talks about clock hazards in nominally >> asynchronous digital systems? Everything I can find seems to assume >> that you are trying to set up all of the chips in lock-step >> synchronous operation. >> >> Secondarily, any opinions on this would be appreciated. >> >> Thanks, >> >> Sean > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .