recovery/removal timing

In article <K-6dnfZewNs-8LfLnZ2dnUU7-IudnZ2d@giganews.com>,
jt_eaton <84408@FPGARelated> wrote:
>
>>
>>Apologies but can I ask if this reply is from an ASIC mindset or is it
>>spam. Almost every statement doesn't make any sense whatsoever for
>FPGAs.
>>
>>Zak
>>---------------------------------------
>>Posted through http://www.FPGARelated.com
>
>Valid question. It is from an ASIC mindset and has nothing to do with
>FPGA's. This entire thread has nothing to do with FPGA's
>
>Xilinx recomends that you never use an asynchonous reset in your logic. 
>Its expensive ( sync reset flops takes 3 LUT's while an async one takes
>4). It's slow ( Xilinx has a app note on rtl programming styles that says
>async resets can slow you down by a factor as high as 4. All those really
>fast multiplier macros use sync reset so if you ask for async then it must
>build them out of LUTs. It is also redundent. Your programming input is
>asynchronous and leaves every flop in the design in a known state. That is
>your power on asynchronous reset system. Adding a second one in logic
>makes no sense at all.
>
>I haven't read Altera docs but I suspect the same will apply

A few nits, but the general gist is all good.  Async resets should be MINIMIZED
in Xilinx logic - but "never" isn't usually attainable.  Even in some Xilinx
app notes they're used.  

Why?- Well, using an async reset on a flop removes the requirement of a 
good clock.  That flop'll will be reset irrespective of the clock state.

So, many times in your clock and reset generation blocks, you'll likely need
the async resets on flops.

I also warn to be careful with assuming FPGA Config = Reset.  They're often 
NOT the same, and just relying on the former, can lead to some rather nasty
and long debug sessions.  My point here is that specifically including a
SYNCHRONOUS reset, in MOST of your logic is a wise design practice.  (Something
Xilinx discourages for optimal fpga use, but IMHO, they're just dead
wrong).

Regards,

Mark

In article <-Jadnfhk6Ivf6bfLnZ2dnUU7-fednZ2d@giganews.com>,
jt_eaton <84408@FPGARelated> wrote:
>>zak wrote:
>>
>
>>I just found a condition where you could have an un-synchronized input on
>a
>>
>>product that has been in manufacture for a decade.  Normally, this signal
>IS
>>
>>synchronized on the FPGA, but there was a particular configuration
>involving
>>
>>multiple boards where it would be synched from the OTHER board, only. 
>>OOPS!
>>
>>Jon
>
>That goes to show that once you ship your product then it probably will
>not see many resets during its lifetime. I've done embedded systems that
>are always on and I suspect that few of them would ever see more than a
>few dozen resets before they are trashed. Designers worry about resets all
>the time but if you screw it up then it is very unlikely that the customer
>will trigger a failure and extremely unlikely that they will do so twice
>in a row. 
>
>Turning it back off and on again can hide a lot of mistakes

John, I agree with assertion, but not neccesarily your conclusions.
Yes, resets may not occur very often in you're devices.
But that IMHO, is more the reason to get it right.  

Murphy's law says that that one customer will hit the troublesome
case more often.  And since it's so fiddly, and hardly used
you don't have many datapoints on failures.  Meaning debugging's 
a bitch.

I pay close attention to reset and initialization.  Been
bitten by too many low probability errors that occur much
too late in the design cycle.  They're the devil to debug.


Regards,
Mark

On 10/23/2015 1:25 PM, jt_eaton wrote:
>>
>> Apologies but can I ask if this reply is from an ASIC mindset or is it
>> spam. Almost every statement doesn't make any sense whatsoever for
> FPGAs.
>>
>> Zak
>> ---------------------------------------
>> Posted through http://www.FPGARelated.com
>
> Valid question. It is from an ASIC mindset and has nothing to do with
> FPGA's. This entire thread has nothing to do with FPGA's
>
> Xilinx recomends that you never use an asynchonous reset in your logic.
> Its expensive ( sync reset flops takes 3 LUT's while an async one takes
> 4). It's slow ( Xilinx has a app note on rtl programming styles that says
> async resets can slow you down by a factor as high as 4. All those really
> fast multiplier macros use sync reset so if you ask for async then it must
> build them out of LUTs. It is also redundent. Your programming input is
> asynchronous and leaves every flop in the design in a known state. That is
> your power on asynchronous reset system. Adding a second one in logic
> makes no sense at all.
>
> I haven't read Altera docs but I suspect the same will apply

I think you are a bit confused about the async reset.  Every FF in the 
fabric is connected to an async reset signal that spans the entire chip. 
  This is called (oddly enough) the Global Set/Reset or GSR in Xilinx 
