CTS 不同mode 下的balance 问题
长完scan 后再长func会发现scan的skew飘掉,
比较长func之前和之后scan 下的相同clock path ，发现cell的位置和种类都没有变化，但是transition和delay 值有变化，而且是有些path变长，有些path 变短，所以导致skew 飘掉，不明白为什么transition 和delay值会变?
改变长tree 的顺序，还是有同样的问题存在
想不到原因是什么 ，希望高人来指点迷津 ，不胜感激
如果是同样的net和buf/inv（注意，不是其他组合逻辑单元），不同mode下，trans和delay都变化较大，你首先应该检查环境的设定
先顶陈大，我也觉得如果环境一样不应该出现不同mode不一样delay的情况。
另外，歪个楼，为什么先长scan?出于什么考虑?
是在同样的operating_condition 下长的tree，只是根据designer 的要求把不同模块的tree 分步长了，
原来也遇到过类似的问题，不过那时是因为先长的tree 的BUF/INV在长下一条tree时被动到了,这次我长好一条后有mark 住，而且位置是没有变
所以比较奇怪为什么skew会飘
我可能要试一下把两条tree 同时长看看，不知道会是什么样的结果
谢谢小编支持呵呵
是根据designer 的要求长的，在scan 下有一条主要的tree
环境应该是一样的，可能要再长长看
谢谢帮忙
请问小编，不长scan mode下的clocktree是否可行?
我们之前的处理都是只做func 下的CTS ，两种mode 一般都是mux。
每日一题（028）
我认为：不同Mode下，SDC 不同，TIming window的变化对Transition应该有影响啊，因此同样的tree 在不同的Mode下的Skew是不同的，具体飘多少应该是case_by_case的。
你比较两次的时候都是有routing吗?
或者都是没有routing的吗?
如果都有routing，比较两个wire有没有不同
如果都没有routing，从根部开始比较两者从哪里开始差。（比较RC）
如果一个有routing一个没有 那飘很正常啊
另外长的先后顺序也有点奇怪 颠倒了
ICC里面有个set_cts_scenario,
也就是设置成专门的 cts 情况的，
你可以写个单独的sdc 给这个scenario用，
谢谢大家支持原因已经找到 同时长的时候就没有这种问题
后来发现是在report_clock时没有设置operating_condition
在执行CTS后，如果需要再次report的话，需要重新读senario。这与CTS脚本中的读入senario方法不同。
特别是remove_sdc时，需要加入 -keep(***).具体记不清了。在ICC里按下Tab，会自动弹出来。
重新reports，最好把common文件重新读入。
这样报出来到的值，才与CTS自动执行后一致。否则差别很大.
麻烦问一下，同时长是怎么操作呢?将两个时钟文件合成一个读入吗?
对的 这两个时钟没有关系 所以同时长了