Re: [time-nuts] Metastability (was Brooks Shera)

[Bob Camp]

Hi

The worst case (this time) are errors in the bottom 5 bits. The software will 
treat them as valid data. That assumes things stay simple. You are looking a 
counter that wraps around a lot of times….

Bob

On Mar 26, 2013, at 7:33 AM, Javier Serrano  
wrote:

> On Mon, Mar 25, 2013 at 11:16 PM, Tom Van Baak  wrote:
>>> Both edges of the 24MHz clock gating pulse are asynchronous with respect
>>> to the signal being gated.
>>> Metastability can result with clock pulse widths that lie within a
>>> critical range.
>>> 
>>> Bruce
>> 
>> I don't disagree with your statement above, but my question was -- does it 
>> matter in a GPSDO; does it matter in this GPSDO?
>> 
>> Occasionally missing a 24 MHz tick is a not a worry (all gated frequency 
>> counters share this "feature"). A one-count ambiguity is normal and 
>> expected, even welcome. Note also that the PIC will see only 0 or 1; there 
>> is no metastability in software. So where exactly is the problem?
> 
> Properly designed gated frequency counters get the input pulses into
> their system clock domain by using a synchronizer. Then they use this
> synchronized pulse to freeze the value of their internal counters. In
> the process of synchronizing the input you do introduce a 1 clock tick
> uncertainty, and this is unavoidable unless you go to more evolved
> designs based on interpolation. I don't think this is what we discuss
> about when we talk about metastability. If my understanding is
> correct, what we are discussing is what happens if you try to freeze
> the value of a counter with a signal which is asynchronous to the
> clock of that counter. Imagine that you have a 32-bit counter and your
> async pulse comes when the counter is transitioning from 0x to
> 0x. *All* bits are changing state. Even without metastability
> involved, i.e. assuming you don't hit the metastability window in any
> of the 32 FFs you use for freezing the counter value, you have a
> problem which is not a 1 tick problem. This is because the delays of
> each bit going from the counter FFs to the freezing register FFs are
> never exactly the same, so at the moment of freezing you might sample
> e.g. 0xABCDABCD, i.e. something completely unrelated to the value you
> would expect. Metastability would only make things worse by making
> some of those bits "undefined" for some length of time.
> 
> So this is a well understood problem with a standard solution. Designs
> which don't use this solution can still function well if the
> occurrence I described is not very frequent.  It was said in the other
> thread that Brooks Shera got rid of outliers (defined by him as more
> than 30 ticks offset) in software. That still leaves a 30 tick
> uncertainty for the time tag. So again, there is a proper way of
> dealing with metastability, but that does not automatically imply that
> designs not using it will malfunction. It depends on how often it
> happens and what the specifications are for the given design. Still,
> coping with metastability properly is so simple and cheap that there
> is really no reason not to do it.
> 
> Cheers,
> 
> Javier
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Javier Serrano]

On Mon, Mar 25, 2013 at 11:16 PM, Tom Van Baak  wrote:
>> Both edges of the 24MHz clock gating pulse are asynchronous with respect
>> to the signal being gated.
>> Metastability can result with clock pulse widths that lie within a
>> critical range.
>>
>> Bruce
>
> I don't disagree with your statement above, but my question was -- does it 
> matter in a GPSDO; does it matter in this GPSDO?
>
> Occasionally missing a 24 MHz tick is a not a worry (all gated frequency 
> counters share this "feature"). A one-count ambiguity is normal and expected, 
> even welcome. Note also that the PIC will see only 0 or 1; there is no 
> metastability in software. So where exactly is the problem?

Properly designed gated frequency counters get the input pulses into
their system clock domain by using a synchronizer. Then they use this
synchronized pulse to freeze the value of their internal counters. In
the process of synchronizing the input you do introduce a 1 clock tick
uncertainty, and this is unavoidable unless you go to more evolved
designs based on interpolation. I don't think this is what we discuss
about when we talk about metastability. If my understanding is
correct, what we are discussing is what happens if you try to freeze
the value of a counter with a signal which is asynchronous to the
clock of that counter. Imagine that you have a 32-bit counter and your
async pulse comes when the counter is transitioning from 0x to
0x. *All* bits are changing state. Even without metastability
involved, i.e. assuming you don't hit the metastability window in any
of the 32 FFs you use for freezing the counter value, you have a
problem which is not a 1 tick problem. This is because the delays of
each bit going from the counter FFs to the freezing register FFs are
never exactly the same, so at the moment of freezing you might sample
e.g. 0xABCDABCD, i.e. something completely unrelated to the value you
would expect. Metastability would only make things worse by making
some of those bits "undefined" for some length of time.

