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

apacheda

回复 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.

陈涛

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

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

tianxiong_14

回复 10# 陈涛


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

damonzhao

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

回复 12# 陈涛


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

icfbicfb

cap太大了，2个地方，

yuyan1987

我是新手，抛砖引玉。希望各位大哥指正。
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

回复 12# 陈涛


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

apacheda

回复 12# 陈涛
Launch FlipFlop的CLK Pin上没有Transition Time 为0 ，Clock Tree应该没有Build。

amd2010

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。