How to define clocks in my cases? S.O.S!!!

Hi, all:

The clocks in my design is:
External input CLK0 can be either 32MHz or 64MHz, which is selected with clk_sel pin.
CLK0 passes through a PLL to become 64MHz CLK1.

Then with the help of clk_sel, either CLK1 or CLK0 is selected as the CLK2, which serves as the root clock of system. The diagram is illustrated as below.
CLK0 --> PLL --> CLK1;
CLK2 = clk_sel? CLK1 : CLK0;

Then how to define the constraints about the clock?
Shall I use set_case_analysis to set clk_sel to either 0 or 1, and performs the analysis independently?

On the other hand,
There are PLL and MUX between CLK0 and CLK2 in case of clk_sel=1, while only MUX in case of clk_sel=0, so different definition of input_delay maybe needed for this two cases?

Thanks in advance!
laughlatest

Hi,

I do not know about Synopsis flow, but you should use set_clock_latency instead of input_delay for clock in Encounter based flow.

The next question is "what place is the clock root?". The answer depends on chosen archirecture. Do you cotstraint any output pins? I mean, have you any external system that must sync work with your die (uses the same clock to read from your die)? If no, you could use PLL output (or MUX output) as Root of generated clock.

If the answer is "yes", the clock tree may may be more complicated.

Could you provide more info about whole system that uses your die?

P.S. Multiplexed clocks are very often used , so try to google it (ex: https://www.altera.com/search?outpu...ontend&ie=UTF-8&oe=UTF-8&site=www&q=mux clock)

Hi, kulyapinav:

Thanks for your kindness.

Surely, my chip has to provide reference sampling clock to external AD and DA. But the clock also comes from the MUX output, while not the input clock itself.
I am wonder whether this fact simplify the problem to some extent.

If I choose the MUX output as the clock root, then how synthesis tool will handle the path from CLK0(input CLK pin) to MUX output?
(For reference, PLL comes from 3-rd party IP, MUX is special cell for clock multiplexing selection comes from vendor technology library).
And in this case, how to use the set_clock_latency?

Thanks in advance
laughlatest

Hi,
You should not skip CLK port at all.
I meant following:
create_clock -name CLK0 [get_ports CLK] ....
create_generated_clock \
-name CLK1 \
-source [get_ports CLK] -divide_by 1 \
-master_clock [get_clocks CLK0] \
-add [get_pins PLL/OUT]
set_case_analysis 1 [get_ports PLL_selection]
set_clock_latency $some_nubmer CLK0
set_clock_latency $some_number CLK1

It should work for FE. And, if it works for you, you could use PLL output pin as root of the CLOCK tree during BACK-END, instead of has to include PLL macro in Physical (propagated) Clock Tree.

Hi,

Thanks a lot.
I think that your proposal will work for me in case of clk_sel=1. I will just try it.
One thing shall be clarified: In my design, PLL is used to double the clock frequency.
When clk_sel=0, the CLK0 is a 64MHz clock and used as system clock directly,
when clk_sel=1, the CLK0 is a 32MHz clock and translated to 64MHz by PLL, then used as system clock.

Still, I am wonder why it is PLL output pin, instead of MUX output pin,
that shall be used as root of CTS.
As you know, in case of clk_sel=0, PLL output pin is not used anyway!

And also in your proposal,why is there no need of "set_case_analysis 0"?

Best regards

Still, I am wonder why it is PLL output pin, instead of MUX output pin,
that shall be used as root of CTS.
As you know, in case of clk_sel=0, PLL output pin is not used anyway!

Click to expand...

It affects to clock latency. And it is your choise and it depends on your design. U should understand how clock latency value affects on I2C and C2O cost groups.
I am just wonder you will get over-optimistic clock tree latency for BE design (propagation clock latency) if you point the clock tree root to MUX out.

And also in your proposal,why is there no need of "set_case_analysis 0"?

Click to expand...

Iam not sure I understood you right. You can optimize your data path for one mode only (if multiplexed clocks are not correlated; in case if the clocks are correlated, you do not need to do it).
In general, multiplexed clocks are used in order to separate two operation modes (test mode and operation mode for example). In this case you need optimize only one operation mode (obviously, it should be mode which one refers to higher clock frequency).

BTW, one more importantant task: does you MUX support "hot" (without FF set/reset) clock switching?

Hi, kulyapinav

Thanks so much!
Now I think I have got to understand your proposal correctly.
Focusing on optimization of the path with PLL seems appropriate to me.

The MUX cell(MUX2CK) comes from vendor's library, and is specific to clock switching,
so I think I have no need to worry about it.

But when it comes to the relation between clock latency and cost group,
actually, I don't know much about it.Would you please give me a brief and clear
explanation?

Best regards

laughlatest, you could specify your clock at the mux output, but how will you fix the slew before the mux? You really need a CTS tool which can handle multimode. You should look into use Azuro's powercentric, it can balance clocks in both modes.

By the way does your PLL have a timing model with all timing arcs defined? If so then you should be able to just define CLK0.

iwpia50s,

Thanks.
My project is a netlist sign-off project, BE task is out-sourcing to 3rd-party design house,
who provide us technology lib and also PLL IP etc.
So I just wonder whether I can simplify my FE task as much as possible, and push the things
to BE. Anyway, they are expert to deal with such things.^-^.
Maybe I am just too optimistic about it.

According to my understanding, I may have no need to balance clocks in two modes,
because they are not used at the same time.
If all input/output are related to the MUX output, so why shall the balance between clocks in two
modes be cared about?

B&R
laughlatest

hi iwpia50s,
Actually above timimg constraints (clock root is defined at PLL output or MUX output) are fully acceptable for BE (I use this flow often. I use Cadence Encounter BE tool set).You can easy fix the slew BEFORE the mux through max_transition constraint usage.

hi laughlatest,
clock latency it is delay of clock tree (tree of buffer and inverter cells). Clock tree sinthesizer tool tries to equalize all local latency (delay from clock root to every FF) in such way so CLK signal arrives all FFs at the same time. Mismatch in local latencies is SKEW or uncertainty parameter. So, if Skew = 0ps, clock arrives all FFs at the same time (global latency= every local latency).
reg2reg cost group
Register-to-register data paths are absolutely independed on latency. In case if Skew !=0, reg2reg data paths depend on skew value, and do not depend on latency (it is every simple: just abs(launch clock delay - cupture clock delay) = Skew ).

Input-to-register cost group
This cost group is a special case of reg2reg (inherits common reg2reg paradigm ) - launch clock delay value is input pad/port delay rather then clock tree local delay. In such way, so you have only capture FF and input port is a equivalent of launch FF

register-to-output cost group
This is a special case of reg2reg too, but you have launch FF and output port instead of capture FF

So, you can very easy extrapolate reg2reg setup slack calculation to in2reg and reg2out cost group.