What timing constraints should be applied on synchronizers?

The reason that set_false_path is a bad practice has to do with busses.

Click to expand...

The statement doesn't seem to be related to the synchronizer topic. By nature, synchronizers can't be used for busses.

FvM said:

The statement doesn't seem to be related to the synchronizer topic. By nature, synchronizers can't be used for busses.

Click to expand...

When you have to pass a bus between clock domains you synchronize a load signal that tells the receiving domain when it is safe to capture the buss values. The timing arcs go through the load signal and the buss it self could be false_pathed. But if you do that then there is no guarentee that the router will keep the buss signals together, applying some loose constraint will do that.

I see what you mean. I believe it's a mostly theorectical problem. I didn't came across similar issues in any practical synchronizer application.

But if you have a circuit where routing delay skew is severe. According to my understanding a set_max_delay constraint should work.

Another necessary comment referring to the original problem. If you apply a false_path constraint in the post #14 circuit, all other timing specifications using the same path (all other suggested constraints in the picture) are ignored, as claimed in the "dead cat" comparison.

So a max_delay constraint must be used instead of false_path.

rahul.achates said:

Dear ivlsi (dont know ur name ... ) ,
Noon of the sta tool will able to calculate the path between different clock domain , since signals coming from one clock domain to other clock domain are totally asynchronous and tool will not able to calculate the timing.
Rahul

Click to expand...

So, what happen if I don't define False Path between clocks or any other async signals?? Will the tool ignore these paths automatically? How tools handle this situation? How do they report about it?

- - - Updated - - -

As for the divided clocks, should I put MultiCycle Path between them even if I defined the driven clock as a divided one?

- - - Updated - - -

max_delay constraint must be used instead of false_path

Click to expand...

What about min_delay constraints? should they be applied as well? why yes/not?

max_delay constraint must be used instead of false_path

Click to expand...

What's about Min Delay constraints?

ivlsi said:

What's about Min Delay constraints?

Click to expand...

Min delay plays a role between the 1st stage and 2nd stage flip flop in a 2 stage synchronizer. As there are no combo logic between 1st and 2nd stage FF in a synchronizer the signal may reach fast enough to cause hold time failure in the 2nd FF. If the hold time requirement of the 2nd stage FF is not met, eventually the output of the synchronizer will go metastable and break all other circuits. This is theory.

But practically speaking in present days designs, synchronizers are either part of the vendor library or they are hard maced already. If you use such components in design you will never face min delay / hold time issue between 1st stage and 2ns stage FFs in a synchronizer.

- - - Updated - - -

FvM said:

I see what you mean. I believe it's a mostly theorectical problem. I didn't came across similar issues in any practical synchronizer application.

But if you have a circuit where routing delay skew is severe. According to my understanding a set_max_delay constraint should work.

Click to expand...

I see a good point in jt_eaton statement. I have seen in many places a synchronization method called as "mux recirculation synchronizer", which is used to transfer a bus data between two clock domains using an enable signal as control signal for latching the bus data. If we set two clock domains as async or false path, I am sure the bus data path will also be ignored from STA. What do you think is the best way we can handle this issue ?

Min delay plays a role between the 1st stage and 2nd stage flip flop in a 2 stage synchronizer.

Click to expand...

The FFs clocked by clk2 will be timing checked according to the regular constraints. No additional timing constraint required or even useful. Using min/max_delay constraints disables the regular checks and involves a risk to hide a timing violation.

The bus domain crossing problem is somehow beyond the scope of the original synchronizer question, I think.

The case where bus signal can be latched under control of an enable signal applies only to slow busses with sufficient time between samples, otherwise you have to refer to a DC-FIFO. But if it's applicable you have e.g. two clock cycles timing margin for bus delay. That's probably five- to tenfold the expectable routing and logic delay. Thus I said the need for delay timing constraints is a purely theoretical idea. But technically, max- and min_delay constraints can be used instead of false_path for the path between clock domains if you see a reasonable purpose.