So this is a well understood problem with a standard solution. Designs
which don't use this solution can still function well if the
occurrence I described is not very frequent.  It was said in the other
thread that Brooks Shera got rid of outliers (defined by him as more
than 30 ticks offset) in software. That still leaves a 30 tick
uncertainty for the time tag. So again, there is a proper way of
dealing with metastability, but that does not automatically imply that
designs not using it will malfunction. It depends on how often it
happens and what the specifications are for the given design. Still,
coping with metastability properly is so simple and cheap that there
is really no reason not to do it.

Cheers,

Javier
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Hal Murray]

li...@rtty.us said:
> If the data is changing as the clock fires, the flip flop oscillates rather
> than goes to a single state.

It may not oscillate.  Some sit at halfway and then wander off, slowly at 
first but with an exponential speedup.

The usual way to describe metastability is how much longer you have to wait 
until the data is stable.  The clock-to out gets stretched.

Here is an example from the net:
  http://www2.tek.com/cmswpt/psdetails.lotr?ct=PS&cs=psu&ci=13298
The first picture, about a page down, shows metastability.  You can see the 
number of events decaying as you get farther from the normal case.



-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[lists]

There is an AMD patent where they actually drive the input pin to make it 
decide rather than hang. I have no first hand knowledge with the design (well 
other than knowing the designer) since I couldn't use the scheme in my own 
designs.

-Original Message-
From: Bob Camp 
Sender: time-nuts-boun...@febo.com
Date: Mon, 25 Mar 2013 18:02:33 
To: Discussion of precise time and frequency measurement
Reply-To: Discussion of precise time and frequency measurement

Subject: Re: [time-nuts] Metastability (was Brooks Shera)

Hi

In normal operation, the counter is clocking back and forth across the 1024 / 
24,000,000 boundary. It has to do this for the control loop to "see" anything. 
Put another way, if it's always 1024 / 24,000,000 the loop does nothing at all. 

It's the "race" between things like enable and clock or data and clock that 
generates metastable conditions. If the data is changing as the clock fires, 
the flip flop oscillates rather than goes to a single state. In this case 
oscillation is not a good thing…..

Bob

On Mar 25, 2013, at 5:43 PM, Chris Albertson  wrote:

> First off we have the answer.  This thing works very reliably well.
> The question is "why?"
> 
> In the normal steady state case the phase of the VCXO is held to be
> 1024/24,000,000 seconds.  This means the plus from pin 15 of the 4046
> would be about 4,000 nanoseconds long and would never be anything so
> much as a factor of ten away from 4 uSec.
> 
> One thing I notice is that I think the QST artcle has the pins on the
> 4520 mislabeled.  Pins 9 and 10 are the two inputs to an AND gate.
> The 24MHz counter is being "anded" with the phase detector and the
> result of the AND is then fed to the counter.  My data sheet shows
> pins 2 and 10 as being called "enable".  So what we have as a pulse
> that is about 4uSec wide gating a 24MHz square wave.
> 
> There might be a "race" to see if the enable pin or the clock pin gets
> a pulse first and it would be a coin flip now and then but it's only
> an off by one problem.
> 
> In the no-steady state case, when power is first applied before the
> loop is closed.  I don't think we care about glitches and and if the
> VXCO is stable but as soon as it does locj the pulse going to pin the
> 4520's pin-10 will be 1024 times longer than the the period of the
> signal at pin-9  Again, pins 10 and 9 are the two inputs to an AND
> gate (after pin-10 is inverted)
> 
> On Mon, Mar 25, 2013 at 2:04 PM, Bob Camp  wrote:
>> Hi
>> 
>> With the 24 MHz clock in the circuit, and the logic families shown, the most
>> likely metastability issues are edge rather than clock pulse width related.
>> When you hit the "magic window" (think picoseconds) there is a probability
>> of going metastable. It's not a 100% thing. Even with multiple synchronizer
>> stages *not* being metastable is also not a 100% guarantee.
>> 
>> The real question is - does a once every X seconds / hours / centuries event
>> bother me in the application? Once you get to a multi stage synchronizer,
>> the dimensions on the time are large enough that the answer is generally no.
>> The event is so rare that you will never see it with these data rates. Being
>> sure it's fixed is easy.
>> 
>> It's the flip side - error rate without the synchronizer that is a bit
>> harder to quantify. Things could run for weeks outside the threat window. Is
>> it a several times a minute (every few days) or once an hour (every few
>> weeks) problem? In the first case, you probably do care. Multiple hits per
>> minute will mess up the loop. In the second case, you will never notice the
>> issue.
>> 
>> Of course, boost the clock, change the logic family, mix logic families,
>> fiddle this or that and you probably should look at things again...
>> 
>> Bob
>> 
>> -Original Message-
>> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
>> Behalf Of Bruce Griffiths
>> Sent: Monday, March 25, 2013 4:38 PM
>> To: Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] Metastability (was Brooks Shera)
>> 
>> Both edges of the 24MHz clock gating pulse are asynchronous with respect
>> to the signal being gated.
>> Metastability can result with clock pulse widths that lie within a
>> critical range.
>> 
>> Bruce
>> 
>> Chris Albertson wrote:
>>> On Mon, Mar 25, 2013 at 12:45 PM, David McGaw
>> wrote:
>>> 
>>>> S/LS logic was introduced in the mid 70's, F/AS/ALS around 1980, HC was
>>>> early 80's.  By the t