devices.  It is always asserted during configuration and can also be 
driven by a user signal.

An async reset can be critical to restore a defined state to the design 
in the event the clock stops.  This signal is usually pretty slow and 
may be hard to get to meet system synchronous timing requirements.  The 
trick to proper use is to make sure there are other controls that 
maintain a reset state for the design when the async signal is removed. 
  These synchronous resets can apply to local sections of logic which 
must start up synchronized while usually the entire design does not. 
Then timing is more easily met.

-- 

Rick

In article <n0dvqo$m3p$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 10/23/2015 1:25 PM, jt_eaton wrote:
>>>
>>> Apologies but can I ask if this reply is from an ASIC mindset or is it
>>> spam. Almost every statement doesn't make any sense whatsoever for
>> FPGAs.
>>>
>>> Zak
>>> ---------------------------------------
>>> Posted through http://www.FPGARelated.com
>>
>> Valid question. It is from an ASIC mindset and has nothing to do with
>> FPGA's. This entire thread has nothing to do with FPGA's
>>
>> Xilinx recomends that you never use an asynchonous reset in your logic.
>> Its expensive ( sync reset flops takes 3 LUT's while an async one takes
>> 4). It's slow ( Xilinx has a app note on rtl programming styles that says
>> async resets can slow you down by a factor as high as 4. All those really
>> fast multiplier macros use sync reset so if you ask for async then it must
>> build them out of LUTs. It is also redundent. Your programming input is
>> asynchronous and leaves every flop in the design in a known state. That is
>> your power on asynchronous reset system. Adding a second one in logic
>> makes no sense at all.
>>
>> I haven't read Altera docs but I suspect the same will apply
>
>I think you are a bit confused about the async reset.  Every FF in the 
>fabric is connected to an async reset signal that spans the entire chip. 
>  This is called (oddly enough) the Global Set/Reset or GSR in Xilinx 
>devices.  It is always asserted during configuration and can also be 
>driven by a user signal.
>
>An async reset can be critical to restore a defined state to the design 
>in the event the clock stops.  This signal is usually pretty slow and 
>may be hard to get to meet system synchronous timing requirements.  The 
>trick to proper use is to make sure there are other controls that 
>maintain a reset state for the design when the async signal is removed. 
>  These synchronous resets can apply to local sections of logic which 
>must start up synchronized while usually the entire design does not. 
>Then timing is more easily met.

I've got trouble thinking how the GSR could be used for any useful thing
by the designer.  The trouble with the GSR is that it's removal edge 
is slow, and asynchronous to everything.  So flops may reset fine with 
this signal, but coming out of reset, the state's still unknown.  The 
parts of a design that can make reliable use of this, is a rare exception,
not the rule, IMHO.

And back to the OP - I believe he was NOT referring to this GSR at all, but
to the normal Async reset on a FF i.e. (verilog)

always @( posedge clk or posedge reset )
  if( reset )
     q <= 0;
  else 
     q <= d;

This is the async flip flop, where clock recovery/removal timing checks
must be done, as was asked in the start of the thread.

Remove the "posedge reset" from the sensitivity list, and it's a 
synchronous reset, with just normal setup/hold checks.   Synchronous 
are preferred and much more efficient in today's FPGAs.

Regards,

Mark 
   

