EETOP 创芯网论坛 (原名：电子顶级开发网)

标题: 后端面试--每日一题（062） [打印本页]

作者: 陈涛 时间: 2011-8-12 11:38
标题: 后端面试--每日一题（062）
本帖最后由陈涛于 2011-8-12 13:41 编辑

The timing report is created in PT format. The design is 0.5um oldtechnology.
Question:
1) Is there clock tree built in the design?
2) what reasons cause the setup violation? How to manually fix them?

这是一个PT格式的时序报告，使用的是很老旧的工艺，（所以延迟都比较大，不过不影响下面的问题分析）
问题：
1）这个设计里面有时钟树吗？
2）什么原因造成的setup违反？如何手动解决问题？提示：有多个不同的原因

此帖在EDACN上面发表过，感觉是一个比较经典的后端时序分析的问题，留次存照

( , 下载次数: 185 )

作者: icfbicfb 时间: 2011-8-12 11:56
重贴以下，还行，没法看，

你哪里来这么多考核题目吗

作者: 陈涛 时间: 2011-8-12 11:58
被人考+考别人+上网找

作者: icfbicfb 时间: 2011-8-12 12:12
哈哈，我来回答下，

1） yes， clock tree built
2） large delay cells in the path , due to large cap/trans violations ,
please do opt to fix it ,

作者: 陈涛 时间: 2011-8-12 12:23
2) 哪个？什么原因造成的？应该如何解决？（不能笼统地说让tool自己去优化）

作者: tt99647 时间: 2011-8-12 12:46
求正解啊

作者: apacheda 时间: 2011-8-12 13:05
U12 跟U16这两个Cell处有问题，Net Delay太大，主要是因为Transition造成的，简单的说，只要是能修Transiiton的方法都能优化掉这条Path。

作者: tianxiong_14 时间: 2011-8-12 13:39
回复 4# icfbicfb

这个明显是ideal-clock 只是设置了latency . 你还需要学习。

作者: 陈涛 时间: 2011-8-12 13:39
本帖最后由陈涛于 2011-8-12 13:43 编辑

恭喜7楼找到了2处问题！（还少1个）

什么原因造成这两处的transition过大？从报告里面是可以分析出来的。

这里应该附加一个条件，找出原因并且手动修复，不得使用工具的opt功能

作者: 陈涛 时间: 2011-8-12 13:45

回复 icfbicfb

这个明显是ideal-clock 只是设置了latency . 你还需要学习。
tianxiong_14 发表于 2011-8-12 13:39

登录/注册后可看大图

icfbicfb 说的没错，只是不够具体。

还是你要多。。。

作者: apacheda 时间: 2011-8-12 14:05
回复 9# 陈涛
U7这个Cell的Fanout太大，我不确定U7用的Cell的Size是不是最大的，如果不是，这个Cell周边又有空地的话，可以做Size Up。
如果已经是最大的了，那么可以通过Split Net的方式，减小这个Cell的Fanout的，那么U12的TIming可以被优化点。
U16前面的那个Net应该是Detour了，否则不该有那么大的Cap。

所到第三个原因，我得想想这个Library Setup Time是不是偏大，不大确定啊，但是这个Flop的Setup Timing有点大，如果确定是这个值不合理，那么是到这个Flop的Clock Tree有点问题。Clock Tree没有Build起来，但是又采用porpagted clock.

作者: 陈涛 时间: 2011-8-12 14:16
U7和U16答案正确！找到问题的原因，解决的办法就有了。就算不能马上找到方法，至少也知道了方向。
当初在EDACN时，有个上海交大的同学，达到了这个程度。当时答对的没几个，几年的时间，平均水平明显地提高了！

第3点，你看的位置与真正的问题很接近，但不是setup过大。为什么说clock tree没有build起来？

作者: tianxiong_14 时间: 2011-8-12 14:17
回复 10# 陈涛

可能是时代不同吧，，，怎么clock tree没 generate 还用propagate跑 PT不懂在为啥那么做。我也就看到两处
一处是fanout 一个是线走太长还是别的引起的大的capacitance ，，这个clock skew应该有1ns的预估，，，，
加一加快修好了，，，，哈哈

作者: damonzhao 时间: 2011-8-12 14:18
1. clock tree exists.
2.U12/U17/U16 have too much delay,
we can insert buffer in net QA/n9/n12, or upsize U7/U15

作者: tianxiong_14 时间: 2011-8-12 14:21
回复 12# 陈涛

啥意思，，勾起我的兴趣了。。。。再瞧瞧。

作者: icfbicfb 时间: 2011-8-12 14:22
cap太大了，2个地方，

