Max Transition违反的修复方法

Posted 2023-05-12

参考技术A 数字IC设计中max_cap和max_tran这类逻辑DRC或者说时序DRC是在设计中必须修复的问题，到最后版图完成，这些问题都是要clean的。他们的分析与优化贯穿前后端设计中。下面按照从前到后的流程逐一讲解每个阶段如果出现max_tran违反该如何解决。下面用到的命令，主要针对的是Synopsys公司的综合工具DC以及布局布线工具ICC。

如果设计中报告存在max transision的违反，首先看一下最大违反是多少，违反的路径多不多，然后去分析出现违反的原因。

这种问题出现的原因无非三种：

1、扇出太大；

2、连线太长；

3、驱动强度太弱；

对于第一种情况，如果出现违反的net很多，那么很有可能是由于高扇出网络很多导致的，可以在sdc时序约束文件中将max_fanout的值设置的小一些，加紧约束；

对于第二种情况，可以采用手工ECO或者用PT进行ECO。对于长连线net可以增大前级的驱动能力，但是最常用的应该是在net中间插入buffer了。

对于第三种情况，同样可以采用手工ECO或者用PT进行ECO。可以增大net前一级cell的驱动能力，即用size_cell命令修复。

如果设计中存在一些非常小的违反，也可以采用工具自带的一些命令去让软件自动进行优化，以此减少设计者的工作量。下面依次讲解数字IC设计前后端中一些修复max_transition的命令。

1、逻辑综合阶段：同样，和修复Max Cap一样可以用compile_ultra来修复：compile_ultra -only_design_rule，如果是dont_touch的net，可以忽略。

2、布局之后，CTS之前：

2.1 命令让软件自动修复psynopt -only_design_rule

2.2 如果是高扇出引起的，那么可以在布局之前将max_fanout的值设置的小一些；如果高扇出的问题只发生在某个集中的地方，那么可以手动调整它的扇出。

2.3 加紧约束，set_max_transition xxx [current_design]，这个值可以比库里面的值稍微小10%（约束更紧一些），同时留一定的裕量。

3、CTS阶段

如果CTS之后发现在时钟网络的dont_touch net上存在max_transition的违反，那么可以将CTS阶段时钟树的fanout设置的小一些，例如：

>set_clock_tree_options -target_skew 0 -max_fanout 30

Max_cap问题如果出现在这些net上，也可以用这种方法修复。

还有一种是在CTS的时候让软件去修复逻辑DRC违反，不过这种方法会特别耗时，不建议使用：

>set_clock_tree_options-advanced_drc_fixing true

>setcts_enable_drc_fixing_on_data true

4、CTS之后（PosCTS）：

>psynopt -only_design_rule

5、布线阶段

>route_opt -incremental -only_design_rule

6、chipfinish阶段

在这里，相比于上一步，只做了一下DFM的操作，如果这里存在max_transition的违反，那么应该也是极其少量的，可以简单的通过focal_opt即可修复，命令如下：

>focal_opt -drc_nets all -effort high

原文链接： 数字IC前后端设计中的时序收敛（五）--Max Transition违反的修复方法 - Horizon00 - 博客园 (cnblogs.com)

如何修复drv?

参考技术A 前面两周介绍了如何修复setup和hold violation， 这次我们接着来讲下另外一个十分重要的violation—— drv 的修复。

首先，我们来了解下drv的基本概念，drv全称design rule violation，设计规则违反，主要包括max transition，max capacitance， max fanout, max length。 分别对pin的转换时间，电容，扇出，wire长度有要求。其中，max transition和capacitance的violation是我们必须要修复的，因为过大的slew和load都会造成lookup table查找表的数值较大且不精确。fanout和length并不是必须要修复的，但是数值过大的话，会影响前两者。接下来，我们来看看在ECO阶段时，如何来手动修复max transition和max capacitance。

首先来看max transition，通常我们也称为slew，可以看下概念介绍。

【时序分析基本概念介绍 】

有很多原因会造成slew的violation，但最主要的分为以下几类：

1）cell的驱动能力太弱

2）fanout数目过大

3）net长度太长

Cell驱动能力太弱

这是最常见的一类slew的violation，如果某个cell的驱动能力太弱，无法驱动下一级的cell，则比较容易产生比较大的delay。

如何来修呢? 也很简单，我们可以通过size up这个cell来提高驱动能力，比如X1的BUF换成X4, X8的等。

一般情况下，如果我们看到某个cell的output transition比input transition大很多，那说明这个cell的驱动不够，我们可以尝试size up一下。如下图所示：第一个X1的INV input transition是18.051，而输出transition是66.328。明显的是X1的INV推不动下面的14个fanout，可以考虑将X1的INV换成驱动更强的cell。

Fanout数目过大

这也是常见的一类容易造成slew violation的情况。过多的fanout会显著恶化pin的transition。

对于这种情况，我们可以通过插入buffer来减少fanout数目。如下图所示：

中间的output pin驱动了15个instance，分布在左右两边，如果该cell的驱动能力不强，整体的net长度又比较长的话，则比较容易引起max transition的violation。

对于这种情况，我们可以选择在该instance的右边插入一个buffer，由于buffer的驱动较强，所以让它来驱动右边的10几个instance，这样就能显著降低fanout的数目，修复max transition的violation。如下图所示：原来的instance的fanout由15个变成了4个。

这边推荐一个比较实用的小功能，在ECO窗口中，我们可以选择Listed terminals旁边的框框，然后在GUI界面上框住添加的buffer所需要驱动的cell的pin，工具就会自动会让buffer驱动这些pin，比我们通过命令抓取这些pin更简单快捷。

net长度太长

过长的net长度也会恶化slew，造成max transition的violation。如下图所示：

对于这种情况，我们可以在net的中间插入一个buffer来打断这根net，就可以解掉这个max transition的violation

max capacitance代表pin的load（负载）太大了，超过了约束或者library里面的设置，同样会造成timing数据的不准确。修复的方法和transition一样，对于输出pin上的max capacitance来说，一般是fanout数目过大，或者下一级net太长；对于输入pin上的max capacitance来说，一般是上一级cell的驱动不够，或者输入的net太长等等，基本情况和max transition一样，这边就不过多介绍了。

修复drv并不困难，我们首先要做的事搞清楚violation的出现的原因，对症下药，才能更好地解决问题。

原文网址：https://m.sohu.com/a/271677033_99933533