后端面试--每日一题（062）

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上面发表过，感觉是一个比较经典的后端时序分析的问题，留次存照

重贴以下，还行，没法看，
你哪里来这么多考核题目吗

被人考+考别人+上网找

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

2) 哪个?什么原因造成的?应该如何解决?（不能笼统地说让tool自己去优化）

求正解啊

U12 跟U16这两个Cell处有问题，Net Delay太大，主要是因为Transition造成的，简单的说，只要是能修Transiiton的方法都能优化掉这条Path。

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

恭喜7楼找到了2处问题！（还少1个）
什么原因造成这两处的transition过大?从报告里面是可以分析出来的。
这里应该附加一个条件，找出原因并且手动修复，不得使用工具的opt功能

icfbicfb 说的没错，只是不够具体。
还是你要多。

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.

U7和U16答案正确！找到问题的原因，解决的办法就有了。就算不能马上找到方法，至少也知道了方向。
当初在EDACN时，有个上海交大的同学，达到了这个程度。当时答对的没几个，几年的时间，平均水平明显地提高了！
第3点，你看的位置与真正的问题很接近，但不是setup过大。为什么说clock tree没有build起来?

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

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

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

cap太大了，2个地方，

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

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

Launch FlipFlop的CLK Pin上没有Transition Time 为0 ，Clock Tree应该没有Build。

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。

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。

OK
第3个问题就在clock上，1.0的差到底是从哪里来的?
通过这道题，想告诉菜鸟们，发现时序违反后，应该如何入手，分析问题，找出原因

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

Como ayudar

看来现在都是大牛了啊

CTS自然做了，
可以set_max_transition/优化传递时间，set_max_delay优化path,

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

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

没做clock tree不代表就是ideal clock

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.