Re: [time-nuts] Metastability (was Brooks Shera)

[Bruce Griffiths]

Tom Van Baak wrote:

Both edges of the 24MHz clock gating pulse are asynchronous with respect
to the signal being gated.
Metastability can result with clock pulse widths that lie within a
critical range.

Bruce
 

I don't disagree with your statement above, but my question was -- does it 
matter in a GPSDO; does it matter in this GPSDO?

Occasionally missing a 24 MHz tick is a not a worry (all gated frequency counters share 
this "feature"). A one-count ambiguity is normal and expected, even welcome. 
Note also that the PIC will see only 0 or 1; there is no metastability in software. So 
where exactly is the problem?

   
Agilent go to a lot of trouble to add synchronisers (and sometimes clock 
jitter eg HP5345A) to their gated frequency counters to ensure that the 
average measured frequency is unbiased.

For more detail see:
http://www.hpmemory.org/an/pdf/an_200.pdfpp 
27-28
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdf  
pp 12-15


The average value of the counter output when sampled is important in a 
GPSDO.
Metastability can result in an output that oscillates or dwells at a 
level that is neither 1 nor 0.
How the PIC reacts to such inputs is unpredictable although on an 
interrupt input, at least, its likely to use a synchroniser.



For educational purposes if nothing else, I'm looking for a precise description 
of the scenario (at the picosecond level if necessary) that reveals the flaw in 
his board. I'm not saying there isn't; I'm just saying I'd like to see it 
explained. Either his design was accidentally or intentionally clever, or there 
is in fact a minor fault. However, if there is a flaw, we also need to explain 
why in 15 years no one has reported glitches in their Shera boards.
   
Probably because those that built them either didn't have the necessary 
equipment or were unaware of the potential problem.

I sort of understand metastability, but just adding more hardware to reduce it 
doesn't seem to be the only way to deal with the issue in a GPSDO.

Said -- how do you handle this in your Fury design?

/tvb




Bruce

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Chris Albertson]

On Mon, Mar 25, 2013 at 3:41 PM, Chris Albertson
 wrote:

>> In normal operation, the counter is clocking back and forth across the 1024 
>> / 24,000,000 boundary. It has to do this for the control loop to "see" 
>> anything. Put another way, if it's always 1024 / 24,000,000 the loop does 
>> nothing at all.


Yes.  the counter value never should go more than 30 counts away from
1024.  He defines a difference of over 30 as a "glitch" and as I
wrote, if this happens three times he does a reset and toggle a LED.
 I was surprized at how low the threshold is.  30 seems low but
appearenty it almost never goes that far from 1024

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Chris Albertson]

On Mon, Mar 25, 2013 at 3:02 PM, Bob Camp  wrote:
> Hi
>
> In normal operation, the counter is clocking back and forth across the 1024 / 
> 24,000,000 boundary. It has to do this for the control loop to "see" 
> anything. Put another way, if it's always 1024 / 24,000,000 the loop does 
> nothing at all.
>
> It's the "race" between things like enable and clock or data and clock that 
> generates metastable conditions. If the data is changing as the clock fires, 
> the flip flop oscillates rather than goes to a single state. In this case 
> oscillation is not a good thing…..

