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

[weetabixharry]

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:

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?

 

[FvM]

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.

 

[weetabixharry]

Asynchronous reset is asserted at start-up and having relative long duration.

These are two major assumptions that could be wrong and (as far as I understand) the static timing analysis has no awareness of.

I don't understand which real world problem you are discussing here.

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.

 

[FvM]

These are two major assumptions that could be wrong

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.

That button could be pushed at any time, causing potential timing violations in the second flip-flop.

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.

 

[weetabixharry]

Pushing at any time is no problem, again only the reset release matters.

As I wrote in my first post, the problem is that this will cause metastability in the 2nd flip-flop.

 

[KlausST]

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

 

[FvM]

As I wrote in my first post, the problem is that this will cause metastability in the 2nd flip-flop.

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.

 

[weetabixharry]

"safe" is a rather general phrase.

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.

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

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.

 

[FvM]

Referring to the question in your first post

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.

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.

 

[weetabixharry]

Metastable state will surely end far before reset release.

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.

The usual solution is to reset all design FFs by the asynchronous reset, not only a few selected.

Clearly our experience is a little different here. Certainly in ASIC designs I totally agree, but in FPGA designs I rarely see this.

Dedicated partial resets must be synchronous, otherwise they are not safe. Timing analysis won't help you in this regard.

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.

 

[KlausST]

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

 

[FvM]

Recent FPGA families have logic-array-block-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 Aug 13, 2022 ---

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

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.

 

[KlausST]

Hi,

Unfortunately a global reset doesn't necessarily guarantee safe reset release.

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

 

[weetabixharry]

Recent FPGA families have logic-array-block-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.

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 Aug 13, 2022 ---

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

Yes, exactly.

 

[weetabixharry]

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:

The asynchronous-assert of CLR on FF1 can (as you say) cause data to arrive at FF1 at the “wrong” time and cause metastability of FF2. Also, (as you say) Vivado does not warn us by throwing a timing violation. Finally, (as you say) many texts do not discuss this or indirectly tell us not to worry about it. I’m not sure I have the answer but here are some thoughts.

1. It is simply not possible for Vivado STA to analyze the asynchronous-assert of a reset. -because, the reset is asserted without reference to any clock in the design. Further, we have placed timing exceptions (set_false_path) on the reset input to the FPGA, which prevents STA.
2. …but the metastability of FF2 is a problem, right? Well, during a reset, the FPGA engineer should ensure that all important operations (eg. launching the missile) are placed on hold until the reset is de-asserted. So, if the metastability of FF2 can propagate downstream and cause problems then maybe other flip-flops that follow FF2 should be reset too.
3. I’m still uncomfortable. Ok, me too. Maybe we just need to ensure that the reset is asserted long enough for metastability to settle out – and then de-assert the reset.
4. You can avoid the problem altogether by using a reset that is synchronous assert and synchronous de-assert.