combinational logic before synchronizer

If there is combinational logic in the path before double stage synchronizer input, it is considered to be not correct.
What are the problems if there is combinational logic before synchronizer?

This combinational logic before synchronizer can result in glitches. which might be captured and will propagate to the destination clock domain.
You can refer the below link for more info..or you will get info on the net easily...https://www.edaboard.com/threads/198995/

The expression for synchronizer MTBF has the product fclk*fdata in the denominator. Possible glitches will increase fdata.

How can the combinational logic produce glitches before the synchronizer?

Consider a circuit having a 2 input and gate before a synchronizer. Assume the 2 inputs to the and gate come from flops and both are pulses. Assume 1 pulse occurs 1 cycle after the other. If the flop producing the 1st pulse has a higher clk->Q delay than the other flop, then their will be small time interval in which both these pulse outputs are 1. This will result in a glitch..
Please draw timing diagrams to get a clear understanding...

sharath666

If the AND gate and the two flipflops whose outputs are inputs to the AND gate is part of the design/circuit of clock domain clk1, then this and gate and corresponding glitches that will come out of this and gate is a part of the design and this glitch is then an allowable glitch because the designer has put this and gate and knows that glitched will come. so i will not say it is an unwanted or unexpected glitch. Then this glitch needs to be propagated to clock domain clk2 also. So we need to place a diuble stage synchronizer after this and gate so that any output from this and gate safely propagates to clock domain clk2. But surely we need to make sure that the double stage synchronizer is capable of removing metastability for such a glitch and pass the glitch safely to clock domain clk2.

Please comment.

Regards

No glitches are acceptable in any circuit in any part of the world.
If you are saying that the designer is aware that there is a glitch in his circuit and if that glitch has to be passed correctly onto the other domain. then your idea is incorrect. Any glitches found at any stage of the design process have to be suppressed.

sharath666 said:

No glitches are acceptable in any circuit in any part of the world.
If you are saying that the designer is aware that there is a glitch in his circuit and if that glitch has to be passed correctly onto the other domain. then your idea is incorrect. Any glitches found at any stage of the design process have to be suppressed.

Click to expand...

That is why I wrote "so i will not say it is an unwanted or unexpected glitch". I agree that gliches needs to be removed from designs. So to state accurately , I shall not call that pulse as a glitch but an wanted pulse in the design.

See, the designer has put two flipflops followed by an and gate in such a way that the outputs of the flipflops are inputs to the AND gate. So even if the output of the AND gate need not to be send to another design which is opertaing in an different clock clk2 , the output of the and gate is the output of the first design which is operating in clk1. So that pulse is a wanted pulse and not a glitch. If it was a glitch the designer of that design would have taken care in his/her design such that such a pulse does not happen. Now a need comes to connect that design to another design which opertaes at clk2 and so a double stage synchronizer was placed. Where is the problem then? Please comment.

No glitches are acceptable in any circuit in any part of the world.

Click to expand...

Misses the point. Glitches can occur in the output of LUT based combinational logic if more than one input changes simultaneously. The problem under discussion is if it's acceptable to feed these glitches to the input of a D-FF synchronizer.

As previously discussed, the glitches increase the effective synchronizer data rate and thus reduce the metastability MTBF. No problem if the synchronizer is designed with a sufficient MTBF margin and the glitches can only occur near to valid signal changes at the synchronizer input.

If the glitches occur at times when the input signal is expected silent, they can generate a false synchronizer output signal.

As an example consider a binary counter followed by a comparator. The comparator output must be expected to have glitches when more than one counter output changes, e.g. when the output overflows to zero. In this case, the comparator output should be registered before it's send to a synchronizer.

Continuing with FVM's point, the scenario which I have described in my 2nd post is an unexpected scenario(something the designer is not aware of) and which he/she must take care to avoid.

I agree that not allowing any glitches for the synchronizer input is the safest way.

The reason this thread was raised is due to the reason, the tools which checks RTLs to see if there is any CDC problem or not, reports a violation if there is any combinational logic before a synchronizer.

Why the tool report it as a violation? Why will a designer put any combinational logic when the designer is trying to pass a signal from one clock domain to another clock domain. The designer will only put a synchronizer without using any combinatioal logic before the double stage synchronizer to pass the signal from one clock domain to another domain. Will not the designer will register the output of the signal which is coming out of clock domain 1 after passing throgh a combinational logic?So designer will take care of that. what is the possible reason that when the CDC Analysis tool was made in such a way so that if the CDC Analysis tool sees a combination logic before a synchronizer it will report a violation. Can you please explain from this angle?

Regards,

I gave an example where glitches generated by combinational logic can cause a false pulse after the synchronizer.

A straight forward way to avoid this issue is not to use any combinational before the synchronizer, that's what the said tools are apparently enforcing. I don't see a problem with this safe method. It's up to you to decide that the tool's suggestions can be ignored in a specific design.

Usually combi logic before a synchronizer is a design issue(for the reasons already explained). The CDC tool is used to find out such issues. It is like how a simulator is used to find out functional issues and spyglass is used to find out lint issues. You can think of the CDC tool in the same manner.