企业官网建设流程全解析

做后端的朋友应该都有过这种经历：ECO改了十几条net，觉得“也就几分钟的活”，结果回到StarRC重新抽寄生，一跑就是四五个小时。全量提取本身没毛病，但ECO场景下，整个芯片99.9%的布线和cell根本没动，你花了好几个小时让工具把没动的东西又算了一遍。StarRC的incremental ECO flow，就是专门解决这个问题的，核心开关就是ECO_MODE。

这篇文章不聊PPT式的流程介绍，我从一个实际改过flow的人的角度，把ECO_MODE怎么用、用的时候工具内部到底发生了什么、以及我踩过的坑，一次性说清楚。适合正在做数字后端物理验证、被ECO反复折磨的工程师，也适合刚接手StarRC flow、想搞清楚增量提取原理的朋友。

1. 为什么需要incremental ECO flow

1.1 ECO之后的全量重提，时间都花在哪了

先算一笔账。一颗500万实例规模的设计，跑一轮完整的StarRC全量寄生提取，多核并行的情况下，耗时普遍在5到10个小时这个量级。时间基本花在这几件事上：读入物理数据库、把每一根走线切分成段、对每个线段做pattern matching和场求解器计算、生成RC网格、最后reduction加写出SPEF。这里面最耗时的不是最后写文件，而是前面那些几何处理和RC求解。

ECO场景下你实际改了什么？功能ECO，可能只是替换了几十个标准单元；时序ECO，可能在关键路径上插了百来个buffer，再加一些metal patch。画个范围出来，撑死了占芯片面积的千分之几。为了这千分之几的区域，把全芯片再从头到尾算一遍，这账怎么算都不划算。

所以增量提取的思路很直接：上次已经算过的线网和cell，结果原封不动拿着用，这次只对发生变化的区域重新提取，最后把新旧结果拼成一份完整SPEF。听起来很简单，但实际做起来牵扯到几个关键点，后面会细说。

1.2 ECO_MODE到底改了什么：从“重新算”变成“只算变的部分”

ECO_MODE这个开关，本质上是在告诉StarRC：这次不是从零开始的full extraction，你手上有一份上一次的提取结果，按照增量模式来跑。

工具拿到ECO_MODE之后，做的事情可以拆成三步。第一步，对比ECO前后的网表和物理数据库，找出发生过变化的cell和net。第二步，针对这些变化的部分，算出需要重新提取的物理区域，说直白点就是一个或者几个bounding box，工具只会对落在box范围内的线网重新做完整提取流程。第三步，把新提取的结果和之前保存的旧结果做一个拼接，输出完整的SPEF文件。

这个思路放在生活里很好理解。你家装修，只改了一个卫生间，正常施工队不会把整栋楼的水电重做一遍。ECO_MODE就是告诉StarRC“这次只动卫生间的水电”，其他房间的管线图直接沿用之前画好的。关键是，你得让施工队知道“哪个是卫生间”，以及“之前的图纸在哪里”。

1.3 什么样的ECO适合开增量flow

这里要泼一盆冷水：不是所有ECO都适合开ECO_MODE。我见过有人把ECO_MODE当成银弹，结果增量提取跑完，SPEF和PR工具里对不上，排查半天，最后发现是改动范围太大，增量提取节省的时间全赔在Debug上了。

适合开增量flow的ECO类型，基本是这三类。

第一类，功能ECO。比如RTL freeze之后发现逻辑错了，需要换一个cell、改几根连线，这类改动通常局限在很小的逻辑锥里。

第二类，时序ECO。CTS之后插buffer、修hold、插decap、加shielding，这类改动区域局部性很强，而且ECO前后physical hierarchy没什么变化。

第三类，小范围metal patch。比如为了修EM/IR在局部加宽走线，或者对特定net做了reroute。

