set_clock_tree_exceptions

clkgen里不用做树，所以做了exception。对类似的三个endpoint做了non stop
但是重新cts完之后，还是有这三个违例。
report_clock_tree -exceptions：

看着是设了进去

求教，

这样的设置之外，还有啥需要设置的?
或者，这种setup违例还有别的方法可以修不?

exclude pin 而不是 non stop pin
set_disable_timing/set_false_path

先分析下propagated部分为什么差那么多

毫无头绪 怎么看

report_timing[-path_type <path_type>]
(path type:
Values: full, end, only, short, start,
full_clock, full_clock_expanded)
Full_clock 可以将您propagated的clock 展开， 再如小编大人介绍debug.
后面您的clock setting 不是很看得懂。看上去您launch path 是个count register 啊 如果是跟generate clock 相关的counter 能否尝试将他们设成一个skew group
再者 您的non_stop_pin 和不用做树是什么关系 ，还望指教。
以上言论不代表本台观点

timing path和你怎么做cts没什么关系，不管你clk怎么做，如果这条timing path本来就存在的话他是不会消失的，除非你设了false_path。从lz的timing report来看你的cts应该是直接在clk rootpin 上直接做的，然后你设了是3个non-stop pin，所以cts会穿过这三个点然后去平衡rootpin后所有的loading（除这三个点外），所以导致clkgen里的ff被插入大量insertion delay去和data FF的clk pin平衡。
我建议的方法是在clk gen外面找point做cts，然后cts point和clk source之间手动插buffer chain。

多谢指教~理理思路~timing还不太会修

原来如此啊~多谢多谢~我去试试

这三条肯定是不能设false_path的，本意是说clkgen里的要求不高，想让ICC忽略到这三个end point的时序计算。

我比较奇怪的是，设了non stop 和没设的效果是一样的，时序大概都是贴粗来的这样。感觉是没设对的样子。
另外，想说能不能手动把它拉近呢..这事儿我看论坛里一直有人问 ，好像没看到有正面的回复。

你报出来的timing report里是不是就只有你设的那三个点的clk latency最短?如果是话那就说明你已经设上了non-stop pin。
你可以在ICC里画个小region，把clkgen的cell都放进去。
还有你说的没效果是没什么效果?是这三个点的timing依然可以报出来还是clk latency依然被平衡了?

就是之前做cts没有任何针对clk_pll的设置的。然后rpt出来clk_pll就有这三个违例，也只有这三个。
然后就按照一楼设置了non stop，但是rpt结果也还是这三个违例，连slack大小都没变化。

那我估计这三个点应该是generate clk点吧，当你对一个master clk做cts时ICC会自动把后面的generate点当做non-stop pin来处理的，所以你自己设不设non-stop pin都一样。
所以我建议你在ICC里靠近clk源头的地方（比如PLL或IO附近）画个小region，然后把clk gen的cell都放进去，然后在clkgen外面做cts

设成exclude pin可以考虑吗?

那我估计这三个点应该是generate clk点吧，当你对一个master clk做cts时ICC会自动把后面的generate点当做non-stop pin来处理的，所以你自己设不设non-stop pin都一样。
所以我建议你在ICC里靠近clk源头的地方（比如PLL或IO附近）画个小region，然后把clk gen的cell都放进去，然后在clkgen外面做cts

对，确实是几个generate！因为一开始我就是CK加了buffer，然后几个generate clock都恶化的好厉害。

不太懂怎么把clk gen的cell限制在画的region里，region怎么画呢?能说说具体命令不?

一直不太明白exclude和non stop的区别..

设成exclude pin的话，这三个generate clk后面的FF都不会去做cts了。所以不能设exclude pin

create_bounds -name clkgen -coordinate {$xl $yl $xu $yu} -type hard -exclusive [get_cells fh128/cnp/clkgen]

多谢多谢！原来bound还可以这样用！以前都是拿它限制Place，还觉得效果好差
设完bound再做cts的话，工具就会在clkgen外面做cts了对吧?

