简介Cadence Innovus 21.13用户指南是数字IC后端设计领域的重要参考文档面向从事布局布线、时序收敛和功耗优化的工程师。该资源为1个PDF文档压缩包大小约53.68MB内含完整版《Innovus User Guide》。指南系统介绍了物理自动布局、单元库管理、多电压区域划分、全局与详细布线、时钟树构造、时序分析及功耗优化等核心模块并针对21.13版本更新了先进工艺节点支持、设计流程改进以及用户界面与工作流优化等内容。通过阅读这些章节读者可掌握从工具配置到签核收敛的完整方法论也能在遇到电阻电容影响、信号串扰、时序违例等具体问题时快速查阅排错思路。已有6968人下载学习适合作为后端设计人员的案头参考也适用于希望系统学习Innovus最佳实践的初学者。1. 数字IC后端设计为什么还要翻一份21.13的Innovus用户指南如果你手头还留着从同事那里拷贝的 Innovus 旧版脚本我建议你先停一停。最近我在一个 7nm 后端收敛项目里翻车照搬一份基于旧版的 floorplan 脚本跑出来的 power stripe 方向完全不对浪费了一整天。回头看问题就是命令行为已经随版本改掉而我没查最新文档。这份 Innovus 用户指南 21.132022 年 2 月更新就是官方对命令、参数和边界条件最完整的交代。它不是教程而是数字IC后端设计流程的“行为词典”新人拿来建立流程认知熟手拿来排查参数边界。下面我按实际使用顺序拆一遍。2. 把输入关把严21.13 的 Data Preparation 与 init_design 实战我拆这份指南时最先看的是 Design Import and Export Capabilities 这一整章。原因很简单后端项目里大半的“玄学报错”最后都能追溯到输入数据不干净。LEF 顺序错了、SDC 里带了一条综合阶段才能用的约束、liberty 库的 PVT 和 MMMC 定义对不上这类问题不到 route 阶段不会被引爆等炸了就很难回头。2.1 Data Preparation 到底准备哪些东西指南的 Data Preparation 小节把输入文件分成几类technology file、physical library、timing library、timing constraints、capacitance table。每一类都有对应的准备命令和检查手段。Technology file 我从不让工具自动猜。LEF 里的 layer、via、spacing 定义如果和工艺真实规则不一致后续所有 DRC 都白做。Physical library 要区分 technology LEF 和 macro/cell LEF前者描述工艺层、via 和 design rule后者描述单元或宏的尺寸、pin 和 blockage。两个文件在 init_lef_file 里的顺序错了Innovus 会把 macro 的 pin 直接丢掉后面 CTS 和布线全是 floating pin。Timing library 重点看 liberty 文件是不是当前被测 corner 的 NLDM 或 CCS 模型。很多团队会把综合库直接拿给后端用但综合阶段的 wire load model 和时钟不确定性占用到了后端流程里就是束缚。Guide 里专门有一节强调 set_case_analysis 约束的处理意思是后端不能照单全收要按实现流程重新校准约束。下表是我每次建 flow 前必须核对的东西输入文件作用我踩过的坑tech LEF定义层、via、间距等工艺规则tech LEF 放 macro LEF 后面导致单元 pin 读取异常macro/cell LEF定义单元尺寸、pin、obstruction缺了 pin shape 或 blockageplace 后 overlap 一堆liberty 库提供 timing/power 模型PVT 角不一致CTS 前后的 skew 完全对不上SDC 约束定义时钟、IO、时序例外带着综合阶段的 set_clock_uncertainty优化被绑死cap table用于 RC 计算不生成则寄生参数不准route 后时序收敛难度翻倍2.2 init_design 流程一个能跑的样板21.13 推荐的数据导入入口仍然是 init_design。我一般会在顶层脚本里单独写一个 init.tcl把库和网表的相关全局变量全部集中管理# Innovus 21.13 init_design 示例 set init_mmmc_file data/top.mmmc set init_lef_file tech/tsmc7_tech.lef tech/tsmc7_macro.lef set init_pwr_net VDD set init_gnd_net VSS set init_verilog netlist/top.v set init_top_cell top set init_design_settop 0 init_design这里每个变量都有明确分工。init_mmmc_file 指向多模多角分析文件Innovus 会通过它知道有哪些 corner、哪些约束模式init_lef_file 必须把 tech LEF 放最前面后跟 macro LEFinit_pwr_net 和 init_gnd_net 用来指定电源地网络名避免后续 globalNetConnect 时到处找名字init_verilog 是门级网表init_top_cell 告诉工具顶层单元叫 top。MMMC 文件是整个流程的地基我一般写成这样create_library_set -name ss_lib \ -timing {./lib/ss_nom_lp.lib ./lib/ss_nom_wp.lib} create_constraint_mode -name func_mode \ -sdc_files {./sdc/top_func.sdc} create_delay_corner -name corner_setup \ -library_set ss_lib -constraint_mode func_mode create_rc_corner -name rc_ss \ -qrc_tech ./qrc/tsmc7_qrcTechFile create_analysis_view -name view_setup \ -delay_corner corner_setup -rc_corner rc_ss set_analysis_view -setup view_setup -hold view_setupcreate_library_set 把一个 corner 需要的 liberty 文件绑定在一起通常 setup 和 hold 会共用同一组 lib只是时序分析模式不同。create_constraint_mode 绑定 SDC一个模式可以对应多份 SDC比如 func_mode 和 scan_mode。create_delay_corner 再把这个 corner 的 lib 和 sdc 组合起来create_rc_corner 则负责寄生参数角。最后的 create_analysis_view 和 set_analysis_view 是告诉工具用哪个 view 做 setup、哪个做 hold。setup 和 hold 如果用同一个 view工具会按 common path 处理OCV 精度不够。2.3 导入后的前 10 分钟检查比跑流程重要init_design 跑完不等于数据干净。我每次都会在 log 里先看有没有 Error 和 Warninggrep -i -E error|warning|unconnected|violated innovus.log | head -80如果有大量 unconnected先看是不是电源地没连上。Innovus 的 log 很直接Error 会带命令名和文件路径Warning 会告诉你哪个 pin 找不到对应的 net。做完这步再跑一次完整设计检查checkDesign -all reportDesign reportNet -net VDD -verbosecheckDesign -all 是导入后必做的动作它会把 floating pin、overlapping instance、missing pg pin、broken hierarchy 全部报出来。reportDesign 看当前 design 的 instance 数量、面积、是否还有 blackbox。reportNet 则用来确认 VDD/VSS 是否已经连到所有 pg pin这一步能提前暴露 globalNetConnect 写漏的问题。2.4 导出时别忽略 map 文件流片前要把 Innovus database 转成 GDSII 或 OASISGuide 里单独有一节讲 GDSII Stream 或 OASIS map file。很多人直接 streamOut 不带 map结果 layer 编号对不上到 signoff 时才发现 metal 层全偏了。我现在的标准写法是streamOut top.gds -mapFile layer_map.map \ -merge {stdcell.gds io.gds} -units 1000 \ -mode ALL-layerMap 参数指定每个 GDS layer 和 Innovus 内部 layer 的映射-merge 可以把标准单元和 IO 的 GDS 合并进去-units 1000 表示输出精度-mode ALL 表示导出所有 layer。map 文件必须从工艺厂给的 reference 拿不能自己拍脑袋写。这一章的思路就是输入干干净净后面省掉一半排错时间。别想着 init_design 跑通了就直接 place先花十分钟做检查和报告值回票价。3. 从 Floorplan 到 PlacementDesign Planning 章节的正确用法floorplan 是整个实现流程里人工干预最多的一步。Innovus 21.13 指南把 Design Planning Capabilities 放在很靠前的位置里面有 Floorplanning、Power Planning、Bus Planning、Structured Data Paths 这几块。我自己的经验是floorplan 做得不扎实后面 CTS 和 route 的代价是几何级上升的。3.1 先定 Floorplan 参数utilization、die 尺寸和 pin 位置Floorplan 的第一个命令通常是 floorPlan。它决定 core 利用率、宽高比和四周留白。比如我想做一个 70% 利用率、宽高比接近 1 的布局floorPlan -r 0.7 0.7 20 20 20 20-r 后面第一个 0.7 是宽高比第二个 0.7 是 core utilization后面四个数字分别是 left、top、right、bottom 的留白距离。这个留白不是随便给的IO pin 多或者顶层要走 power ring 的区域留白就要加大。Guide 里提到的 Module Constraint Types、Grouping Instances、Running Relative Floorplanning 都是在手动摆 macro 时常用的功能。我的做法是先用 reportCongestion 或粗跑一遍全局布线看热点再把那几个拥塞区域附近的 memory 或 IP 用 move 或 relative floorplan 固定下来。21.13 里 floorplan 数据可以单独存方便不同版本之间回放saveFPlan top.fp loadFPlan top.fpfloorplan 阶段还要注意 row 类型。如果工艺里有 multiple-height row比如双高单元用于特殊驱动guide 里专门讲了 Using Multiple-height Rows。我没少在这上面吃亏默认 row 高度是单倍高但库里某些高驱动 buffer 是双倍高place 时会被当作 violation 或直接放不下。3.2 电源规划PG stripe 和 via 的规则要一次做对Power Planning and Routing 这一节是 21.13 指南里最值得细读的段落。很多人觉得 addRing、addStripe 随便填两个参数就行实际上 stripe 的宽度、间距、方向直接影响 IR drop 和绕线资源。我的典型电源网格如下globalNetConnect VDD -type pgpin -pin VDD -all globalNetConnect VSS -type pgpin -pin VSS -all addRing -nets {VDD VSS} -around core \ -layer {top M7 bottom M7 left M6 right M6} \ -width 1.2 -spacing 0.6 -offset 0.5 addStripe -nets {VDD VSS} -layer M7 \ -direction horizontal -width 0.8 -spacing 0.4 \ -set_to_set_distance 15globalNetConnect 先把 VDD/VSS 这个逻辑 net 和物理 pg pin 绑定否则后面 addRing、addStripe 看着好像画了 stripe实际网络根本没连上。addRing 用 M6/M7 绕 core 一圈宽度和 spacing 按电流需求定offset 决定 ring 离 core 边缘的距离。addStripe 是内部的电源条带set_to_set_distance 控制两条 stripe 的中心距这个值要结合 IR drop 目标和绕线资源来调。Guide 里还有一段专门讲 Generating Special Power Vias Using Viagen。stripe 和 standard cell row 之间要补 power via工具会按 rule 自动判断用哪种 cutclass。我一般会让工具自动生成 default special via但 via rule 必须从工艺文件里选对尤其 FinFET 工艺的 via 层次多很容易选到低层 via 导致 EM 问题。3.3 Place 之前的四类准备单元在正式 placeDesign 之前我会把 well tap 和 end cap 先加进去spare cell 按项目需要决定。顺序错了会很难看。示例脚本addWellTap -cell TAPCELL* -cellInterval 60 -prefix TAP addEndCap -cell ENDCAP* -prefix EC placeDesign checkPlacementaddWellTap 负责给每个 nwell/pwell 区域提供 body tiecellInterval 是每隔多少距离放一个 tap这个值必须小于工艺允许的最大 nwell 间距具体看 LEF 或 design rule。end cap 放在每行标准单元的端头防止 well 边缘的 OD 区域缺少层次。spare cell 我会单独加guide 里 Place Spare Cells and Spare Modules 一节有说明。spare cell 的密度会影响利用率所以我会在 place 之后、postRoute 之前决定要不要为 ECO 多留一部分。加了 spare cell 之后checkPlacement 是必做的它会报 overlap、row 越界、pg pin 没接等基础问题。3.4 跑完 Place 之后看什么placeDesign 跑完不能直接进 CTS。我通常先用 reportCongestion 看全局拥塞再看一下长线分布。如果某个 region 的 congestion 超过 1.2就要考虑加 blockage 或者把 macro 挪开。Guide 里 Check Placement 一节提到congestion estimate 可以在 place 阶段就打开这样很多问题不至于拖到 route。还有一点placement 阶段的 density 报告要看实际 cell area 占比而不是只看 core utilization。利用率和 density 不是一回事。如果有大量 hard macro空闲区域看起来很大但实际可布线的 channel 被 macro 的 blockage 占掉一大半。这时候加一组createPlaceBlockage -type hard -area把不该有标准单元的区域封起来比事后清 violation 管用得多。4. CTS 与布线收敛时钟树、NanoRoute 和 optDesign 的配合CTS 和 route 是后端流程里最考验流程编排的两步。Innovus 21.13 在时钟树这块默认走 CCOpt跟老版本用 clockDesign 的那套流程差别很大。如果还拿老脚本硬套skew 和 insertion delay 会完全失控。4.1 CTS 的起点时钟规范与 CCOptGuide 的 Clock Tree Synthesis 一章里Flow and Quick Start 是一个可以直接照抄的骨架先把时钟树 spec 准备好然后调 ccopt 的 property再执行 ccopt_design -cts。我的标准动作是# 21.13 推荐使用 CCOpt 流程 set_ccopt_property -target_latency_control normal set_ccopt_property -skew_group_method sdc ccopt_design -cts -outDir reports/cts optDesign -postCTS第一个 property 控制时钟树的 latency 优化力度normal 是默认bias 或者 aggressive 会导致 buffer 数量明显上升。skew_group_method 用 sdc表示按 SDC 中的时钟定义自动分组。ccopt_design -cts 把时钟树综合和优化一次跑完-outDir 指定输出报告位置。跑完之后马上接 optDesign -postCTS这个命令会在物理上修正 setup 和 hold同时避免破坏 CTS 已经建好的时钟树。如果设计里有多组异步时钟Guide 里的 Early Clock Flow 值得认真读。早期时钟流可以在 place 阶段就插入时钟 buffer让时钟 reach 时间先稳定下来而不是等 CTS 阶段一次性处理。这个流程对高频设计很重要但代价是 runtime 变长。4.2 routeDesign 和 NanoRoute 的参数组合NanoRoute 是 Innovus 的布线引擎21.13 里默认用 routeDesign 超级命令。我在布线前会固定下面这几个参数setNanoRouteMode -routeWithTimingDriven true setNanoRouteMode -routeWithSI true setNanoRouteMode -routeWithCrosstalkDriven true setNanoRouteMode -maxThreads 8 routeDesign -globalDetailrouteWithTimingDriven 表示布线时用时序驱动timing 差的路由会优先走更好层、更短路径。routeWithSI 开启信号完整性优化减少串扰routeWithCrosstalkDriven 让布线直接根据串扰风险调整线距。这三个都打开之后route 的 runtime 一定变长但后仿阶段的 SI violation 会少很多。routeDesign -globalDetail 是同时跑全局布线和详细布线。如果设计很大我会先跑一遍routeDesign -global看报告里的 overflow 和 congestion 再决定是否继续。全局布线阶段的 overflow 高于 0.5%基本说明 floorplan 还有问题硬跑详细布线只是在浪费时间。4.3 后布线优化与 SI 修复route 完成后时序大概率还有 violation。Guide 里 Optimizing Timing 这一块分得很细postCTS 优化、postRoute 优化、target-based postRoute 优化、PBA 模式优化。我习惯的节奏是# 后布线修 setup/hold optDesign -postRoute -setup optDesign -postRoute -hold # 再修 SI 问题 optDesign -postRoute -si # 加 filler 收尾 addFiller -cell FILLER* -prefix FILL -respectKeepOutoptDesign -postRoute 有好几个子模式-setup 和 -hold 分开跑更稳定-si 负责修 crosstalk delta delay。如果设计里有大量时钟门控或异步路径还要考虑用 Useful SkewGuide 在 Optimizing Timing Using Useful Skew 一节里有专门说明。Useful skew 的本质是不要把所有 clock sink 拉到同一个相位而是主动调整 skew 来帮助时序收敛。filler 单元要在所有优化结束之后再补因为 optDesign 可能插入新的 bufferfiller 放太早会被撑开形成一堆 overlap。addFiller 后面的 -respectKeepOut 是尊重 keepout region避免 filler 塞到 hard macro 附近。4.4 多线程和 license 管理Guide 里明确区分了 distributed processing、multi-threading 和 superthreading 三种加速模式。多线程只需一个 license分布式需要多个。我常用setMultiCpuUsage -localCpu 8 -noLicense 0这条命令让 Innovus 在本机用 8 个线程。注意 -noLicense 0 表示还是要去检查 license。如果 license 数量不够工具会在启动时直接报 error不会自动退化成单线程。所以我在大批量跑之前会先检查一下 license 池lmstat -a | grep -i innovusGuide 在 Multi-CPU Processing 一节还有提醒session 结束前要 release license。特别是多个项目共用 license 池时上次跑完没释放这次跑会白白等一两小时。5. 避坑指南21.13 版最容易翻车的五个后端实战问题参数和命令都能从指南里查到但真正让工程师崩溃的往往是“看起来正常结果全错”的隐性坑。这里我整理了五个自己或同事真实踩过的高频问题按现象到解决直接给你。5.1 问题一LEF 加载顺序不对macro pin 全丢现象是 init_design 正常完成但 place 时所有 memory 的 pin 都显示 floatingCTS 阶段时钟根本进不到 macro 内部。原因是 init_lef_file 里第一个文件放成了 macro LEFtech LEF 放在后面Innovus 读入单元布局信息时缺少 layer 定义pin shape 无法解析。解决方法是把 init_lef_file 顺序固定为 tech LEF 在前、macro/cell LEF 在后并检查 init_design log 里每个文件是否成功 loading。如果 macro 很多我还会在 init 后跑checkDesign -all这一步会把“missing pin shape”这类问题直接暴露出来。5.2 问题二core utilization 很低但布线溢出爆炸现象是 floorplan 报告利用率只有 55%看起来非常宽松结果 routeDesign 之后 overflow 到 2% 以上DRC 一大堆。原因是只看 core utilization没看实际可布线通道。我用了一个带大量 5nm 工艺硬核的模块macro 边缘有大量 blockage标准单元只能挤在几个窄通道里。利用率的分子被 macro 的面积占了分母却还是整个 core。解决方法是 place 前先在 GUI 里把 macro 周围加createPlaceBlockage然后跑reportCongestion -place看预估溢出。如果溢出集中在某些 channel就把附近的 macro 再拉开一点或者调整 floorplan 的行方向。Guide 里的 Checking the Floorplan 一节也建议用checkFloorplan -verbose提前看 net 跨 region 的分布。5.3 问题三CTS skew 报告没问题但 hold 修不完现象是 CTS 跑完报告里的 global skew 只有几十 ps看起来非常健康但optDesign -postRoute -hold反复插 bufferviolation 数量就是降不下去。原因是 skew 报告只看 clock sink 之间的差值没考虑 on-chip variation 和同一时钟路径上的 common path pessimism。尤其在 FinFET 工艺下不同电压域的 derate 差异很大只看 nominal skew 会误导。解决方法是打开 OCV 分析模式并给 hold 分析加上合适的 clock uncertainty。常用命令如下setAnalysisMode -analysisType onChipVariation set_clock_uncertainty -hold 0.05 [get_clocks clk]同时 Guide 在 Distributed Timing Analysis for Hold Fixing 一节提到可以把 tcl 脚本拆成多组 hold 路径并行修减少优化时间。从那以后我每次 CTS 后都会先看 setup/hold 分相角各自的 slack而不是只盯着 skew 数字。5.4 问题四多线程跑一半 license 被锁死现象是设了 setMultiCpuUsage -localCpu 8跑到一半突然停在某个优化步骤log 里出现 license feature missing 或者 timeout。原因是工具不是一开始把所有 license 全部占住而是在某些并行优化阶段动态 checkout。license 池里剩余数量不够就卡在那里等待看起来像死循环。解决方法是在跑长任务前先用 lmstat 看当前 license 余量然后给 Innovus 限定一个保守的线程数。另一个技巧是使用 Guide 里提到的 license check-out order 控制让工具先 checkout 便宜的 feature再 checkout 贵的物理实现 license避免一个任务吃光所有关键 feature。5.5 问题五Metal fill 把时序和 density 双重搞坏现象是布线后 DRC 通过、时序收敛但一跑金属填充M5 层上的关键路径 delay 涨了 10%同时 density 还超标。原因是 fill 单元是盲目填充的没有设置 minimum density 以外的上限。尤其在高频信号线密集的层metal fill 会改变寄生电容导致 crosstalk 增大。解决方法是按 Guide 里 Recommendations for Adding Timing-Aware Metal Fill 和 Trimming Metal Fill 的说明先开启 timing-aware fill再对关键路径所在层设置较低密度上限。示例参数setMetalFill -layer {M5 M6 M7} \ -density 20 40 -width 0.5 -spacing 0.8 addMetalFill -mode preferred verifyMetalDensity这里的 20 40 表示最低 20%、最高 40%。跑完之后用 verifyMetalDensity 检查整片 wafer 密度分布如果 M5 超过上限我会单独对该层再 trim 一轮。关键路径附近宁可密度低一点也不能让 delay 崩掉。6. 把这份文档当流程地图层次化设计与签核总结的进阶路径21.13 文档后半部分的 Hierarchical Flow Capabilities 是大多数人没耐心读、但非常值钱的部分。当设计跑到几亿门级别扁平化流程根本跑不动。这时就要考虑 partition、timing budgeting 和 Interface Logic Model。我的做法是先在顶层把关键模块设为 partition然后用 timing budgeting 把顶层时钟约束拆到每个子模块。这样每个 block 负责人可以在自己的环境里独立收敛不需要等顶层完整数据库。Guide 里的 Is My Design Ready for Budgeting 一节提供了一套检查清单包括 floorplan 是否完成、黑盒数量是否可控、接口约束是否干净。我每次都会逐条过一遍避免拆了 partition 后顶层约束互相打架。ILM 是另一个实用技巧。子模块收敛后生成 ILM顶层只读 ILM 接口既能保证时序一致性又不用把整个 block 的物理细节带上。虽然生成 ILM 的命令在不同项目里参数差异很大但 Guide 里的 Creating ILMs 给出了完整的文件清单和基本调用方法。第一次用的时候先拿一个小模块跑通生成和回读闭环再放大到全芯片能少踩很多坑。Machine Learning Flow 那节更像是一个预告Innovus 会把布局、CTS 的一些默认策略改成基于训练模型的推荐参数。我在新项目里尝试开了相关性测试发现它对工具版本和设计类型敏感不能盲目相信。更稳妥的方法是把它输出的推荐参数和手工调参结果对比再决定是否采用。最后建议一件具体的事大项目跑完后统一用平台的report_qor -summary输出关键指标包括 timing、power、congestion、antenna 和 density。把它和 checkDesign、verifyMetalDensity 的报告放在同一个目录归档成一份设计质量摘要。这个习惯帮我省掉了大量“翻旧版本数据找根因”的时间。从那以后我每次接手新版本或新工艺都强制把对应版本的 user guide 目录和新增功能章节全部过一遍再开始搭 flow。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 14:25:42 · 阅读 1.2k Innovus 21.13用户指南实战：数字IC后端设计避坑要点
简介Cadence Innovus 21.13用户指南是数字IC后端设计领域的重要参考文档面向从事布局布线、时序收敛和功耗优化的工程师。该资源为1个PDF文档压缩包大小约53.68MB内含完整版《Innovus User Guide》。指南系统介绍了物理自动布局、单元库管理、多电压区域划分、全局与详细布线、时钟树构造、时序分析及功耗优化等核心模块并针对21.13版本更新了先进工艺节点支持、设计流程改进以及用户界面与工作流优化等内容。通过阅读这些章节读者可掌握从工具配置到签核收敛的完整方法论也能在遇到电阻电容影响、信号串扰、时序违例等具体问题时快速查阅排错思路。已有6968人下载学习适合作为后端设计人员的案头参考也适用于希望系统学习Innovus最佳实践的初学者。1. 数字IC后端设计为什么还要翻一份21.13的Innovus用户指南如果你手头还留着从同事那里拷贝的 Innovus 旧版脚本我建议你先停一停。最近我在一个 7nm 后端收敛项目里翻车照搬一份基于旧版的 floorplan 脚本跑出来的 power stripe 方向完全不对浪费了一整天。回头看问题就是命令行为已经随版本改掉而我没查最新文档。这份 Innovus 用户指南 21.132022 年 2 月更新就是官方对命令、参数和边界条件最完整的交代。它不是教程而是数字IC后端设计流程的“行为词典”新人拿来建立流程认知熟手拿来排查参数边界。下面我按实际使用顺序拆一遍。2. 把输入关把严21.13 的 Data Preparation 与 init_design 实战我拆这份指南时最先看的是 Design Import and Export Capabilities 这一整章。原因很简单后端项目里大半的“玄学报错”最后都能追溯到输入数据不干净。LEF 顺序错了、SDC 里带了一条综合阶段才能用的约束、liberty 库的 PVT 和 MMMC 定义对不上这类问题不到 route 阶段不会被引爆等炸了就很难回头。2.1 Data Preparation 到底准备哪些东西指南的 Data Preparation 小节把输入文件分成几类technology file、physical library、timing library、timing constraints、capacitance table。每一类都有对应的准备命令和检查手段。Technology file 我从不让工具自动猜。LEF 里的 layer、via、spacing 定义如果和工艺真实规则不一致后续所有 DRC 都白做。Physical library 要区分 technology LEF 和 macro/cell LEF前者描述工艺层、via 和 design rule后者描述单元或宏的尺寸、pin 和 blockage。两个文件在 init_lef_file 里的顺序错了Innovus 会把 macro 的 pin 直接丢掉后面 CTS 和布线全是 floating pin。Timing library 重点看 liberty 文件是不是当前被测 corner 的 NLDM 或 CCS 模型。很多团队会把综合库直接拿给后端用但综合阶段的 wire load model 和时钟不确定性占用到了后端流程里就是束缚。Guide 里专门有一节强调 set_case_analysis 约束的处理意思是后端不能照单全收要按实现流程重新校准约束。下表是我每次建 flow 前必须核对的东西输入文件作用我踩过的坑tech LEF定义层、via、间距等工艺规则tech LEF 放 macro LEF 后面导致单元 pin 读取异常macro/cell LEF定义单元尺寸、pin、obstruction缺了 pin shape 或 blockageplace 后 overlap 一堆liberty 库提供 timing/power 模型PVT 角不一致CTS 前后的 skew 完全对不上SDC 约束定义时钟、IO、时序例外带着综合阶段的 set_clock_uncertainty优化被绑死cap table用于 RC 计算不生成则寄生参数不准route 后时序收敛难度翻倍2.2 init_design 流程一个能跑的样板21.13 推荐的数据导入入口仍然是 init_design。我一般会在顶层脚本里单独写一个 init.tcl把库和网表的相关全局变量全部集中管理# Innovus 21.13 init_design 示例 set init_mmmc_file data/top.mmmc set init_lef_file tech/tsmc7_tech.lef tech/tsmc7_macro.lef set init_pwr_net VDD set init_gnd_net VSS set init_verilog netlist/top.v set init_top_cell top set init_design_settop 0 init_design这里每个变量都有明确分工。init_mmmc_file 指向多模多角分析文件Innovus 会通过它知道有哪些 corner、哪些约束模式init_lef_file 必须把 tech LEF 放最前面后跟 macro LEFinit_pwr_net 和 init_gnd_net 用来指定电源地网络名避免后续 globalNetConnect 时到处找名字init_verilog 是门级网表init_top_cell 告诉工具顶层单元叫 top。MMMC 文件是整个流程的地基我一般写成这样create_library_set -name ss_lib \ -timing {./lib/ss_nom_lp.lib ./lib/ss_nom_wp.lib} create_constraint_mode -name func_mode \ -sdc_files {./sdc/top_func.sdc} create_delay_corner -name corner_setup \ -library_set ss_lib -constraint_mode func_mode create_rc_corner -name rc_ss \ -qrc_tech ./qrc/tsmc7_qrcTechFile create_analysis_view -name view_setup \ -delay_corner corner_setup -rc_corner rc_ss set_analysis_view -setup view_setup -hold view_setupcreate_library_set 把一个 corner 需要的 liberty 文件绑定在一起通常 setup 和 hold 会共用同一组 lib只是时序分析模式不同。create_constraint_mode 绑定 SDC一个模式可以对应多份 SDC比如 func_mode 和 scan_mode。create_delay_corner 再把这个 corner 的 lib 和 sdc 组合起来create_rc_corner 则负责寄生参数角。最后的 create_analysis_view 和 set_analysis_view 是告诉工具用哪个 view 做 setup、哪个做 hold。setup 和 hold 如果用同一个 view工具会按 common path 处理OCV 精度不够。2.3 导入后的前 10 分钟检查比跑流程重要init_design 跑完不等于数据干净。我每次都会在 log 里先看有没有 Error 和 Warninggrep -i -E error|warning|unconnected|violated innovus.log | head -80如果有大量 unconnected先看是不是电源地没连上。Innovus 的 log 很直接Error 会带命令名和文件路径Warning 会告诉你哪个 pin 找不到对应的 net。做完这步再跑一次完整设计检查checkDesign -all reportDesign reportNet -net VDD -verbosecheckDesign -all 是导入后必做的动作它会把 floating pin、overlapping instance、missing pg pin、broken hierarchy 全部报出来。reportDesign 看当前 design 的 instance 数量、面积、是否还有 blackbox。reportNet 则用来确认 VDD/VSS 是否已经连到所有 pg pin这一步能提前暴露 globalNetConnect 写漏的问题。2.4 导出时别忽略 map 文件流片前要把 Innovus database 转成 GDSII 或 OASISGuide 里单独有一节讲 GDSII Stream 或 OASIS map file。很多人直接 streamOut 不带 map结果 layer 编号对不上到 signoff 时才发现 metal 层全偏了。我现在的标准写法是streamOut top.gds -mapFile layer_map.map \ -merge {stdcell.gds io.gds} -units 1000 \ -mode ALL-layerMap 参数指定每个 GDS layer 和 Innovus 内部 layer 的映射-merge 可以把标准单元和 IO 的 GDS 合并进去-units 1000 表示输出精度-mode ALL 表示导出所有 layer。map 文件必须从工艺厂给的 reference 拿不能自己拍脑袋写。这一章的思路就是输入干干净净后面省掉一半排错时间。别想着 init_design 跑通了就直接 place先花十分钟做检查和报告值回票价。3. 从 Floorplan 到 PlacementDesign Planning 章节的正确用法floorplan 是整个实现流程里人工干预最多的一步。Innovus 21.13 指南把 Design Planning Capabilities 放在很靠前的位置里面有 Floorplanning、Power Planning、Bus Planning、Structured Data Paths 这几块。我自己的经验是floorplan 做得不扎实后面 CTS 和 route 的代价是几何级上升的。3.1 先定 Floorplan 参数utilization、die 尺寸和 pin 位置Floorplan 的第一个命令通常是 floorPlan。它决定 core 利用率、宽高比和四周留白。比如我想做一个 70% 利用率、宽高比接近 1 的布局floorPlan -r 0.7 0.7 20 20 20 20-r 后面第一个 0.7 是宽高比第二个 0.7 是 core utilization后面四个数字分别是 left、top、right、bottom 的留白距离。这个留白不是随便给的IO pin 多或者顶层要走 power ring 的区域留白就要加大。Guide 里提到的 Module Constraint Types、Grouping Instances、Running Relative Floorplanning 都是在手动摆 macro 时常用的功能。我的做法是先用 reportCongestion 或粗跑一遍全局布线看热点再把那几个拥塞区域附近的 memory 或 IP 用 move 或 relative floorplan 固定下来。21.13 里 floorplan 数据可以单独存方便不同版本之间回放saveFPlan top.fp loadFPlan top.fpfloorplan 阶段还要注意 row 类型。如果工艺里有 multiple-height row比如双高单元用于特殊驱动guide 里专门讲了 Using Multiple-height Rows。我没少在这上面吃亏默认 row 高度是单倍高但库里某些高驱动 buffer 是双倍高place 时会被当作 violation 或直接放不下。3.2 电源规划PG stripe 和 via 的规则要一次做对Power Planning and Routing 这一节是 21.13 指南里最值得细读的段落。很多人觉得 addRing、addStripe 随便填两个参数就行实际上 stripe 的宽度、间距、方向直接影响 IR drop 和绕线资源。我的典型电源网格如下globalNetConnect VDD -type pgpin -pin VDD -all globalNetConnect VSS -type pgpin -pin VSS -all addRing -nets {VDD VSS} -around core \ -layer {top M7 bottom M7 left M6 right M6} \ -width 1.2 -spacing 0.6 -offset 0.5 addStripe -nets {VDD VSS} -layer M7 \ -direction horizontal -width 0.8 -spacing 0.4 \ -set_to_set_distance 15globalNetConnect 先把 VDD/VSS 这个逻辑 net 和物理 pg pin 绑定否则后面 addRing、addStripe 看着好像画了 stripe实际网络根本没连上。addRing 用 M6/M7 绕 core 一圈宽度和 spacing 按电流需求定offset 决定 ring 离 core 边缘的距离。addStripe 是内部的电源条带set_to_set_distance 控制两条 stripe 的中心距这个值要结合 IR drop 目标和绕线资源来调。Guide 里还有一段专门讲 Generating Special Power Vias Using Viagen。stripe 和 standard cell row 之间要补 power via工具会按 rule 自动判断用哪种 cutclass。我一般会让工具自动生成 default special via但 via rule 必须从工艺文件里选对尤其 FinFET 工艺的 via 层次多很容易选到低层 via 导致 EM 问题。3.3 Place 之前的四类准备单元在正式 placeDesign 之前我会把 well tap 和 end cap 先加进去spare cell 按项目需要决定。顺序错了会很难看。示例脚本addWellTap -cell TAPCELL* -cellInterval 60 -prefix TAP addEndCap -cell ENDCAP* -prefix EC placeDesign checkPlacementaddWellTap 负责给每个 nwell/pwell 区域提供 body tiecellInterval 是每隔多少距离放一个 tap这个值必须小于工艺允许的最大 nwell 间距具体看 LEF 或 design rule。end cap 放在每行标准单元的端头防止 well 边缘的 OD 区域缺少层次。spare cell 我会单独加guide 里 Place Spare Cells and Spare Modules 一节有说明。spare cell 的密度会影响利用率所以我会在 place 之后、postRoute 之前决定要不要为 ECO 多留一部分。加了 spare cell 之后checkPlacement 是必做的它会报 overlap、row 越界、pg pin 没接等基础问题。3.4 跑完 Place 之后看什么placeDesign 跑完不能直接进 CTS。我通常先用 reportCongestion 看全局拥塞再看一下长线分布。如果某个 region 的 congestion 超过 1.2就要考虑加 blockage 或者把 macro 挪开。Guide 里 Check Placement 一节提到congestion estimate 可以在 place 阶段就打开这样很多问题不至于拖到 route。还有一点placement 阶段的 density 报告要看实际 cell area 占比而不是只看 core utilization。利用率和 density 不是一回事。如果有大量 hard macro空闲区域看起来很大但实际可布线的 channel 被 macro 的 blockage 占掉一大半。这时候加一组createPlaceBlockage -type hard -area把不该有标准单元的区域封起来比事后清 violation 管用得多。4. CTS 与布线收敛时钟树、NanoRoute 和 optDesign 的配合CTS 和 route 是后端流程里最考验流程编排的两步。Innovus 21.13 在时钟树这块默认走 CCOpt跟老版本用 clockDesign 的那套流程差别很大。如果还拿老脚本硬套skew 和 insertion delay 会完全失控。4.1 CTS 的起点时钟规范与 CCOptGuide 的 Clock Tree Synthesis 一章里Flow and Quick Start 是一个可以直接照抄的骨架先把时钟树 spec 准备好然后调 ccopt 的 property再执行 ccopt_design -cts。我的标准动作是# 21.13 推荐使用 CCOpt 流程 set_ccopt_property -target_latency_control normal set_ccopt_property -skew_group_method sdc ccopt_design -cts -outDir reports/cts optDesign -postCTS第一个 property 控制时钟树的 latency 优化力度normal 是默认bias 或者 aggressive 会导致 buffer 数量明显上升。skew_group_method 用 sdc表示按 SDC 中的时钟定义自动分组。ccopt_design -cts 把时钟树综合和优化一次跑完-outDir 指定输出报告位置。跑完之后马上接 optDesign -postCTS这个命令会在物理上修正 setup 和 hold同时避免破坏 CTS 已经建好的时钟树。如果设计里有多组异步时钟Guide 里的 Early Clock Flow 值得认真读。早期时钟流可以在 place 阶段就插入时钟 buffer让时钟 reach 时间先稳定下来而不是等 CTS 阶段一次性处理。这个流程对高频设计很重要但代价是 runtime 变长。4.2 routeDesign 和 NanoRoute 的参数组合NanoRoute 是 Innovus 的布线引擎21.13 里默认用 routeDesign 超级命令。我在布线前会固定下面这几个参数setNanoRouteMode -routeWithTimingDriven true setNanoRouteMode -routeWithSI true setNanoRouteMode -routeWithCrosstalkDriven true setNanoRouteMode -maxThreads 8 routeDesign -globalDetailrouteWithTimingDriven 表示布线时用时序驱动timing 差的路由会优先走更好层、更短路径。routeWithSI 开启信号完整性优化减少串扰routeWithCrosstalkDriven 让布线直接根据串扰风险调整线距。这三个都打开之后route 的 runtime 一定变长但后仿阶段的 SI violation 会少很多。routeDesign -globalDetail 是同时跑全局布线和详细布线。如果设计很大我会先跑一遍routeDesign -global看报告里的 overflow 和 congestion 再决定是否继续。全局布线阶段的 overflow 高于 0.5%基本说明 floorplan 还有问题硬跑详细布线只是在浪费时间。4.3 后布线优化与 SI 修复route 完成后时序大概率还有 violation。Guide 里 Optimizing Timing 这一块分得很细postCTS 优化、postRoute 优化、target-based postRoute 优化、PBA 模式优化。我习惯的节奏是# 后布线修 setup/hold optDesign -postRoute -setup optDesign -postRoute -hold # 再修 SI 问题 optDesign -postRoute -si # 加 filler 收尾 addFiller -cell FILLER* -prefix FILL -respectKeepOutoptDesign -postRoute 有好几个子模式-setup 和 -hold 分开跑更稳定-si 负责修 crosstalk delta delay。如果设计里有大量时钟门控或异步路径还要考虑用 Useful SkewGuide 在 Optimizing Timing Using Useful Skew 一节里有专门说明。Useful skew 的本质是不要把所有 clock sink 拉到同一个相位而是主动调整 skew 来帮助时序收敛。filler 单元要在所有优化结束之后再补因为 optDesign 可能插入新的 bufferfiller 放太早会被撑开形成一堆 overlap。addFiller 后面的 -respectKeepOut 是尊重 keepout region避免 filler 塞到 hard macro 附近。4.4 多线程和 license 管理Guide 里明确区分了 distributed processing、multi-threading 和 superthreading 三种加速模式。多线程只需一个 license分布式需要多个。我常用setMultiCpuUsage -localCpu 8 -noLicense 0这条命令让 Innovus 在本机用 8 个线程。注意 -noLicense 0 表示还是要去检查 license。如果 license 数量不够工具会在启动时直接报 error不会自动退化成单线程。所以我在大批量跑之前会先检查一下 license 池lmstat -a | grep -i innovusGuide 在 Multi-CPU Processing 一节还有提醒session 结束前要 release license。特别是多个项目共用 license 池时上次跑完没释放这次跑会白白等一两小时。5. 避坑指南21.13 版最容易翻车的五个后端实战问题参数和命令都能从指南里查到但真正让工程师崩溃的往往是“看起来正常结果全错”的隐性坑。这里我整理了五个自己或同事真实踩过的高频问题按现象到解决直接给你。5.1 问题一LEF 加载顺序不对macro pin 全丢现象是 init_design 正常完成但 place 时所有 memory 的 pin 都显示 floatingCTS 阶段时钟根本进不到 macro 内部。原因是 init_lef_file 里第一个文件放成了 macro LEFtech LEF 放在后面Innovus 读入单元布局信息时缺少 layer 定义pin shape 无法解析。解决方法是把 init_lef_file 顺序固定为 tech LEF 在前、macro/cell LEF 在后并检查 init_design log 里每个文件是否成功 loading。如果 macro 很多我还会在 init 后跑checkDesign -all这一步会把“missing pin shape”这类问题直接暴露出来。5.2 问题二core utilization 很低但布线溢出爆炸现象是 floorplan 报告利用率只有 55%看起来非常宽松结果 routeDesign 之后 overflow 到 2% 以上DRC 一大堆。原因是只看 core utilization没看实际可布线通道。我用了一个带大量 5nm 工艺硬核的模块macro 边缘有大量 blockage标准单元只能挤在几个窄通道里。利用率的分子被 macro 的面积占了分母却还是整个 core。解决方法是 place 前先在 GUI 里把 macro 周围加createPlaceBlockage然后跑reportCongestion -place看预估溢出。如果溢出集中在某些 channel就把附近的 macro 再拉开一点或者调整 floorplan 的行方向。Guide 里的 Checking the Floorplan 一节也建议用checkFloorplan -verbose提前看 net 跨 region 的分布。5.3 问题三CTS skew 报告没问题但 hold 修不完现象是 CTS 跑完报告里的 global skew 只有几十 ps看起来非常健康但optDesign -postRoute -hold反复插 bufferviolation 数量就是降不下去。原因是 skew 报告只看 clock sink 之间的差值没考虑 on-chip variation 和同一时钟路径上的 common path pessimism。尤其在 FinFET 工艺下不同电压域的 derate 差异很大只看 nominal skew 会误导。解决方法是打开 OCV 分析模式并给 hold 分析加上合适的 clock uncertainty。常用命令如下setAnalysisMode -analysisType onChipVariation set_clock_uncertainty -hold 0.05 [get_clocks clk]同时 Guide 在 Distributed Timing Analysis for Hold Fixing 一节提到可以把 tcl 脚本拆成多组 hold 路径并行修减少优化时间。从那以后我每次 CTS 后都会先看 setup/hold 分相角各自的 slack而不是只盯着 skew 数字。5.4 问题四多线程跑一半 license 被锁死现象是设了 setMultiCpuUsage -localCpu 8跑到一半突然停在某个优化步骤log 里出现 license feature missing 或者 timeout。原因是工具不是一开始把所有 license 全部占住而是在某些并行优化阶段动态 checkout。license 池里剩余数量不够就卡在那里等待看起来像死循环。解决方法是在跑长任务前先用 lmstat 看当前 license 余量然后给 Innovus 限定一个保守的线程数。另一个技巧是使用 Guide 里提到的 license check-out order 控制让工具先 checkout 便宜的 feature再 checkout 贵的物理实现 license避免一个任务吃光所有关键 feature。5.5 问题五Metal fill 把时序和 density 双重搞坏现象是布线后 DRC 通过、时序收敛但一跑金属填充M5 层上的关键路径 delay 涨了 10%同时 density 还超标。原因是 fill 单元是盲目填充的没有设置 minimum density 以外的上限。尤其在高频信号线密集的层metal fill 会改变寄生电容导致 crosstalk 增大。解决方法是按 Guide 里 Recommendations for Adding Timing-Aware Metal Fill 和 Trimming Metal Fill 的说明先开启 timing-aware fill再对关键路径所在层设置较低密度上限。示例参数setMetalFill -layer {M5 M6 M7} \ -density 20 40 -width 0.5 -spacing 0.8 addMetalFill -mode preferred verifyMetalDensity这里的 20 40 表示最低 20%、最高 40%。跑完之后用 verifyMetalDensity 检查整片 wafer 密度分布如果 M5 超过上限我会单独对该层再 trim 一轮。关键路径附近宁可密度低一点也不能让 delay 崩掉。6. 把这份文档当流程地图层次化设计与签核总结的进阶路径21.13 文档后半部分的 Hierarchical Flow Capabilities 是大多数人没耐心读、但非常值钱的部分。当设计跑到几亿门级别扁平化流程根本跑不动。这时就要考虑 partition、timing budgeting 和 Interface Logic Model。我的做法是先在顶层把关键模块设为 partition然后用 timing budgeting 把顶层时钟约束拆到每个子模块。这样每个 block 负责人可以在自己的环境里独立收敛不需要等顶层完整数据库。Guide 里的 Is My Design Ready for Budgeting 一节提供了一套检查清单包括 floorplan 是否完成、黑盒数量是否可控、接口约束是否干净。我每次都会逐条过一遍避免拆了 partition 后顶层约束互相打架。ILM 是另一个实用技巧。子模块收敛后生成 ILM顶层只读 ILM 接口既能保证时序一致性又不用把整个 block 的物理细节带上。虽然生成 ILM 的命令在不同项目里参数差异很大但 Guide 里的 Creating ILMs 给出了完整的文件清单和基本调用方法。第一次用的时候先拿一个小模块跑通生成和回读闭环再放大到全芯片能少踩很多坑。Machine Learning Flow 那节更像是一个预告Innovus 会把布局、CTS 的一些默认策略改成基于训练模型的推荐参数。我在新项目里尝试开了相关性测试发现它对工具版本和设计类型敏感不能盲目相信。更稳妥的方法是把它输出的推荐参数和手工调参结果对比再决定是否采用。最后建议一件具体的事大项目跑完后统一用平台的report_qor -summary输出关键指标包括 timing、power、congestion、antenna 和 density。把它和 checkDesign、verifyMetalDensity 的报告放在同一个目录归档成一份设计质量摘要。这个习惯帮我省掉了大量“翻旧版本数据找根因”的时间。从那以后我每次接手新版本或新工艺都强制把对应版本的 user guide 目录和新增功能章节全部过一遍再开始搭 flow。希望帮到你。本文还有配套的精品资源点击获取