早上刚到工位隔壁同事就火急火燎地喊Innovus里的PR跑了一整夜到现在还没跑完日志停在placeDesign就不动了CPU也不高了这算不算卡死这问题我在数字后端项目里遇到过太多次了。今天就把innovus跑pr跑不下去这类情况的排查思路整理出来从现象判断、根因分析到应急恢复整理成一份能直接抄作业的排查手册给刚上手Innovus做物理实现的工程师做参考。不管你是刚把Innovus装好准备跑第一个案例还是已经在一颗复杂SoC上挣扎了很久这篇文章里的很多排查方法都能直接用上。1. 跑不下去到底长什么样先判断是真死还是假死很多人一看到工具卡住就慌了随手就kill -9结果丢了几个小时甚至一整天的结果。我在实际排障中有接近一半的情况其实是假死——工具没死只是干了一个需要很久的步骤还没有反馈。所以拿到跑不下去这个问题第一件事不是查代码、不是改配置而是先搞清楚它到底是活着但没动静还是已经彻底没救了。1.1 真死、假死的区分方法给你几个我一直在用的实操判断方法每一步都不需要额外装工具看CPU。在终端执行top -p pid如果Innovus进程的CPU稳定在比较高的水平比如100%以上说明它在计算大概率是假死如果CPU几乎为0但进程没退多半是锁死了或者正在等待外界资源。看日志增长。ls -l看innovus.log最后修改时间或者tail -5 innovus.log看内容是否在持续更新。日志还在涨说明工具还在干活。在交互shell里敲命令测试。如果你启动时带了交互界面敲一个help或者set a 1看有没有响应。有响应说明shell是活的只是当前stage没有输出。看系统级状态。vmstat 5连续看几轮重点看swpd列和si/so列。如果swap的换入换出持续很高说明内存和换页正在打架系统已经濒临瘫痪工具可能只是跑得极慢不是死掉。这里有一个我自己的血泪教训有一次placeDesign跑了三个多小时日志最后停在Starting global placement phase 2我等了两个小时实在没耐心直接kill -9。后来恢复snapshot重跑才发现其实再等40分钟就能过。从那以后我再也不急着kill而是先用上面的方法判断完再说。1.2 挂死、报错终止、死循环三种形态跑不下去至少可以分成三种形态处理方式完全不同挂死进程还在但不做任何事不写log。常见原因是等待license、等待集群上其它进程释放文件、线程死锁。这种需要用系统层面的手段排查比如看进程状态是不是D状态不可中断睡眠、有没有僵尸进程占着锁文件。报错终止日志里有明确的Error、Fatal、CRITICAL WARNING随后出现*EXIT*。这种其实最友好因为信息是明确给出的直接搜日志里的关键字就行。很多新手怕报错其实报错是工具在告诉你它发现了问题远比闷头卡死更值得庆幸。死循环/不收敛流程一直在跑CPU高log也在写但迭代指标不下降甚至上升。最常见的就是congestion overflow一直不降、optDesign的violation数量反复横跳。这种最麻烦需要结合具体阶段去判断。这三种形态放在一起看你会发现跑不下去其实不是一个单一问题而是一类问题。后面每一个根因我都尽量把对应的现象和处置方法放到一起说。2. 硬资源问题内存爆了、磁盘满了、线程打架这一层是我排查跑不下去时最先检查的不是因为它的技术含量高而是因为它的定位成本最低、出现频率极高。而且这一层的坑很多时候用系统命令一分钟就能确认。2.1 内存不足的典型征兆与判断方法Innovus是内存大户尤其在大规模的CTS和routeDesign阶段内存占用轻松超过几十GB。内存不足时轻则工具慢到像死机重则直接被系统OOM killer杀掉或者因为swap反复交换导致几乎停摆。判断内存问题的几个方法用free -g看总内存、已用内存和swap占用。如果swap used持续在涨说明物理内存已经顶不住了。用dmesg -T | grep -i oom看有没有Out of Memory的记录。如果有说明系统已经在杀进程了你的Innovus可能侥幸活着但已经被挤兑到极限。观察日志如果log精确地停在某个大数据量操作比如写def、构建routing database、CTS balance阶段之后长时间不动优先怀疑内存。解决内存问题加机器是最直接的办法但工程上常常没那么好运气。几个实测有效的降内存手段减少同时跑的Innovus实例。我见过有人一台机器同时挂三个大设计结果三个全卡死。错峰启动、一次只跑一个大型设计是最简单有效的办法。降低线程数。setMultiCpuUsage -numThreads 4把线程从8降到4内存峰值可能下降20%到40%。代价是速度慢一些但总比跑不下去强。清理中间文件。*.bak、*.gz、前一个run留下的database目录看着不起眼加起来可能占掉几十GB缓存空间。换用层次化流程。对超大规模设计平铺式PR的内存消耗非常高分层做可以显著压低峰值内存。这是进阶操作但值得提前了解。2.2 临时目录与工作目录写满的问题跑着跑着没反应很多新手根本不会想到磁盘满了。Innovus会在工作目录下产生大量中间文件addStripe、routeDesign、optDesign都会生成很多.dat、.txt、.enc、.db文件。工作目录所在分区一旦写满工具的表现常常是直接挂起日志有时连明显的Disk full都打不出来。排查方法df -h看当前目录所在文件系统的使用率。du -sh *看一下是哪个子目录或文件占了大头。特别留意/tmp。有些环境中TMPDIR指向/tmp而Innovus会把临时文件写到那里。/tmp被占满时Innovus的表现就是卡在某个phase不动日志上毫无线索。处理方案也很直接定期清理历史run目录里的旧文件只保留最终输出和数据库给/tmp或者工作目录所在分区预留充足空间更稳妥的做法是在启动脚本里先做一次磁盘余量检查低于设定阈值就拒绝启动而不是等跑了一半再挂。2.3 线程、多开与license等待Innovus的每一步都有多线程配置。线程数开得太多会成倍增加内存占用在共享机器上多核抢内存甚至会导致性能倒退。我的经验值是在16核机器上跑一个大设计线程开8到12个是上限再往上升内存就崩了。用top -H可以看实际线程数。另一个隐蔽的问题是多个Innovus进程跑在同一个目录。它们会互相抢锁文件、抢database谁都在等谁全部卡住。这个问题在ps -ef | grep innovus里一眼就能看到但如果没往这个方向想会白等很久。再就是license等待。log卡在Waiting for license或者某一行checking license的信息上半天不动十有八九是license被占光了或者license server不可达。处理方式用lmstat -a -c portserver看一下license占用。用ping验证本机到license server的网络连通性。实在不行把其它机器上挂着的僵尸innovus进程清掉释放license。资源问题这一层整体思路就是先系统后工具。任何工具都依赖CPU、内存、磁盘、网络这些硬资源它们出问题时的表现往往比工具自身的问题更像卡死。3. 数据与流程配置database、floorplan、constraint的隐患资源层排掉之后就要看数据了。很多跑不下去其实是前面哪一级流程埋的雷到当前这一步才爆出来。这一层的排查往往要花更多时间因为问题不在当前阶段而在上游。3.1 数据导入与数据库一致性检查Innovus跑的每一步几乎都要基于完整的design database。如果你是从ICC/ICC2、Fusion Compiler或者其它工具导过来的数据Lef/Def/Verilog/SDC之间只要有一丁点不一致后面就可能出问题。最常见的几个坑属性没迁移干净。比如clock单元的is_integrated_clock属性没有传过来CTS阶段工具会走一些奇怪的默认路径表现为报一堆warning然后卡住。缺少tie cell/decap cell。read_verilog之后如果厂商库里的tie hi/tie lo cell没有正确mappedplace之后工具去找这些cell找不到会报错卡住。LEF和GDS里unit不一致、Filler cell缺失导致legalization反复失败。SDC里对象引用了设计中不存在的pin/port工具在clock propagation时反复warn并尝试修复消耗大量时间。数据层面我的建议非常明确每次导入完设计后先跑一遍checkDesign -type all不同版本命令名略有差异把所有error和critical warning清零后再往下跑。这一步不能省省了迟早要在更深的步骤里加倍偿还。有一次我急着试一个floorplan方案省了这步直接往下跑结果route阶段挂了半天最后发现是SDC里一个clock pin的path名字写错了回头花十分钟改掉立刻恢复。3.2 Floorplan与pin assignment的隐患Floorplan做得不合理是跑不下去的重灾区。这里最典型的几个问题Macro放得过于集中行不成行、列不成列导致大量区域无法放置cellplace阶段工具在legalization时反复尝试。Blockage把某些区域封死cell被挤到其它区域局部density爆表工具会在place阶段死磕。IO pin assignment与芯片引脚方向不匹配外部信号进来要大绕路congestion map直接爆红。Power domain划分不合理多个domain交错的区域routing资源严重不足。处理经验在做place之前用reportCongestion或者GUI里的congestion map先看热点区域。如果某个区域已经红色甚至深红色别急着往下跑。先调整macro摆放、删掉不必要的blockage、改pin assignment或者用placeInstance把几个关键IP的位置先固定下来再让工具处理剩余区域。这一步确实花时间但比跑一半挂掉再回来省时间得多。3.3 约束文件引发的卡点约束是跑不下去的隐藏杀手尤其optDesign阶段卡着不收敛很多是SDC里写出来的矛盾约束。举几个实际碰到过的例子set_max_transition设得过于激进比如0.05ns工具为了满足这个值疯狂插buffertransition确实改善了但area和congestion爆炸后续route阶段根本跑不动。set_clock_uncertainty和set_clock_transition互相矛盾导致每个buffer插入后的时序预测都在变工具在同一个区域反复调整。生成时钟的clock_leaf没有定义CTS阶段工具不认识某些pin构建时钟树时反复warn并卡住。set_multicycle_path设错比如应该2cycle设成10cycle工具在优化时会接受本来不该接受的路径跑出来的timing毫无意义而且跑得极慢。排查约束问题的方法并不复杂如果optDesign卡住先看最近的violation报告找一个violation数量在反复横跳的指标。如果setup和hold violation之间来回转化基本就是约束自洽出问题了。先把约束简化单独跑optDesign -setup -effort low验证能否收敛再逐项把约束加回去就能定位到是哪一条约束在捣乱。3.4 流程脚本与checkpoint设计很多人喜欢写一大段tcl脚本一次性跑完place、opt、clock、route中间不设任何checkpoint。这种写法一旦跑到后面挂掉恢复成本极高。更稳妥的写法是用procs分段每段结束保存一次design并输出一次summary。流程脚本里还有一些隐性的坑用source加载多个版本工艺库时优先级顺序错了导致后面读到的是旧LEF和当前design不匹配。在route之前重新load了一次floorplan但没有重跑place阶段数据库状态混乱工具可能直接挂起。用了不存在的命令名或选项名工具只是warning但不会停止后续行为在警告之下不可预测跑到后面才爆。所以脚本里我会加上catch和明确的分段标记每段结尾打一行puts STEP_X DONE at [clock format [clock seconds]]。日志里能看到进度标记挂的时候一眼就知道是哪一步而不是翻几百行log找最后一条信息。4. place/opt/route各阶段的经典卡点与处置讲完资源和数据接下来是重头戏各个阶段各自的跑不下去。这里的经验更贴近工具的使用细节也是大家在社区里问得最多的部分。4.1 placeDesign阶段的congestion与densityplace阶段跑不下去最常见的原因就是congestion高、density高工具在全局布局和legalization之间反复迭代。判断方法place的log里会持续打印overflow值比如Total Overflow如果这个值在多个iteration里没有明显下降或者一直停留在一个高位数基本就是congestion问题。几个处置方法按推荐顺序排列调整congestion effort。setPlaceMode -place_global_cong_effort high让工具更早关注拥挤区域。手动摆均匀硬宏。工具不是万能的它自己摆macro时往往只考虑时序不怎么管拥挤度。你手动把几个大IP打散congestion问题经常立刻缓解。用placement blockage划出禁区。某些区域宁可空着也不要让工具硬塞cell否则它会一直尝试摆放。加cell padding。这里就涉及到很多人问的Innovus加cell padding。通过set_cell_padding或者set_pad_pin_cell_padding给热点区域的cell加上padding让cell之间留出空隙反而能缓解局部拥挤。但注意padding加多了density会直线上涨效果适得其反。我一般控制在3%到5%以内具体得看设计规模。还有一个非常实用的经验place卡住不代表真的卡死。工具在非常拥挤的设计里可能会跑出几十个iteration每经过一个iteration都把逻辑重新摆一遍。如果不想等可以用place_design -run_place_global false先跳过全局布局只做legalization和optimization先看看能不能趟过去。这样至少能快速拿到一个大概的congestion报告再决定要不要调整floorplan。4.2 optDesign阶段setup/hold来回振荡optDesign卡住的剧本往往是这样的开始修setup很大的negative slack修成positive了但hold又崩了改修holdhold好了setup又变差。两个指标反复横跳工具停在某个迭代里不出来。造成这种现象的根源通常是约束自洽性差以及工具一次修的力度太大。处置方法分步优化不要指望一次性搞定。先单独跑optDesign -setup跑完后report_timing看关键路径是否收敛再单独跑optDesign -hold两者交替验证。这样做虽然慢但每一步的目标明确不会陷入来回振荡。给工具设上限。比如set_db opt_design_hold_effort low或者限制一次插入buffer的规模减少来回振荡的幅度。具体选项名因版本而异但思路是一致的。把不需要修得太狠的路径先例外掉。例如set_false_path、set_multicycle_path让工具集中火力在真正的关键路径上。回头找前端要约束。如果后端怎么opt都收敛不了很可能是synthesis阶段的约束和后端不一致。这种情况下继续苦修没有意义及时和前端沟通把约束对齐往往比在Innovus里折腾几个小时更有效。我在实际项目里见过一个极端案例一个设计的setup violation数量在5000到8000之间反复横跳修了一下午都没收敛。后来把SDC里一条原本应该false path但误设成0 cycle的路径改掉整个问题十分钟解决。这类问题光靠工具是调不出来的只能靠对设计的理解。4.3 CTS与电源网络addStripe的坑CTS阶段跑不下去首先要查时钟网相关的特殊net定义。Innovus的CTS会优先处理所有clock net如果clock net的routing规则定义有问题比如non-default rule设置成禁止使用工具在构建时钟树时会卡在某一步。电源网络也是在这一步开始处理的而addStripe本身就是一个高频卡点。常见原因电源ring/strap的layer设置和PR routing layer重叠metal direction冲突工具无法生成合法的tracks。Stripe间距设置过密导致routing resource被大量消耗后面route阶段基本没法跑。PG net connection没有先定义好执行addStripe -nets {VDD VSS}时工具找不全pg pin挂在那里。经验之谈电源网络的处理要放在place之后、CTS之前。正式开始前先用预检查命令看一下生成的stripe文件是否符合预期再真正执行addStripe。如果直接跑完addStripe后发现电源环和逻辑routing冲突后面的route基本跑不通不如一开始就慢一点。还有一点容易被忽略如果设计中存在多个电源域不同domain之间的isolation cell和level shifter如果没有正确摆放工具在CTS阶段处理PG net时也会卡住。4.4 routeDesign阶段的DRC收敛问题routeDesign阶段跑不下去更多是detail route之后的DRC修不干净。工具会在Post-route optimization里反复尝试消除short和violation如果congestion已经高到一定程度或者某些区域被堵死它会一直耗在那里不退出。排查思路先单独跑全局布线。执行routeDesign -global_route看congestion report里的overflow是否归零。如果全局溢出不收敛先解决congestion再往下走。分类统计DRC。detail route跑一次后看DRC violation summary按类别统计。如果short集中在某几个区域可以用addRoutingBlockage把一些实在没救的区域封掉引导绕线。这招看着粗暴但很实用。检查电源网络占用的routing资源。如果PG网络太密、间隔太小会给signal留出的空间不够。适当放宽电源strap间距反而能让整体routing更快收敛。route阶段的卡点很多时候要回溯到floorplan和place阶段的决策。比如我遇到过detail route在某个角落反复修short修了三个小时都没清干净最后发现是那个区域下方埋了一个尺寸写错的hard macro导致上方所有的routing layers都被堵死。把macro挪开之后route半小时就结束了。5. 跑挂之后的应急恢复与后续加固最后一节讲点事后的功课。因为跑不下去这件事很难保证永远不发生关键是挂掉之后能不能尽快恢复以及以后怎么少挂。5.1 应急恢复的标准动作遇到跑不下去我自己的标准动作是先判断真死假死绝不轻易kill方法见第1节。确认是真死或者不可接受的不收敛后在交互模式里按CtrlC。Innovus通常会进入暂停态这时先执行saveDesign把当前状态落盘。注意有些版本里CtrlC可能直接终止流程需要看日志确认是否还活着。从最近的snapshot恢复。强烈推荐在每个大阶段结束时保存一次place阶段结束保存place.encCTS结束保存cts.encroute结束保存route.enc。这样无论挂在哪一步最多丢失一个阶段的运算。恢复之后把刚才出问题的阶段改成轻量档先验证一遍。能过再逐步恢复全effort跑。这里有个细节saveDesign本身也会花时间在大设计上可能要十几分钟甚至更久。所以保存的时机要合理不能每个小步骤都存否则保存本身就成了瓶颈。我的习惯是planning、floorplan、place、CTS、route完毕这五个节点必存其它零碎步骤不存。5.2 让流程更健壮的工程化手段分享几个我在实际项目中验证过有效的做法在流程脚本里加后台监控模块。每隔5分钟把ps -o pid,pcpu,pmem -p pid、free -g、df -h追加到一个监控log文件。下次跑挂了先翻监控log一眼就能看出是不是内存或磁盘导致的不用瞎猜。每个阶段开头打印日期和STEP标记阶段结束输出report_summary。这样日志里能快速定位到底挂在哪一步。对关键阶段设置超时保护。比如用Linux的timeout 7200 innovus -no_gui ...超过2小时自动退出。虽然粗暴但至少不会让一个已经没救的流程白占机器资源。超时退出后还能自动把当前状态dump下来方便诊断。跑大设计之前先做快速验证把effort降到最低、关闭部分优化开关用最小迭代跑一遍全流程确认数据链路是通的再按正常effort跑。这有点像新工艺节点试片能提前发现90%的数据问题和文件路径问题。5.3 积累自己的卡点黑名单最后分享一个习惯每遇到一个跑不下去的问题我都会把它记到自己的排障笔记里记录现象、根因、解法。时间久了会发现很多问题是有共性的某个版本的工具在某个effort下对某类约束的兼容性差、某个工艺库的某个cell在CTS里容易引发问题、某个macro摆放位置会导致congestion爆表……这些经验攒多了排查时间会指数级下降。我自己的笔记里已经有几十条这样的记录了从LEF单位不一致导致legalization死循环到时钟树综合阶段因为clock_leaf定义缺失卡了整整一天每一条都是拿加班时间换来的。这次整理出来的内容就是这个黑名单里最常见的那一批。如果你手里有其它怪异的跑不下去的场景欢迎带着log来一起讨论互相攒经验比一个人硬啃手册效率高太多了。 Innovus物理实现PR卡死排障手册：从现象判断到应急恢复
早上刚到工位隔壁同事就火急火燎地喊Innovus里的PR跑了一整夜到现在还没跑完日志停在placeDesign就不动了CPU也不高了这算不算卡死这问题我在数字后端项目里遇到过太多次了。今天就把innovus跑pr跑不下去这类情况的排查思路整理出来从现象判断、根因分析到应急恢复整理成一份能直接抄作业的排查手册给刚上手Innovus做物理实现的工程师做参考。不管你是刚把Innovus装好准备跑第一个案例还是已经在一颗复杂SoC上挣扎了很久这篇文章里的很多排查方法都能直接用上。1. 跑不下去到底长什么样先判断是真死还是假死很多人一看到工具卡住就慌了随手就kill -9结果丢了几个小时甚至一整天的结果。我在实际排障中有接近一半的情况其实是假死——工具没死只是干了一个需要很久的步骤还没有反馈。所以拿到跑不下去这个问题第一件事不是查代码、不是改配置而是先搞清楚它到底是活着但没动静还是已经彻底没救了。1.1 真死、假死的区分方法给你几个我一直在用的实操判断方法每一步都不需要额外装工具看CPU。在终端执行top -p pid如果Innovus进程的CPU稳定在比较高的水平比如100%以上说明它在计算大概率是假死如果CPU几乎为0但进程没退多半是锁死了或者正在等待外界资源。看日志增长。ls -l看innovus.log最后修改时间或者tail -5 innovus.log看内容是否在持续更新。日志还在涨说明工具还在干活。在交互shell里敲命令测试。如果你启动时带了交互界面敲一个help或者set a 1看有没有响应。有响应说明shell是活的只是当前stage没有输出。看系统级状态。vmstat 5连续看几轮重点看swpd列和si/so列。如果swap的换入换出持续很高说明内存和换页正在打架系统已经濒临瘫痪工具可能只是跑得极慢不是死掉。这里有一个我自己的血泪教训有一次placeDesign跑了三个多小时日志最后停在Starting global placement phase 2我等了两个小时实在没耐心直接kill -9。后来恢复snapshot重跑才发现其实再等40分钟就能过。从那以后我再也不急着kill而是先用上面的方法判断完再说。1.2 挂死、报错终止、死循环三种形态跑不下去至少可以分成三种形态处理方式完全不同挂死进程还在但不做任何事不写log。常见原因是等待license、等待集群上其它进程释放文件、线程死锁。这种需要用系统层面的手段排查比如看进程状态是不是D状态不可中断睡眠、有没有僵尸进程占着锁文件。报错终止日志里有明确的Error、Fatal、CRITICAL WARNING随后出现*EXIT*。这种其实最友好因为信息是明确给出的直接搜日志里的关键字就行。很多新手怕报错其实报错是工具在告诉你它发现了问题远比闷头卡死更值得庆幸。死循环/不收敛流程一直在跑CPU高log也在写但迭代指标不下降甚至上升。最常见的就是congestion overflow一直不降、optDesign的violation数量反复横跳。这种最麻烦需要结合具体阶段去判断。这三种形态放在一起看你会发现跑不下去其实不是一个单一问题而是一类问题。后面每一个根因我都尽量把对应的现象和处置方法放到一起说。2. 硬资源问题内存爆了、磁盘满了、线程打架这一层是我排查跑不下去时最先检查的不是因为它的技术含量高而是因为它的定位成本最低、出现频率极高。而且这一层的坑很多时候用系统命令一分钟就能确认。2.1 内存不足的典型征兆与判断方法Innovus是内存大户尤其在大规模的CTS和routeDesign阶段内存占用轻松超过几十GB。内存不足时轻则工具慢到像死机重则直接被系统OOM killer杀掉或者因为swap反复交换导致几乎停摆。判断内存问题的几个方法用free -g看总内存、已用内存和swap占用。如果swap used持续在涨说明物理内存已经顶不住了。用dmesg -T | grep -i oom看有没有Out of Memory的记录。如果有说明系统已经在杀进程了你的Innovus可能侥幸活着但已经被挤兑到极限。观察日志如果log精确地停在某个大数据量操作比如写def、构建routing database、CTS balance阶段之后长时间不动优先怀疑内存。解决内存问题加机器是最直接的办法但工程上常常没那么好运气。几个实测有效的降内存手段减少同时跑的Innovus实例。我见过有人一台机器同时挂三个大设计结果三个全卡死。错峰启动、一次只跑一个大型设计是最简单有效的办法。降低线程数。setMultiCpuUsage -numThreads 4把线程从8降到4内存峰值可能下降20%到40%。代价是速度慢一些但总比跑不下去强。清理中间文件。*.bak、*.gz、前一个run留下的database目录看着不起眼加起来可能占掉几十GB缓存空间。换用层次化流程。对超大规模设计平铺式PR的内存消耗非常高分层做可以显著压低峰值内存。这是进阶操作但值得提前了解。2.2 临时目录与工作目录写满的问题跑着跑着没反应很多新手根本不会想到磁盘满了。Innovus会在工作目录下产生大量中间文件addStripe、routeDesign、optDesign都会生成很多.dat、.txt、.enc、.db文件。工作目录所在分区一旦写满工具的表现常常是直接挂起日志有时连明显的Disk full都打不出来。排查方法df -h看当前目录所在文件系统的使用率。du -sh *看一下是哪个子目录或文件占了大头。特别留意/tmp。有些环境中TMPDIR指向/tmp而Innovus会把临时文件写到那里。/tmp被占满时Innovus的表现就是卡在某个phase不动日志上毫无线索。处理方案也很直接定期清理历史run目录里的旧文件只保留最终输出和数据库给/tmp或者工作目录所在分区预留充足空间更稳妥的做法是在启动脚本里先做一次磁盘余量检查低于设定阈值就拒绝启动而不是等跑了一半再挂。2.3 线程、多开与license等待Innovus的每一步都有多线程配置。线程数开得太多会成倍增加内存占用在共享机器上多核抢内存甚至会导致性能倒退。我的经验值是在16核机器上跑一个大设计线程开8到12个是上限再往上升内存就崩了。用top -H可以看实际线程数。另一个隐蔽的问题是多个Innovus进程跑在同一个目录。它们会互相抢锁文件、抢database谁都在等谁全部卡住。这个问题在ps -ef | grep innovus里一眼就能看到但如果没往这个方向想会白等很久。再就是license等待。log卡在Waiting for license或者某一行checking license的信息上半天不动十有八九是license被占光了或者license server不可达。处理方式用lmstat -a -c portserver看一下license占用。用ping验证本机到license server的网络连通性。实在不行把其它机器上挂着的僵尸innovus进程清掉释放license。资源问题这一层整体思路就是先系统后工具。任何工具都依赖CPU、内存、磁盘、网络这些硬资源它们出问题时的表现往往比工具自身的问题更像卡死。3. 数据与流程配置database、floorplan、constraint的隐患资源层排掉之后就要看数据了。很多跑不下去其实是前面哪一级流程埋的雷到当前这一步才爆出来。这一层的排查往往要花更多时间因为问题不在当前阶段而在上游。3.1 数据导入与数据库一致性检查Innovus跑的每一步几乎都要基于完整的design database。如果你是从ICC/ICC2、Fusion Compiler或者其它工具导过来的数据Lef/Def/Verilog/SDC之间只要有一丁点不一致后面就可能出问题。最常见的几个坑属性没迁移干净。比如clock单元的is_integrated_clock属性没有传过来CTS阶段工具会走一些奇怪的默认路径表现为报一堆warning然后卡住。缺少tie cell/decap cell。read_verilog之后如果厂商库里的tie hi/tie lo cell没有正确mappedplace之后工具去找这些cell找不到会报错卡住。LEF和GDS里unit不一致、Filler cell缺失导致legalization反复失败。SDC里对象引用了设计中不存在的pin/port工具在clock propagation时反复warn并尝试修复消耗大量时间。数据层面我的建议非常明确每次导入完设计后先跑一遍checkDesign -type all不同版本命令名略有差异把所有error和critical warning清零后再往下跑。这一步不能省省了迟早要在更深的步骤里加倍偿还。有一次我急着试一个floorplan方案省了这步直接往下跑结果route阶段挂了半天最后发现是SDC里一个clock pin的path名字写错了回头花十分钟改掉立刻恢复。3.2 Floorplan与pin assignment的隐患Floorplan做得不合理是跑不下去的重灾区。这里最典型的几个问题Macro放得过于集中行不成行、列不成列导致大量区域无法放置cellplace阶段工具在legalization时反复尝试。Blockage把某些区域封死cell被挤到其它区域局部density爆表工具会在place阶段死磕。IO pin assignment与芯片引脚方向不匹配外部信号进来要大绕路congestion map直接爆红。Power domain划分不合理多个domain交错的区域routing资源严重不足。处理经验在做place之前用reportCongestion或者GUI里的congestion map先看热点区域。如果某个区域已经红色甚至深红色别急着往下跑。先调整macro摆放、删掉不必要的blockage、改pin assignment或者用placeInstance把几个关键IP的位置先固定下来再让工具处理剩余区域。这一步确实花时间但比跑一半挂掉再回来省时间得多。3.3 约束文件引发的卡点约束是跑不下去的隐藏杀手尤其optDesign阶段卡着不收敛很多是SDC里写出来的矛盾约束。举几个实际碰到过的例子set_max_transition设得过于激进比如0.05ns工具为了满足这个值疯狂插buffertransition确实改善了但area和congestion爆炸后续route阶段根本跑不动。set_clock_uncertainty和set_clock_transition互相矛盾导致每个buffer插入后的时序预测都在变工具在同一个区域反复调整。生成时钟的clock_leaf没有定义CTS阶段工具不认识某些pin构建时钟树时反复warn并卡住。set_multicycle_path设错比如应该2cycle设成10cycle工具在优化时会接受本来不该接受的路径跑出来的timing毫无意义而且跑得极慢。排查约束问题的方法并不复杂如果optDesign卡住先看最近的violation报告找一个violation数量在反复横跳的指标。如果setup和hold violation之间来回转化基本就是约束自洽出问题了。先把约束简化单独跑optDesign -setup -effort low验证能否收敛再逐项把约束加回去就能定位到是哪一条约束在捣乱。3.4 流程脚本与checkpoint设计很多人喜欢写一大段tcl脚本一次性跑完place、opt、clock、route中间不设任何checkpoint。这种写法一旦跑到后面挂掉恢复成本极高。更稳妥的写法是用procs分段每段结束保存一次design并输出一次summary。流程脚本里还有一些隐性的坑用source加载多个版本工艺库时优先级顺序错了导致后面读到的是旧LEF和当前design不匹配。在route之前重新load了一次floorplan但没有重跑place阶段数据库状态混乱工具可能直接挂起。用了不存在的命令名或选项名工具只是warning但不会停止后续行为在警告之下不可预测跑到后面才爆。所以脚本里我会加上catch和明确的分段标记每段结尾打一行puts STEP_X DONE at [clock format [clock seconds]]。日志里能看到进度标记挂的时候一眼就知道是哪一步而不是翻几百行log找最后一条信息。4. place/opt/route各阶段的经典卡点与处置讲完资源和数据接下来是重头戏各个阶段各自的跑不下去。这里的经验更贴近工具的使用细节也是大家在社区里问得最多的部分。4.1 placeDesign阶段的congestion与densityplace阶段跑不下去最常见的原因就是congestion高、density高工具在全局布局和legalization之间反复迭代。判断方法place的log里会持续打印overflow值比如Total Overflow如果这个值在多个iteration里没有明显下降或者一直停留在一个高位数基本就是congestion问题。几个处置方法按推荐顺序排列调整congestion effort。setPlaceMode -place_global_cong_effort high让工具更早关注拥挤区域。手动摆均匀硬宏。工具不是万能的它自己摆macro时往往只考虑时序不怎么管拥挤度。你手动把几个大IP打散congestion问题经常立刻缓解。用placement blockage划出禁区。某些区域宁可空着也不要让工具硬塞cell否则它会一直尝试摆放。加cell padding。这里就涉及到很多人问的Innovus加cell padding。通过set_cell_padding或者set_pad_pin_cell_padding给热点区域的cell加上padding让cell之间留出空隙反而能缓解局部拥挤。但注意padding加多了density会直线上涨效果适得其反。我一般控制在3%到5%以内具体得看设计规模。还有一个非常实用的经验place卡住不代表真的卡死。工具在非常拥挤的设计里可能会跑出几十个iteration每经过一个iteration都把逻辑重新摆一遍。如果不想等可以用place_design -run_place_global false先跳过全局布局只做legalization和optimization先看看能不能趟过去。这样至少能快速拿到一个大概的congestion报告再决定要不要调整floorplan。4.2 optDesign阶段setup/hold来回振荡optDesign卡住的剧本往往是这样的开始修setup很大的negative slack修成positive了但hold又崩了改修holdhold好了setup又变差。两个指标反复横跳工具停在某个迭代里不出来。造成这种现象的根源通常是约束自洽性差以及工具一次修的力度太大。处置方法分步优化不要指望一次性搞定。先单独跑optDesign -setup跑完后report_timing看关键路径是否收敛再单独跑optDesign -hold两者交替验证。这样做虽然慢但每一步的目标明确不会陷入来回振荡。给工具设上限。比如set_db opt_design_hold_effort low或者限制一次插入buffer的规模减少来回振荡的幅度。具体选项名因版本而异但思路是一致的。把不需要修得太狠的路径先例外掉。例如set_false_path、set_multicycle_path让工具集中火力在真正的关键路径上。回头找前端要约束。如果后端怎么opt都收敛不了很可能是synthesis阶段的约束和后端不一致。这种情况下继续苦修没有意义及时和前端沟通把约束对齐往往比在Innovus里折腾几个小时更有效。我在实际项目里见过一个极端案例一个设计的setup violation数量在5000到8000之间反复横跳修了一下午都没收敛。后来把SDC里一条原本应该false path但误设成0 cycle的路径改掉整个问题十分钟解决。这类问题光靠工具是调不出来的只能靠对设计的理解。4.3 CTS与电源网络addStripe的坑CTS阶段跑不下去首先要查时钟网相关的特殊net定义。Innovus的CTS会优先处理所有clock net如果clock net的routing规则定义有问题比如non-default rule设置成禁止使用工具在构建时钟树时会卡在某一步。电源网络也是在这一步开始处理的而addStripe本身就是一个高频卡点。常见原因电源ring/strap的layer设置和PR routing layer重叠metal direction冲突工具无法生成合法的tracks。Stripe间距设置过密导致routing resource被大量消耗后面route阶段基本没法跑。PG net connection没有先定义好执行addStripe -nets {VDD VSS}时工具找不全pg pin挂在那里。经验之谈电源网络的处理要放在place之后、CTS之前。正式开始前先用预检查命令看一下生成的stripe文件是否符合预期再真正执行addStripe。如果直接跑完addStripe后发现电源环和逻辑routing冲突后面的route基本跑不通不如一开始就慢一点。还有一点容易被忽略如果设计中存在多个电源域不同domain之间的isolation cell和level shifter如果没有正确摆放工具在CTS阶段处理PG net时也会卡住。4.4 routeDesign阶段的DRC收敛问题routeDesign阶段跑不下去更多是detail route之后的DRC修不干净。工具会在Post-route optimization里反复尝试消除short和violation如果congestion已经高到一定程度或者某些区域被堵死它会一直耗在那里不退出。排查思路先单独跑全局布线。执行routeDesign -global_route看congestion report里的overflow是否归零。如果全局溢出不收敛先解决congestion再往下走。分类统计DRC。detail route跑一次后看DRC violation summary按类别统计。如果short集中在某几个区域可以用addRoutingBlockage把一些实在没救的区域封掉引导绕线。这招看着粗暴但很实用。检查电源网络占用的routing资源。如果PG网络太密、间隔太小会给signal留出的空间不够。适当放宽电源strap间距反而能让整体routing更快收敛。route阶段的卡点很多时候要回溯到floorplan和place阶段的决策。比如我遇到过detail route在某个角落反复修short修了三个小时都没清干净最后发现是那个区域下方埋了一个尺寸写错的hard macro导致上方所有的routing layers都被堵死。把macro挪开之后route半小时就结束了。5. 跑挂之后的应急恢复与后续加固最后一节讲点事后的功课。因为跑不下去这件事很难保证永远不发生关键是挂掉之后能不能尽快恢复以及以后怎么少挂。5.1 应急恢复的标准动作遇到跑不下去我自己的标准动作是先判断真死假死绝不轻易kill方法见第1节。确认是真死或者不可接受的不收敛后在交互模式里按CtrlC。Innovus通常会进入暂停态这时先执行saveDesign把当前状态落盘。注意有些版本里CtrlC可能直接终止流程需要看日志确认是否还活着。从最近的snapshot恢复。强烈推荐在每个大阶段结束时保存一次place阶段结束保存place.encCTS结束保存cts.encroute结束保存route.enc。这样无论挂在哪一步最多丢失一个阶段的运算。恢复之后把刚才出问题的阶段改成轻量档先验证一遍。能过再逐步恢复全effort跑。这里有个细节saveDesign本身也会花时间在大设计上可能要十几分钟甚至更久。所以保存的时机要合理不能每个小步骤都存否则保存本身就成了瓶颈。我的习惯是planning、floorplan、place、CTS、route完毕这五个节点必存其它零碎步骤不存。5.2 让流程更健壮的工程化手段分享几个我在实际项目中验证过有效的做法在流程脚本里加后台监控模块。每隔5分钟把ps -o pid,pcpu,pmem -p pid、free -g、df -h追加到一个监控log文件。下次跑挂了先翻监控log一眼就能看出是不是内存或磁盘导致的不用瞎猜。每个阶段开头打印日期和STEP标记阶段结束输出report_summary。这样日志里能快速定位到底挂在哪一步。对关键阶段设置超时保护。比如用Linux的timeout 7200 innovus -no_gui ...超过2小时自动退出。虽然粗暴但至少不会让一个已经没救的流程白占机器资源。超时退出后还能自动把当前状态dump下来方便诊断。跑大设计之前先做快速验证把effort降到最低、关闭部分优化开关用最小迭代跑一遍全流程确认数据链路是通的再按正常effort跑。这有点像新工艺节点试片能提前发现90%的数据问题和文件路径问题。5.3 积累自己的卡点黑名单最后分享一个习惯每遇到一个跑不下去的问题我都会把它记到自己的排障笔记里记录现象、根因、解法。时间久了会发现很多问题是有共性的某个版本的工具在某个effort下对某类约束的兼容性差、某个工艺库的某个cell在CTS里容易引发问题、某个macro摆放位置会导致congestion爆表……这些经验攒多了排查时间会指数级下降。我自己的笔记里已经有几十条这样的记录了从LEF单位不一致导致legalization死循环到时钟树综合阶段因为clock_leaf定义缺失卡了整整一天每一条都是拿加班时间换来的。这次整理出来的内容就是这个黑名单里最常见的那一批。如果你手里有其它怪异的跑不下去的场景欢迎带着log来一起讨论互相攒经验比一个人硬啃手册效率高太多了。