recovery/removal timing

>
>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 cycle
produces the reset but the design shouldn't care and work in all cases. If
you put an asynchronous signal into two different metastable filters then
their outputs may not be identical.

John Eaton

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

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

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

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

>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

Zak

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

On Friday, October 30, 2015 at 2:49:26 PM UTC-4, Mark Curry wrote:
> But, Altera's document directly refutes your last statement.
>=20
> 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."
>=20
> The clock recovery check depends on the state of areset, clk, AND the D-i=
nput.
>=20

It wasn't my statement it was Altera's statement.  Suffice it to say then t=
hat Altera's own document is self-contradictory.  On page 11, in the sectio=
n 'Metastability safe reset design' they clearly state that violating reset=
 recovery requirements can cause metastability.  On page 13, as you found t=
hey state the exact opposite.  Given that Altera is talking out of both sid=
es, 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 per=
haps 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 ge=
neral 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 re=
quirement with no penalty as page 13 states, then there effectively is no s=
uch requirement that needs to be 'met' so there would be no need to synchro=
nize the trailing edge of reset.  What does it even mean to have a requirem=
ent that does not need to be met?  Now granted, they do have the caveat abo=
ut 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 synchroni=
ze 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

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

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

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

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

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