recovery/removal timing

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

In article <sdudnT94KJgxv4XLnZ2dnUU7-KOdnZ2d@giganews.com>,
zak <93737@FPGARelated> 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?

Without any specific knowledge of the actual circuitry of a FF - ask 
yourself this - at the inactive edge of reset, let's say the D pin is
a one - the reset is causing a 0 at the FF output.  If the clock 
recovery timing is not met (basically a setup/hold check with respect
to the async reset pin) - what value would you expect at Q?  An 
unknown value is the only reasonable assumption.

Now ask yourself if D is a zero (matching the reset state).  Is it now
safe to assume the the recovery check doesn't matter?  I wouldn't
bet on it.  I can see hand wavy arguments both ways.  

Now someone with more intimate details of the FF internals
may argue one way or another - but me as a logic designer?  No way I'm
depending on that.   

Do as Altera advises and properly synchronize that inactive edge 
of reset.  Make sure your timing tools are checking that path.
Reset/Initialization problems can be quite the devil to find and 
debug.

Regards,

Mark

Thanks Mark. That is a good answer

Zak


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

>In article <sdudnT94KJgxv4XLnZ2dnUU7-KOdnZ2d@giganews.com>,
>zak <93737@FPGARelated> wrote:
>>Hi All,
>>

>Now ask yourself if D is a zero (matching the reset state).  Is it now
>safe to assume the the recovery check doesn't matter?  I wouldn't
>bet on it.  I can see hand wavy arguments both ways.  
>
>Now someone with more intimate details of the FF internals
>may argue one way or another - but me as a logic designer?  No way I'm
>depending on that.   
>
>Do as Altera advises and properly synchronize that inactive edge 
>of reset.  Make sure your timing tools are checking that path.
>Reset/Initialization problems can be quite the devil to find and 
>debug.
>
>Regards,
>
>Mark

You shouldn't have to hand wave or guess, you should be able to look at
timing requirements from the silicon vendors data sheet and it will tell
what the reset_deassert to clock recovery time is. It should also note if
that constraint is only valid when D=1 or not.

It's hard to imagine any flop going to 1 in that situation but you can get
some really weird behavior from muxed based logic.



I like to do both an asynchronous and synchronous reset on every flop and
connect the asynchronous reset directly to the input pad so that both
edges are asynchronous. You delay the synchronous reset enough clocks so
that you never see a 1 on the D input until after the recovery time has
passed. This is great for large chips where the transport delay across the
die can be multiple clock cycles.

If you syncronize the asynchronous reset then you also create a mess that
the dft engineer has to clean up. 


You will also mess up the timing for any signal that passes between soft
reset domains.


John Eaton

z3qmtr45@gmail.com




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

>>In article <sdudnT94KJgxv4XLnZ2dnUU7-KOdnZ2d@giganews.com>,
>>zak <93737@FPGARelated> wrote:
>>>Hi All,
>>>
>
>>Now ask yourself if D is a zero (matching the reset state).  Is it now
>>safe to assume the the recovery check doesn't matter?  I wouldn't
>>bet on it.  I can see hand wavy arguments both ways.  
>>
>>Now someone with more intimate details of the FF internals
>>may argue one way or another - but me as a logic designer?  No way I'm
>>depending on that.   
>>
>>Do as Altera advises and properly synchronize that inactive edge 
>>of reset.  Make sure your timing tools are checking that path.
>>Reset/Initialization problems can be quite the devil to find and 
>>debug.
>>
>>Regards,
>>
>>Mark
>
>You shouldn't have to hand wave or guess, you should be able to look at
>timing requirements from the silicon vendors data sheet and it will tell
>what the reset_deassert to clock recovery time is. It should also note
if
>that constraint is only valid when D=1 or not.
>
>It's hard to imagine any flop going to 1 in that situation but you can
get
>some really weird behavior from muxed based logic.
>
>
>
>I like to do both an asynchronous and synchronous reset on every flop
and
>connect the asynchronous reset directly to the input pad so that both
>edges are asynchronous. You delay the synchronous reset enough clocks so
>that you never see a 1 on the D input until after the recovery time has
>passed. This is great for large chips where the transport delay across
the
>die can be multiple clock cycles.
>
>If you syncronize the asynchronous reset then you also create a mess
that
>the dft engineer has to clean up. 
>
>
>You will also mess up the timing for any signal that passes between soft
>reset domains.
>
>
>John Eaton
>
>z3qmtr45@gmail.com
>
>
>
>
>---------------------------------------
>Posted through http://www.FPGARelated.com

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

jt_eaton wrote:


> You shouldn't have to hand wave or guess, you should be able to look at
> timing requirements from the silicon vendors data sheet and it will tell
> what the reset_deassert to clock recovery time is. It should also note if
> that constraint is only valid when D=1 or not.
> 
> It's hard to imagine any flop going to 1 in that situation but you can get
> some really weird behavior from muxed based logic.
The real problem is if the reset is distributed on general switch fabric 
while the clock is on a low-skew clock net, some FFs could be released from 
reset on one clock, others could be released on the next clock, if the clock 
is fast.  Think of some state machine register that is supposed to start at 
zero, and start going through states after reset ends.  It could end up in 
an odd state if some FFs are still being reset while others have got out of 
reset.

Jon

>The real problem is if the reset is distributed on general switch fabric

>while the clock is on a low-skew clock net, some FFs could be released
from
>
>reset on one clock, others could be released on the next clock, if the
clock
>
>is fast.  Think of some state machine register that is supposed to start
at
>
>zero, and start going through states after reset ends.  It could end up
in 
>an odd state if some FFs are still being reset while others have got out
of
>
>reset.
>
>Jon

True but the tool takes care of that and tells you if it passed
recovery/removal at every register based on clock period check. In case it
doesn't you can then assist by reducing reset fanout e.g. cascading
stages.

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

zak wrote:


> True but the tool takes care of that and tells you if it passed
> recovery/removal at every register based on clock period check. In case it
> doesn't you can then assist by reducing reset fanout e.g. cascading
> stages.
If the reset signal is produced on-chip by a FF clocked off the same clock 
as the system that is getting the rest, then you are right, the tools have 
all the info they need to make sure this is right.  It would be insane to 
hace an externally-generated reset without reclocking it in the FPGA off the 
same clock, but you certainly could do this by mistake.

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

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


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

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


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