版图ECO的那点事（上）

      ECO是所有版图工程是都不能忽略的关键路径，一个良好的ECO流程、策略可以加速流片的时间，反过来，可能让整个团队在一周内没有产出。为了让小伙伴们可以从繁重的ECO流程里跳脱出来，基于笔者的设计经验，分三期给大家带来一个系列的文章：版图ECO的那点事，希望能引起大家的共鸣。      功能修改ECO的带入方式
      对于版图工程师，经常会碰到一些function ECO的需求，尤其是在冲击最终Tape-Out的关键时期，会有如下的一种境地（以时序修复的过程举例）
      
      从上图可以看到，为了保证数据库有优先级的收敛，最后的timing ECO会分为几个主要步骤
      功能模式的时序修复：function mode
      存储器自测模式的时序修复：mbist mode
      其他测试模式的时序修复：test mode
      芯片接口时序修复：IO mode
      功能模式的重要性、工作量和难度都是最大的，需要尽早地修复。然后是其他的模式，基本上是按照步骤和优先级完成整个芯片的时序修复的。
      通常我们统一把改变功能的ECO，称之为function ECO，但是实际上，这种ECO可能是针对真正的function mode的，也有可能是针对mbist 逻辑的，或者at-speed test mode的。
      由于function ECO会引起潜在的timing arc的变化，带入function ECO的时间点是有讲究的。一般来讲，只会在一种模式的timing 修复告一段落的时候，我们才会带入这个模式的function ECO。
      假如在时间节点Pre-B，前端准备好了一个比较大的function ECO，这个ECO是给mbist服务的。通常我们需要先验证这个脚本的正确性，如果脚本本身没问题，我们在这个Pre-B的时候并不带入，因为这个时候整个mbist的时序还不够稳定，
      
      等待到了Pre-C的节点，mbist 的时序修复基本完成的阶段，这时可以相当自信的使用增量方式代入这个ECO。理论上讲，新出来的timing violation都是由于这个脚本引起的。这里的timing violation通常有两种类型
      由于实现function ECO的时候，原先的cell被push，data上的timing变差：
      PS：APR工具一般不会去push clock path上的cell，clock的变差一般是应为re-route引起的。
      新加入的cell带来了新的timing arc：这些timing 需要重新核定和修复，由于已经进入到ECO阶段了，建议直接在PT里边进行核查就好。APR里边只需要关注physical就好。
    【敲黑板划重点】
      增量设计工作模式，是ECO阶段的重重之重，任何违背增量设计方案的举动，都会造成局部损耗，甚至团灭
      功能ECO的脚本生成的探究和技巧
      后端的同学一般会在最终layout的节点，给前端同学分享最终layout版本的网表，一般为了阅读方便，后端都是给前端同学一个不带PG信息的netlist。前端同学在完善数据库的过程中，同时也会对各种问题进行评估，最终给出解决方案：

• 软件改动
• 约束用户行为
• 硬件改动
  

      如果有任何需要在硬件方面做的功能修改，前端的同学会先保证RTL修改、验证完成后，对相应的final layout的网表进行修改。
      综上所述，一个function ECO的诞生无外乎下面的过程：
      
      前端主要是关注功能，后端主要是关注实现，对于下面的几个主题的关注度，这里展示一下：
[td]

主题	前端关注	后端关注
芯片功能	High	Low
电源	Low	High
ECO面积影响	Low	High
clock tree	Low	High
cross-hierarchy	Low	High

      前端的同学基于final layout的网表，改出来一版带function ECO的功能网表，基本就算大功告成了。
      通常在后端工具里边，工程师习惯使用脚本来处理一切，在ICC里边，一定要会使用下面的这个命令，这样才可以把前端工程师给入的netlist平滑过渡为脚本：
      
      通常来讲，直接使用这个命令会产生完整的ECO命令，如下例
      1.open_mw_cel -lib $MW_LIB $MW_CEL
      2.eco_netist -by_verilog_file $ECO_netlist -diff_only -output eco_change.tcl
      这个命令，并不会改变数据库的状态，因为我们使用了diff_only选项。运行过程如下：
      
      这些消息只是打印了一下设计的summary，并没有ECO改变的细节，这里我们一起看一下ECO的脚本的小结
      
      可以看到，这里的动作非常多，这难道是前端的期望？
      不要慌张，打开脚本一探究竟！一起来看一下ECO的脚本，eco_change.tcl
      
      在整个ECO的前面大半部分，主要都是tie connection的准备，这里以高亮的pin举例，操作如下：

• 断掉当前连接
• 移除当前连接对应的net
• 使用SNPS_LOGIC0 net连接高亮pin
  

      这么多的tie 连接肯定是和ECO没有关系的了，
  【敲黑板划重点】
      - Tie connection derived from synthesis
      如果在综合网表里边看到这个连接，那么它就是tie connection
      
      在ICC里边，就会相应的报告出来tie connection：
      
      由于我们的ECO后的netlist里边，上边两种情况并没有被ICC工具定性为tie connection，所以ICC需要使用额外的操作来完成对应的tie connection （其实是重复和冗余的，大家知道为什么了吧？）

• create_net -tie_low LOGIC_0
• create_net -tie_high LOGIC_1
• connect LOGIC_0 $CELL/TIE_LOW_PIN
• connect LOGIC_1 $CELL/TIE_HIGH_PIN
  

      - SYNOPSYS_UNCONNECT的处理
      如果在网表里边存在下面的连接声明
      
      为了数据库的完整性，ICC需要在所有没有连接的pin上去接一个SYNOPSYS_UNCONNECT的net，这种操作经常会出现在总线连接的情况下：一组总线，有部分的pin有连接，那么其他的pin就会连接到SYNOPSYS_UNCONNECT上了。这样会产生大量荣誉的重新连接的命令
      抓住细节，探寻本真， 合理使用命令和相关的变量，是高效合理完成工作的必要条件
      为了有效解决这两个问题，这里隆重介绍两位大侠，有了他们护法，上述的问题可以迎刃而解（前提是原始layout 网表里边没有leaf cell的floating input ）
      
      这两个变量在icc里边，默认都是false，在进行eco_netlist的时候，需要把他们设置成true（如上图）。
      1.变量一（eco_netlist_ignore_tie_changes）: 设置为true的时候，所有网表里边带来的tie connection，都被eco_netlist忽略，开一下这个选项打开时的ECO 命令的summary:
      
      和原始的ECO脚本相比，减少了很多connect_net的命令，create_net也减少了，最重要的是，create_net -tie 是没有的
      
      2.变量二（eco_netlist_preprocess_for_verilog）：这个变量可以忽略网表里边的SYNOPSYS_UNCONNECT，首先这些连接不会对数据库产生任何影响，但是如果需要ICC处理的话，他的方法也很简单，把连接SYNOPSYS_UNCONNECT的pin都会==再（append）==连接到一个新的net上，名字和这个pin一样，
      PS：这个做法真的有意义吗？需要问问ICC的开发人员了
      
      从上图可以看到，eco应用以后，多连了一个net，其实是没有任何用处的。
所以，在把第二个变量改成true，ECO脚本的真实面貌就呈现出来了，其实这个ECO真的很简单！
      
      本讲小结
      增量设计工作模式，是ECO阶段的重重之重，任何违背增量这几方案的举动，都会造成局部损耗，甚至团灭抓住细节，探寻本真， 合理使用命令和相关的变量，是高效合理完成工作的必要条件