clock tree 的 buffer 很绕很长，导致network delay很大

张馨然

前提：正常的长tree，其中，有一个master clock，沿着path后面定义了有10多个generated clock。

问题：有一些generated clock path特别的长，network delay最大的30ns，其中clock buffer 长得很不顺，上下左右来回的绕。

补充：看了一下上面出现问题的需要balance的ff，都比较近，不需要很多的buffer。

xingyun620

抛砖引玉：
什么工艺，transition是不是压的太低了？有没有dont touch之类的设定导致logical DRC violation？
你看到的buffer乱窜不一定是它们垫长的，可能是为了balance某一路垫delay而导致的，所以你要找到真正长得很长的那一路，看看问题是啥，其它的可能是被它拉长的。

张馨然

回复 2# xingyun620


    1.用的是华宏.11的。  2.transition不禁，data path 1 clock path 0.5 。
    3.找到了最长的一条path，想先往下做下去，就把最长path上面的ff/ck端  set_clock_balance_points -consider_for_balancing false ****  。又长了一遍tree，结果这条最长的path还在。正常是不应该存在的，因为不balance 上面的ff。

    不清楚原因，难道我要从place 阶段把他 set 上？

xingyun666666

回复 3# 张馨然

  找到原因了吗？

xingyun666666

回复 2# xingyun620

有没有dont touch之类的设定导致logical DRC violation？师哥的意思是：可能有dont touch之类的设定导致logical DRC violation，工具为了修这些DRC，就多插了一些Buf，使得tree变长了？

张馨然

回复 3# 张馨然


   1.查过没有在和他相关的cell pin net上 set dont touch ，看了这些buffer都是驱动很差的1x的，按道理如果为了修drc，不会是这种buffer。

   2.在build clock之前set_clock_balance_points，用report_clock_balance_points查看，确实已经把那些ck段认为是 except points。
      在build clock之后我发现还有那条path后，我有用report_clock_balance_points查看，没起到作用，把上述的except points依旧当成 balance points。不知道是否在route clock阶段except point 才起到作用，正在try

xingyun620

回复  xingyun620

有没有dont touch之类的设定导致logical DRC violation？师哥的意思是：可能有dont t ...
xingyun666666 发表于 2018-9-4 10:37

                               
登录/注册后可看大图

dont touch可能会导致transition不解，如果net很长，delay一下就上去了，tree也会变长。

xingyun620

回复 6# 张馨然

建议去log里看看cts各个stage的情况，比如build clock tree时insertion delay是多大，skew多大，有没有需要注意的warning。长完后看看tree上的DRC，fanout解了没，transition异常吗；
看看很长的那一路插得inverter名字，大概能知道tool是干什么的，是垫delay的？是解drc的？
有时候设置ignore pin并不会让那一路不长tree，他只是不考虑balance而已，比如那一路是某个ICG推出来，fanout有35个，它只是其中一路，这时候你设ignore也不会让这路变短的。

xingyun666666

回复 7# xingyun620


   dont touch一般都是前端给的SDC中会设置吧？后端有时候还会误操作设置了dont touch？！我好像没有过

shilldg

首先还是确认下generate clock有没有设置错误，其次看看是不是为了避开大的macro。