On 10/23/2015 4:32 PM, Mark Curry wrote:
> In article <n0dvqo$m3p$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 10/23/2015 1:25 PM, jt_eaton wrote:
>>>>
>>>> Apologies but can I ask if this reply is from an ASIC mindset or is it
>>>> spam. Almost every statement doesn't make any sense whatsoever for
>>> FPGAs.
>>>>
>>>> Zak
>>>> ---------------------------------------
>>>> Posted through http://www.FPGARelated.com
>>>
>>> Valid question. It is from an ASIC mindset and has nothing to do with
>>> FPGA's. This entire thread has nothing to do with FPGA's
>>>
>>> Xilinx recomends that you never use an asynchonous reset in your logic.
>>> Its expensive ( sync reset flops takes 3 LUT's while an async one takes
>>> 4). It's slow ( Xilinx has a app note on rtl programming styles that says
>>> async resets can slow you down by a factor as high as 4. All those really
>>> fast multiplier macros use sync reset so if you ask for async then it must
>>> build them out of LUTs. It is also redundent. Your programming input is
>>> asynchronous and leaves every flop in the design in a known state. That is
>>> your power on asynchronous reset system. Adding a second one in logic
>>> makes no sense at all.
>>>
>>> I haven't read Altera docs but I suspect the same will apply
>>
>> I think you are a bit confused about the async reset.  Every FF in the
>> fabric is connected to an async reset signal that spans the entire chip.
>>   This is called (oddly enough) the Global Set/Reset or GSR in Xilinx
>> devices.  It is always asserted during configuration and can also be
>> driven by a user signal.
>>
>> An async reset can be critical to restore a defined state to the design
>> in the event the clock stops.  This signal is usually pretty slow and
>> may be hard to get to meet system synchronous timing requirements.  The
>> trick to proper use is to make sure there are other controls that
>> maintain a reset state for the design when the async signal is removed.
>>   These synchronous resets can apply to local sections of logic which
>> must start up synchronized while usually the entire design does not.
>> Then timing is more easily met.
>
> I've got trouble thinking how the GSR could be used for any useful thing
> by the designer.  The trouble with the GSR is that it's removal edge
> is slow, and asynchronous to everything.  So flops may reset fine with
> this signal, but coming out of reset, the state's still unknown.  The
> parts of a design that can make reliable use of this, is a rare exception,
> not the rule, IMHO.
>
> And back to the OP - I believe he was NOT referring to this GSR at all, but
> to the normal Async reset on a FF i.e. (verilog)
>
> always @( posedge clk or posedge reset )
>    if( reset )
>       q <= 0;
>    else
>       q <= d;
>
> This is the async flip flop, where clock recovery/removal timing checks
> must be done, as was asked in the start of the thread.
>
> Remove the "posedge reset" from the sensitivity list, and it's a
> synchronous reset, with just normal setup/hold checks.   Synchronous
> are preferred and much more efficient in today's FPGAs.

If the OP is talking about using the async reset of individual FFs, I 
can offer no advise.  I have never encountered a situation where I 
needed that.

-- 

Rick

All of us learn our craft starting off with small designs that we take
through each design stage all the way to a working product. But real life
is different. Real designs are far to large for any single engineer to do
the entire thing so we use several engineers with each one assigned to do
a different task.

Those tasks are:


Component Designers who create the leaf cell designs


Architects who select the leaf cells, configure and interconnect them


Board designers who design the printed circuit assembly




When you work by yourself it is tempting to look ahead and try to take
care of issues that will arise in the next phase of the design process. DO
NOT DO THIS. While I am sure that you are a competent engineer and that
the engineer who was assigned that task will be happy that you decided to
butt in and do his job for him it you should rmember that some people are
sensitive about this.

If its not your job then you don't get to make those decisions.


 

>I've got trouble thinking how the GSR could be used for any useful >thing
by the designer.  The trouble with the GSR is that it's 
>removal edge is slow, and asynchronous to everything.  So flops may
>reset fine with this signal, but coming out of reset, the state's
>still unknown.  The parts of a design that can make reliable use of
>this, is a rare exception,not the rule, IMHO.
>

The way it works is that you need to do an asynchronous assert and a
synchronous deassert. Your assert resets all user flops but sets all the
flops in your synchronous reset system into their assert state. Your user
flop will clear to 0 and it will have a 0 on its D input from the
synchronous reset system.

Nothing will happen when you deassert your asynchronous reset because you
will still have the synchronous one active. That one will deassert over
time and will be synchronous to the flops clock.

You design it by finding out the longest path from your asynchronous input
pin to every flop in your chip. Double that time ( we like to sandbag our
designs) and  divide it by your reference clock period. That gives you the
number of clock cycles that you have to maintain the synchronous reset
after you deassert your asynchronus reset. That takes care of your slow
removal because each flop will still be controlled by the synchronous
reset.




>
>always @( posedge clk or posedge reset )
>  if( reset )
>     q <= 0;
>  else 
>     q <= d;
>

You see this alot in designs. Component designers are obsessed with making
sure that their designs get reset so they build every flop with an
asynchronous reset port and connnect them all directly to the boards power
on reset signal.

Theres just one little problem. Component designers do not own the reset
system design, It now belongs to other engineers and you are  doing their
job for them. They are not happy. With a top down design they tell you
what to do, you do not get to tell them what to do.


What should you do instead.


always @( posedge clk or negedge reset_n )

  if      (! reset_n )   q <= 0;
  else if (  reset   )   q <= 0;
  else                   q <= d;

If you do this then the architects are no longer locked into your reset
design. If they want it then they can tie the reset inactive and they have
your design. They could also tie the reset_n inactive and have a
completely synchronous design or they could as I have suggested use both.
If you use both then the design is dft clean and you are not messing up
your timing the way the your design does.


So who does own the reset system design?

The board designer