Looking at the source code...

1) He tries to detect what he calls "glitches" which are unexpected
values of the counters.  He waits for three of them then turns on the
"glitch LED" and does a hard reset to the counters by lowing the CLR
line.This seems to be the only case the  "CLR" is arrested.  In
other than glitch cases he lets the counters wrap.   So I guess we
could see by looking at the LED how often this happens.  He defines
"glitch" as the phase shifting by an impossible amount three times in
three seconds

2) there is another safety feature in that he only allows the output
to the DAC to move at a slow rate (I think one count per 30 seconds?)


-- 

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Tom Van Baak]

> Both edges of the 24MHz clock gating pulse are asynchronous with respect 
> to the signal being gated.
> Metastability can result with clock pulse widths that lie within a 
> critical range.
> 
> Bruce

I don't disagree with your statement above, but my question was -- does it 
matter in a GPSDO; does it matter in this GPSDO?

Occasionally missing a 24 MHz tick is a not a worry (all gated frequency 
counters share this "feature"). A one-count ambiguity is normal and expected, 
even welcome. Note also that the PIC will see only 0 or 1; there is no 
metastability in software. So where exactly is the problem?

For educational purposes if nothing else, I'm looking for a precise description 
of the scenario (at the picosecond level if necessary) that reveals the flaw in 
his board. I'm not saying there isn't; I'm just saying I'd like to see it 
explained. Either his design was accidentally or intentionally clever, or there 
is in fact a minor fault. However, if there is a flaw, we also need to explain 
why in 15 years no one has reported glitches in their Shera boards.

I sort of understand metastability, but just adding more hardware to reduce it 
doesn't seem to be the only way to deal with the issue in a GPSDO.

Said -- how do you handle this in your Fury design?

/tvb


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[David]

On Mon, 25 Mar 2013 14:56:25 -0700, Hal Murray
 wrote:

>
>n1...@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.

Besides the rare application note, I have seen metastability data in
ECL datasheets and in datasheets from other logic families when the
part was specifically described as hardened against metastability.

It would be fun to build a test fixture to characterize metastability
in some popular logic families from various manufacturers.  I lack the
right kind of oscilloscope to do it the easy way but maybe there is a
more sophisticated way.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [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  wrote:

> 
> n1...@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@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Bob Camp]

Hi

In normal operation, the counter is clocking back and forth across the 1024 / 
24,000,000 boundary. It has to do this for the control loop to "see" anything. 
Put another way, if it's always 1024 / 24,000,000 the loop does nothing at all. 

It's the "race" between things like enable and clock or data and clock that 
generates metastable conditions. If the data is changing as the clock fires, 
the flip flop oscillates rather than goes to a single state. In this case 
oscillation is not a good thing…..

Bob

On Mar 25, 2013, at 5:43 PM, Chris Albertson  wrote:

> First off we have the answer.  This thing works very reliably well.
> The question is "why?"
> 
> In the normal steady state case the phase of the VCXO is held to be
> 1024/24,000,000 seconds.  This means the plus from pin 15 of the 4046
> would be about 4,000 nanoseconds long and would never be anything so
> much as a factor of ten away from 4 uSec.
> 
> One thing I notice is that I think the QST artcle has the pins on the
> 4520 mislabeled.  Pins 9 and 10 are the two inputs to an AND gate.
> The 24MHz counter is being "anded" with the phase detector and the
> result of the AND is then fed to the counter.  My data sheet shows
> pins 2 and 10 as being called "enable".  So what we have as a pulse
> that is about 4uSec wide gating a 24MHz square wave.
> 
> There might be a "race" to see if the enable pin or the clock pin gets
> a pulse first and it would be a coin flip now and then but it's only
> an off by one problem.
> 
> In the no-steady state case, when power is first applied before the
> loop is closed.  I don't think we care about glitches and and if the
> VXCO is stable but as soon as it does locj the pulse going to pin the
> 4520's pin-10 will be 1024 times longer than the the period of the
> signal at pin-9  Again, pins 10 and 9 are the two inputs to an AND
> gate (after pin-10 is inverted)
> 
> On Mon, Mar 25, 2013 at 2:04 PM, Bob Camp  wrote:
>> Hi
>> 
>> With the 24 MHz clock in the circuit, and the logic families shown, the most
>> likely metastability issues are edge rather than clock pulse width related.
>> When you hit the "magic window" (think picoseconds) there is a probability
>> of going metastable. It's not a 100% thing. Even with multiple synchronizer
>> stages *not* being metastable is also not a 100% guarantee.
>> 
>> The real question is - does a once every X seconds / hours / centuries event
>> bother me in the application? Once you get to a multi stage synchronizer,
>> the dimensions on the time are large enough that the answer is generally no.
>> The event is so rare that you will never see it with these data rates. Being
>> sure it's fixed is easy.
>> 
>> It's the flip side - error rate without the synchronizer that is a bit
>> harder to quantify. Things could run for weeks outside the threat window. Is
>> it a several times a minute (every few days) or once an hour (every few
>> weeks) problem? In the first case, you probably do care. Multiple hits per
>> minute will mess up the loop. In the second case, you will never notice the
>> issue.
>> 
>> Of course, boost the clock, change the logic family, mix logic families,
>> fiddle this or that and you probably should look at things again...
>> 
>> Bob
>> 
>> -Original Message-
>> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
>> Behalf Of Bruce Griffiths
>> Sent: Monday, March 25, 2013 4:38 PM
>> To: Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] Metastability (was Brooks Shera)
>> 
>> Both edges of the 24MHz clock gating pulse are asynchronous with respect
>> to the signal being gated.
>> Metastability can result with clock pulse widths that lie within a
>> critical range.
>> 
>> Bruce
>> 
>> Chris Albertson wrote:
>>> On Mon, Mar 25, 2013 at 12:45 PM, David McGaw
>> wrote:
>>> 
>>>> 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
>>>> 
>>> I think this is all moot because as I just wrote in another email the
>>> PPS signal never gets out of the 74hct4046 chip.   What gets out is
>>> the output of  "Phase Detector #3".  You've have to know in some
>>> detail how the 4046 chips' PD3 works.
>>> 
>>> Chris Albertson
>>> Redondo Beach, Califo

Re: [time-nuts] Metastability (was Brooks Shera)

[Hal Murray]

n1...@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Chris Albertson]

First off we have the answer.  This thing works very reliably well.
The question is "why?"

In the normal steady state case the phase of the VCXO is held to be
1024/24,000,000 seconds.  This means the plus from pin 15 of the 4046
would be about 4,000 nanoseconds long and would never be anything so
much as a factor of ten away from 4 uSec.

One thing I notice is that I think the QST artcle has the pins on the
4520 mislabeled.  Pins 9 and 10 are the two inputs to an AND gate.
The 24MHz counter is being "anded" with the phase detector and the
result of the AND is then fed to the counter.  My data sheet shows
pins 2 and 10 as being called "enable".  So what we have as a pulse
that is about 4uSec wide gating a 24MHz square wave.

There might be a "race" to see if the enable pin or the clock pin gets
a pulse first and it would be a coin flip now and then but it's only
an off by one problem.

In the no-steady state case, when power is first applied before the
loop is closed.  I don't think we care about glitches and and if the
VXCO is stable but as soon as it does locj the pulse going to pin the
4520's pin-10 will be 1024 times longer than the the period of the
signal at pin-9  Again, pins 10 and 9 are the two inputs to an AND
gate (after pin-10 is inverted)