作者: yuyan1987 时间: 2011-8-12 14:24
我是新手，抛砖引玉。希望各位大哥指正。
1. QA net delay很大，由于fanout太大，导致transition问题。可以增强驱动cell或者插buffer；
2. U12 cell delay延迟大，可能是由于本身驱动能力不够，加上负载电容稍大，也可以增强U12驱动能力；
3. n12 net delay 很大，由于负载电容太大导致，可能是U16输入电容太大，因为U16本身的transition也很大，可以增强net的驱动cell或者在U16输入端插buffer。

作者: tianxiong_14 时间: 2011-8-12 14:24
回复 12# 陈涛

那个时代有OCV的概念么，，，我不明白clock上 skew有1ns ，，，

作者: apacheda 时间: 2011-8-12 14:40
回复 12# 陈涛
Launch FlipFlop的CLK Pin上没有Transition Time 为0 ，Clock Tree应该没有Build。

作者: amd2010 时间: 2011-8-12 14:45
1) 我认为这个clok tree应该是没有build的。两个理由：A. clk端得transition为0。 B. clock network delay刚好是整数，凑的太好了吧。发生这种情况可能是既设置了"set_clock_latency -source 5 | 4",又同时“set_propagated_clock”
2）violation的主要原因一个是QA的fanout太大，如果工具优化的话可以修下fanout和transition，手工修的话可以upsize U7。
另外就是n12de transition太大，也可以upsize U15，或者distance比较远的话在U15和U16之间插buffer。

作者: amd2010 时间: 2011-8-12 14:47
1) 我认为这个clok tree应该是没有build的。两个理由：A. clk端得transition为0。 B. clock network delay刚好是整数，凑的太好了吧。发生这种情况可能是既设置了"set_clock_latency -source 5 | 4",又同时“set_propagated_clock”
2）violation的主要原因一个是QA的fanout太大，如果工具优化的话可以修下fanout和transition，手工修的话可以upsize U7。
另外就是n12de transition太大，也可以upsize U15，或者distance比较远的话在U15和U16之间插buffer。

作者: 陈涛 时间: 2011-8-12 15:08
OK
第3个问题就在clock上，1.0的差到底是从哪里来的？

通过这道题，想告诉菜鸟们，发现时序违反后，应该如何入手，分析问题，找出原因

作者: amd2010 时间: 2011-8-12 15:46

OK
第3个问题就在clock上，1.0的差到底是从哪里来的？

通过这道题，想告诉菜鸟们，发现时序违反后，应该 ...
陈涛发表于 2011-8-12 15:08

登录/注册后可看大图

set_clock_latency 5 -source -late [get_clocks CLK]
set_clock_latency 4 -source -early [get_clocks CLK]

作者: apolo1969 时间: 2011-8-12 20:44
Como ayudar

作者: Andreatong 时间: 2011-8-13 21:41
CTS自然做了，
可以set_max_transition/优化传递时间，set_max_delay优化path,

作者: chibijia 时间: 2011-8-13 23:33
也来答答题。
1、U12这个cell的延时也很大，可以增大U7这个cell的驱动能力，以减小到达U7/Y端的transition。
2、n12和U16/B2这个pin之间的capacitance也太大了吧，估计是线电容太大了。看能否优化这个path上的delay。

作者: 1359784773 时间: 2011-8-16 14:22
回复 8# tianxiong_14

怎么看出这就是ideal clock呢？clock后面不是写着propagated么？望指教，谢谢。

作者: amd2010 时间: 2011-8-16 17:54
没做clock tree不代表就是ideal clock

作者: xyshadow 时间: 2011-8-16 22:18
回复 1# 陈涛

1) clock is propagated -> CTS done

2) large fan out at U7/Y, HFN buffer/create buffer tree

n12 long net leads to large cap, reroute or insert buffer on route
capture clock delay 1ns shorter then launch, optimize clock tree to delay the capture reg
large lib setup time, need to check .lib.

作者: chlor 时间: 2011-8-17 10:07
想看看这个CTS到底是做了还是没做啊，
1.0的差值是clock skew么

作者: abao123 时间: 2011-12-19 17:26
回复 21# amd2010
请问下版主从图上哪里可以看出有1.0的差距？？？

作者: abao123 时间: 2011-12-19 17:27
回复 22# 陈涛
请问下版主从图上哪里可以看出有1.0的差距？

作者: 牧月 时间: 2012-1-15 19:00
这道题收获太大了，谢谢楼主啊！
通过上面大家的分析，第三个原因是不是set_clock_latency -early 4 clk和set_clock_latency -late 5引起的啊！我这里没加-source因为报告中显示的是network delay。但是这个分析显然是CTS后的，所以是不是将这两句脚本删除就可以达到消除launch和capture間1单位skew的目的。
求牛人确认是否对

