recovery/removal timing

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

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

>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

>Kevin Jennings

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

Zak

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

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

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

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.

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

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

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

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

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.  

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

Any proof?

If you look at the well tried circuit of reset synchronisation, according
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 is
now the synchronised reset(if deassrted). Both flops clocked by same
system clock and their asyc port wired to reset(arrives ant time). This
design cannot be explained to work unless D1 & D2 inputs are relevant to
definition of recovery/removal as the design must ignore the situation
when clock edge of second flop is too close to reset deassertion. It will
then fail 50/50

Zak


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

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

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.



John Eaton


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