recovery/removal timing

>
>Normally with setup/hold if D is not changing then timing violation 
>does not apply. 
>Does this apply to recovery/removal as well with respect to D input?
>


If your D input is 1 then the timing between reset deassert and clock will
determine whether the flop stays 0 or flips to 1.

If your D input is 0 then it shouldn't matter because you are choosing
between staying at 0 or loading a 0. Its the same result either way.

The problem is that this depends on how the flop is implemented. If you
build a flop using multiplexers and don't use glitchless muxes then it
would be possible to see a 1 in this situation.

Your silicon vendors data sheet should spell this out. If it is missing or
ambiguous then be afraid, be very afraid.

John Eaton



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

On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote:
> 
> 
> If your D input is 1 then the timing between reset deassert and clock will
> determine whether the flop stays 0 or flips to 1.
> 
> If your D input is 0 then it shouldn't matter because you are choosing
> between staying at 0 or loading a 0. Its the same result either way.
> 

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

Kevin Jennings

>On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote:
>> 
>> 
>> If your D input is 1 then the timing between reset deassert and clock
>will
>> determine whether the flop stays 0 or flips to 1.
>> 
>> If your D input is 0 then it shouldn't matter because you are choosing
>> between staying at 0 or loading a 0. Its the same result either way.
>> 
>
>If you violate timing you should not necessarily expect things to work
>properly so saying "...choosing between staying at 0 or loading a 0. Its
the
>same result either way" on your second example is rolling the dice and
>hoping you won't get unlucky.
>
>Kevin Jennings

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
---------------------------------------
Posted through http://www.FPGARelated.com

On Thursday, October 29, 2015 at 1:38:50 PM UTC-4, zak wrote:
> >On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote:
> >> 
> >> 
> >> If your D input is 1 then the timing between reset deassert and clock
> >will
> >> determine whether the flop stays 0 or flips to 1.
> >> 
> >> If your D input is 0 then it shouldn't matter because you are choosing
> >> between staying at 0 or loading a 0. Its the same result either way.
> >> 
> >
> >If you violate timing you should not necessarily expect things to work
> >properly so saying "...choosing between staying at 0 or loading a 0. Its
> the
> >same result either way" on your second example is rolling the dice and
> >hoping you won't get unlucky.
> >
> >Kevin Jennings
> 
> 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)
> 

Several reasons:
- If it really was so 'reliable' then you would only need one stage synchronizer, not two.  But you do need two or more in order to be reliable because you will likely be violating timing on each flip flop in that reset synchronizer.
- The resets you are talking about typically happen once per power up, not millions of times per second so the chances of you seeing it fail are slim
- If you get an *extra* errant reset clock cycle for some reason you wouldn't know it because the system wouldn't reset.  It's only if no reset gets generated that you *might* notice that things are not as they should be.
- Most flip flops in a design do not need to be reset with a global reset at all.  Those that don't have that need will be unaffected by whether or not there actually is a reset to that flip flop.

Kevin Jennings

>
>Several reasons:
>- If it really was so 'reliable' then you would only need one stage
>synchronizer, not two.  But you do need two or more in order to be
reliable
>because you will likely be violating timing on each flip flop in that
reset
>synchronizer.
>Kevin Jennings

I think you are misunderstanding the filtered reset design. It connects
reset to async port of BOTH flops. So it is not worried about second flop
i.e. no problem will occur there if reset is released near its clock edge
and there is no third flop to put it right.

Moreover Altera says this design metsatbility proof (I assume 100%)

Zak 


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

On 10/29/2015 2:21 PM, zak wrote:
>>
>> Several reasons:
>> - If it really was so 'reliable' then you would only need one stage
>> synchronizer, not two.  But you do need two or more in order to be
> reliable
>> because you will likely be violating timing on each flip flop in that
> reset
>> synchronizer.
>> Kevin Jennings
>
> I think you are misunderstanding the filtered reset design. It connects
> reset to async port of BOTH flops. So it is not worried about second flop
> i.e. no problem will occur there if reset is released near its clock edge
> and there is no third flop to put it right.
>
> Moreover Altera says this design metsatbility proof (I assume 100%)

It has been demonstrated time and time again that there is no such thing 
as "metastability proof" in FFs.

This also can occur in mechanical devices and I just realized that the 
penultimate mechanical time piece is subject to this problem.  The 
Shortt double pendulum clock has a mechanism that speeds up the slave 
pendulum when needed based on the relative timing of the two pendulums. 
  The mechanism that detects this is subject to metastability or a 
similar effect.  When timed just "wrong", on the cusp of decision 
between fast and slow the mechanism misapplies the speed up mechanism 
giving a chaotic jolt to the slave pendulum (potentially the opposite of 
the intended direction).  I expect this perturbation has little 
consequence, but it is interesting that it happens.

The kicker on the master pendulum uses a gravity lever to give it a push 
every 30 swings.  This is timed by the slave pendulum, so there will 
still be small perturbations in the strength of the push, but nothing 
like metastability that I can see.

-- 

Rick

