2
\$\begingroup\$

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:

enter image description here

(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): enter image description here

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?

\$\endgroup\$
0

2 Answers 2

4
\$\begingroup\$

The first circuit that you have shown is a case of RDC (Reset Domain Crossing) as the launching flop and capturing flops are in two different reset domains.

As you said, if you assert the async reset in the first flop, it's well possible that D transits to '0' near to the close edge in the second flop, within setup-hold window, driving it to metastability. This is not a safe circuit at all. This has to be taken care by adding proper RDC structures in between such timing paths.

ASIC tool set includes RDC tool to check scenarios like this and do RDC sign-off. I am not sure whether Xilinx tool set has RDC checks, I have never tried. Probably not so evolved like in ASIC tool set, because designers like to use synchronous resets globally in the FPGA designs.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Thank you for the excellent link. Just discovering the name "Reset Domain Crossing" is a huge help, as my web searches now take me to plenty of relevant information. \$\endgroup\$
    – Harry
    Aug 13, 2022 at 13:21
  • 1
    \$\begingroup\$ Welcome. It's often an overlooked topic :) \$\endgroup\$
    – Mitu Raj
    Aug 13, 2022 at 15:01
0
\$\begingroup\$

There is an implied assumption here: the async reset is combined with inputs that don't cause the logic to immediately leave the reset state.

So for example, a device that appears as an SPI target will not see its Chip Select signal asserted in the first cycle, a device that is memory-mapped to a bus will not be addressed on the first cycle, and so on.

This is indeed a hole in static timing analysis, but one that is commonly ignored, because the majority of users would just disable that check as they control enough of the other logic to make sure that the transition out of reset will be safe, so the errors would just be a nuisance.

Reset signal deassertion needn't be synchronous if the first inputs the device sees will not alter its state -- e.g. a state machine would be initialized to an idle state while the reset signal is asserted, and then left in the idle state afterwards by feeding it inputs that take it through an idle to idle transition.

This also nicely solves the case where the device has multiple clock domains, but only a single reset signal.

Typically, the device controlling the asynchronous reset signal will either know that it needs to wait for a few cycles, or this happens automatically because of sequential execution -- if you set the GPIO to deassert the reset signal and then start the SPI transfer, enough time will have passed between those two instructions already, and for a memory-mapped device, two nop instructions will help.

\$\endgroup\$
2
  • \$\begingroup\$ These feel like potentially very dangerous assumptions to me and I much prefer Mitu Raj's statement that "this is not a safe circuit at all". So, on a case-by-case basis, we need to make absolutely sure we use it in a way that makes it safe. In many cases, that may be straightforward... but the idea of not even synchronizing any of your resets seems crazy to me! Relying on what the next several inputs may or may not be after reset just sounds like a recipe for disaster. \$\endgroup\$
    – Harry
    Aug 13, 2022 at 20:38
  • \$\begingroup\$ You can synchronize the resets, which makes it a bit more resistant to protocol violations directly after a reset, but that doesn't gain you much compared to an explicit mechanism to detect the violation and work around it -- for an SPI transfer I'd rather ignore the whole transaction than cleanly start on the second rising edge of the clock, for example, and that puts the client back into "wait a few cycles after deasserting reset" territory anyway (and in a synchronous protocol I'd just provide a "ready" signal to show when my device has fully left reset). \$\endgroup\$ Aug 14, 2022 at 22:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.