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的诞生无外乎下面的过程:
前端主要是关注功能,后端主要是关注实现,对于下面的几个主题的关注度,这里展示一下:
主题 | 前端关注 | 后端关注 |
---|---|---|
芯片功能 | High | Low |
电源 | Low | High |
ECO面积影响 | Low | High |
clock tree | Low | High |
cross-hierarchy | Low | High |
前端的同学基于final layout的网表,改出来一版带function ECO的功能网表,基本就算大功告成了。
通常在后端工具里边,工程师习惯使用脚本来处理一切,在ICC里边,一定要会使用下面的这个命令,这样才可以把前端工程师给入的netlist平滑过渡为脚本:
通常来讲,直接使用这个命令会产生完整的ECO命令,如下例
open_mw_cel -lib $MW_LIB $MW_CEL
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(如上图)。
- 变量一(eco_netlist_ignore_tie_changes): 设置为true的时候,所有网表里边带来的tie connection,都被eco_netlist忽略,开一下这个选项打开时的ECO 命令的summary:
和原始的ECO脚本相比,减少了很多connect_net的命令,create_net也减少了,最重要的是,create_net -tie 是没有的
- 变量二(eco_netlist_preprocess_for_verilog):这个变量可以忽略网表里边的SYNOPSYS_UNCONNECT,首先这些连接不会对数据库产生任何影响,但是如果需要ICC处理的话,他的方法也很简单,把连接SYNOPSYS_UNCONNECT的pin都会==再(append)==连接到一个新的net上,名字和这个pin一样,
PS:这个做法真的有意义吗?需要问问ICC的开发人员了
从上图可以看到,eco应用以后,多连了一个net,其实是没有任何用处的。
所以,在把第二个变量改成true,ECO脚本的真实面貌就呈现出来了,其实这个ECO真的很简单!
本讲小结
- 增量设计工作模式,是ECO阶段的重重之重,任何违背增量这几方案的举动,都会造成局部损耗,甚至团灭
- 抓住细节,探寻本真, 合理使用命令和相关的变量,是高效合理完成工作的必要条件
记住和贯彻这两个工作准则,一定会让同学们的工作成绩突飞猛进、技术能力大大提升。喜欢的话就点个赞吧!