SDC for ALTCLKCTRL

[Altera_Forum]

Hello, 

 I have an ALTCLKCTRL component implemented in my design targeting a Cyclone V FPGA. The ALTCLKCTRL has 4 of its inputs occupied:  1. Clock_1 driven by an FPGA pin. 2. Clock_2 driven by an FPGA pin. 3. Clock_3 coming from a pll_a. 4. Clock_4 coming from a pll_b.  All of the above are from the same bank and connected correctly - the design passes fitting without issue and last but not least - it works.  However, I do have some trouble with timing analysis: I use the "create_clock" SDC command for creating Clock_1 and Clock_2 and then the "derive_pll_clocks" macro to generate Clock_3 , Clock_4 and the output of ALTCLKCTRL. The result: Clock_1, Clock_2, Clock_3, Clock_4 get recognized as clocks by the tool but the output of ALTCLKCTRL doesn't.  From all I read the "derive_pll_clocks" macro should apply to ANY clock sourcing element...So why doesn't it work for ALTCLKCTRL ?

[Altera_Forum]

No. derive_pll_clocks, as the name implies, only works for PLL clock outputs. Is only 1 of the 4 clocks active in the design at a time? If so, you also need a set_clock_groups timing exception because only one of the 4 clocks will be active on the output of the mux at a time. It would look something like: 

 set_clock_groups -exclusive -group clock_1 -group clock_2 -group clock_3 -group clock_4  If any of the clocks bypass ALTCLKCTRL and are used in the design when a clock from the mux is active, you may need to add additional generated clock commands targeted to the output of the mux and then add set_clock_groups exceptions between them.  Steve

[Altera_Forum]

Suppose only one of the clocks is active at a given time. 

Why "set_clock_groups" is enough ? Shouldn't I also apply the "create_generated_clock" for the ALTCLKCTRL's output ?  Surely the ALTCLKCTRL component has some delay from input to output.

[Altera_Forum]

It does have delay, but you don't need to define the delay since the tool knows about internal resource delays. Clock creation is for creating essentially reference points for timing analysis, not defining delays. You can define delays if you want, but it's not necessary for internal paths. Using set_clock_groups will tell TimeQuest that only one clock is active at a time, the way your design is supposed to work.

[Altera_Forum]

--- Quote Start ---  Clock creation is for creating essentially reference points for timing analysis, not defining delays.  --- Quote End ---   Exactly. If I don't use the "create_generated_clock" command on the output of ALTCLKCTRL - how would the tool know that it should analyze timing in reference to that point ?  I mean, we use the "create_generated_clock" on all PLL outputs - so why is the ALTCLKCTRL any different ? Why doesn't it deserve a "create_generated_clock" command on it's output ?

[Altera_Forum]

There's nothing stopping you from doing it. Are you saying that the tool is reporting that the output of ALTCLKCTRL is an unconstrained clock? Like I said, if you have other clocks that don't go through the mux, you would need to create generated clocks on the output of the clock mux as references. The reason you don't need to in your case is that ALTCLKCTRL is not generating a new clock. PLLS do create new clocks based off of other clocks. 

 But if for some reason the tool is reporting it as unconstrained (which is unusual), then yes you'd need generated clocks as well.

[Altera_Forum]

--- Quote Start ---  Are you saying that the tool is reporting that the output of ALTCLKCTRL is an unconstrained clock?.  --- Quote End ---   Not exactly and that's where it gets strange... In the "Clock Status Summary" it doesn't show at all (not even as a red unconstrained path).   I don't see in the "Clock Tree" report either. All other clocks are there, the output of ALTCLKCTRL isn't...  But despite the phantom behavior the MUX and the design it drives work.

[Altera_Forum]

--- Quote Start ---  Not exactly and that's where it gets strange... In the "Clock Status Summary" it doesn't show at all (not even as a red unconstrained path).   I don't see in the "Clock Tree" report either. All other clocks are there, the output of ALTCLKCTRL isn't...  But despite the phantom behavior the MUX and the design it drives work.  --- Quote End ---    you will find all details here: https://www.mixdown.ca/redmine/attachments/download/71/timing_analysis_of_internally_generated_clocks_in_timequest_v2.0.pdf  figure 19 (not really figure but SDC

[Altera_Forum]

Thanks, but this doesn't explain why TimeQuest fails to identify the output of ALTCLKCTRL as a clock.

[Altera_Forum]

Excluding a bug - the only explanation I can think of is this: 

For timing purposes, the tool doesn't treat the output of ALTCLKCTRL as a clock source. Instead, it views it ALTCLKCTRL as a balanced delay in the clock path for all MUX inputs.  I.E: nothing more than a "long wire" leading to the input of the global clock tree. Therefore, it's never considered as an additional clock source.  Do you agree with this assumption ?

[Altera_Forum]

That sounds right. The key is what you see in the unconstrained paths report. If it's not there, it's not an issue. But you should still have set_clock_groups for the output of the mux.

[Altera_Forum]

You definitely have to manually constrain this. You need to find the output of the altclkctrl in the node finder, and then do: 

 create_generated_clock -name pin1 -source [get_ports pin1] {altclkctrl|dout} create_generated_clock -name pin2 -source [get_ports pin2] {altclkctrl|dout} -add create_generated_clock -name pll_clk_1 -source [get_pins altpll...clkout1] {altclkctrl|dout} -add create_generated_clock -name pll_clk_2 -source [get_pins altpll...clkout2] {altclkctrl|dout} -add  The last item is the name of the altclkctrl. The -source for the pins is just the name of the top-level port, while the -source for the PLL can be found when you run Report Clocks and is the Target column for the PLL generated clock. For the -name option, naturally name then whatever you want. Then you'll need something like: set_clock_groups -exclusive -group {pin1}   -group {pin2}   -group {pll_clk_1}   -group {pll_clk_2} Naturally, add other clocks to this command as appropriate.

[Altera_Forum]

--- Quote Start ---  You definitely have to manually constrain this  --- Quote End ---   So you disagree with what I wrote in# 10 ? You assume it's a bug in the tool ?

[Altera_Forum]

I'm not sure what you mean by fails to recognize. The altclkctrl is basically a mux, and the clocks all pass through it and are analyzed. This is the way it would work if you built a mux out of logic. The real problem is that timing analysis assumes all clocks can happen at the same time, so you'll get an analysis where pin1 goes through the mux and feeds the source register and pll_clk1 goes through the mux and feeds the destination(which in theory could happen when you switch clocks). Just adding the generated clocks doesn't change this analysis. Instead, it gives you a clear clock name that you can use for your set_clock_groups. 

As a test, before adding the generated_clocks, do a report_timing on some paths that are fed by this altclkctrl and see what it analyzes. If this was a clock that wasn't recognized, you wouldn't get any analysis, but I suspect you will. (In theory, you could skip doing the generated clocks and probably just do a set_clock_groups with the four clocks that drive into the altclkctrl, and probably be fine. The only way this wouldn't work is if you had paths that were outside of the altclkctrl you wanted to analyze, e.g. if you had a path who's source register is directly driven by pll_clk1 and destination is driven by pll_clk2 you might not want to cut that, but still would want to cut the analysis between these two clocks when they go through the altclkctrl block.)