1. 数字后端流程中 place 环节的定位与整体思路数字后端设计里place布局这一步是绕不开的核心环节。简单说前端综合出来的网表只是一堆逻辑门和触发器的连接关系没有任何物理位置信息而 place 要做的事情就是把这些 std cell标准单元按照一定的规则摆放到芯片的版图区域里。摆得好后续绕线顺畅、时序容易收敛摆得不好congestion拥塞爆炸、setup 违例一堆后面再怎么修都事倍功半。我做了这些年后端最大的体会就是place 阶段偷的懒route 阶段要加倍还回来。很多新手觉得 place 就是跑个命令等结果实际上从 floorplan 交接过来的那一刻起每一步的决策都在影响最终能不能签核。这篇文章我会围绕 place 的完整流程把 std cell 摆放、congestion 控制、setup 时序优化这几个关键点拆开讲清楚同时把常见的坑和排查思路一并整理出来。不管你是刚入行的后端新人还是想系统梳理流程的老手应该都能从中找到可以直接用的东西。place 在整个后端 flow 里的位置很明确floorplan 之后、CTS 之前。它接收的是 floorplan 确定的 die 面积、core 区域、macro 摆放位置、IO pin 分配、power plan 等约束输出的是一个已经摆好 std cell 的 DEF。这个 DEF 会交给 CTS 做时钟树综合再往后是 route。所以 place 的质量直接决定了 CTS 和 route 的难度。从工具角度来说目前主流的两大平台就是 Cadence 的 Innovus 和 Synopsys 的 ICC2。两者的 place 引擎思路大同小异都是先做全局布局global placement再做详细布局detailed placement中间穿插各种优化。我下面以 Innovus 为主来讲因为它的日志和报告更直观初学者更容易上手但核心原理是通用的。2. Place 之前的准备工作与约束检查2.1 输入文件清单与检查要点在跑 place 之前你得确保手头的输入文件是齐全且正确的。缺一个文件或者版本对不上后面出来的结果全是白费功夫。我一般会按下面的清单逐项确认文件类型具体内容检查要点网表综合后的 .v 文件单元库版本匹配、无黑盒时序库.lib / .db与网表单元一致、PVT corner 正确物理库.leftech cell层定义完整、cell 尺寸正确约束.sdc时钟定义、IO 延迟、例外寄生参数.qrc / .tluplus与工艺节点匹配版图DEFfloorplan 输出die/core 区域、macro 位置、pin 分配这里面最容易出问题的是 LEF 和网表的匹配。我踩过一次坑综合用的库和物理库不是同一个版本结果 place 跑完发现有些 cell 在 LEF 里根本找不到工具直接报错退出。所以跑之前一定要用工具自带的 check 命令过一遍Innovus 里可以用checkDesign来做完整性检查。2.2 约束文件的确认SDC 约束是 place 阶段做时序优化的依据。如果 SDC 有问题place 出来的结果时序肯定不对。我通常重点看这几个地方时钟定义create_clock 的周期、波形是否正确有没有漏掉 generated clock。IO 约束set_input_delay / set_output_delay 是否合理有没有覆盖所有 IO。例外false path、multicycle path 是否设置到位避免工具在不需要优化的路径上浪费精力。clock uncertainty这个值直接影响 setup 的余量place 阶段一般会留得比 CTS 后大一些。有个经验place 阶段我会把 clock uncertainty 设得稍微悲观一点比如比最终目标多留 50-100ps。这样 place 出来的结果到了 CTS 之后不会因为时钟树延迟而突然恶化太多。2.3 Floorplan 交接的确认Floorplan 阶段确定的 macro 位置、power ring、IO pin 分配在 place 之前要再确认一遍。特别是 macro 周围的 halokeepout margin如果留得不够std cell 挤进去之后会导致 macro 引脚附近严重 congestion。我一般会在 macro 四周留至少 5-10um 的 halo具体看工艺和 macro 引脚密度。IO pin 的分配也特别关键。热搜词里提到的 “poor placement for routing between an io pin and bufg” 就是典型的 IO pin 和时钟 buffer 之间绕线困难的问题。如果 IO pin 被分配到了离时钟网络很远的位置place 阶段工具会尝试把相关的 buffer 往那边摆但可能因为 congestion 摆不过去导致绕线绕远、时序变差。所以 floorplan 阶段分配 pin 的时候就要考虑时钟网络的大致走向。3. Place 核心流程与关键参数解析3.1 全局布局与详细布局的分工Place 分两大步global placement 和 detailed placement。Global placement 决定每个 cell 大致在哪个区域允许 cell 重叠detailed placement 则把 cell 对齐到合法的 row 和 site 上消除重叠。Innovus 里一条place_opt_design命令就把这两步都跑了但理解它们各自在做什么对调优很有帮助。Global placement 的核心目标是最小化线长wirelength同时控制 congestion。工具会用各种算法解析法、模拟退火等来求解。这个阶段你可以通过设置 density 来控制布局的松紧程度。Density 设得太高cell 挤在一起congestion 必然爆炸设得太低面积浪费芯片成本上去了。一般我会把 target density 设在 0.7-0.85 之间具体看设计特点。Detailed placement 阶段工具会做大量的局部优化包括 cell swapping、cell sizing、buffer insertion 等。这个阶段对 setup 时序的优化最明显。Innovus 会在 detailed placement 过程中反复调用时序引擎对关键路径上的 cell 进行 upsizing 或者换用更低阈值的 cell。3.2 Congestion 控制的关键手段Congestion 是 place 阶段最头疼的问题之一。它的本质是某个区域的绕线需求超过了可用的绕线资源。造成 congestion 的原因很多macro 太密集、pin density 太高、cell density 太高、时钟网络太集中等。我在实际项目中总结了几种有效的 congestion 控制手段第一合理设置 congestion effort。Innovus 里可以通过setPlaceMode -congEffort high来让工具在 place 阶段花更多精力优化 congestion。但注意设太高会显著增加运行时间而且可能牺牲时序。我一般先用 medium 跑一版看结果如果 congestion 确实严重再调高。第二使用 partial placement blockage。在 congestion 严重的区域放 blockage强制工具把 cell 摆到别处。这个手段很直接但用多了会导致面积利用率下降。我的经验是只在 macro 之间的窄通道或者 pin 密集区域用blockage 的密度设在 30%-50% 左右。第三调整 cell padding。对高引脚数的 cell 加 padding让它们之间留出更多绕线空间。Innovus 里可以用setPlaceMode -placeIoPinPad或者对特定 cell 设 padding。第四控制 clock cell 的摆放。时钟网络上的 buffer 和 inverter 如果摆得太集中会在局部造成 congestion。可以用setPlaceMode -clockGateAware之类的选项让工具考虑时钟网络的分布。3.3 Setup 时序优化的实现机制Place 阶段的 setup 优化主要靠 cell sizing 和 buffer insertion。工具会分析时序路径找出 slack 为负的路径然后尝试把路径上的 cell 换成驱动能力更强的版本或者插入 buffer 来改善信号完整性。这里有个关键参数setOptMode -effort。设成 high 会让工具做更激进的优化但运行时间会明显增加。我一般会在最终 signoff 前的 place 跑 high effort中间迭代用 medium 就够了。另外setOptMode -usefulSkew这个选项值得关注。它允许工具在 place 阶段就做一些有用的时钟偏斜调整提前改善 setup。不过这个选项要和 CTS 阶段的 skew 策略配合好不然可能白做。还有一个容易被忽略的点place 阶段的时序优化是在理想时钟下做的没有真实的时钟树延迟。所以工具优化出来的结果到了 CTS 之后可能会有变化。我的做法是在 place 阶段把 setup 的目标 slack 设得比最终要求紧一些比如要求 0ns 的话place 阶段争取做到 100ps 以上。4. 实操过程与核心环节实现4.1 环境搭建与设计导入假设你已经有了所有输入文件下面是我常用的 Innovus place 流程。先启动工具并导入设计# 启动 Innovus innovus # 设置多线程加速 setMultiCpuUsage -localCpu 8 # 导入网表、LEF、库 set init_verilog ./netlist/top.v set init_lef_file ./lef/tech.lef ./lef/cells.lef set init_mmmc_file ./mmmc/view_definition.tcl set init_design_netlisttype Verilog set init_design_settop 1 set init_top_cell top # 执行初始化 init_design导入之后第一件事是检查设计完整性checkDesign -all这个命令会检查网表、库、约束之间的一致性。如果有 missing cell 或者 pin 不匹配会在这里报出来。千万别跳过这一步我见过太多因为库版本不对导致后面全盘重来的案例。4.2 约束加载与检查接下来加载 SDC 并检查# 加载时序约束 read_sdc ./sdc/top.sdc # 检查时钟定义 report_clocks # 检查时序路径 report_timing -max_paths 10 -early report_timing -max_paths 10 -late这里要特别确认时钟有没有正确传播。如果 report_clocks 显示时钟没有定义或者周期不对后面所有时序优化都是错的。热搜词里提到的 “检查:setup constraints physical” 其实就是在提醒我们place 之前要把物理约束和时序约束都检查到位。物理约束包括 floorplan 的 DEF、placement blockage、region constraint 等。时序约束就是 SDC。两者缺一不可。4.3 Floorplan 加载与确认# 加载 floorplan DEF defIn ./def/floorplan.def # 检查 die/core 区域 report_die_area report_core_area # 检查 macro 位置 report_macros加载完 floorplan 后我习惯用 GUI 看一眼 macro 的摆放和 IO pin 的分配。特别是时钟相关的 IO要确认它们的位置是否合理。如果发现某个时钟 buffer 需要放在离 IO 很远的地方就要提前考虑是不是要调整 floorplan。4.4 Place 主流程执行一切确认无误后开始跑 place# 设置 place 模式 setPlaceMode -congEffort high \ -timingDriven true \ -placeIoPinPad 2 \ -modulePlan false # 设置优化模式 setOptMode -effort high \ -usefulSkew true \ -setupTargetSlack 0.1 \ -holdTargetSlack 0.05 # 执行 place place_opt_designplace_opt_design这一条命令背后做了很多事情global placement、detailed placement、预布线、时序优化、DRC 修复等。跑完之后工具会输出一份 summary包括 congestion 情况、时序 slack 分布、面积利用率等。4.5 结果检查与报告分析Place 跑完后必须做详细的检查。我一般按下面的顺序来第一步看 congestion。Innovus 里可以用reportCongestion来查看 congestion map。重点关注 overflow 的区域如果某个区域 overflow 超过 5%基本可以确定 route 阶段会出问题。reportCongestion -overflow第二步看时序。用report_timing检查 setup 和 hold 的 slack 分布。Place 阶段主要关注 setuphold 一般留到 CTS 之后修。report_timing -max_paths 50 -late -nworst 10第三步看面积利用率。report_area可以看 std cell 占用的面积和 core 面积的比例。利用率太高超过 85%会导致 congestion 风险太低则浪费面积。第四步看 DRC。Place 阶段可能会有一些 cell 重叠或者 well 相关的 DRC用verifyGeometry检查。verifyGeometry4.6 迭代优化策略很少有设计能一次 place 就完美。通常需要几轮迭代。我的迭代策略是这样的第一轮用 medium effort 快速跑一版看整体 congestion 和时序的大致情况。这一轮的目的是摸清设计的主要矛盾在哪里。第二轮针对第一轮暴露的问题调整参数。如果是 congestion 问题加 blockage 或者调 density如果是时序问题调 opt effort 或者加 useful skew。第三轮用 high effort 跑最终版确保结果尽可能好。每一轮之间我会把结果和上一轮对比看改动是否有效。如果某一轮改动后结果反而变差就要回退重新想策略。5. 常见问题与排查技巧实录5.1 Congestion 爆炸的排查思路Congestion 是 place 阶段最常见也最棘手的问题。我遇到过的 congestion 原因大致分几类Macro 通道太窄。两个 macro 之间如果只留了几微米的通道std cell 摆进去之后绕线资源根本不够。解决办法是在 floorplan 阶段就留够通道宽度一般建议至少 20-30um具体看工艺。Pin density 太高。某些模块的 std cell 引脚特别密集比如 datapath 或者 memory 接口。这种情况下可以在局部降低 density或者用 partial blockage 把一部分 cell 赶到别处。时钟网络集中。时钟 buffer 如果都堆在一个区域会在那里造成 congestion。可以用setPlaceMode -clockGateAware true让工具分散摆放时钟 cell。IO pin 分配不合理。热搜词里提到的 “poor placement for routing between an io pin and bufg” 就是这个问题。IO pin 和时钟 buffer 之间如果距离太远绕线会经过很多区域造成沿途 congestion。解决办法是在 floorplan 阶段就把时钟相关的 IO 分配到靠近时钟网络的位置。下面是我整理的 congestion 排查速查表现象可能原因排查方法解决手段局部 overflow 高cell density 太高reportCongestion -overflow加 partial blockagemacro 周围拥塞halo 不够查看 macro 间距增大 halo时钟区域拥塞clock cell 集中查看 clock cell 分布设 clockGateAware全局拥塞density 设太高report_area降低 target densityIO 附近拥塞pin 分配不合理查看 pin 位置调整 floorplan5.2 Setup 违例修不动的处理Place 阶段 setup 违例修不动通常有几个原因约束太紧。如果 SDC 里的时钟周期本身就不合理工具再怎么优化也达不到。这时候要和前端确认约束是否实际可行。路径太长。如果关键路径跨越了整个芯片place 阶段很难通过 cell sizing 来修复。这种情况需要考虑在 floorplan 阶段调整模块位置或者在前端做逻辑优化。Cell 驱动能力不足。如果库里的 cell 最大驱动能力都不够工具也无能为力。这时候要考虑用更低阈值的 cell或者调整综合策略。Congestion 限制了优化。如果关键路径经过 congestion 严重的区域工具可能无法在那里插入 buffer 或者换 cell。这时候要先解决 congestion 问题再修时序。我的经验是place 阶段如果 setup 违例超过总路径数的 5%就要停下来想想是不是约束或者 floorplan 有问题而不是一味地调 opt effort。5.3 Place 后结果与 CTS 不一致的处理Place 阶段是在理想时钟下优化的CTS 之后有时钟树延迟结果会有变化。如果变化太大说明 place 阶段的优化方向可能有问题。我一般会在 place 之后做一个预判看看关键路径上的时钟延迟大概是多少如果超过时钟周期的 10%就要在 place 阶段留更多余量。另外place 阶段用的 clock uncertainty 要合理不能设得太乐观。5.4 工具版本与脚本兼容性问题热搜词里出现了 “inno setup” 相关的内容虽然那是安装程序制作工具但侧面说明工具版本和脚本兼容性是个常见痛点。Innovus 不同版本之间命令和选项可能有变化比如某些选项在新版本里被 deprecated 了。我的做法是固定项目使用的工具版本不要随意升级。脚本里对关键命令加版本判断。保留一份已知可用的脚本作为 baseline改动时对比。5.5 实操心得与避坑清单最后分享几条我在实际项目中总结的心得提示Place 之前一定要用 checkDesign 和 checkTiming 过一遍这两个命令能帮你省下大量 debug 时间。注意不要为了追求零 congestion 而把 density 设得过低面积浪费的代价可能比 congestion 更大。提示Place 阶段的日志要仔细看工具会在日志里提示哪些路径修不动、哪些区域有风险这些信息比最终报告更有价值。每次改参数只改一个改完对比结果这样才能知道哪个参数起了作用。保留每一轮的 DEF 和报告方便回退和对比。和前端保持沟通place 阶段发现的约束问题要及时反馈。不要迷信工具的自动优化该手动加 blockage 或者调整 floorplan 的时候要果断。Place 这个环节说到底是在面积、时序、congestion 三者之间找平衡。没有完美的结果只有最合适的取舍。我做了这么多项目每次 place 都还是会遇到新问题但只要有系统的排查思路和足够的经验积累大部分问题都能在几轮迭代内解决。希望这些内容对正在做数字后端的朋友有所帮助少走一些我当年走过的弯路。