[SOLVED] Why is a reset with asynchronous assert safe?

Status
Not open for further replies.
W

weetabixharry

Full Member level 4
Joined
Oct 9, 2013
Messages
232
Helped
69
Reputation
142
Reaction score
73
Trophy points
1,318
Location
Sweden
Activity points
3,463
As far as I understand, a reset with asynchronous assert, synchronous de-assert is considered absolutely safe. I understand that this prevents metastability at the output of a flip-flop using that reset because recovery and removal requirements are guaranteed to be met.

What I don't understand is why this is safe when I connect the output of that flip-flop to any other flip-flop that isn't using that same reset.

I have drawn an example using Xilinx FPGA flip-flop primitives FDCE and FDRE. However, my question applies to any FPGA/ASIC technology:



(Note: "Async Reset" has asynchronous assert, synchronous de-assert).

In this case, "Async Reset" can cause the input to the 2nd flip-flop to transition from '1' to '0' within the setup-hold aperture. I would have thought this would be a timing violation, causing potential metastability.

However, static timing analysis (using the Xilinx toolchain) produces no errors. I have tried to be careful to ensure none of my timing constraints are interfering. I targeted my constraints at the specific pins of the specific flip-flops in the reset synchronizer:

Code: 
set_false_path -from [get_ports I_Rst] -to [get_pins Rst_Next_reg/D]
set_false_path -from [get_ports I_Rst] -to [get_pins Rst_reg/D]

These constraints apply to this (standard) reset synchronizer circuit (see FDPE):