反过来，如果你这次ECO动了大范围走线，比如几乎把整层metal重新routing了一遍，或者电源地网络做了调整，又或者ECO之后的线网变化量占全芯片超过了百分之几的量级，那增量提取的优势就很有限了。我个人的经验阈值是，变化区域超过全芯片面积的2%到3%，就别折腾ECO_MODE了，直接全量跑反而省心。你省下的那点时间，不够应付增量模式带来的各种边界case。

2. ECO_MODE的原理与参数细节

2.1 ECO_MODE在StarRC配置里的位置

StarRC的抽取流程，通常是通过一个配置文件或者tcl脚本来控制的。你打开一个典型的StarRC配置，会看到NETLIST_FILE、DATABASE、EXTRACT_SOURCE、SPEF_FILE这些老面孔。ECO_MODE也是在这个层面生效的。

最朴素的用法，就是单独准备一份ECO专用的配置文件，在里面把ECO_MODE置为TRUE，然后配上几个增量模式特有的变量，比如旧数据库路径、变化网表路径、变化区域文件路径。工具跑的时候，看到ECO_MODE这个开关，就知道自己该走增量分支了。

需要提醒的是，StarRC不同版本之间，配置变量的叫法会有差异。有的版本叫ECO_MODE，有的版本把增量提取相关的开关分散在几个不同的选项里。我写过一句注释放在配置里：以当前版本的StarRC User Guide为准。这不算甩锅，不同工艺节点、不同版本工具，ECO flow的成熟度和变量命名确实不太一样，拿到一个新环境，第一件事去UG里搜一下ECO关键字，比直接套老flow靠谱得多。

2.2 增量提取时，工具内部到底做了什么

开ECO_MODE跑增量提取的时候，日志里最值得关注的信息是这几行：识别出多少条changed nets、多少个changed cells、提取的bbox坐标是什么、最终合并了多少段RC。看懂这些日志，你就知道工具在这一轮到底干了多少活。

第一步是变化识别。StarRC会把你指定的ECO前后数据库拿来比对，找出网表层面有变化的cell和net。这里的变化，不只是“多了个cell”或者“少了个cell”，还包括同一个cell的pin连接关系变了、同一个net的拓扑变了。如果你的flow里同时给了ECO_NET_LIST这种变化网表文件，工具也会用这个文件来辅助确认。

第二步是区域计算。工具会根据变化的cell和net，向外推一个提取范围。为什么要向外推？因为寄生提取不是只抽目标net自己，net和相邻net之间的耦合电容也得算。你改了一条net，它旁边的net虽然电器连接没变，但耦合电容变了，这些受影响的对象也要纳入重新提取范围。所以工具算出的bbox，通常比实际改动区域要外扩好几微米，正常现象。

第三步才是真正做提取。在这个bbox范围内，所有线网的几何处理、RC求解、reduction都是重新做的。范围外面的部分，直接复用之前的提取结果。最后，新老结果做一个merge。

有一种情况要特别留意：增量提取出来的RC，和新提取的几何，在边界处可能产生不连续。工具会做一致性处理，但你如果在后续分析里看到某条net的RC异常，先怀疑一下是不是增量提取边界处的拼接出了问题。

2.3 基线提取和ECO增量提取的输入输出对比

把两种模式的输入输出放在一起看，差别很直观。

我见过有些团队的flow，ECO增量提取跑完之后，输出的是只包含变化net的增量SPEF，然后回到PT里通过命令把增量SPEF和原始SPEF合并。也有人干脆让StarRC内部完成拼接，输出一份完整的更新版SPEF。这两种路径各有取舍。前者对PT侧的整合能力要求高一点，但对StarRC来说输出更轻量；后者对后端工程师最透明——你拿到的依然是完整的SPEF，签核流程和全量模式没有任何区别。

如果条件允许，我建议优先用“输出完整SPEF”的模式。原因很简单：增量SPEF的合并环节多一个步骤，就多一个出错点，而且出了问题往往不好定位。

