What timing constraints should be applied on synchronizers?

[ivlsi]

Hi All,

What timing constraints should be applied on synchronizers?

Between what flops should be applied the multicycle constraint?

Why applying 'false path' constraint on synchronizers is a bad practice?

Why applying min/max delays on the synchronizers is a good practice? How should these constraints be applied?

Thank you!

 

[vamsi1255]

Re: Synchronizer Timing Constraints

Hi

What type of synchronizers ? data or reset

~vamsi

 

[sam536]

Re: Synchronizer Timing Constraints

Implementation tools assume False paths are no longer interact with each other and place some where else . The routing and congestions issues pops out.

But, never heard applying FP between synchronizer is bad approach...

Where as MCP/Max delays will ease out the above problem.
Between CLK1 driving registers(FF1) and CLK2 driving registers(FF2) in the , Either MCP/False path/MAX delays need to apply.

Thanks

 

[ivlsi]

Re: Synchronizer Timing Constraints

So, what's the difference between these constraints in terms of synchronizers:
- applying multicycle path of 2 on the second stage of the synchronizer
- applying max delay (probably also min delay) between the first and second stages of the synchronizer

In case of applying min/max delay on the synchronizer, what values should be chosen? Max delay = two clocks period? What value should be chosen for Min Delay?

What's the difference between applying min/max delay and multicycle path on the synchronizer?

And one more question... If I put min/max constraints on the data paths between the clock domains, which prevent metastable situations, why ever are the synchronizers needed?

As for the false path, all is clear.

 

[ivlsi]

As for the MultiCycle Path between what pins of the Synchronizer should it be applied?

 

[rahul.achates]

Dear ivlsi (dont know ur name ... ) ,

You need to read some books on STA,I can explain a little bit.

STA - static timing analysis, which mean tool calculate the timing on every path , flop to flop or input to flop or flop to out or input to output ...

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.

since signals going from one clock domain to other clock domain .. there could be setup/hold violations due to uncertainty of arriving of signal , we use sync cells.

You should not applied multicycle path on sync cell , this is not a good practice. But you can define false path .. which we do in .sdc file by below command

set_false_path -from clock_domain_1 -to clock_domain_2
set_false_path -from clock_domain_2 -to clock_domain_1

this will declare false path for all signals going/coming from clock_domain_1 or clock_domain_2.


Rahul

 

[ivlsi]

You need to read some books on STA

What books would you recommend?

 

[rahul.achates]

This is very good book.

https://www.amazon.com/Static-Timing-Analysis-Nanometer-Designs/dp/0387938192

 

[ivlsi]

You should not applied multicycle path on sync cell, this is not a good practice.

Can you explain why it's a bad practice? I've heard that MCP is necessary constraint for synchronizers.

 

[rahul.achates]

What is the use of putting MCP on sync cells ?

Rahul

 

[ivlsi]

What is the use of putting MCP on sync cells ?

I just heard it's necessary. I suppose this constraint allows the tool to "skip" the first stage of synchronizer while keeping a timing path from clk1 to clk2.

 

[FvM]

There's no "timing path to keep" between clk1 and and clk2 in the synchronizer. We can (at least theoretically) assume a case where clk1 and clk2 are not unrelated and you have some constrained pathes between both clock domains. In this case, the set_false_path statement would be explicitely specified -to the synchronizer register to avoid unwanted side effects.

 

[rahul.achates]

I just heard it's necessary. I suppose this constraint allows the tool to "skip" the first stage of synchronizer while keeping a timing path from clk1 to clk2.

I think either you get wrong input or the purpose using that something else.

STA .. doesn;t check any timing between clk1 to clk2 ...

I think below is what you want to ask ..

clk2 is divided version of clk1 .... so in that case clk1 and clk2 having relationship and there is no need of any sync cell for the signals going from clk1 to clk 2 ..

but you will have to declare MCP for the signals going from clk1 to clk2 ..

In other case , where clk1 and clk2 not having any relationship .. you just have to declare false path .. nothing else.

Rahul

 

[ivlsi]

Are these the wrong constraints for the synchronizer (see the picture below)?

 

[FvM]

Only a false_path constraint makes sense. It's sufficient to write a single -to register constraint.

 

[ivlsi]

What about max delay? Will it work together with Palse Path as it shown on the picture?
Why MultiCycle Path doesn't make sense?

 

[rahul.achates]

max delay and multicycle path doesn't make any sense here ,however you can use it if the purpose is different.

you should only be using false_path for signals going from clk1 to clk2 ...

max_delay you should be using if you want all signals from clk1 should have limited skew ..

multicycle path ... not useful here.

 

[FvM]

What about max delay? Will it work together with false Path as it shown on the picture?

Sounds like you have a dead cat and consider how to feed it. False path states there's no timing relation at all, any other constraint becomes obsolete.

I suggest reading about timing constraints in a digital logic text book.

 

[rahul.achates]

FvM .. Good one.

I already told him to read some book in my previous post ... but seems like someone testing the technical skills

 

[jt_eaton]

The reason that set_false_path is a bad practice has to do with busses. Even if there is no timing constraint on each signal you still would like the router to keep all the signals together. If you FP them then you may find that 7 signals are routed together while 1 signal takes a really long path. Setting some easily met constraint prevents this from happening