recovery/removal timing

[Mark Curry]

In article <8a16f740-4fdc-45b2-a502-c612072a531e@googlegroups.com>,
KJ <kkjennings@sbcglobal.net> wrote:

On Friday, October 30, 2015 at 12:16:19 PM UTC-4, jt_eaton wrote:

There is no timing to violate. The vendors data sheet will specify a
reset_deassert to clock rise setup time that is only valid if the D input
has a 1 that has met the D input setup time.If D is a 0 then there is no
timing requirement.


Produce the Altera (since that's what has been discussed) datasheet or application note or some other quality source that supports your statement.

To refute, I'll put up the following from "AN 545: Design Guidelines and Timing Closure Techniques for HardCopy ASICs". Admittedly, this is for HardCopy ASICs, not FPGAs but note that there is
no mention of the state of the 'D' input. Timing issues are always between two signals, not three. In this case it is between 'reset' and 'clock'.

Reset recovery time refers to the time between de-asserted reset and when the clock signal goes high again. Violating recovery time causes metastability on register outputs.

Kevin Jennings
[1]https://www.altera.com/en_US/pdfs/literature/an/an545.pdf

Kevin,

I'm lost who's arguing what in this thread. Usenet's a lousy forum
for this thing. But, Altera's document directly refutes your last statement.

Page 13 of that Document:
"In the event that the ref_clk edge arrives close to the time
areset is removed from FF1 and FF2, there is no metastability risk on FF2 because
the D-input value is already at a stable value."

The clock recovery check depends on the state of areset, clk, AND the D-input.

Regards,

Mark

 

[KJ]

On Friday, October 30, 2015 at 2:49:26 PM UTC-4, Mark Curry wrote:

But, Altera's document directly refutes your last statement.

Page 13 of that Document:
"In the event that the ref_clk edge arrives close to the time
areset is removed from FF1 and FF2, there is no metastability risk on FF2 because
the D-input value is already at a stable value."

The clock recovery check depends on the state of areset, clk, AND the D-input.

It wasn't my statement it was Altera's statement. Suffice it to say then that Altera's own document is self-contradictory. On page 11, in the section 'Metastability safe reset design' they clearly state that violating reset recovery requirements can cause metastability. On page 13, as you found they state the exact opposite. Given that Altera is talking out of both sides, I guess they are not such a good source after all. Good catch!

My statement then is that the page 13 statement must be either wrong or perhaps written poorly or the page 11 statement is true only under conditions that are left unstated. If page 13 is correct, then it would be true in general and there would not even be a reset recovery time requirement in the first place. Think about it, if you can violate the reset recovery time requirement with no penalty as page 13 states, then there effectively is no such requirement that needs to be 'met' so there would be no need to synchronize the trailing edge of reset. What does it even mean to have a requirement that does not need to be met? Now granted, they do have the caveat about the input being stable, but that will typically be the case anyway since most upstream flops will be in a stable state due to the reset.

So, if you really believe page 13, you shouldn't feel any need to synchronize reset. If you really believe page 11, then you will. If you don't know which way to go, you should take the safe route and synchronize.

Kevin Jennings

 

[jt_eaton]

If you violate timing you should not necessarily expect things to work
properly so saying "...choosing between staying at 0 or loading a 0. It
the
same result either way" on your second example is rolling the dice and
hoping you won't get unlucky.

Kevin Jennings

There is no timing to violate. The vendors data sheet will specify
reset_deassert to clock rise setup time that is only valid if the D inpu
has a 1 that has met the D input setup time.If D is a 0 then there is n
timing requirement.



John Eaton


--------------------------------------
Posted through http://www.FPGARelated.com

 

[jt_eaton]

Well in that case how do we explain that the well documented reset sync
design works.
I mean that design that connects reset to async port of two stages
synchroniser but connects D input of first register to '1'. If it is
matter of dice that design would not be reliable as claimed. (also known
as filtered reset design)

Zak

Thats called a metastable filter. The dice toss determines which cycl
produces the reset but the design shouldn't care and work in all cases. I
you put an asynchronous signal into two different metastable filters the
their outputs may not be identical.

John Eaton

--------------------------------------
Posted through http://www.FPGARelated.com

 

[Mark Curry]

In article <0e1bc68e-73c4-409d-8886-62e886915507@googlegroups.com>,
KJ <kkjennings@sbcglobal.net> wrote:

On Friday, October 30, 2015 at 2:49:26 PM UTC-4, Mark Curry wrote:
But, Altera's document directly refutes your last statement.

Page 13 of that Document:
"In the event that the ref_clk edge arrives close to the time
areset is removed from FF1 and FF2, there is no metastability risk on FF2 because
the D-input value is already at a stable value."

The clock recovery check depends on the state of areset, clk, AND the D-input.


It wasn't my statement it was Altera's statement. Suffice it to say then that Altera's own document is self-contradictory. On page 11, in the section 'Metastability safe reset design' they
clearly state that violating reset recovery requirements can cause metastability. On page 13, as you found they state the exact opposite. Given that Altera is talking out of both sides, I
guess they are not such a good source after all. Good catch!

My statement then is that the page 13 statement must be either wrong or perhaps written poorly or the page 11 statement is true only under conditions that are left unstated. If page 13 is
correct, then it would be true in general and there would not even be a reset recovery time requirement in the first place. Think about it, if you can violate the reset recovery time
requirement with no penalty as page 13 states, then there effectively is no such requirement that needs to be 'met' so there would be no need to synchronize the trailing edge of reset. What
does it even mean to have a requirement that does not need to be met? Now granted, they do have the caveat about the input being stable, but that will typically be the case anyway since most
upstream flops will be in a stable state due to the reset.

So, if you really believe page 13, you shouldn't feel any need to synchronize reset. If you really believe page 11, then you will. If you don't know which way to go, you should take the safe
route and synchronize.

I agree, the statement is poorly worded. What I think it meant to say, (and what I've
been arguing all along) is that "..there is no metastability risk on FF2 because
the D-nput value is already at a stable value (0) matching the output value Q (0)."

If the D input did NOT match, I think ALL of us would agree that you have a hazard.
But since D==Q, the clock recovery isn't checked/invalid and the reset recovery
mechanism, (as suggested by both Xilinx and Altera) works. Can there be
any other conclusion? Do you think that both A's and X's recommended
methodology has a hazard? Do you follow this recommendation?

If I had time, I'd quickly simulate this. It'd be easy to setup. I know longer
rememeber enough about UDP modeling to just look at the cell models and
see what it does. I *DO* recall seeing this in models in the past however -
qualifying a recovery check with a comparison D==Q.

Regards,

Mark

 

[rickman]

On 10/30/2015 4:42 AM, zak wrote:

I didn't say there couldn't be metastability. I said there would be no

oscillation. Similar to balancing a pencil on end, the state resolves
monotonically with an arbitrary delay.


Rick

No oscillation still doesn't mean correct sampling but will help signal
settle for next flop. It remains that input must be in a known state for
some finite time to be sampled correctly.

I'm not sure what "correct sampling" means regarding metastability. By
definition the sampling is done on a changing signal, so the resulting
value is not defined.

I guess I'm not sure what you are saying. Did we lose context of the
original issue?

--

Rick

 

[zak]

On 10/30/2015 4:42 AM, zak wrote:

I didn't say there couldn't be metastability. I said there would b
no

oscillation. Similar to balancing a pencil on end, the stat
resolves
monotonically with an arbitrary delay.


Rick

No oscillation still doesn't mean correct sampling but will hel
signal
settle for next flop. It remains that input must be in a known stat
for
some finite time to be sampled correctly.

I'm not sure what "correct sampling" means regarding metastability. By
definition the sampling is done on a changing signal, so the resulting
value is not defined.

I guess I'm not sure what you are saying. Did we lose context of the
original issue?

--

Rick

The input D must be read by flop as '0' or '1' according to predefine
levels intrinsic to the flop. If D is changing how do you expect to sampl
it as '0' or '1'. There should be no transition near the sampling cloc
edge and D must be defined as either '0' or '1' so that the level i
sampled onto Q. This is the whole point in any sampling device. Nothin
mysterious here. It is the very basis of tSU and tH

Zak

--------------------------------------
Posted through http://www.FPGARelated.com

 

[rickman]

On 10/30/2015 3:58 PM, zak wrote:

On 10/30/2015 4:42 AM, zak wrote:

I didn't say there couldn't be metastability. I said there would be
no

oscillation. Similar to balancing a pencil on end, the state
resolves
monotonically with an arbitrary delay.


Rick

No oscillation still doesn't mean correct sampling but will help
signal
settle for next flop. It remains that input must be in a known state
for
some finite time to be sampled correctly.

I'm not sure what "correct sampling" means regarding metastability. By
definition the sampling is done on a changing signal, so the resulting
value is not defined.

I guess I'm not sure what you are saying. Did we lose context of the
original issue?

--

Rick

The input D must be read by flop as '0' or '1' according to predefined
levels intrinsic to the flop. If D is changing how do you expect to sample
it as '0' or '1'. There should be no transition near the sampling clock
edge and D must be defined as either '0' or '1' so that the level is
sampled onto Q. This is the whole point in any sampling device. Nothing
mysterious here. It is the very basis of tSU and tH

Of course. I think we all understand what sampling is.

On the other hand, I have no idea what your point in discussing "correct
sampling" is.

--

Rick

 

[zak]

On 10/30/2015 3:58 PM, zak wrote:
On 10/30/2015 4:42 AM, zak wrote:

I didn't say there couldn't be metastability. I said there woul
be
no

oscillation. Similar to balancing a pencil on end, the state
resolves
monotonically with an arbitrary delay.


Rick

No oscillation still doesn't mean correct sampling but will help
signal
settle for next flop. It remains that input must be in a known state
for
some finite time to be sampled correctly.

I'm not sure what "correct sampling" means regarding metastability.
By
definition the sampling is done on a changing signal, so th
resulting
value is not defined.

I guess I'm not sure what you are saying. Did we lose context of the
original issue?

--

Rick

The input D must be read by flop as '0' or '1' according to predefined
levels intrinsic to the flop. If D is changing how do you expect to
sample
it as '0' or '1'. There should be no transition near the samplin
clock
edge and D must be defined as either '0' or '1' so that the level is
sampled onto Q. This is the whole point in any sampling device
Nothing
mysterious here. It is the very basis of tSU and tH

Of course. I think we all understand what sampling is.

On the other hand, I have no idea what your point in discussing "correc

sampling" is.

--

Rick

On the point of oscillation that you raised. If technology can dampe
oscillations or completely remove them then it is only part of the timin
violation problem. It remains that there will be tSU/tH requirement n
matter what technology is used. Dampening oscillations will only improv
on MTBF.

Zak
--------------------------------------
Posted through http://www.FPGARelated.com

 

[rickman]

On 10/30/2015 4:45 PM, zak wrote:

On 10/30/2015 3:58 PM, zak wrote:
On 10/30/2015 4:42 AM, zak wrote:

I didn't say there couldn't be metastability. I said there would
be
no

oscillation. Similar to balancing a pencil on end, the state
resolves
monotonically with an arbitrary delay.


Rick

No oscillation still doesn't mean correct sampling but will help
signal
settle for next flop. It remains that input must be in a known state
for
some finite time to be sampled correctly.

I'm not sure what "correct sampling" means regarding metastability.
By
definition the sampling is done on a changing signal, so the
resulting
value is not defined.

I guess I'm not sure what you are saying. Did we lose context of the
original issue?

--

Rick

The input D must be read by flop as '0' or '1' according to predefined
levels intrinsic to the flop. If D is changing how do you expect to
sample
it as '0' or '1'. There should be no transition near the sampling
clock
edge and D must be defined as either '0' or '1' so that the level is
sampled onto Q. This is the whole point in any sampling device.
Nothing
mysterious here. It is the very basis of tSU and tH

Of course. I think we all understand what sampling is.

On the other hand, I have no idea what your point in discussing "correct

sampling" is.

--

Rick

On the point of oscillation that you raised. If technology can dampen
oscillations or completely remove them then it is only part of the timing
violation problem. It remains that there will be tSU/tH requirement no
matter what technology is used. Dampening oscillations will only improve
on MTBF.

I didn't say the oscillations were the same thing as metastability. The
point is in the case of the reset timing, there is no timing violation
on the D input. So unless there was an oscillation from the reset
timing violation, why would the output change at all?

--

Rick

 

[zak]

This doc (see page 22) answers directly issues raised in this post

http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf

Za
--------------------------------------
Posted through http://www.FPGARelated.com

 

[KJ]

On Friday, October 30, 2015 at 4:28:37 PM UTC-4, Mark Curry wrote:

I agree, the statement is poorly worded. What I think it meant to say, (and what I've
been arguing all along) is that "..there is no metastability risk on FF2 because
the D-nput value is already at a stable value (0) matching the output value Q (0)."

Not saying that's not the case, I'm just saying that the part about 'D=Q' in your statement is not supported by any device manufacturer from what I've been able to find. Maybe it's an oversight on their part, maybe their device happen to work the way you would like, who knows? The point is when you rely on things that are not specifically supported, you're the one out on the limb. The fact that Altera directly contradicted themselves means that one of those statements 'as-is', is incorrect. Maybe it's the page 13 statement that should be completely removed?

The problem with discussing the use of the async reset within the context of a 'power on reset' is that within that context, the circuit usage is fail-safe. Let's say one or both of those flip flops really does flake out and goes to the wrong state, what happens? Either the reset pulse inside the device is shorter than it "could" have been, or the flops end up seeing the reset followed by a 'non-reset' for one clock cycle followed by a one clock cycle wide 'reset' clock cycle followed by 'non-reset' and normal operation. In either of those scenarios, I would suspect that nearly every single FPGA design in the world will work just fine without any hiccups. So an end user really has no clue as to whether the proposed async reset of that second flip flop that is used to generate the final chip wide reset is actually working the way you think it does or not. Try to use an async reset like that where every clock cycle does need to be correct many millions of times every second and run for days/weeks under environmental and voltage stress if you want to demonstrate reliability. Discussing it within the context of a 'once every now and then' event doesn't show much. By the way, I'm not advocating anyone to do this, just using this example to show that the 'power on reset' application of the async reset of a flip flop in the context where failure would go undetected does not demonstrate reliability of the circuit in any sort of meaningful way.

> If the D input did NOT match, I think ALL of us would agree that you have a hazard.

I'm not sure why you say that, but OK.

But since D==Q, the clock recovery isn't checked/invalid and the reset recovery
mechanism, (as suggested by both Xilinx and Altera) works.

Well, Altera as we've seen contradicts themselves. In another place they do not use the async reset input at all, instead they feed it into the D input [2]. I haven't found anything on Xilinx's website. In fact, what I've found specifically recommends that you never use the asynchronous reset [1].. Can you post the Xilinx recommendation that you are discussing?

As a similar, but related example, [3] is an example of a transparent latch that will fail if D=Q=1, but not if D=Q=0. While this is a different example, it does expose that just because D=Q, doesn't necessarily imply anything special without in-depth knowledge of how the underlying device is implemented in transistor in the silicon. If you want to take a crack at it, explain why the D=Q path that you're proposing applies to the flip flop but not to the latch.

Can there be
any other conclusion? Do you think that both A's and X's recommended
methodology has a hazard?

Can't comment on X's recommendation since I haven't been able to find it. A recommended two different things within the span of two pages of the same document so obviously they don't quite understand it well enough at the time to document it either. But in the Quartus 13.1 handbook [4], the async reset is only used to reset the very first flip flop in the chain (See figure 12-19 on page 31) so it's hard to say they are advocating the asynchronous reset of anything beyond that first flip flop. The reality is that there is no reason for even that flip flop to be reset asynchronously either as Altera shows in [2].

Do you follow this recommendation?
I don't use async reset at all unless the device I'm interfacing with requires it for some reason, and typically there is no such requirement. I'll bring the async reset into D and clock it through pretty much as I would any other async input. I've never had the need to reset the device absolutely as fast as possible and never had the need to operate when the clock isn't up and running. Basically reset like shown in [2].

The link that Zak last posted by Cummings et al is actually somewhat relevant but it comes from secondary sources. The authors all appear to have at least some ASIC design expertise, but they have no real skin in the game since they aren't the device manufacturer and again, the context of the circuit is the fail-safe power on reset. Not dissing their expertise, just framing it. Unfortunately, in section 7.1 which is specifically devoted to explaining why there is no metastability on the second flip flop, all they offer up as an explanation is to say "There is no logic differential between the input and output of the flip-flop so there is no chance that the output would oscillate between two different logic values." They did not indicate that they performed any Spice simulations and actual lab testing to bolster that claim, they just simply made a claim. In the next section, they indicate that they suggested to a doubter that they perform a transistor level sim and that person then reported that it agreed with the prediction. So at least someone performed some simulation, but again without lab data, it's not as strong.

Probably all this means is that for a circuit such as power on reset where failure is tolerated, any synchronizing circuit will work just as well as any other. For a circuit that cannot tolerate failure, the idea that you can ignore a timing requirement because the input and output of a flip flop are in the same state is a dicey one to bet anything on.

Anyway, I'm sure the horse is long since dead and the beating can stop. But it was interesting.

Kevin Jennings

[1] http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/sim.pdf page 56, section titled 'Set, Resets, and Synthesis Optimization' in chapter 5 'Coding for FPGA Device Flow'.

[2] http://quartushelp.altera.com/14.0/mergedProjects/verify/da/comp_file_rules_reset_external.htm

[3] This form of latch has been directly observed to eventually fail with certain common technologies if D=Q=1.
process(D, C)
begin
if (C=1) then
Q <= D;
end if;
end process;

This will fail as well
Q <= (D and C)
or (Q and not(C));

This form of latch will not fail, but only if implemented exactly like this.. The third term is redundant and will be removed by synthesis tools unless specifically prevented from doing so, but if that term is removed it will make the latch fail

Q <= (D and C)
or (Q and not(C))
or (D and Q); <-- Redundant but required

[4] https://www.altera.co.jp/ja_JP/pdfs/literature/hb/qts/qts_qii51006.pdf, page 31, Figure 12-19.