求助：时序分析中同一时钟的不同路径问题

新手，SOC前端的，最近和后端一起做时序分析时发现一个问题。Encounter做CTS的时候报出来的一些timing violation。
分析后发现问题如下
源时钟CK，从A点出发---->B点时钟处理逻辑1（比如分频逻辑）----->D点切换逻辑-->E点输出时钟CKE
|^
V|
------>C点时钟处理逻辑2--------------
在对E点后的时钟CKE作后面的时序分析时，比如寄存器a时钟为CKE，其D端计算数据路径时，时钟路径从A到B到D再到E；而其时钟端的时钟路径计算则从A到C到D再到E。工具用了一个最坏情况去计算时序，但问题是实际情况中时钟只可能来自同一路径，要么前者，要么后者，不可能同时来自两条路径。
求问如何让工具避免这种不真实的计算方式，考虑过加constraint，但是两条路径都是合理的，屏蔽其中一条反而不合理。
有没有什么相关命令，求指教
另请问CPPR的设置应该和这种情况没关系吧
谢谢

自己顶，真心求教

我觉得应该就是CPPR， 你看下report里有没有CPPR的 recovery，
没有的话就打开CPPR

打开了，但是CPPR的补偿为0

你的RTL正确吗?好像不能出现这样的情况吧！

看来高手对这种简单问题都不感兴趣，我自问自答吧……
首先这个跟CPPR没关系，CPPR补偿是以同一路径的时钟为前提的，ABD,ACD路径不一样，所以不涉及到CPPR
后来做时序检查的时候分成两个case，set case analysis在D点，ABD和ACD分开检查

这个是典型的Clock reconvergency问题, 时钟源头一样,然后走不同的路径,然后在某个mux上重新汇聚,在做timingcheck的时候这两条路径互相check,就产生violation,然而这样的路径是虚假的,因为一个mux不能同时通过两个时钟.
解决方法可以在mux上设case_analysis,每个mode只过一条路径,这样mode会变多,需用MMMC来解.做时钟树的时候一般情况下两条路径做到大致平衡,不过也有不能平衡的情况,比如DLL.

hawkz说的MMMC是一种解法
如果不想用MMMC的话，在B和C处，分别定义generated_clock，然后把它俩set_false_path

学习了

是的，目前也是这样做的

谢谢陈版的建议，这是一个从constrain上解决的好办法

我们也遇到同样问题。
很奇特的是：在encounter 下是完全没问题的。只在primetime 下出问题。
个人认为这是一个primetime 很久的bug 了。

按照primetime 文档，ABD,ACD 也应该算reconvergent logic in clock network，但是
set CRPR 后没用。
将D点设置为generated_clock 解决了setup ，但是出现一个莫名其妙的hold violation。

个人理解 ABD,ACD 应该不算reconvergent logic in clock network，逻辑上不可能但是工具单从电路结构上看并不认为是false的
我用的ETS同样也是这样的情况

我的想法跟陈涛一样，在B和C处create_generated_clock，然后对这两个generated clock设置false path或者set_clock_ groups -logically_exclusive

顶小编，这个方法好，我也使用过，此方法也适合对sdc中时钟节点定义不适合做时钟树的时候重新定义时钟

陈大，按照你的方法，在B和C处，分别定义generated_clock，把它俩set_false_path后，是不是还要在D点加上一句set_caee_analysis呢?

你看下report里有没有CPPR的 recovery

真心学习了，陈大的方法真好！

不错的资料，学习了，太好了