Possible Reset domain crossing?

Question

I have an ICG that gates a clock. The enable of the ICG is driven from one reset domain, say rst1. The gated clock drives a flop from another reset domain, say rst2.

Is this a "reset domain crossing" (RDC)? Does a tool like spyglass/jasper can find this issue like it finds a conventional RDC (that exists on the data path)?

Answer 1

I will take a stab at this, giving some background on what I have seen.

Firstly, I would argue there is no such thing as a "Reset Domain Crossing". I would call it a "Clock Domain Crossing, involving a reset signal". Because resets are no different than the D or Q when going from one point to another in sequential logic.

Let's say for clarity that we ignore RST1/RST2, and talk in terms of CLK1 and CLK2. RST1 is synchronous with respect to CLK1(from a deassertion standpoint as Pradyuman Bissa stated), and RS2 the same but with respect to CLK2.

The circuit you described, I am assuming looks like this:

This is a CDC issue, and would most likely be captured by a CDC tool (Jasper I thought was more for formal verification so it may not catch this). Things that would cause this to NOT be caught by a CDC tool would be any type of additional constraints that are added. Say you did some exclusion between CLK1 and CLK2, or you wildcarded some exclusion or cell. These would remove this from the failure list so you would not see this.

Having done CDC evaluation on designs with 50+ clocks, I can tell you that the failure list is so long that chances are good you coverup your own mistakes with incorrect exclusions/wildcards.

It's possible that this circuit still works. Particularly if the CLK1(gated) is enabled sometime after the reset has deasserted.

So to answer your question about a tool catching it, yea it probably would. End here before old man rant.

But I would argue, and what I believe Pradyuman Bissa is saying is that you should create a module/cell that gives you this functionality without the need to explicitly define the logic. This also allows you to reduce the chances that you introduce a CDC in the first place. Sometimes the best way to remove these errors is to reduce the chance you make them in the first place.

An example could be something like looks like the diagram below:

You can then instantiate this anytime you have a need to gate a clock and have an accompanying reset with the other clock domain. There is obviously some issues with needing to ensure that the reset from CLK2 is held long enough for the reset sync to see it.

I have seen many issues where people take something like this and hand place the logic instead of just creating one particular cell and instantiating that when needed. The amount of gates/flops required for this cell are generally minimal in the grand scheme of a design.