3. 完整实操流程：从基线到ECO增量提取

3.1 阶段一：基线提取时多存一份家底

增量提取的前提，是有一份可靠的基线提取结果。很多人栽跟头，就是栽在基线侧没把东西存全。

基线提取跑完之后，至少要把这几样东西保留下来：StarRC生成的提取结果数据库或中间文件、完整的SPEF文件、这一版的网表、以及对应的物理数据库快照。有些flow里还习惯把StarRC的log一起归档，方便后面出问题的时候回溯。

这里有一个经常被忽视的细节：基线提取的结果，和ECO之后的物理数据库，必须来自同一条工艺路线。也就是说，你在基线侧用的是哪套工艺文件、哪套RC tech file，ECO增量侧也得用同一套。如果中间换了工艺角，或者更新了RC tech file，增量提取的结果是不可信的，这时候必须全量重跑。

我自己的习惯是，在基线提取的配置里，把输出结果的重名称做得规整一些，带上版本号。比如block_v12_base.spef、block_v12_base_database，后面ECO跑增量的时候，一眼就能看出该用哪份。

3.2 阶段二：ECO实现后，把变化信息整理清楚

ECO在PR工具里改完之后，EDA工具一般能帮你导出变化相关的文件。Innovus和ICC2里都有ECO相关的命令，能输出当前版和上一版之间变化的cell列表、net列表，以及变化区域的范围。

这部分是整个ECO_MODE流程里最看经验和耐心的地方。PR工具给你的变化信息，往往有冗余。比如ECO改动了20条net，但工具给的bbox可能覆盖了周边一大片。冗余倒没有安全性问题，只是增量提取的效率会打折扣。你需要做的，是人工确认一下这些变化信息的合理性。

我在实际项目里会干这么一件事：拿到ECO变化文件之后，不急着跑StarRC，先画一下变化cell的分布，看看是聚成一两片，还是散得满天飞。如果分布非常分散，增量提取的bbox算出来可能覆盖半个芯片，那增量flow就名存实亡了。碰到这种case，直接转全量，别犹豫。

3.3 阶段三：ECO_MODE增量提取的执行与检查

假设基线结果已经归档，ECO变化信息也准备好了，下面这段配置是我工程里常用的写法，变量名按你们版本的工具稍作调整就能用。

基线提取配置：

set NUM_CORE 16 set TMPDIR "/proj/xxx/tmp" set DATABASE "/proj/xxx/ndm/block_v12" set EXTRACT_SOURCE "NDM" set NETLIST_FILE "/proj/xxx/block_v12.v" set SPEF_FILE "/proj/xxx/block_v12_base.spef" set EXTRACT_AS_LUMPED 20

ECO增量提取配置：

set NUM_CORE 8 set ECO_MODE TRUE set DATABASE "/proj/xxx/ndm/block_v13" set OLD_DATABASE "/proj/xxx/ndm/block_v12" set ECO_NET_LIST "/proj/xxx/eco_v13.nets" set ECO_BOUNDS "/proj/xxx/eco_v13.bounds" set SPEF_FILE "/proj/xxx/block_v13_eco.spef"

跑起来之后，重点看日志里的这几处：

• changed net/cell的统计数量，和你在PR工具里看到的ECO规模是否对得上
• 实际提取的bbox范围，和预期改动区域是否吻合
• merge阶段有没有warning，尤其是提示某些net未能匹配到旧结果的情况
• 最终SPEF写出的时间戳和文件大小是否合理

增量提取跑完，我会顺手对比一下变化区域里那些net的RC数值。比如选几条改过的net，把增量SPEF里的总C值、总R值拿来和全量提取的结果做抽样比对。碰到数量级不对的，立刻停下来查，别等到PT里爆时序了再回头。

3.4 阶段四：结果验证与交接

