时钟树问题 请教

zhangyang370281

这种mux结构选择时钟，在后端设计中经常遇到，比如ram的bist时钟和func时钟等等，这两种时钟关系是logic exclusive(逻辑互斥)，一般PR工具比如（ICC、INNVOS）能自动处理生成时钟树，但是对于两个时钟都是高速模式下，且存在多个mux的情况下会出现不同时钟域之间的setup/hold抵触的情形，比如bist模式和func模式，主要是由于capture reg和lanuch reg的具有不同的mux,时钟到达不同mux的D0端或D1端latency不同，导致capture reg和lanuch reg在bist时钟下的skew和在func时钟下的skew不同，出现bist时钟下的setup(hold)和func下的hold(或者setup)互相抵触，需要生成时钟树时小心处理。
对于楼主说的情况，因为scan模式下的setup很松，基本工具能够处理的比较好，采用上述定义时钟的方式，生成时钟树时问题不大

fangwang85

zhangyang370281 发表于 2020-10-5 20:41
这种mux结构选择时钟，在后端设计中经常遇到，比如ram的bist时钟和func时钟等等，这两种时钟关系是logic ex ...

大神请教下，clock tree怎么处理才算合理呢，是不是需要将这两路都长一样齐啊，谢谢了

zhangyang370281

如果bist_clock和func_clock复用同一个mux，这个时候bist_clock和func_clock的的时钟skew是一样的，无需担心，因为func模式下setup/hold满足，bist模式下也会满足的；如果存在ram和bist_reg的mux是独立的（比如两个mux，ram使用一个Mux，bist_reg使用一个mux），这种情况下，做时钟树时尽量保证bist_clock的时钟skew和func_clock的时钟skew尽量接近，如何构建时钟skew比较接近的时钟树也是一个难点，需要在 cts flow中多次尝试，达到自己满意的结果

fangwang85

zhangyang370281 发表于 2020-11-26 22:26
如果bist_clock和func_clock复用同一个mux，这个时候bist_clock和func_clock的的时钟skew是一样的，无需担 ...

谢谢大神，有时候做cts 会发现clock tree长的比较短，所以想重新优化一下局部的时钟树。目前能用的方式 是自己手动加buffer 或者 重新create_clock, icc貌似没有局部调整时钟的命令

zhangyang370281

ICC我记得不支持CCD，即时钟和数据协同优化，说白了就是自动实现usefull skew在优化setup和hold

qq94043

set case   不同mode 分别长自己的tree

fangwang85

qq94043 发表于 2020-12-14 16:42
set case   不同mode 分别长自己的tree

你好，你的意思是，先set_case_anaysis 0 [get_pins mux/s]  长一路，再set_case_anaysis 1 [get_pins mux/s] 长一路？

qq94043

fangwang85 发表于 2020-12-15 13:46
你好，你的意思是，先set_case_anaysis 0 [get_pins mux/s]  长一路，再set_case_anaysis 1 [get_pins mu ...

对的 这些mux 会有同一个source 来control的 ， 在source点设置case_analysis就可以了

fangwang85

qq94043 发表于 2020-12-16 14:38
对的 这些mux 会有同一个source 来control的 ， 在source点设置case_analysis就可以了
...

谢谢回复，我理解 如果这么长tree， 需要将长好的tree  freeze住，否则长scan的tree还是会动到func的tree

qq94043

fangwang85 发表于 2020-12-16 14:45
谢谢回复，我理解 如果这么长tree， 需要将长好的tree  freeze住，否则长scan的tree还是会动到func的tree ...

两个mode 的 constraint 同时吃啊  工具自动就长好了啊  没有说先长谁后长谁  scan的tree 长 就在mux前面balance呗  也不会影响func 的啊