Multicycle path or False path ?

[viju]

If we send data from one clock(say slow clk) domain to other clock domain(say fast clk), then what kind of constraint we have to give while doing synthesis or STA. Please refer the diagram given here.
There is a general guideline that when ever the data crossing the clk domain in your design, give cosntraints set_false_path -from clk1 -to clk2.

But if we have a case as show in the attached diagram, then should we give multicycle constraint like :
set_multicycle_path 2 -setup -end -from clk1 -to clk2

or false path constriant like :
set_false_path -from clk1 -to clk2

Please help me to understand use of two important timing exeptions.

 

[rjainv]

What is the relationship between waveform of CLK1 and Clk2 ?

Are they coming from same source ? is one a divided version of other ? What is the least separation that can be between edges of CLK1 and CLK2 ? is that deterministic ?

 

[engr]

I think we need to set_falsepath command in this case, becasue doent matter how much delay between different clock domains it takes we need to specify that path as false path.
The paths between the clock domains we remove the timing constraints, mean we have to set false path only, if u set multicycle(2) path command, then tool again try to optimize the path for 2 clock cycles, but we dont want to optimize at all
Thanks

 

[viju]

What is the relationship between waveform of CLK1 and Clk2 ?

Are they coming from same source ? is one a divided version of other ? What is the least separation that can be between edges of CLK1 and CLK2 ? is that deterministic ?

Hi rjainv,

Thank you for your reply.

Can you please explain me for the both the case that you have mentioned ?
What if both the clks are the from the same clk source ( i think same pll )and what if the dont know the exact separtion between both the clks.

I think in practice you can not say that how much skew on clk1 and how much skew on clk2. And aprt from this we have clk uncertainy due to OCV(i.e. jitter + varialbe skew due to ocv).
Anyway,
Do you mean that if both ckls are from the same clk source than we should declare it as a multicycle path as we are knowing the phase relationship betweeen two clks, and hence no chance of timing violation and hecne no need to give false path ?
And even if the clks are not from the same clk, but if we know the phase realtion ship between the launch edge and capture edge, we can make sure that there will not any violation detected and hence no need to declare falsepath, and can give multicycle path.
If it is so, then I have one more question that, how to find out that our clks will be having such kind of relationship in terms of their phase? Even if the clks are coming from the same pll, how can we make sure that the all the clks will start from zero at the same time?
Please give me detailed answer. It will help me a lot to enhance my fundamentals...

 

[Nir Dahan]

The key here is like rjainv mentioned - the relationship between clk1 and clk2.
if they are DERIVED from the SAME clock and they have some sort of relationship which you can DEFINE, then it makes sense to have STA for this path.
if however you have no correlation whatsoever between these clocks i.e. they are fully asynchronous then I would set a false path there.

hope this helps,

ND

https://asicdigitaldesign.wordpress.com

 

[ashy]

If you want to optimise the path, i feel its better to set a MAX delay between these two clocks, ofcourse to set a realistic max delay you will need the relation ship between the two clks as rjainv and Nir pointed out.

 

[ljxpjpjljx]

yes, you should first decide whether the clk1 and clk2 are from the common source! then you can see the sync logic between the two clock domain! then you can do some decision whether you should set false path or multicycle path!

 

[rjainv]

Firstly, what is the design intent ?

So far we are clear that if they are from same source and have a deterministic relationship, we can time them in STA, and make sure that there is no setup/hold violation on the data transfer.

But, if they are not coming from same clock source, and we infer that these clock domains are asynchronous, we should not blindly false_path them.
If its a async crossing,
a) there should be either a synchronizer on this path ( I can see combo cloud in figure, so this is not a part of synchronizer crossing for sure),
b) or should be a data path qualified by a control path which is synced separately.
c) or should be a static signal, which only changes once in a while in manner that its new value is not important for a few cycles, while it settles down to correct value.

You should look at the larger picture of design intent.
May be a synchronizer is missing here????