recovery/removal timing

[KJ]

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

 

[KJ]

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

 

[KJ]

On Thursday, October 29, 2015 at 2:21:45 PM UTC-4, zak wrote:

I think you are misunderstanding the filtered reset design.

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

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

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

You can assume whatever you want based on your incorrect recall of the circuit. 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

 

[Mark Curry]

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

 

[jt_eaton]

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 wil
determine whether the flop stays 0 or flips to 1.

If your D input is 0 then it shouldn't matter because you are choosin
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 yo
build a flop using multiplexers and don't use glitchless muxes then i
would be possible to see a 1 in this situation.

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

John Eaton



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

 

[KJ]

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

 

[KJ]

On Thursday, October 29, 2015 at 3:55:46 PM UTC-4, zak wrote:

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

This makes no sense, but I won't belabor it

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.

Again, this is your belief that "no problem is expected there" as well as "proven to work" for that matter. In the 'Synchronized Asynchronous Reset' circuit, Altera states the benefit as being that reset "takes effect almost instantaneously, and ensures that no data path for speed is involved, and that the circuit is synchronous for timing analysis and is resistant to noise". Now take a look at the 'Asynchronous Reset with Follower Registers' section which is similar except that the async reset is not connected to anything but the first flip flop. In that section, they explain the reasoning with metastability and MTBF. You would have to suspend your belief to explain why that circuit is "proven to work".

In any case, we're way off the beaten path. My only point in this thread was what I put in the first post which is "If you violate timing you should not necessarily expect things to work properly". You have an unfounded belief that "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." You have provided no datasheet that backs your claim of correct behavior in spite of a timing violation so I'll leave it at that and move on.

If you're lucky, you'll go through your career and never have this bite you in the rear. If you're not so lucky, well, hopefully the bite is not too painful and you learn the lesson at that time since you're unwilling to learn it at this time.

Kevin Jennings

 

[Mark Curry]

In article <9c5808ac-160c-49b1-a141-b311b69a75ba@googlegroups.com>,
KJ <kkjennings@sbcglobal.net> wrote:

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.

This isn't true in general at all - it all depends on the underlying
design of the cell. The SDF format was specifically modified to
allow this feature - to do a timing check depending on some other state
(i.e. internal state of the cell).

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.

I think you're missing my point - we're agreeing more than disagreeing.
I don't advocate depending on that hand wavy, but not documented
requirement that no clock recovery check is neccesary when D==Q.

However, as Zak points out, the Xilinx recommended reset resynchronization
implies that this is true. If it isn't then the recommended reset
synchronization has a timing hazard.

It may be similar to another "heard, but not documented" feature of
Xilinx technology - that a LUT output will NOT glitch if you only change
one input. Another feature that I wouldn't recommended depending
on, but is asked from time to time in these and similar forums, and
I beleive Xilinx has stated a "hand wavy" ok.

Regards,

Mark

 

[zak]

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. It
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 syn
design works.
I mean that design that connects reset to async port of two stage
synchroniser but connects D input of first register to '1'. If it i
matter of dice that design would not be reliable as claimed. (also know
as filtered reset design)

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

 

[zak]

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 b
reliable
because you will likely be violating timing on each flip flop in tha
reset
synchronizer.
Kevin Jennings

I think you are misunderstanding the filtered reset design. It connect
reset to async port of BOTH flops. So it is not worried about second flo
i.e. no problem will occur there if reset is released near its clock edg
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

 

[rickman]

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

 

[zak]

Except that the device responds to changes on the inputs, not from the
state of their outputs. In other words, meeting (or not meeting)
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 t
believe that
"If D is same as Q" on the FF, the clock recovery check isn'
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
false
hope. It is not what will be guaranteed to happen, it's just somethin
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 o
the flop as it a case of latching.

Anyway, one thing sure the design that is proven to work (what I state
above) connects reset to async port of BOTH flips so surely the secon
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. I
serves a different purpose in that if clock stops and you want to reappl
reset...

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

 

[rickman]

On 10/29/2015 3:32 PM, KJ wrote:

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.

I don't personally know that much about the current state of FPGA
internals, but in a related conversation in one of these groups I was
told today's technology will not produce an oscillation on the output
with a D input timing violation. I would think this is the same thing
as the reset not meeting setup/hold timing.

Any ideas?

--

Rick

 

[zak]