如果你给的cts点还是在clkgen里的clk root pin的话工具不会自己去bound外面找点去做cts，工具只会在你给的点后做cts。我的意思是你自己在clkgen外面找点，然后在这个点上create一个clk，然后在这个点上做cts，做完之后再把这个点上的clk删掉。

嗯嗯 大概明白意思了 我去试试~多谢！

exclude pin 不会影响你generate clock的cts ，master 到gen clock path上的buffer数量。可以通过设成exclude pin 去减少这段path上的buffer insertion， 因为include pin不会做CTS 但是会修DRC而插入必要的BUFFER。
当然这么设置最好应用在master clock 和generate clock 没有cross path上。

如果从你说的“clkgen里不用做树”，但是你这个Startpoint ：fh128/cnp/clkgen/cnt_reg_2_和endpoint：fh128/cnp/clkgen/hclk_pll_reg都是在clkgen中，为什么不都设上?
再说，从你贴出来的这条path看，我猜，这些在clkgen中reg都要balance。尽管你说“clkgen里不用做树”，但是它们之间还是需要balance的。
要是仅仅是到“类似的三个endpoint”有setup violation，那你给他设上float pin，把它们的latency做长，就可以修掉。
楼上那些，除了damonzhao指点了下，其他人给方法的都是瞎扯淡，没答到点子上来。
这只是一个简单的tree没有balance好的问题。

1、“如果从你说的“clkgen里不用做树”，但是你这个Startpoint ：fh128/cnp/clkgen/cnt_reg_2_和endpoint：fh128/cnp/clkgen/hclk_pll_reg都是在clkgen中，为什么不都设上?”
确实是不太明白应该怎么设...原话也是前端给的，对timing还在自个儿揣摩初期..如果哪里真的太菜了请见谅吧~
2、“再说，从你贴出来的这条path看，我猜，这些在clkgen中reg都要balance。尽管你说“clkgen里不用做树”，但是它们之间还是需要balance的。”

“clkgen不用做树”， 我是这么理解的。对clkgen内部没有啥特别要求，但是如果报了违例就肯定要修。

这位同学考虑问题太简单，按你说的这样无差别的做cts去平衡会导致整个clk的latency特别长，因为clkgen里本来就不能去和dataFF去做balance，clk latency的长短也是评判一个clk做的好坏的标准之一，而且有的design会要求clk的latency不能太长。

lz现在是只做了master clk一个cts，在那三个点设exclude pin之后这三个generate clk后面的FF就不会被balance，除非这三个generate clk单独再做cts

而且如果按你说的把这三个generate clk点的latency调的和其他FF一样长，那么这三个generate clk后面的FF会跟着变更长！这样就没办法平衡！
所以LZ，你还是按我的建议在clk gen外面找点，而且master clk和generate clk要分开做cts，做完后再在master clk cts点和generate clk cts点处去调这些clk之间的skew。

嗯嗯 在跑了 我这里机器比较慢 还没看到结果

就事论事。
在这条path上，明显就是tree没balance好，到Sartpoint是的latency是4.5326, 到Endpoint的latency是1.3837。
再说它这些reg就都是clkgen中的啊。
我看是你就不会去分析问题的，或者说你根本就不懂cts。
很简单的，你把它们的latency做差不多一样长，就不会有violation。
菜鸟就是被你种人给忽悠的。
我也很奇怪，这些小编水平那么高，怎么就不出来指明下。

不懂装懂的典型就是你这种人
就这条path而言，这个endpoint事实上就是generate clk点（LZ已经确认）。你现在把这个endpoint的clk latency垫长，这一条path是修掉了，但这个generate clk后面的FF和master clk有talk的path接着会冒出很多violation！

弱弱的说一句，我觉得这个是generate clk点就是因为在CK端加了buffer之后这条违例确实有好转，但是clk_acq和clk_core真的恶化的好厉害..很多很多违例冒了出来。

老实说你们讨论的我还不能全看明白，对时序也是一知半解。是不是大家的思路不太一样?

大家纯讨论就好。我知道天热大家是容易上火..
如果伤了和气就不好啦~对吧对吧~