4

This is similar to this question, asking if a reset is needed in a 2 flip-flop synchronizer. The answer to that question was: "no, not necessarily".

So, my question is:

  • Why do almost all of the 2 flip-flop (or N flip-flop) synchronizer implementations I find have no reset?
    • Is there some problem/drawback with resetting?
    • Is the answer the same for both synchronous and asynchronous (i.e. asynchronous assert, synchronous de-assert) resets?

enter image description here

My Search Results:

These are the VHDL/Verilog implementations I have found and none of them have resets:

A google image search also finds dozens of circuit diagrams without resets connected (or at least without them drawn).

The only implementation I have found with a reset is the System Verilog implementation on p. 47 of this article.

Harry
  • 270
  • 2
  • 8
  • 1
    It simply isn't necessary. If the input is in a known state, the output will be in a known state within 2 clock cycles regardless. Why spend the resources (especially in an FPGA) to route a reset signal to the synchronizer? – Dave Tweed Aug 13 '22 at 22:45
  • @Dave Tweed Because something utterly terrible could happen during those 2 clock cycles. – Harry Aug 14 '22 at 13:42

2 Answers2

3

Even if you don't reset 2FF-synchroniser, you can still make it work. When such a 2FF-synchroniser is initially power-on and clocked, it drives an unknown value at its output for 2 clock cycles at most. In the next clock cycle, output will be driven to the actual value as at the valid input. If you make sure that the rest of the design in the clock domain is on reset during this initial clocking period, unknown values will not be sampled by the capturing flop. Once the design comes out of reset, 2FF-synchoronizer would have settled and you would always be sampling the valid input. This could be a scenario in which you may not need a reset in 2FF-synchroniser.

Otherwise in modern FPGAs, 2FF-synchroniser described in RTL may not need a reset, because all the flops have a known value on power-on, which is usually '0' by default. In ASIC, I have seen async clear signal in the 2FF-synchroniser CDC cells to put it in a known state on power-on before even clocking it.

UPDATE:

There could be scenarios where reset is required in 2FF-synchroniser, particularly in ASIC designs. Say for example, consider this case: the design in destination clock domain is reset asynchronously without clock, and released reset. It's clocked later on. First two clock cycles could then propagate an unknown value from 2FF-synchroniser. What if this is '1', and '1' means somekind of trigger to the design (design intent) from the source clock domain, then this is actually a false trigger. But if the synchroniser was reset along with the design, this could have been avoided. So, having a reset in 2FF-synchroniser cell gives the designer flexibility to handle scenarios like this.

Mitu Raj
  • 10,843
  • 6
  • 23
  • 46
  • I understand why resetting may or may not be desired. My question was whether there was any reason that this **option** seems to be missing from almost every implementation I have ever seen. In cases where resetting is not required (which will happen often, especially in FPGAs), we can just tie the reset to constant '0'. But if we have a special case where we need to reset, then is there any drawback? From your comments, it sounds like there would be no problem (and I can't think of any reason there would be a problem). – Harry Aug 13 '22 at 23:23
  • 1
    It could be design dependent. Say for example, consider this case: the design in destination clock domain is reset asynchronously without clock, released reset. It's clocked later on. First two clock cycles could then propagate an unknown value from 2FF. What if this is '1', and '1' means somekind of trigger to the design from another clock domain, then this is actually a false trigger, right? But if there was reset in 2FF, this would not have happened. So having a reset, gives you flexibility in all possible cases. – Mitu Raj Aug 14 '22 at 06:34
  • That's exactly what I'm asking! These may be rare cases where we want to reset the synchronizer's registers, but I think these situations do exist. So I would like to add a reset to my 2 flip-flop synchronizer component to handle these rare cases. Maybe in 99% of cases, I will just tie reset to '0'... but I would like to have the option to reset in the rare 1% of cases. I just wanted to check if adding this reset would introduce any problems. (And I think you have already answered my question: no there is no problem, but in many cases, this reset would not be necessary). – Harry Aug 14 '22 at 06:48
  • I shall update the answer accordingly.@Harry – Mitu Raj Aug 14 '22 at 07:50
0

Your system should be designed to be robust to having inputs come up in an unknown state. Your reset sequence should cover over the time during which your clocks are still coming up (including your synchronizer clock). Having your sync flops come up as ‘X’ is useful in simulation as a means to check for that.

There is an exception to this: the reset itself. Often, this is implemented using a synchronizer that is asynchronously reset, with the internal reset negation being synchronous.

hacktastical
  • 49,832
  • 2
  • 47
  • 138
  • Your first sentence doesn't seem to be related to my question. (And, depending on exactly what you would define as "inputs", I would argue that the whole purpose of a reset sequence is to **prevent** the system coming up in an unknown state). I would also say that simulation convenience is usually not a good reason to change synthesized hardware. (But I'm not sure it's even relevant here - we'll still start with 'U'/'X' in any registers that have not been reset yet, as long as we don't apply any power-on defaults).... – Harry Aug 13 '22 at 19:45
  • ... Your final sentence describes a reset synchronizer, which is a different circuit from a 2 flip-flop synchronizer. Therefore, I don't feel that this answers my question(s). – Harry Aug 13 '22 at 19:45