My only point in this thread
was what I put in the first post which is "If you violate timing yo
should
not necessarily expect things to work properly". You have an unfounded
belief that "If your D input is 0 then it shouldn't matter because yo
are
choosing between staying at 0 or loading a 0. Its the same result either
way." You have provided no datasheet that backs your claim of correc
behavior

>Kevin Jennings

In that case the same concept should hold true for setup/hold as well. I
so timing violation will occur even though D input has no transition. Wha
would setup or hold mean then?

Zak

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

 

[zak]

I don't personally know that much about the current state of FPGA
internals, but in a related conversation in one of these groups I was
told today's technology will not produce an oscillation on the output
with a D input timing violation. I would think this is the same thing
as the reset not meeting setup/hold timing.

Any ideas?

--

Rick

Can't be possible. It is not matter of technology since you need a know
state at sampling window rather than changing state. Technology ca
improve on timing window but this can't be zero time.

Asynchronous based design doesn't care about timing of flops but logi
decisions go through varying delay paths... I heard years ago Achroni
trying some ultra high speed fpga based on async design but never hear
any update.

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

 

[rickman]

On 10/29/2015 5:40 PM, zak wrote:

I don't personally know that much about the current state of FPGA
internals, but in a related conversation in one of these groups I was
told today's technology will not produce an oscillation on the output
with a D input timing violation. I would think this is the same thing
as the reset not meeting setup/hold timing.

Any ideas?

--

Rick

Can't be possible. It is not matter of technology since you need a known
state at sampling window rather than changing state. Technology can
improve on timing window but this can't be zero time.

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.

Asynchronous based design doesn't care about timing of flops but logic
decisions go through varying delay paths... I heard years ago Achronix
trying some ultra high speed fpga based on async design but never heard
any update.

I believe they are targeting only very large customers and have been
shipping product for some time now, but I don't recall for sure. It
should be easy to check out.
--

Rick

 

[zak]

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

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 signa
settle for next flop. It remains that input must be in a known state fo
some finite time to be sampled correctly.

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

 

[psustew]

On Thursday, October 29, 2015 at 8:34:48 AM UTC-4, zak wrote:

One of fundamental aspects of implementing an asynchronous reset, which
is
often overlooked, is that the reset must be DEASSERTED with proper
timing
margin with respect to the clock. This is why Altera, and many other
vendors recommend synching the reset to the relevant clock domain.
Recovery is
defined as the setup time of the deassertion of the reset with respect
to
the clock. Removal is defined as the hold time of the deassertion of
the
reset with respect to the clock. This is defined in the Altera
documenation
-- I think it's in the Quartus handbook. Timequest does an excellent
job
analyzing these paths if proper timing constraints are defined.

Robert - lead VHDL/Verilog trainer
www.digitaldesignconcepts.org

Thanks Robert,

My original question was not about "standard" definitions of
recovery/removal but rather the relation of reset deassertion to D input.


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?

I think Mark Curry answered my question. I will be grateful if you can
share your views with this regard.

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

Recovery and Removal does NOT apply to the D input. It only applies to the application of asynchronous signals (preset or set) and the clock. The D input is a don't care for this timing check. Simply put, if your flip/flop's asynchronous inputs and clocks change at the same time, or without enough timing margin, the flop's output will be indeterminate or unstable. As I said, this is a timing check that is often overlooked by designers.

 

[zak]

Recovery and Removal does NOT apply to the D input. It only applies to
the application of asynchronous signals (preset or set) and the clock.
The
D input is a don't care for this timing check. Simply put, if your
flip/flop's asynchronous inputs and clocks change at the same time, o
without
enough timing margin, the flop's output will be indeterminate o
unstable. As
I said, this is a timing check that is often overlooked by designers.

Any proof?

If you look at the well tried circuit of reset synchronisation, accordin
to your view it should not work. So somebody should be wrong.

The circuit is this:

'1' connects to D1(input of flop1) , Q1 output wired to D2(flop2). Q2 i
now the synchronised reset(if deassrted). Both flops clocked by sam
system clock and their asyc port wired to reset(arrives ant time). Thi
design cannot be explained to work unless D1 & D2 inputs are relevant t
definition of recovery/removal as the design must ignore the situatio
when clock edge of second flop is too close to reset deassertion. It wil
then fail 50/50

Zak


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

 

[KJ]

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