On Mon, Mar 25, 2013 at 2:04 PM, Bob Camp  wrote:
> Hi
>
> With the 24 MHz clock in the circuit, and the logic families shown, the most
> likely metastability issues are edge rather than clock pulse width related.
> When you hit the "magic window" (think picoseconds) there is a probability
> of going metastable. It's not a 100% thing. Even with multiple synchronizer
> stages *not* being metastable is also not a 100% guarantee.
>
> The real question is - does a once every X seconds / hours / centuries event
> bother me in the application? Once you get to a multi stage synchronizer,
> the dimensions on the time are large enough that the answer is generally no.
> The event is so rare that you will never see it with these data rates. Being
> sure it's fixed is easy.
>
> It's the flip side - error rate without the synchronizer that is a bit
> harder to quantify. Things could run for weeks outside the threat window. Is
> it a several times a minute (every few days) or once an hour (every few
> weeks) problem? In the first case, you probably do care. Multiple hits per
> minute will mess up the loop. In the second case, you will never notice the
> issue.
>
> Of course, boost the clock, change the logic family, mix logic families,
> fiddle this or that and you probably should look at things again...
>
> Bob
>
> -Original Message-
> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
> Behalf Of Bruce Griffiths
> Sent: Monday, March 25, 2013 4:38 PM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Metastability (was Brooks Shera)
>
> Both edges of the 24MHz clock gating pulse are asynchronous with respect
> to the signal being gated.
> Metastability can result with clock pulse widths that lie within a
> critical range.
>
> Bruce
>
> Chris Albertson wrote:
>> On Mon, Mar 25, 2013 at 12:45 PM, David McGaw
> wrote:
>>
>>> 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
>>>
>> I think this is all moot because as I just wrote in another email the
>> PPS signal never gets out of the 74hct4046 chip.   What gets out is
>> the output of  "Phase Detector #3".  You've have to know in some
>> detail how the 4046 chips' PD3 works.
>>
>> Chris Albertson
>> Redondo Beach, California
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



-- 

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Bob Camp]

Hi

With the 24 MHz clock in the circuit, and the logic families shown, the most
likely metastability issues are edge rather than clock pulse width related.
When you hit the "magic window" (think picoseconds) there is a probability
of going metastable. It's not a 100% thing. Even with multiple synchronizer
stages *not* being metastable is also not a 100% guarantee. 

The real question is - does a once every X seconds / hours / centuries event
bother me in the application? Once you get to a multi stage synchronizer,
the dimensions on the time are large enough that the answer is generally no.
The event is so rare that you will never see it with these data rates. Being
sure it's fixed is easy.

It's the flip side - error rate without the synchronizer that is a bit
harder to quantify. Things could run for weeks outside the threat window. Is
it a several times a minute (every few days) or once an hour (every few
weeks) problem? In the first case, you probably do care. Multiple hits per
minute will mess up the loop. In the second case, you will never notice the
issue. 

Of course, boost the clock, change the logic family, mix logic families,
fiddle this or that and you probably should look at things again...

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Bruce Griffiths
Sent: Monday, March 25, 2013 4:38 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Metastability (was Brooks Shera)

Both edges of the 24MHz clock gating pulse are asynchronous with respect 
to the signal being gated.
Metastability can result with clock pulse widths that lie within a 
critical range.

Bruce

Chris Albertson wrote:
> On Mon, Mar 25, 2013 at 12:45 PM, David McGaw
wrote:
>
>> 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
>>  
> I think this is all moot because as I just wrote in another email the
> PPS signal never gets out of the 74hct4046 chip.   What gets out is
> the output of  "Phase Detector #3".  You've have to know in some
> detail how the 4046 chips' PD3 works.
>
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Bruce Griffiths]

Both edges of the 24MHz clock gating pulse are asynchronous with respect 
to the signal being gated.
Metastability can result with clock pulse widths that lie within a 
critical range.


Bruce

Chris Albertson wrote:

On Mon, Mar 25, 2013 at 12:45 PM, David McGaw  wrote:
   

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
 

I think this is all moot because as I just wrote in another email the
PPS signal never gets out of the 74hct4046 chip.   What gets out is
the output of  "Phase Detector #3".  You've have to know in some
detail how the 4046 chips' PD3 works.

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

   


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[Chris Albertson]

On Mon, Mar 25, 2013 at 12:45 PM, David McGaw  wrote:
> 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

I think this is all moot because as I just wrote in another email the
PPS signal never gets out of the 74hct4046 chip.   What gets out is
the output of  "Phase Detector #3".  You've have to know in some
detail how the 4046 chips' PD3 works.

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Metastability (was Brooks Shera)

[David McGaw]

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.



On 3/25/13 2:56 PM, Attila Kinali wrote:

On Mon, 25 Mar 2013 14:03:23 -0400
David McGaw  wrote:


Actually, most modern FFs are hardened against metastability so often a
single synchronizer will do especially if it is feeding a synchronous
circuit.

I would not count on that. Most 74xx that hobbyists use are from
the HC and HCT families. These have been designed in the 70s (IIRC)
and i very much doubt that any of the manufacturers changed anything
in their design since then.

Attila Kinali



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.