Innovus和ICC2在先进工艺的下的表现本身已有定论，毕竟大部分公司已经用脚投票了。尽管如此，对于大部分没有从事过工艺和工具评估的同学来说，很难直接认识到它们在结果上的差距。最近终于有机会实现这样一件事，借此机会将大部分结果分享出来供大家参考。由于篇幅较长，本期只将二者的整体对比和在物理DRC方面的比较贴出，timing和详细的对比会在后续的文章中陆续发出来，敬请持续关注~
在对比过程中两个工具的流程都吸取了部分已有的经验，但是流程和脚本基本从零开始。不了解原因的option尽量不加，以便充分暴露更多问题，当然官方推荐的设置还是大部分加上了，否则可能会出现很多意外的问题。这是一项浩大的工程，从后端实现到signoff在一般公司中需要投入大量的时间去做，本人时间精力和水平有限，难以覆盖完全，有经验的同学欢迎指正并一起讨论。
前提
工具版本基本为最新或者次新，以便让比较更具实际意义，尤其是ICC2在新旧版本上的表现有较大差异，因此尽量使用最新版本。结果的验证工具使用StarRC+PT+Calibre，顺便验证了一下ICValidator。其中signoff条件采用或者部分采用silicon proved设置，如果引入QRC+Tempus则变量增多不利于实验和对比，同理也没有使用ecsm格式的时序库。主要工具版本如下：
Innovus与ICC2的体验对比
本次评估使用Innovus common UI，也就是stylus模式，该模式相对legacy UI更容易上手，各类设置有一定规律可循，get_db尤其好用，个人看来容易上瘾，遇事不决get_db多半没错。但也有些缺点：某些情况get_db不太直接，比如想要获取pg net连接的pin的时候，只能用get_db pins -if ".net.name==$nname"，速度较慢（可能有什么好的用法我没搞清楚）。部分set_db的option仍然说明不完善，以及attribute editor弹出速度慢。同时默认设置情况下source命令有-echo，log膨胀且难看等，不过都是些小问题，无伤大雅。
与此相比，ICC2整体命令行更成体系，不同设置和命令可以在man结果中看到一定相关性，整体有一定规律可循，新版本qor有一定提升，具体的差距还要等所有结果出来才好比较。但是默认设置下很多时候与StarRC+PT的correlation也不太好，需要使用StarRC-In-Design, ICV-In-Design Metal Fill, PT delay calculation等高级功能才能较好地匹配。电源绕线在边界比较容易出drc，少数base drc会有残留，需要额外添加规则。另外就是为什么cut metal需要手动加入，一直十分不理解这里的意义？
在输入数据的准备方面，Innovus优势比较明显，lef+liberty足够简单，不像ICC2需要db+lef/gds生成ndm。但是7nm下lvf的库体积很大，导致有时候read\_db速度比较慢，设置用multi thread模式有改善，但是ndm打开数据仍然更快一些。ecsm格式的库在体积上小很多，但为了避免引入过多变量，本次评估并未使用。
DRC结果对比
平心而论，两个工具剩下的DRC数量都不多，而且preroute相关的DRC数量较多，base DRC也有不同程度的剩余，都需要增加一些特定的设置才能比较好地收敛。主要出现的DRC可以分为以下几类：
a) boundary cell只能连接一个方向的rail/follow pin
b) sram的pin color在某些优化命令执行后改变
优化后的color改变会导致与之相连的VIA出现大量的color spacing，目前没有找到比较好的办法，最好是lef里面没有FIX MASK的设置，如果没有可以通过工具命令重置该cell的mask shift的值。
c) floating input pin引起的DRC(PO.R.19)
本问题是7nm常出现的DRC之一，常见的原因也就是floating 的input pin，少量原因就是绕线导致的open，数量较多的时候不太容易找到原因。
d) VIA0 enclouse问题，常出现在M1 power stripe（纵向）恰好落在row boundary附近
本问题在ICC2中看到较多，可能与tech file中的规则和signoff不匹配有关。
e) 偶数CPP规则，主要在调整boundary cell的边界时注意，尤其是sram较多的地方
主要用于决定sram等hard macro的相对位置，也正是因为这个规则导致7nm中的macro halo大概率不会完全一样，都会有或多或少的偏移，而且手动调整确实麻烦，建议写个脚本自动调整macro的位置和halo
f) TAP cell和ECO DECAP或者FILLER之间的OD spacing，该问题属于Innovus和ICC的已知问题，都可以通过swap tap的类型来解决，个人尝试ICC2 swap后相对干净一些。
replace_fillers_by_rules -replacement_rule od_tap_distance -tap_cells $tap_cells \
-right_violation_tap $right_tap -both_violation_tap $both_tap -left_violation_tap $left_tap \
-adjacent_non_od_cells $vio_cells_type -tap_distance_range {0.228 1000}
swap_well_taps -cells [get_db [get_db base_cells -if .base_name==*_TAP*] .name] -default_cell $default_tap \
-diffusion_forbidden_spacing 0.228 \
-violation_report swap_well_taps.violations.txt -swap_report swap_well_taps.swap.txtg) SRAM边界的VIA常出现enclosure问题
h) SRAM范围内的metal与via出现的area/spacing等问题(Innovus较多)
具体原因不详，貌似SRAM范围内的metal与core范围内需要满足不同的规则，但是tech lef中或者工具在绕线中并没有做这种区别。
i) macro spacing：没有详细研究具体需要多少，上下左右都5um没有出现问题
j) cut metal spacing CM1B.S.1，出现在Innovus中，可以通过特殊设置规避
该设置属于reference流程中的一部分。
set_db route_design_with_trim_metal "-layer 2 \
-mask2 {-pitch 0.24 -core_offset 0.095 -width 0.03 } \
-mask2 {-pitch 0.24 -core_offset 0.225 -width 0.03 } \
-mask1 {-pitch 0.24 -core_offset 0.015 -width 0.03 } \
-mask1 {-pitch 0.24 -core_offset 0.145 -width 0.03 }"k) ICC2写出的DEF读入Innovus中可能会有color问题，因为二者在处理color上的策略有些不同，可以在Innovus中通过update_power_vias更新multi-mask层的VIA来解决
以上就是两个工具在实现过程中主要出现的DRC汇总，数量不多的金属绕线DRC并没有一一列出。当然不同的设计，采用不同的IP都可可能出现更多问题，欢迎大家留言或者加群共同讨论~
来源：数字后端设计芯讲堂
作者：数字后端设计芯讲堂
推荐阅读
如果大家有任何后端技术与职业发展方面的问题，抑或关于数字后端感兴趣的技术话题想要了解和探讨，欢迎关注我的知乎专栏： 数字IC后端设计工程师修炼之路
同时欢迎关注微信公众号：数字后端芯讲堂，一起探讨技术，共同提升!
本极术专栏也会同步更新芯片设计后端的技术干货，也请关注数字IC后端设计工程师修炼之路。