增量提取的SPEF出来之后，常规做法是直接load进PT重新做时序分析。但我强烈建议在跑时序之前，先花几分钟做一次数据完整性检查。

检查的第一项，是SPEF里net的数量和网表对得上。第二项，是比较ECO前后那些没有改动的net，看看它们的RC数值有没有发生不该有的变化。如果说ECO_MODE正常工作，未变化net的RC值应该和基线SPEF基本一致。我曾遇到过一次增量SPEF里，有几十条没改过的net电容值明显异常，结果查下来是数据库版本不匹配导致工具错误地重复提取了部分区域。

确认无误之后，再把SPEF交给时序分析。输出的文件命名上，我会明确标注这是ECO增量提取的结果，同时把基线的SPEF留在归档目录里。这个习惯在后期做signoff审计的时候帮了我好几次，别人问起某个ECO版本的寄生参数是哪一轮生成的，翻文件名就能对上。

4. 常见问题与排查技巧实录

4.1 高频问题速查表

把我在项目里碰到过的问题按频率列个表，方便你对症下药。

4.2 实战里最容易踩的坑

坑一，基线结果被清理。增量提取最怕的就是“基线没了”。很多自动化流程会在ECO之前清理中间文件，结果把StarRC的提取结果数据库一并清掉了。单靠SPEF文件做不了增量提取，因为你丢失了RC片段的底层数据。我们后来在clean脚本里专门加了一行排除规则，保护归档目录下的基线提取结果。

坑二，误以为开了ECO_MODE就等于增量提取。ECO_MODE只是让工具进入增量模式，工具还是要靠你提供的变化信息来识别区域。如果变化文件没给对，工具要么识别不出任何变化，要么只能靠数据库全量对比来兜底，后者在大型设计上慢得跟全量提取没区别。

坑三，层次化设计里的增量提取边界问题。做block层次化抽取的时候，顶层ECO改了一个子模块内部的cell，如果增量flow没有把这个block内部的提取结果一起纳入重算范围，顶层SPEF和block自身SPEF在边界处就会对不上。处理这类问题的经验是：ECO牵涉到的模块，直接对该模块做完整重提，顶层走增量，两边拼接的时候核对端口。

坑四，增量提取后新cell缺RC模型。ECO里新加了一个stdcell，但增量模式的库里没有为这个cell准备好对应的提取模型，工具就会拿不到它的寄生参数。这问题不常见，但碰上会很隐蔽——SPEF文件能正常出来，就是这条net的RC值明显偏小。排查的方法就是去看log里有没有关于missing model的warning。

4.3 关于ECO_MODE的几点个人心得

第一，增量提取不是免费的午餐。它省的是计算时间，花的是管理成本。基线结果要管好、变化文件要理清、每次版本迭代的对应关系要记录，一套功夫下来，增量flow才跑得顺。如果你的项目几乎没有ECO，或者一年到头才改几次ECO，那老老实实全量提取可能反而是最优解。

第二，第一次用ECO_MODE的时候，强烈建议拿一个小block，同时跑一遍全量提取和增量提取，把两份SPEF的RC数值整体对比一次。这一步验证比看十遍文档都管用。我当年就是靠这个对比，确认了工具版本之间ECO_MODE的行为差异。

第三，和PR工具那边的ECO命令一定要串起来。增量flow跑得顺的团队，通常都把StarRC的ECO_MODE和PR工具里的ECO脚本封装在同一个flow里，PR改完自动导出变化文件，直接喂给StarRC。手动跑来跑去，中间太容易出错了。

说到底，ECO_MODE本身不复杂，复杂的是把它安放到一个可靠的整体流程里。我个人的习惯是，不管增量提取跑得多顺，归档里永远留一份最新的全量提取SPEF做对照。这个习惯看着笨，但帮我拦住了好几次增量提取边界处隐藏的RC偏差。ECO这件事，省时间是好事，省出问题来，代价可不止是几个小时。