recovery/removal timing

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

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

snipped-for-privacy@gmail.com

--------------------------------------- Posted through

if

get

and

the

that

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

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

from

clock

at

in

of

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

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

FPGAs.

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

a

IS

involving

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

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

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

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

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

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.

by the designer. The trouble with the GSR is that it's

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.

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

life

do

do

DO

to

are

all

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

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

r r e

One of fundamental aspects of implementing an asynchronous reset, which is often overlooked, is that the reset must be DEASSERTED with proper timing m argin with respect to the clock. This is why Altera, and many other vendor s recommend synching the reset to the relevant clock domain. Recovery is d efined as the setup time of the deassertion of the reset with respect to th e clock. Removal is defined as the hold time of the deassertion of the res et 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

is

timing

Recovery is

to

the

documenation

job

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