recovery/removal timing

[zak]

Hi All,

In Altera devices (at least) it is recommended that reset be applied t
the async port of flips. It is also recommended that such reset should b
pre-synchronised before wiring it to these async ports. This save
resource and helps recovery/removal timing.

What exactly is recovery/removal. I know it is defined in terms of rese
release and that reset should not be de-asserted close to clock edge. Fai
enough but is this independent of D input? I mean if D input is stable (o
passes setup/hold) does it matter still that reset release near clock edg
will be problem on its own. From timieQuest it looks certainly that i
does matter but why? How is reset actually applied inside the flip?

Any help appreciated.

Zak

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

 

[Mark Curry]

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

 

[zak]

Thanks Mark. That is a good answer

Zak


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

 

[jt_eaton]

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 a
timing requirements from the silicon vendors data sheet and it will tel
what the reset_deassert to clock recovery time is. It should also note i
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 ge
some really weird behavior from muxed based logic.



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

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


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


John Eaton

z3qmtr45@gmail.com




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

 

[zak]

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 not
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 ca
get
some really weird behavior from muxed based logic.



I like to do both an asynchronous and synchronous reset on every flo
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 acros
the
die can be multiple clock cycles.

If you syncronize the asynchronous reset then you also create a mes
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 i
spam. Almost every statement doesn't make any sense whatsoever for FPGAs.

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

 

[Jon Elson]

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

 

[zak]

The real problem is if the reset is distributed on general switch fabri

while the clock is on a low-skew clock net, some FFs could be release
from

reset on one clock, others could be released on the next clock, if th
clock

is fast. Think of some state machine register that is supposed to star
at

zero, and start going through states after reset ends. It could end u
in
an odd state if some FFs are still being reset while others have got ou
of

reset.

Jon

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

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

 

[Jon Elson]

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

 

[Mark Curry]

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

 

[Mark Curry]

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

 

[Mark Curry]

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

 

[jt_eaton]

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

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

Valid question. It is from an ASIC mindset and has nothing to do wit
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 take
4). It's slow ( Xilinx has a app note on rtl programming styles that say
async resets can slow you down by a factor as high as 4. All those reall
fast multiplier macros use sync reset so if you ask for async then it mus
build them out of LUTs. It is also redundent. Your programming input i
asynchronous and leaves every flop in the design in a known state. That i
your power on asynchronous reset system. Adding a second one in logi
makes no sense at all.

I haven't read Altera docs but I suspect the same will apply


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

 

[jt_eaton]

zak wrote:


I just found a condition where you could have an un-synchronized input o
a

product that has been in manufacture for a decade. Normally, this signa
IS

synchronized on the FPGA, but there was a particular configuratio
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 wil
not see many resets during its lifetime. I've done embedded systems tha
are always on and I suspect that few of them would ever see more than
few dozen resets before they are trashed. Designers worry about resets al
the time but if you screw it up then it is very unlikely that the custome
will trigger a failure and extremely unlikely that they will do so twic
in a row.

Turning it back off and on again can hide a lot of mistakes


John Eaton


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

 

[rickman]

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

 

[rickman]

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

 

[jt_eaton]

All of us learn our craft starting off with small designs that we tak
through each design stage all the way to a working product. But real lif
is different. Real designs are far to large for any single engineer to d
the entire thing so we use several engineers with each one assigned to d
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 tak
care of issues that will arise in the next phase of the design process. D
NOT DO THIS. While I am sure that you are a competent engineer and tha
the engineer who was assigned that task will be happy that you decided t
butt in and do his job for him it you should rmember that some people ar
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 >thin
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
synchronous deassert. Your assert resets all user flops but sets all th
flops in your synchronous reset system into their assert state. Your use
flop will clear to 0 and it will have a 0 on its D input from th
synchronous reset system.

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

You design it by finding out the longest path from your asynchronous inpu
pin to every flop in your chip. Double that time ( we like to sandbag ou
designs) and divide it by your reference clock period. That gives you th
number of clock cycles that you have to maintain the synchronous rese
after you deassert your asynchronus reset. That takes care of your slo
removal because each flop will still be controlled by the synchronou
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 makin
sure that their designs get reset so they build every flop with a
asynchronous reset port and connnect them all directly to the boards powe
on reset signal.

Theres just one little problem. Component designers do not own the rese
system design, It now belongs to other engineers and you are doing thei
job for them. They are not happy. With a top down design they tell yo
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 rese
design. If they want it then they can tie the reset inactive and they hav
your design. They could also tie the reset_n inactive and have
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 u
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 rese
signal. They look at all the power supplies and debounce the reset butto
to create a single active low open drain signal. They then route tha
signal to every chip on the board. If a chip doesn't have a reset inpu
then they route it through the chip controlling it. They stitch togethe
the products reset system from the reset systems of all the chips on th
board.

Finally they add the ESD filtering and the design is complete. The boar
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

 

[kaz]

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 rea
life
is different. Real designs are far to large for any single engineer t
do
the entire thing so we use several engineers with each one assigned t
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 decide
to
butt in and do his job for him it you should rmember that some peopl
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 usefu
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 o
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 i
responsible to synchronise reset to all domains. So it is interna
responsibilty and even if it is one clock domain it is much easier to d
that sort of work inside fpga.

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

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




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

 

[kaz]

I've got trouble thinking how the GSR could be used for any usefu
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 ca
work in principle but vendors cannot guarantee how first edge of use
clock is going to be relative to GSR release. So internally generate
reset wouldn't work either as it will depend on powerup states. The
always advise of having external reliable reset source.

Kaz


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

 

[psustew]

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

 

[zak]

One of fundamental aspects of implementing an asynchronous reset, whic
is
often overlooked, is that the reset must be DEASSERTED with prope
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 respec
to
the clock. Removal is defined as the hold time of the deassertion o
the
reset with respect to the clock. This is defined in the Alter
documenation
-- I think it's in the Quartus handbook. Timequest does an excellen
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 o
recovery/removal but rather the relation of reset deassertion to D input


Normally with setup/hold if D is not changing then timing violation doe
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 ca
share your views with this regard.

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