笔者作为ICC/ICC2的深度用户（deep user），在过去的大部分时间都在把玩S家APR工具里的各种相关命令、配置和GUI操作种种。最近几年也有了机会使用了C家强大的ARP工具：innovus，感触颇多。人嘛，终归是感情的动物，一个新欢一个旧爱，怎么取舍，又怎么平衡，着实让笔者犯了难。不如写下浅薄的见解，让各位读者帮忙一起帮忙斟酌斟酌。（评论不周之处，还望S家/C家的金主们海涵~~）
ICC的概貌
S家ICC诞生于上世纪末的，在IC后端设计的历史上是战功显赫的一代名将！大家都知道，S家是在上世纪90年代末期，依靠着强大的综合工具（也就是后来的DC）发迹的。这里边有两个重要的提示
- 当时的设计规模逐渐增大，依赖人工综合的方式已经不能满足市场的需求，自动化逻辑综合的市场需求逐步增大
- 静态时序分析的理论也初见成效，综合器的mapping和optimization需要同步支持
这里的基础，可以奠定S家日后多年的业务根基，那就是timing（时序分析）。
与其说ICC（IC Compiler）是一个工具，不如说它是一套工具：ICC = Milkyway + PC（Physical Compiler）+ Astro
大家各有分工，有各自牵连
- milkyway：基于lef/gds/tf等信息创建物理库
- PC：专注于place和place\_opt
- Astro: 专注于CTS和route
对于用户而言，这些细节不可见也不必见，除过MW可能需要额外生成（如果库只提供LEF和GDS的时候，需要用户自己生成），其他的步骤都是可以连贯使用的。（PS：现在回望，其实MW-gen就是简单的提高壁垒，本质上并非完全必要的步骤）.
ICC的GUI操作也就正常发挥，据笔者了解整个GUI是拿C++写就的，但是有异常强大的命令行系统，这个给平平的GUI提供了非常好的支持，但是对于初学者有一点点不友好，前期的学习曲线比较平缓，在体味到工具的优势之前，用户需要一点点耐心。
话说回来，整个APR的流程里边，GUI的操作主要集中在FP，DRC，GUI分析几个典型步骤，主要还是依赖命令行。反过来看，拥有强大的命令行ICC，GUI更是锦上添花。
ICC的整体命令行系统的归类非常科学，其中也能看到作者的用心，命令命名系统的核心理论就是： 蛇形拼写法，有兴趣的同学可以莅临笔者的知识星球了解一下。
因为有了蛇形拼写法的支持，从命令结构上可以分为如下几类：
set\_*: 配置命令，譬如：
- set\_host\_option：配置主机选项
- set\_dont\_touch $OBJ: 对目标施加dont\_touch 属性
report\_*: 报告命令，譬如
- report\_timing: 对时序进行报告
- report\_qor: 生成数据库的质量报告
- report\_clock\_tree：对时钟树进行报告打印
all\_*: 以集合（collection）返回目标数据。通常用户也可以使用其他命令得到等价的结果，但是此类alias的用途，在构建脚本的时候非常方便，被广大BE-er广泛使用。
- all\_register: 返回数据库里的所有时序逻辑器件
- all\_fanin/fanout: 返回目标的扇入/扇出
- all\_clocks：获取数据库中的所有的clock
- man $CMD: 获取CMD命令的手册细节（manual）
- $CMD -h: 获取CMD命令的简短帮助
此外还有很多：create\_*，get\_*, check\_*, remove\_*等等，每个命令都有一些选项和依赖关系，需要大家逐步去学习，这一点，对于初学者而言，确实有点不容易。但是一旦掌握了一定数量的命令，后期做ARP就像用VIM，可以大大降低对鼠标的依赖，有效提升了工作效率。
由于ICC的设计思路和DC有很多类似，从时间上讲也是有前后关系的（现有DC），所以ICC里边的很多命令，都可以在DC中找到踪迹，对于传统的DC用户，ICC的上手也不会是零起步了。加之S家后面的Star-RC和PT工具，在鼎盛时期的S家可谓是R2G全流程的绝对霸主，仅就ICC的市占率顶峰时期就高达近80%，其统治地位可见一斑。
ICC的优缺点浅见
- 优点
1 - 命令接口强大，归类科学：命令行就是一切，所有的GUI操作基本都可以使用命令行来复现
2 - 命令返回类型高度统一：命令的返回的默认格式是集合（collection），使用内建的foreach\_in\_collection非常容易操作，由于是指针格式，效率很高。也提供collection\_to\_list这样的命令，便于习惯TCL用户用foreac对返回的列表进行遍历。
3 - 丰富的帮助系统：拥有man help apropos三员大将，相互扶持和支撑，更得益于丰富的帮助文本内容，基本一看就会，不太用问人。甚至包括信息机制（PREFIX-NUMBER类别，譬如：SEL-005），也可以使用man 寻求帮助
4 - 丰富的接口：输入输出的文件接口丰富，支持包括但不限于netlist/DDC/ILM/UPF/SDC/MW/DB/LEF/DEF/GDS/UPF/SPEF/OASIS etc.等文件格式
5 - 与DCT/DCG的结合：得益于S家自身强大的物理感知综合工具（DCT/DCG），ICC可以得到更好的物理和时序的correlation。（PS：这点笔者曾经尝试过DDC导入，进行ICC优化，但是效果并不明显，可能是笔者自身流程问题，这里先不做展开）
6 - 工具普及度高，可以比较容易找到社群帮助
7 - 工具历史悠久（25年~），健壮性很强
- 不足
1 - 运行时间（runtime）：由于MW和lib分属不同的数据体，ICC也是PC和Astro的聚合体，对于这种_混搭家庭_可以工作，但是不停的访问timing db会明显增加runtime，这点在大规模，先级工艺（<28nm），高PPA要求的场景下影响非常明显。
2 - QoR收敛度：ICC也采用了分布式计算的多线程方式进行运行，可以调动多个thread/core，runtime确实有所改善，但是不清楚是不是软件之间的distribution/sync问题，同样的数据库/输入，在连续多次提交出来的QoR差距比较明显，这点会对时序/物理敏感的模块不太友好，通常需要多个并行job来提高QoR，这种运算随机性有时候，会给用户带来一定的困扰。
3 - 工具崩溃：在相对复杂的设计环境中，ICC有时候容易出现crash的情形。这种情形通常不是工具的问题，而是设计的问题，FAE经常会推荐一些比较新的版本缓解这类问题。如果是运算溢出，那么应该在软件中设置overflow的溢出机制，直接crash会让问题难以定位，这里也是会让用户苦恼的地方，但是话又说回来，没有遇到crash的BE-er，那一定不是一个老BE-er了。
4 - 先进工艺的挑战；第一代ICC的开发的时候，工艺线宽的主流还是在um级别，但是从2015年开始FinFet的工艺逐渐崛起，IC工艺确确实实已经开启了新纪元。FinFet带来了两个挑战：巨大的timing lib和异常复杂的绕线/布局约束，这些都让ICC显得有点力不从心。这个时候也是ICC2登上历史舞台的时候了
ICC2的诞生
回望历史，T家在2013.11正式官宣第一代16nm FinFet工艺的风险量产，这也是世界上第一个拿到风险量产的晶圆代工厂（Intel的FinFet其实会稍早于，TSMC）。S家适时的在2014.3推出了面向FinFet工艺的ICC2的第一个版本。由于各种原因ICC2的第一炮并没有打响，用户报告的各种问题让S家应接不暇，这也成为了C家的Innovus顺势反扑的一个时间窗口，这些历史钩沉的往事这里先不做展开了。
无论你是不是ICC用户，ICC2看起来都是那么新鲜，除过了几个模块命令place\_opt, clock\_opt，route\_opt还能找到，但实际的内容和应用方式也已经和ICC完全不一样了。
上边对于ICC小结里的一些问题和现象，S家的开发人员一定比用户还要痛彻心扉，ICC2的转变一定是革命性的，否则要让一个上世纪末的工具来通过增量方式适应当下，这个代价和风险明显会高很多。长痛不如短痛，用户可能一下子不能适应，但是慢慢都会好起来，基础一定要改，否则根本问题不能解决。
ICC2的重要调整
- NDM横空出世：用户对于MW的诟病一定不是一天两天了。除过操作的不方便以外，各种命令和ICC的不一致，用户的可介入性比较差，MW也是纯物理的，和日渐巨大的timing lib 渐行渐远，NDM由此诞生
1 - NDM: New Design Model. 顾名思义就是要创建一个全新的数据结构的库类型，NDM可以分为带timing lib和physical lib两种模式，但是无论哪种，ICC2对于timing lib和physical lib的访问确实加快了很多。基于此的影响，同样的case，ICC2的run time通常是ICC的5~10X的提高。
2 - NDM依然要借助于lm（library manager）来产生，这个风格和ICC时代还是保持了一致
- 数据结构的改变：从之前的plain结构变成了面向对象（OOP）的结构方式。这样的好处对于数据归类管理会方便很多。譬如所有的对timing相关的变量和选项都是用time.（注意这里的点）做前缀，这样的好处对于用户查找和未来工具的扩展都会比较方便。对应的ICC2提供了：set\_app\_options和get\_app\_options两个命令来设置和报告app\_option.但是这个变化对于用户而言是一个双刃剑，譬如上边place\_opt命令，之前大家都是在命令后面直接加选项，就能跑，现在需要先设置app\_option，才能跑，对于ICC老用户的体验会比较差
- 对FinFet的支持更为强大
- 重构的place、CTS以及route引擎：据坊间传闻，ICC2的核心编写团队来自于之前的Magma团队，不知道各位能不能嗅到一种Talus的味道呢？
- GUI重构：
1 - clock debug 更为强大
2 - 和ICV/RH的紧密结合
- 数据收敛度和工具崩溃：这两点在ICC2都有了长足进步。
ICC2从各个方面讲，都是革命性和预言性的，在当时都应该是划时代的ICC当仁不让的接班人，S家对ICC2寄予厚望，希望把老大哥ICC的问题解决掉以后，顺势就把老大哥手里的市场份额也都承接过来，各居其位，各负其责，让APR的市场稳稳的握在自己的手上。
可是历史就是有这么一个个意外和惊喜构成的，无论S家怎么规划和补丁，都不得不感叹历史的车轮确实比他们的计划快了那么一丢丢，C家的INNOVUS横空出世，一炮而红，当仁不让的站在了时代的风口浪尖
横空出世的innovus
innovus的第一版发布于2014.12，目标市场也是FinFet，它的前身就是和ICC一直抢占市场的EDI（ICC基本占据了大部分市场，C家急需一个能打的产品来重夺市场份额），innovus临危受命，不但初战告捷，而且节节取胜，到目前为止先进工艺（FinFet）的市场里边，innovus已经占据了80%的份额，让C家回到了数字芯片后端设计老大的位置，innovus在这里确实功不可没！
innovus沿用了encouter的设计理念，并且通过一些调教，在runtime和QoR双双取得胜算，即是对前辈EDI的超越，也是对竞争对手的发起了挑战！
深而不漏的innovus
这里从一个ICC/ICC2的老用户的视角，分享一下对innovus的感觉
因为有相当长的ICC/ICC2经验，上手innovus并没感觉太多不适，过渡起来比较平滑，这里有以下一些部分需要高亮（感触）
- 对timing和physical库的处理：从EDI时代，C家对于timing和physical的库的处理就是比较开放的。timing直接调用的是明码的lib格式，这个通常也是FAB/vendor出具的最原始的格式；physical library也是直接调用的FAB/vendor出具的原始通用格式LEF（对于物理库，APR阶段其实不需要GDS，LEF就是从GDS里边抽取出来的边界和遮挡信息，就是为了简化而存在的）。C家在这两点上积累了成熟的经验。相较而言，S家固守的timing db 文件，也是从lib在lc（library-compiler）需要转存一遍，至于物理库的MW/NDM确实是增加了用户的额外工作量，所以从这点上来讲，C家在开源和通用上一贯做的很好，在大数据（FinFet）来临的时代，数据结构的增量性演变，一定是C家占据了优势（毕竟对lef/lib的直接应用经验积累了很多）
- 数据库初始化的策略（init）：S家的数据初始化，其实是一个flow，譬如：读取网表，UPF，设定MCMM配置，基本就算完成了，C家这里使用了一套setup+trigger的方式（这个和跑innovus的其他命令有点像，先配置再运行），好处是主命令比较短，譬如这里的init\_design，前边的配置需要小心，如果哪里配置的不对，也只有在init\_design运行的时候才能报出来，但是innovus的错误会回显提示做的非常生硬，一般就是直接说文件出错了，有时候连行号都报的不准（应该是没有准确定位到错误点，程序直接跑飞的状态退出了），用户在debug的时候会比较痛苦
- 优秀的floorplan的规划：innovus在对core、die和io三处的规划比较讨巧，首先他根据LEF里的CLASS类型，将IO类型直接单另出来，这个会严格限制IO的摆放区间就只能在IO ring 区域，但是对于flipchip的时候，又不是很好用，很多用户，会把LEF里的IO的CLASS直接变成BLOCK，这样就不会有这个问题，但是相应的，如果没有合理的IO-ring，innovus也没法给用户插入fillerIO，这里可能需要用户权衡利弊。其次，innovus对于halo的理解很优秀，这个其实就是就是S家的keepout margin（和hard placement blockage有相似性），但是C家应用的很彻底，无论是GUI显示，还是摆放，包括floorplan finish步骤的对core site的调整，都会被这个影响，个人用下来感觉很好用，因为他是基于design的，对memory/macro的周边布局非常友好；第三，对于std-cell site row的理解和应用也合理，innovus对于std-cell的摆放是一定要放到 site-row和cell-site上的，因为LEF里边这里都是定义死的，S家其实也可以这么处理，不在grid的调整和旋转完全是无意义的，这种也减少了用户犯错的几率
- 时序库的连接和timing update：不得不说S家的时序分析确实是强项，无论你在GUI里边做了移动cell的操作，或者在命令行里调用了任何对timing有调整的命令，ICC/ICC2都会做update\_timing，这点对于debug的时候会有浪费时间的嫌疑，C家的策略很聪明，使用了类似断点（interrupt）的方式来解决这个问题，首先你在GUI里边随便操作，timing 信息只要link过，就不会改变，除非用户手动timeDesign，其次如果是需要更改时序约束，用户需要使用命令set\_interactive\_constraint\_modes来提交一个断点保护，在这个里边进行对应的命令操作，然后退出断点，这里再使用report\_timing的时候，才会触发update timing，这个方式对于大数据量的先进工艺其实是很有优势的，用户不会频繁的更改，timing lib数据量过大，update timing的时间损耗会很明显，innovus的断点方式其实有点类似于轻告警（light-warning），用户需要斟酌后再操作。
- 时序分析：innovus为了独（免）树（遭）一（闲）帜（话），将STA分析里的各个名词（term）重新进行了定义，尽量凸显出自身的风采，这点对于熟悉S家时序分析的用户有所不便，需要再学习一下。本真的STA理论没有变化，只是名词的不同。但是初期看到时序分析报告中clock都是负值，有点不知所以然，看久了也才习惯过来，如果用户需要用tempus进行timing signoff，这套系统还是需要好好把玩一些的，如果还是PT，也不用太深究了。
- 时序报告：在innovus的reprot\_timing时序分析里边，第一反应使用argument/option来控制打印输出，最后发现自己草率了，一定需要set\_table\_style来配置，这个又回到第一个话题：先配置，再使用的方法学。笔者理解，对于report类的快速回显命令，这样做确实有点麻烦，也很难把此类命令dump成脚本，总是要搭配set\_table\_styley一起用，稍显啰嗦
- runtime和QoR：
1 - runtime：同样的输入，innovus还是可以快一些的，在powerplan的时候会比较明显，physical可一直都是C家的强项。
2 - QoR：工具很稳定，很少遇到crash的问题，整个数据库的稳定性和一致性非常好，即时采用了多线程多core运行，一致性非常稳定，这点体验对于ICC用户来说简直就是质的飞跃，不得不赞，赞不绝口啊！
命令系统：相较于熟悉ICC/ICC2命令格式的用户来讲，innovus的命令系统就是一个字：（此处省略这个字吧）。可见的命令有如下几类系统
单纯从命令数量上来看innovus远远超过ICC/ICC2，但是命名太分散，用户记忆和使用不是很方便，此外innovus的命令帮助系统相较S家还是有一些羸弱，这里确实需要进一步强化，还好C家有了一统江湖stylus（Common-UI），不但将工具内部的命令统一化，也将工具链上的命令统一化：geneus/innovus/quantas/tempus/voltus，大幅度降低用户学习的边际成本，提高了用户的粘度，由此可见C家一统天下的豪情壮志。
1 - dbGet=dbget ：大小写不敏感
2 - Put：大写开头，和TCL原生的put以示区分
3 - 小骆驼拼写法（这类应该是EDI原始的命令命名拼写法）：defIn
4 - 蛇形拼写法（能看到向S家靠拢的意味）：get\_cells
5 - 其他；
时至今日，innovus在FinFet以经牢牢占据著了主动权，加之和ARM的深度合作，在PPA的推演下一路高歌猛进，甚至也带动了整个C家的数字R2G的占有率，让C家转的盆满钵满。
工艺演进的车轮从未停止，无论是3nm FinFet或者GAA工艺，还是Intel开放FAB服务，或者国内FAB的先进工艺的精进，这个巨大的市场从来不缺玩家，无论是奋起直追的S家，抑或稍有起色的C家，甚至是未来的某个横空出世的第三极，只要有技术的驱动，就不会有人甘心落后，加之国内芯片业务的高速繁荣，笔者预测未来三年一定会有一个崭新的局面，各位ICer一起拭目以待吧！
作者：艾思后端设计
文章来源：艾思后端实现
推荐阅读
更多嵌入式AI干货请关注嵌入式AI专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
