最近被一个ICC2和StarRC的correlation问题折腾了两周。项目做到收敛阶段PR里面看时序已经干干净净结果换到签核环境里一跑setup violation一片一片往外冒。最夸张的时候两条工具针对同一个版图提出来的net delay偏差到8%以上这已经不是靠留margin能兜住的范围了。后来一步步排查发现根子不在STA脚本上也不在约束上而是ICC2内部提取出来的寄生参数和StarRC提取出来的寄生参数从一开始就没站在同一条线上。这篇文章就把我当时怎么把两边的RC提取结果一点点对齐的过程整理出来重点说清楚哪些参数、哪些设置会直接毁掉correlation以及定位问题的思路。无论你是刚接手先进工艺项目的后端工程师还是正在被“PR过了签核挂掉”折磨的做flow的同学这篇都值得看完。1. 先把问题定义清楚我们在聊的correlation到底是哪一层1.1 为什么PR的时序和签核时序天生就不是一回事要理解correlation为什么重要得先搞清楚一个基本事实ICC2在做布局布线、优化时序的时候用来评估延时的寄生参数来自它自己内置的RC提取引擎而签核阶段我们拿到的版图通常要交给StarRC重新做一次独立的寄生提取生成的SPEF再注回PrimeTime里做最终时序签核。这两条路径不是天然相等的。PR阶段为了能在合理时间内完成几百个instance的迭代优化ICC2的提取引擎会在保证精度的前提下做大量简化。比如把一段线的电阻分布简化掉、把via的电流路径合并一下、把短线干脆只留电容不算电阻。StarRC作为独立的签核级提取工具建模更完整对版图的几何细节、电流分布、coupling环境都算得更精细。同一个版图两套提取结果自然会有差异。差异在一定范围内没问题因为PR工具的优化本身会带一点自适应性。但如果差异大到ICC2认为某条路径有300ps的setup margin而StarRC提取后签核显示这条路径是负的150ps那问题就不是“加margin”能解决的了必须回到根上把两边的提取对齐。1.2 那次问题具体长什么样我当时在某个先进工艺的项目上最开始是在一个SS corner下发现total cap系统性偏了6%左右。这个偏差很有意思不是个别net的问题而是几乎所有net的cap都偏大。当时第一反应是ICC2里某个全局的工艺参数没设对但查了一圈发现ICC2用的qrc和StarRC里配的qrc其实不是同一个版本这就给后面所有对比埋了雷。更麻烦的是clock net。clock树的net通常又长又绕经过的via特别多StarRC算出来的clock net cap比ICC2高了15%。这个直接反映到clock skew上导致一组寄存器的hold margin全线告急。我后来单独统计过那段时间花在“解hold violation”上的时间有一大半其实是在替correlation的偏差买单。所以那次之后我养成一个习惯在做任何大规模时序修复之前先把PR内部提取和签核提取拉到一个平面上确认“同一个物理版图”在两边的RC视图基本一致再谈优化和收敛。2. 影响correlation的提取细节一个都不能漏2.1 工艺文件和qrcTechFile的“血统”问题ICC2和StarRC虽然通常是同一套工具链里的产品两者理论上有能力使用同一份工艺RC文件但实际项目中频繁出现两边用的不是同一份文件的情况。最常见的有三类一是ICC2里面用的是库自带的旧版qrcStarRC那边已经换成新版的qrcTechFile二是两边虽然文件名看着一样但一个从TLU转换过来一个是原始二进制的qrc单位或者精度已经不同三是mapping文件不一致导致layer号、金属厚度密度信息映射错位。这个东西听上去特别基础但就是特别容易出问题。我的经验是第一步必须先确认ICC2和StarRC使用的qrcTechFile完全同一个文件并且随附的layer mapping、TLU文件也都一一对应。不要听信“应该是一样的”“都是默认的”这种话直接把文件的md5拉出来比一遍最靠谱。另一个很容易被忽略的点是要对比correlation不能拿ICC2布线后但还没做金属填充的版图去和StarRC那边已经做完fill的版图比。版图本身都不一样提取结果当然不一样。后面具体说版图形态的问题。2.2 耦合电容与阈值参数耦合电容是total cap的大头之一。两个工具在提取时都有一个“耦合电容阈值门限”coupling threshold的概念用来决定哪些耦合关系值得建模。这个门限如果设得过高大片弱耦合电容会被忽略掉total cap明显偏小门限设得很低模型会越来越准但提取时间会成倍增长。问题在于ICC2和StarRC的默认门限并不是同一个值。我在项目里遇到过一次ICC2默认的耦合门限比StarRC默认值高不少导致ICC2眼里这根线周边的“环境电容”根本不参与计算而StarRC算得一丝不苟。结果就是两根线的coupling cap差异肉眼可见地大。解决方式也简单两边显式设置同一个值不要依赖默认。我当时统一设成了0.05代价是ICC2提取时间变长了一点但换来的是两边能对上。还有一类阈值叫short net threshold意思是判断哪些net属于“短线”。短线在PR提取里通常被简化为纯电容模型不算电阻。但StarRC即使对很短的线也会保留完整的电阻模型。如果ICC2把一堆短线都判成纯电容而StarRC还在老老实实算电阻那这些短线的transition和delay自然接不上。这个参数两边也必须对上而且要结合target library里单元本身的输入电容大小来选阈值不能机械套一个值。2.3 电阻拆分与Via建模电阻的差异往往是先进工艺下correlation差的最隐蔽来源。一根走线如果跨了好几层金属中间经过一堆via每个via的电阻会因为cut数量和电流分布不同而有很大变化。ICC2在某些默认设置下会对一段路径上的多个via做合并简化电阻算得偏乐观StarRC则会把via真实形状、cut数量和连接关系都算进去。时钟树的net尤其吃亏因为clock net通常长、via密集、跨层多。一次两次还好几十个via的电阻误差叠起来delay差异就非常可观了。后来我在ICC2里把via级别的详细电阻建模打开让它在优化时不要合并via信息clock net的correlation瞬间好了不少。电阻差异还有一个来源是线宽处理。制造过程中金属线实际宽度和设计宽度有偏差StarRC对线宽变化、线端缩短这类几何修正处理得更细。如果ICC2用的还是理想宽度模型长线的电阻自然偏向乐观。这个问题一般得靠工艺文件里的修正系数来平衡没法在提取命令层面彻底解决但起码要意识到它存在。2.4 版图形态与dummy fill的影响版图本身不一致是correlation差异里最冤的一种。很多团队的标准流程是PR做完之后先跑一遍金属填充生成带dummy的版图给签核提取做输入但ICC2内部在优化时序的时候用的是没有dummy的版图。dummy会改变金属线周围的环境尤其是上下左右都是dummy时单位长度电容会明显变大。一边看的是“没有邻居”的版图一边看的是“插满邻居”的版图total cap能对上才怪。处理办法是流程层面保证要么ICC2优化时也把dummy信息吃进去要么签核提取时和PR优化保持同一个阶段的版图。实际操作里更常见的是在PR阶段做提取对比时把两边的输入版图定格在同一版等correlation调好之后再让各自的signoff流程走各自的fill规则。另外一个容易被忽略的版图差异是poly和diffusion的缩短修正。部分工艺在签核提取时会做OD/PO的几何修正而ICC2优化时可能没有。这些修正对局部net的电阻影响很大特别是cells drive很近的小网络。如果发现correlation差异集中在某些标准单元附近的短net上大概率就是几何修正导致的。3. 实操让ICC2和StarRC用同一套规矩做提取3.1 先拉一张对齐检查表把环境钉死correlation问题最怕东一榔头西一棒子。我现在的习惯是开始任何对比之前先拉一张“对齐检查表”把每一项都落实到具体文件、具体数值而不是“看起来差不多”。对比项ICC2侧StarRC侧核对方式qrcTechFile同路径同文件同路径同文件比较文件md5TLU / mapping版本一致版本一致比对版本号和mapping内容提取温度显式设置显式设置对比日志coupling threshold统一数值统一数值对比日志short net threshold统一数值统一数值对比日志via电阻模型不合并按实际cut对比选项版图输入同一阶段同一阶段对比版图日期/档案corner定义min/max一致min/max一致对比corner表这张表看起来简单但真做起来会发现很多配置藏得特别深。比如ICC2里某个library自带的技术文件会覆盖你的全局设置StarRC那边corner文件里又把温度悄悄改掉了。不加检查就直接开跑提取后面所有对比都是在浪费时间。3.2 ICC2侧怎么设置提取参数ICC2里的提取和优化是绑定在一起的但很多correlation相关选项需要你显式去开。我这边的做法是这样在完成detail route之后重新对当前设计做一次正式提取然后把这个提取结果同时用于优化评估和SPEF写出# ICC2侧示例不同版本语法可能略有出入以实际版本手册为准 set_parasitic_parameters -extraction_temperature 25 extract_rc -coupling_threshold 0.05 extract_rc -short_net_threshold 30 extract_rc -via_resistance_mode detailed # 写出SPEF用于和StarRC结果对比 extract_rc -outfile ./icc2/icc2.spef -format spef这里面有几处容易踩坑。第一温度必须显式设不要依赖工艺库默认温度。温度和电阻的关系是线性的温度差个20度长线电阻能差出好几个百分点。第二-via_resistance_mode detailed这个选项一旦打开提取时间会涨但对时钟树这种via密集型网络非常值得。第三coupling_threshold和short_net_threshold这两个值要和StarRC完全一致我通常把它们统一写在一个公共环境文件里两边共用。如果你用的是更老的流程比如在route前就做extract那correlation大概率会更差。因为route之前的金属形状和最终route shape差别很大提取出来只是“估计值”。对比correlation一定要基于detail route完成后的最终版图。3.3 StarRC侧怎么设置提取参数StarRC单独提取时主题思路是把刚才那张对齐表里的所有条件都复制过来。我通常这样组织# StarRC侧示例具体命令以当前版本手册为准 set_parasitic_parameters -extraction_temperature 25 extract -coupling_threshold 0.05 extract -short_net_threshold 30 extract -via_resistance_mode full # 输出SPEF extract_model -format spef -output ./starrc/starrc.spefStarRC相对而言更接近“签核基准”所以我在实际项目中倾向于把StarRC的结果当作正确值把ICC2的结果往它那边靠。比如StarRC算出某个net的total cap是10fFICC2算出来只有8.5fF那优先怀疑ICC2那边有没有少算了耦合电容或者qrc版本是不是和StarRC不一致。另外一个容易忽略的细节是corner定义。StarRC可以一次用同一个输入版图分别提取出Cmax、Cmin、Rmax、Rmin这些不同的corner。ICC2内部在做时序优化时只能同时存在一个RC视角。如果你拿ICC2的SS corner去和StarRC的TT corner比那得出来的“correlation差”根本毫无意义。对比时必须保证两边都处于同一个工艺corner的同一个mode下。3.4 快速评估correlation的方法设置都对齐之后不能靠肉眼说“看起来差不多”要量化。我一般做三件事。第一件事把两份SPEF解析出来对同一组net统计total cap和total resistance。可以用一段简化脚本去解析SPEF格式里的D_NET段把每个net的C和R汇总起来。工程上不需要做一个完整的SPEF parser只统计关键字段就够了。# 简化思路分别读两份SPEF统计每个net的C和R # 这里只表示统计逻辑实际解析要看SPEF具体格式 def collect_spef(spef_file): data {} current_net None for line in open(spef_file): if line.startswith(*D_NET): parts line.split() current_net parts[1] data[current_net] {C: 0.0, R: 0.0} elif line.startswith(*CAP) and current_net: pass # 累加电容 elif line.startswith(*RES) and current_net: pass # 累加电阻 return data icc2_data collect_spef(./icc2/icc2.spef) starrc_data collect_spef(./starrc/starrc.spef) # 遍历求每个net的相对误差、平均误差、最大误差、R方等第二件事把两份SPEF分别注回PrimeTime针对同一组reg-to-reg路径做对比。比较path delay的均值、最大值、以及两者的线性关系。好的correlation画出来应该是一条贴近yx的直线斜率在0.95到1.05之间R方在0.95以上。如果斜率明显偏离1说明存在系统性偏差优先查温度和qrc如果R方很低说明偏差是散点式的优先查局部版图差异和via建模。第三件事做分层分类型的误差细分。把net按类型分成data、clock、reset按所在layer分成M1-M3、M4-M6、M7及以上分别统计误差。correlation差很少是均匀分布的绝大多数情况下都是某一类net在拖后腿。clock net差就重点查via高层金属net差就重点查线宽和filldata短net差就重点查short net threshold。这样定位问题会快很多。4. 当correlation还是不对怎么定位问题4.1 全局系统性偏差优先查环境和材料如果你统计完所有net发现几乎每个net的cap都偏差一个固定比例比如ICC2整体比StarRC偏小5%那基本不是某个局部设置的问题而是全局条件不一致。优先级最高的排查项是qrcTechFile。我上面说过文件不同、版本不同、单位不同都会导致全局偏差。其次是温度。电阻对温度敏感即便cap没怎么变R一旦整体偏差delay照样跑偏。再者是corner本身。有些工艺的min corner和max corner在RC上差异极大如果两边在跑不同corner下的提取那偏差会相当整齐地出现在所有net上。还有一个常见坑是单位。SPEF的单位和qrc里的单位必须一一对上。如果ICC2里cap的单位是ffStarRC写出来是pf而你统计脚本没换算就会看到10倍的系统性偏差。这种错误很蠢但真的很常见。4.2 局部点位偏差按layer拆开看系统性偏差排掉之后如果问题还剩下那就得按layer拆。我当时遇到过一种情况整体correlation在可接受范围内但M5这条层的cap误差特别大平均差了12%。单独看M5的走线形态才发现这条层上有大量的宽金属用作电源地轨Clock net在穿过这些宽轨旁边时两者之间的coupling关系特别复杂。StarRC对这种大块金属和信号线之间的fringe电容建模非常细致ICC2默认的简化模型则容易低估这些边缘电容。遇到这类问题需要单独提高ICC2在这类宽金属附近的提取精度。如果能通过调整coupling_threshold解决当然好解决不了就得和工艺库支持确认一下ICC2对该层是否开启了更精细的场求解模型。局部偏差另一个常见来源是slot和cut。有些层为了缓解应力会引入slot形状这些slot边缘的电容贡献很微妙。如果某条net恰好跨过多个slot区域StarRC会精确计算每个slot边沿的电容ICC2如果当成完整金属平板来处理误差就会被放大。这种个案就没有特别好的统一解法要么接受局部net的偏差并在PR阶段额外留margin要么把这类特殊形状在提取时用更细的模式单独跑。4.3 时钟网络要单独给一把尺子时钟树是correlation重灾区原因前面提过net长、via多、跨层频繁、扇出大。在定位时钟网络相关问题时我一般会额外做一次“clock-only”对比。方法不复杂把clock net单独过滤出来对比每个clock net的total cap、total resistance以及到每个clock pin的delay。如果clock net的correlation明显比data net差最先怀疑via建模。接着看跨层次数一份clock net从根部到末端可能换了七八层金属中间几十个via。每个via稍微差一点点累计起来就是几个百分点的delay误差。另外clock缓冲器的输入电容也是一个不能忽视的点。如果ICC2和StarRC在标准单元模型上的视角一致那这个差异不会出现但现实是ICC2内部优化时可能用了library里某个简化过的电容视图而StarRC计算的是实际pin cap加net cap的总和。这种偏差虽然源头在库视角不纯粹是RC提取问题但最终表现出来的同样是correlation差。4.4 常见问题速查表最后把我在几个项目里实际踩过的坑汇总成一张速查表方便你遇到问题时快速对照。现象可能原因建议动作所有net的cap系统性偏大或偏小qrc/TLU版本不一致或单位不一致比对文件md5核对SPEF单位长线电阻整体偏高温度设置不一致两边显式指定同一温度短线transition和delay偏差明显short_net_threshold不一致统一threshold并确认短线的电阻模型clock net偏差大于data netvia被合并简化ICC2打开详细via电阻建模局部layer偏差集中宽金属、slot、填充dummy影响单独检查该层net形状与dummy分布PR显示完全干净签核大量violation耦合门限差异累积导致统一coupling_threshold并量化对比cap对得上但delay对不上corner定义或OCV设置不一致检查corner和derate脚本这张表的价值不在于每一条多高深而是给你一个排查顺序先环境、再阈值、再版图形态、再特殊net。顺序反了容易在单个net上死磕很久最后发现只是温度差了20度。说回那个项目。那次对齐之后ICC2和StarRC在关键net上的delay偏差从8%压到了2%以内signoff和PR的时序图终于能叠在一起看了。那次给我最深的一个体会是correlation问题很少只有一个原因它更像一层层小偏差叠起来的结果。你每对齐一个参数偏差就小一点一直对到可接受范围为止。最后分享一个小技巧。现在我在每个block跑完ICC2之后不会急着进入全面签核而是先写出一份SPEF再单独用StarRC快速提取同一版图只抽100条代表性net做快速对比。这100条net里包括最长的clock net、最密的data局部区域、跨层最多的线、以及靠近电源地轨的敏感信号。全部对上了再往下走对不上就回到这张速查表逐项排查。这套办法帮我省掉的返工时间远比多跑一次StarRC要值。