On Thursday, October 29, 2015 at 2:21:45 PM UTC-4, zak wrote:
>=20
> I think you are misunderstanding the filtered reset design.=20

Or perhaps you're misunderstanding it.  I'm assuming that you're referring =
to 'Synchronized Asynchronous Reset' in chapter 12 of the Quartus handbook =
(specifically, Figure 12-20) [1]...but who knows

>=20
> Moreover Altera says this design metsatbility proof (I assume 100%)
>=20

They made no such claim in this section.  Altera states no reason for havin=
g the second flip flop, but I would claim that it is there specifically for=
 metastability protection.  As with any metastability protection, that seco=
nd flip flop will not be a 100% guarantee, but it will be close enough to f=
or practical purposes.

You can assume whatever you want based on your incorrect recall of the circ=
uit.  That would be rolling the dice again.

Kevin Jennings

[1] https://www.altera.co.jp/ja_JP/pdfs/literature/hb/qts/qts_qii51006.pdf =
page 12-32

In article <u5SdnYBUwKE4xK_LnZ2dnUU7-U2dnZ2d@giganews.com>,
zak <93737@FPGARelated> wrote:
>>On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote:
>>> 
>>> 
>>> If your D input is 1 then the timing between reset deassert and clock
>>will
>>> determine whether the flop stays 0 or flips to 1.
>>> 
>>> If your D input is 0 then it shouldn't matter because you are choosing
>>> between staying at 0 or loading a 0. Its the same result either way.
>>> 
>>
>>If you violate timing you should not necessarily expect things to work
>>properly so saying "...choosing between staying at 0 or loading a 0. Its
>the
>>same result either way" on your second example is rolling the dice and
>>hoping you won't get unlucky.
>>
>>Kevin Jennings
>
>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

Zak - very good point - you're analysis is spot on.  Looking back at my
designs, I see I am now using the Xilinx recomended reset synchronizer, same
as discussed here.  You're right however, in that using that methodology
depends on the assertion "If D is same as Q" on the FF, the clock recovery
check isn't neccesary.  Which I advocated against depending on 
in my initial response.  Looks like I'm not following my own advice.

But I think it's safe for the reasons I stated - Xilinx recommends it, they
know the Flop internals, therefore, they understand the internal behaviors of
the design.

Looking back, however, I noticed I PREVIOUSLY used a different reset 
synchronizer:

reg [ STAGES - 1 : 0 ] reset_in_D;
always @( posedge clk )
  if( clk_en )
    reset_in_D <= { reset_in_D, reset_in };

assign reset_out = reset_in_D[ STAGES - 1 ] | reset_in;

That version probably is a less optimal use of resources, however, I think
it's safer in the general case - since it doesn't depend on any
specific clock recovery behaviour.  Same behaviour - async active edge of
reset is passed through asynchronously.  Inactive edge is synchronized.  No
clock recovery check to worry about, as the async reset on the flop isn't used.

I may reconsider using this other reset synchronizer again....

Regards,
Mark

On Thursday, October 29, 2015 at 3:04:05 PM UTC-4, Mark Curry wrote:
> 
> Zak - very good point - you're analysis is spot on.  Looking back at my
> designs, I see I am now using the Xilinx recomended reset synchronizer, same
> as discussed here.  You're right however, in that using that methodology
> depends on the assertion "If D is same as Q" on the FF, the clock recovery
> check isn't neccesary.  

Except that the device responds to changes on the inputs, not from the state of their outputs.  In other words, meeting (or not meeting) a timing requirement does not depend on the current state of the output, it only depends on the inputs and their timing relationship.  If you want to believe that "If D is same as Q" on the FF, the clock recovery check isn't necessary." that's up to you, but it's a belief that is not grounded in any sort of reality.

Belief that if something happens to be in the correct state already so that means that you can violate timing and not change that state is a false hope.  It is not what will be guaranteed to happen, it's just something that you hope will happen.  Find a datasheet that actually states what you believe.

Kevin Jennings

>Except that the device responds to changes on the inputs, not from the
>state of their outputs.  In other words, meeting (or not meeting) a
timing
>requirement does not depend on the current state of the output, it only
>depends on the inputs and their timing relationship.  If you want to
believe that
>"If D is same as Q" on the FF, the clock recovery check isn't
necessary."
>that's up to you, but it's a belief that is not grounded in any sort of
>reality.
>
>Belief that if something happens to be in the correct state already so
>that means that you can violate timing and not change that state is a
false
>hope.  It is not what will be guaranteed to happen, it's just something
that
>you hope will happen.  Find a datasheet that actually states what you
>believe.
>
>Kevin Jennings

It is not a case of output but that this output flags the inner state of
the flop as it a case of latching. 

Anyway, one thing sure the design that is proven to work (what I stated
above) connects reset to async port of BOTH flips so surely the second
flop is not protected and that means to me no problem is expected there.

I Should say metastablity safe rather than proof. Sorry.

The question that arises why need connect reset to second flop at all. It
serves a different purpose in that if clock stops and you want to reapply
reset...

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