作者: sages 时间: 2012-6-30 20:30
这个skew怎么来的，还真不知道，如果是PT自己分析的话，那么正常的post timing verification应该是读入generated clock，这个时候记忆中按理说是显示的insertion delay。
可能确实如前面几楼的说的，在做PT分析时序的时候，
首先读入了generated clock，然后又set_clock_latency -early 4/-late 5，不知道由于这样，将前面一句读入generated clock的结果覆盖掉了。这个还有待验证，用PT试下就知道了。
还望斑竹解答一下

作者: Tonyhai 时间: 2012-6-30 20:54
1ns的差距应该是 clock tree 没有做平吧？？

作者: ikey 时间: 2013-4-9 11:27
U16 x-talk这么明显，为什么没人说呢？

作者: cheernixue 时间: 2013-4-9 17:01
set_clock_latency 5 -source -late [get_clocks CLK]
set_clock_latency 4 -source -early [get_clocks CLK]

因为是setup，所以launch时钟尽量往后推，clock nerwork delay是5，capture时钟尽量往前靠，所以clock network delay是4，这是为了让setup更加严格，这就是那1ns的由来，我认为。

作者: cheernixue 时间: 2013-4-9 17:08
当然如果时钟树没有做平衡，出现1ns的skew也是正常的

作者: kunfun2002 时间: 2013-4-10 17:40
我認為先把所有的CELL都size up到最大,看結果能優化到多少?並且看大的NET delay path是否有真正的繞遠路?有繞遠路的話很可能是routing congestion所造成的,解法可以調整floorplan或是power stripe讓出routing resource的空間,以便解決detour所造成的net delay過大的問題

作者: rlatnrud0310 时间: 2013-5-14 01:18
clock tree exists

作者: 39123811 时间: 2013-5-17 14:52
楼主能不能把参考答案也列出来下，要不后来看的人一点实际价值都没有。（等等，这题好像没有参考答案）

作者: 陈涛 时间: 2013-5-17 15:51
答案都在跟帖里面，对于有偏差或者缺少正确答案的帖子，我有补充。
读那些跟帖，了解别人的思路，再找出正确的答案，也是一个很好的学习机会。
应该比看完问题直接看答案有价值

作者: garfield1989 时间: 2013-6-8 16:24
版主，你好，我是刚刚学习encounter的小白，我想问：encounter中，在做cts和opt时clock是怎么确定的？我在做一个项目时遇到一个问题，net a （在sdc文件中没有定义它为clock，是按照正常output定义的约束）是一个outpin ，它在逻辑上是一个mux_2的输出，这个mux_2 的其中一个选择输入是clk（在sdc文件中已经定义为clock），在reportIgnoredNets 生成的报告中，将net a 定义成了clock net。thank you.

作者: scu_lin 时间: 2013-6-25 22:48
这个每日一题相当好，哈哈，多谢分享~~

作者: half_honey 时间: 2014-5-16 16:17
太有启发了~修timing去了

作者: half_honey 时间: 2014-5-17 10:53
回复 14# damonzhao

insert buffer in net ？试下来还是会增加时延，最后slack更大了..

作者: damonzhao 时间: 2014-5-19 09:07
回复 48# half_honey

修setup吧？如果减小delay，可以对驱动的buffer sizeup一下，这样cell本身的delay会减小，驱动能力增大了，对net上的延迟也有改善。net比较长的，可以insert buffer，但是buffer也别太小了，否则，cell delay增大的太多了，就会出现你说的情况。

作者: half_honey 时间: 2014-5-19 10:18
回复 49# damonzhao

这样...原来是插的太小了》。

作者: damonzhao 时间: 2014-5-19 10:49
回复 50# half_honey

作者: 钐钐 时间: 2015-6-24 13:25
顶一下吧，挺经典

作者: tonyhard 时间: 2019-10-21 13:52
经典题型，谢谢。

作者: lbt556653 时间: 2020-3-26 17:16
set_clock_latency 5 -source -late [get_clocks CLK]
set_clock_latency 4 -source -early [get_clocks CLK]
为什么要一起设呢？考虑OCV？

作者: lfzhang 时间: 2022-5-4 20:00
真好

作者: 15909834256 时间: 2025-3-14 13:52
fanout过大导致U12 Delay大，另外U16是不是因为驱动太小导致的啊

欢迎光临 EETOP 创芯网论坛 (原名：电子顶级开发网) (https://bbs.eetop.cn/)