[time-nuts] Metastability (was Brooks Shera)

[Bob Camp]

Hi

The reason you don't see MTBF's is that they are indeed hard to find. Even the formulas that come up with them are not particularly easy to deal with. What they very much want you to do is to spend big bucks on the analysis program and the data to drive it. 

To put some numbers on it:

At 353.8 ps offset and a 24 MHz clock you have a MTBF of 12,345 events for a single FF. For a two FF sync (effectively 3 in series) you have 12,345^3 = 1.88e^12. You go from "gee pretty often" to "never that I'll ever see". Yes I made up the 12,345. The transition from "oops" to "never" is why you rarely see the numbers. Unless the data rates are very high, the reliability very stringent, or the logic really awful, you just fix it and move on. 

Bob

On Mar 25, 2013, at 5:56 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

> 
> n1hac at alum.dartmouth.org said:
>> S/LS logic was introduced in the mid 70's, F/AS/ALS around 1980, HC was
>> early 80's.  By the third 7400 generation (F/AS/ALS) the problem was well
>> known with parameters available and the logic fairly hard to it.
> 
> The problem is well understood in the right circles, but we wouldn't be 
> having this much of a discussion if it really was widely understood.
> 
> The parameters are not readily available.  I've never seen them in data 
> sheets.  Sometimes you can find them in app-notes, but those are usually just 
> typicals.  I don't remember seeing any worst-case test results.  Peter Alfke 
> from Xilinx did a lot of good work in this area.
> 
> "Hard" is an interesting term.  In general, settling time scales with the 
> general speed of a logic family.  But then designs go faster so there may not 
> be any net gain.
> 
> The classic solution is a synchronizer: 2 FFs.  Nobody ever does the math 
> behind it.  For example, did Bruce's recent comments include any MTBF numbers?
> 
> There is a hidden assumption in the classic synchronizer.  The key idea is 
> that you need time to allow the first FF to settle.  That means the clock 
> must be significantly slower than the max clock rate for the simple FF-FF 
> path.  You get that without any thought if you use the same clock for a pile 
> of logic that includes something like an ALU.  The time through the ALU is 
> the settling time for the synchronizer.
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.