The board designer is responsible for creating the board's power on reset
signal. They look at all the power supplies and debounce the reset button
to create a single active low open drain signal. They then route that
signal to every chip on the board. If a chip doesn't have a reset input
then they route it through the chip controlling it. They stitch together
the products reset system from the reset systems of all the chips on the
board.

Finally they add the ESD filtering and the design is complete. The board
designer has the complete engineering responsibility for the products
power on reset system.

Now heres where the problem comes in. Component designers are obsessed
with making sure that each flop is reset while the reset button is
depressed. But we surveyed every board designer who had ever done that job
and none of them were worried about that at all.

Sure it gets screwed up every now and then but our digital tools are good
enough that you will always find the problem and fix it before release.
Its not a problem. What is a problem that keeps the board designers up at
nite is ESD. You can't even begin to test for that until you have real
silicon, PCBs and case parts. By the time you get those you are well past
the point where you should be making changes to your design.


So your boss is obsessed with making sure that the product does not reset
while the reset button is NOT pressed and you are designing to the exact
opposite requirement. 

Thats why I get so annoyed with engineers who insist that a complete
asynchronous reset system is the only way to go. For one thing there are
other equivaltent options that they have not considered and second of all
they do not get to decide how to do it. Its not their job.


John Eaton









 













  
























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

>All of us learn our craft starting off with small designs that we take
>through each design stage all the way to a working product. But real
life
>is different. Real designs are far to large for any single engineer to
do
>the entire thing so we use several engineers with each one assigned to
do
>a different task.
>
>Those tasks are:
>
>
>Component Designers who create the leaf cell designs
>
>
>Architects who select the leaf cells, configure and interconnect them
>
>
>Board designers who design the printed circuit assembly
>
>
>
>
>When you work by yourself it is tempting to look ahead and try to take
>care of issues that will arise in the next phase of the design process.
DO
>NOT DO THIS. While I am sure that you are a competent engineer and that
>the engineer who was assigned that task will be happy that you decided
to
>butt in and do his job for him it you should rmember that some people
are
>sensitive about this.
>
>If its not your job then you don't get to make those decisions.
>
>
> 
>
>>I've got trouble thinking how the GSR could be used for any useful
>thing
>by the designer.  The trouble with the GSR is that it's 
>>removal edge is slow, and asynchronous to everything.  So flops may
>>reset fine with this signal, but coming out of reset, the state's
>>still unknown.  The parts of a design that can make reliable use of

>Thats why I get so annoyed with engineers who insist that a complete
>asynchronous reset system is the only way to go. For one thing there are
>other equivaltent options that they have not considered and second of
all
>they do not get to decide how to do it. Its not their job.
>
>
>John Eaton

Inside fpga there might be several clock domains and the fpga engineer is
responsible to synchronise reset to all domains. So it is internal
responsibilty and even if it is one clock domain it is much easier to do
that sort of work inside fpga.

You certainly need reset otherwise you will have power up variation or
variation per reset release if not applied properly. But some registers
may not need it. It is certainly vital for state machines and control
registers but for data paths if data value is irrelevant for any control
logic.

One thing I find it misunderstood is that reset whether applied through D
input(mis-named synchronous) or through async port must be viewed as
asynchronous from its origin if it can arrive independent of clock.



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

>>I've got trouble thinking how the GSR could be used for any useful
>thing
>by the designer.  The trouble with the GSR is that it's 
>>removal edge is slow, and asynchronous to everything.  So flops may
>>reset fine with this signal, but coming out of reset, the state's
>>still unknown.  The parts of a design that can make reliable use of
>>this, is a rare exception,not the rule, IMHO.
>>
>

True. Altera (possibly others) do not guarantee powerup state. GSR can
work in principle but vendors cannot guarantee how first edge of user
clock is going to be relative to GSR release. So internally generated
reset wouldn't work either as it will depend on powerup states. They
always advise of having external reliable reset source.

Kaz 


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

On Friday, October 9, 2015 at 4:25:25 PM UTC-4, zak wrote:
> Hi All,
> 
> In Altera devices (at least) it is recommended that reset be applied to
> the async port of flips. It is also recommended that such reset should be
> pre-synchronised before wiring it to these async ports. This saves
> resource and helps recovery/removal timing. 
> 
> What exactly is recovery/removal. I know it is defined in terms of reset
> release and that reset should not be de-asserted close to clock edge. Fair
> enough but is this independent of D input? I mean if D input is stable (or
> passes setup/hold) does it matter still that reset release near clock edge
> will be problem on its own. From timieQuest it looks certainly that it
> does matter but why? How is reset actually applied inside the flip?
> 
> Any help appreciated.
> 
> Zak
>  
> ---------------------------------------
> Posted through http://www.FPGARelated.com

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

>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