Reset domain crossing for designs with set-reset flops

Reset domain crossing (RDC) is essentially a structure where a signal crosses over from one reset domain to another reset domain. There are cases where the reset domain definition is not simple and straight forward. One such case is the handling of “Set-Reset” flops, where there are more than one asynchronous set/reset controlling a flop. Scenarios involving data transfer between two such flops is also a challenge. Another concern is if the output of such flops is used as a reset further down the design. This paper looks at these problems structurally and proposes a strategy to resolve them.

The problem with reset domain crossings and set-reset flops

A reset domain crossing (RDC) is a structure in digital design where a signal generated by a flip-flop using an asynchronous reset (or set) is captured by another flop using another asynchronous reset (or set). Every reset signal in a digital design, which can assert asynchronously and independently of any clock, is called an asynchronous reset. All flops using the same asynchronous reset in a digital design corresponds to a reset domain. If a signal generated by a flop in one reset domain is captured by a flop in another reset domain, such structures are called reset domain crossings.

A set-reset flop is a flip-flop with two asynchronous set/reset. With more than one reset on a single flop, the problem become more complex. Although designers are taught to avoid such structures, various design scenarios can still end-up with RTL code that can get synthesized as a set/reset flop. Often in large design teams, engineers or teams responsible for RDC cleanup of the design are different from the RTL coders. With tight design schedules and RDC happening late in the RTL closure stage, it is becoming very difficult to avoid such design structures. This structure is hence expected to be caught by the RDC EDA tools and have to be analyzed and fixed by the RDC engineer.