Are my constraints somehow still too general? (I know there is a separate discussion about constraining max delay and forcing nearby placement of the two flip-flops, but I don't think that is relevant to my question here).

I have searched and searched and can't find an explanation. Could anyone help me to understand?
 

Solution
W
I would like to finally close this thread by sharing a superb response I received on the Xilinx forums from a user named "markg@prosensing": link.


I would encourage anyone interested to read and re-read his whole response because it is incredibly comprehensive. He finishes with this concise summary, which I think really sums up all the key details:

Sort by date Sort by votes
Seriously I don't understand which real world problem you are discussing here. Asynchronous reset is asserted at start-up and having relative long duration. Only deassertion matters in timing analysis. It is covered by regular setup and hold checks and doesn't require specific constraints. The essential requirement is to have separate reset synchronizers for each clock domain.
 

Upvote 0 Downvote
FvM said:
Asynchronous reset is asserted at start-up and having relative long duration.
Click to expand...
These are two major assumptions that could be wrong and (as far as I understand) the static timing analysis has no awareness of.

FvM said:
I don't understand which real world problem you are discussing here.
Click to expand...

For example, what if my external reset is driven by a push-button (with appropriate debouncing)? That button could be pushed at any time, causing potential timing violations in the second flip-flop.
 
Last edited:

Upvote 0 Downvote
weetabixharry said:
These are two major assumptions that could be wrong
Click to expand...
Not in any real design I ever saw. If the system involves a manual reset, you'll take care that the reset causes a safe state, e.g. all outputs off.
weetabixharry said:
That button could be pushed at any time, causing potential timing violations in the second flip-flop.
Click to expand...
Pushing at any time is no problem, again only the reset release matters. You'll probably take measures to prevent a bouncing reset. Usually it's achieved by external hardware design, e.g. using a reset IC, but in case of doubt, the reset release may be delayed by a counter.
 

Upvote 0 Downvote
Hi,

"safe" is a rather general phrase.

It could be to "safely" accept the RESET.
or just to prevent metastability (as you wrote)
... or some other "functions"

Could you draw a timing diagram showing your concern, so we can focus on the same problem as you do.

Klaus
 

Upvote 0 Downvote
weetabixharry said:
As I wrote in my first post, the problem is that this will cause metastability in the 2nd flip-flop.
Click to expand...
There are two answers:
- Metastable state will surely end far before reset release.
- The state of the second FF at the time of reset release is undefined, also without considering metastability. The usual solution is to reset all design FFs by the asynchronous reset, not only a few selected. Dedicated partial resets must be synchronous, otherwise they are not safe. Timing analysis won't help you in this regard.
 
Upvote 0 Downvote
KlausST said:
"safe" is a rather general phrase.
Click to expand...
Yes, sorry, I wasn't 100% sure if metastability is my only concern... but maybe it is best if we start by just discussing metastability.

KlausST said:
Could you draw a timing diagram showing your concern, so we can focus on the same problem as you do.
Click to expand...
I have attempted to draw a timing diagram:

  • Assume Data In = '1' constantly.
  • Async reset is asserted very close to the rising edge of the clock.
  • Therefore "Data Mid" (output of 1st flip-flop, input of 2nd flip-flop) transitions from '1' to '0' very close to the rising edge of the clock. (WARNING!)
  • Therefore Data Out becomes metastable.
 

Upvote 0 Downvote
Referring to the question in your first post
weetabixharry said:
What I don't understand is why this is safe when I connect the output of that flip-flop to any other flip-flop that isn't using that same reset.
Click to expand...
It is not safe, if Data Out has any impact on the design behaviour, in other words affect design ouput or internal states still persisting after reset release. Need to assure that design output and registers are also reset.
 
Upvote 0 Downvote
FvM said:
Metastable state will surely end far before reset release.
Click to expand...
Yes, but this would only be relevant if both flip-flops were in the same reset domain, which they are not. The second flip-flop is not reset, so can enter a metastable state (see my timing diagram above). If the first flip-flop had a synchronous reset, then this metastability would be impossible.

FvM said:
The usual solution is to reset all design FFs by the asynchronous reset, not only a few selected.
Click to expand...
Clearly our experience is a little different here. Certainly in ASIC designs I totally agree, but in FPGA designs I rarely see this.

FvM said:
Dedicated partial resets must be synchronous, otherwise they are not safe. Timing analysis won't help you in this regard.
Click to expand...

Yes - this is exactly what I was worried about! This "timing violation" is not detected by static timing analysis, simulation, or any other tool that I am aware of. So, how on earth do I make sure that my colleagues are doing this correctly? I guess manual code review is the only option.
 

Upvote 0 Downvote
Hi,

I agree with the above... but ...
in your timing diagram... the metastability is more than one clock period long.
But indeed metastability ends after the second rising clock edge with a clean LOW output.

So, the higher the clock frequency the more likely is metastability. But on the other side the higher the clock frequency that shorter is the period time for this metastability. It automatically corrects the metastability to a stable state at the next rising clock edge.

Isn´t there a global RST in your FPGA that sets/clears all FFs inside?

Klaus
 

Upvote 0 Downvote
Recent FPGA families have logic-array-b-wide asynchronous clear signals, it usually costs no extra logic or routing resources if you connect all FFs of a clock domain to the respective synchronized reset instead of only a few. It's just a matter of coding style. Code review should definitely care for it.
--- Updated ---

KlausST said:
Isn´t there a global RST in your FPGA that sets/clears all FFs inside?
Click to expand...
Unfortunately a global reset doesn't necessarily guarantee safe reset release. A direct external clock can be expected to run during reset release, potentially causing timing violations and undefined states. If we assume that "async reset" is a synchronized copy of the global reset input, we get safe behaviour for the discussed structure if all connected logic transitions to defined state during reset assertion.
 
Last edited:

Upvote 0 Downvote
Hi,
FvM said:
Unfortunately a global reset doesn't necessarily guarantee safe reset release.
Click to expand...
I agree.
But in the given example, if all FFs are reset then also the 2nd FF is reset and one gets clean states without the metastability problem for the 2nd FF output.

Klaus
 
Upvote 0 Downvote
FvM said:
Recent FPGA families have logic-array-b-wide asynchronous clear signals, it usually costs no extra logic or routing resources if you connect all FFs of a clock domain to the respective synchronized reset instead of only a few.
Click to expand...

One important exception I know is DSP slices. In Xilinx FPGAs, the ~6-series DSP48A1 did allow async resets, but the documentation warned about worse timing performance. The ~7-series DSP48E1 and ~Ultrascale DSP48E2 only support synchronous resets. And in some (or maybe all) of those cases, only resetting to '0' is supported, which may be an invalid/dangerous value in some use cases. (So better use a valid flag and not rely on reset values).

For general-purpose FFs, I find it difficult to get really up-to-date and reliable information about this. I was always taught to only reset registers that truly hold state (e.g. valid flags, FIFO read/write addresses, etc). Everything else (e.g. the data signals that are accompanied by valid flags) have no reason to be reset, so should not be reset.

This reduces fan-out of reset signals (which reduces the number of duplicated registers needed to reach that fan-out), reduces the routing resources consumed by reset signals (which helps with congestion) and in some cases reduces combinatorial logic (depending on how the reset is implemented by the synthesis tool).

However, I don't know if the impact of these things may be much smaller in modern FPGAs. I think it is a difficult thing to quantify.
--- Updated ---

KlausST said:
Hi,

I agree.
But in the given example, if all FFs are reset then also the 2nd FF is reset and one gets clean states without the metastability problem for the 2nd FF output.

Klaus
Click to expand...
Yes, exactly.
 

Upvote 0 Downvote
I would like to finally close this thread by sharing a superb response I received on the Xilinx forums from a user named "markg@prosensing": link.


I would encourage anyone interested to read and re-read his whole response because it is incredibly comprehensive. He finishes with this concise summary, which I think really sums up all the key details:

 
Upvote 0 Downvote
Solution
Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…