1. 数字后端流程中 place 阶段的核心定位与整体思路数字后端设计里place布局这个环节处在一个非常微妙的位置。往前一步是 floorplan往后一步是 CTS 和 route它像是整个物理实现的“中场发动机”——floorplan 定下了 die 和 core 的边界、macro 的摆放、power plan 的骨架而 place 则要把成千上万个 std cell 按照时序、拥塞、功耗的多重约束安放到合法且合理的行row里。很多人刚入行时觉得 place 就是跑一条place_opt_design命令等它跑完看报告就行但真正做过几个项目之后你会发现place 阶段埋下的隐患往往要到 route 甚至 signoff 阶段才爆发到时候再回头改代价可能是几天甚至一周的迭代。这篇文章我想围绕 place 阶段展开把 std cell 布局、setup 时序优化、congestion 控制这几条主线串起来讲清楚。适合正在学习数字后端流程的在校生、刚转岗到后端的工程师以及想系统梳理 place 阶段方法论的中级工程师。我不会只讲命令怎么敲而是把每个决策背后的“为什么”讲透——为什么这个阶段要优先修 setup为什么 congestion 要在 place 阶段就压下去为什么有些 io pin 到 bufg 的路径会在 place 阶段报出 poor placement 的警告。这些问题的答案决定了你跑 place 时到底是在“碰运气”还是在“做设计”。place 阶段的输入是 floorplan 后的 DEF、时序约束 SDC、工艺库文件以及各种 physical 约束。输出是一个合法化的 placed DEF以及一份能反映当前时序和拥塞状况的报告。听起来简单但中间涉及的优化维度非常多global placement 决定大致位置legalization 把 cell 对齐到 row 和 sitedetailed placement 再做局部微调同时 timing-driven placement 会不断根据 setup/hold 的 slack 去推动 cell 移动。整个过程是一个多目标优化的博弈你不可能让所有指标同时最优必须根据项目阶段和设计特点做取舍。我个人的习惯是place 阶段先把 congestion 和 setup 这两件事盯死。原因很直接congestion 在 place 阶段如果已经超过 1% 的 overflow到了 route 阶段基本会恶化到 3% 以上那时候再修就是拆东墙补西墙而 setup 在 place 阶段修不到位CTS 之后 clock skew 一加进来slack 会进一步恶化到时候能动的空间更小。所以 place 阶段的目标不是“跑完就行”而是“给后面留足余量”。2. place 阶段的核心细节解析与实操要点2.1 std cell 布局的基本原理与 legalization 机制std cell 的布局不是随便找个空位塞进去就完事。工艺库里的每个 std cell 都有固定的高度通常是 site 高度的整数倍宽度则各不相同。place 工具在做 global placement 时会先把 cell 当成可重叠的点来优化线长和时序得到一个理想位置然后 legalization 阶段再把这些重叠的 cell 推开对齐到合法的 row 和 site 上。这个过程有点像停车场停车——global placement 是告诉你“理想车位在哪”legalization 是实际把车停进划线车位里如果理想位置附近没空位就得挪到远一点的地方。这里有个关键点legalization 之后cell 的实际位置和理想位置之间会有偏差这个偏差会直接影响线长和时序。如果设计密度太高legalization 的挪动幅度会很大时序和拥塞都会恶化。所以我在 place 之前一定会检查 floorplan 的利用率一般控制在 70% 到 75% 之间比较稳妥超过 80% 就要警惕。你可以用checkPlace命令来检查 placement 的合法性它会报告 overlap、row 对齐、site 对齐等问题。注意legalization 之后一定要跑一次checkPlace如果报告里有大量 overlap 或者 unplaced cell说明 floorplan 的 row 定义或者 blockage 设置有问题不要急着往下跑。2.2 setup 时序优化的时机与策略place 阶段修 setup 的逻辑和 CTS 之后完全不同。CTS 之前 clock 是理想时钟工具看到的是零 skew、零 latency 的理想情况所以 place 阶段修出来的 setup slack 是“乐观值”。但这不代表 place 阶段不用修 setup——恰恰相反place 阶段要把 setup 修到足够好给 CTS 之后的 skew 和 latency 留出余量。我的经验是place 阶段结束时 WNS 最好能到 -50ps 以内TNS 控制在 -200ps 以内这样 CTS 之后即使恶化 100 到 150ps也还有机会在 route 阶段修回来。place 阶段修 setup 的主要手段有几个cell sizing把驱动能力弱的 cell 换成强的、buffer insertion在长线上插 buffer、cell movement把关键路径上的 cell 拉近、logic restructuring用工具做 pin swap 或者 gate merge。这些手段里cell sizing 和 buffer insertion 对 congestion 的影响最大因为强驱动 cell 和 buffer 都会占用更多面积和布线资源。所以我在 place 阶段会分两轮修 setup第一轮用place_opt_design做全局优化第二轮用optDesign -preCTS做增量优化中间穿插 congestion 检查避免时序修上去了但拥塞爆了。2.3 congestion 的成因与 place 阶段的控制手段congestion 的本质是布线资源供不应求。在 place 阶段cell 的分布决定了布线需求的分布如果某个区域 cell 密度过高或者 pin density 过大就会形成 congestion hotspot。常见的 congestion 成因包括macro 周围的 channel 太窄、std cell 行利用率不均、高 pin 密度的 cell 扎堆、power stripe 占用了太多布线层。place 阶段控制 congestion 的手段主要有调整 floorplan 的利用率分布、设置 partial blockage 或者 density screen、用place_opt_design的 congestion 优化选项、手动挪动 macro 或者调整 channel 宽度。我一般会在 place 之后跑reportCongestion或者用 congestion map 来看 hotspot 分布如果 overflow 超过 0.5%就要定位具体区域并分析原因。有时候 congestion 不是全局问题而是某个 macro 的 pin 太密导致的局部热点这时候调整 macro 的 orientation 或者加一个小的 blockage 就能解决。2.4 io pin 到 bufg 的 poor placement 警告解读热词里提到的 “poor placement for routing between an io pin and bufg” 是一个很典型的 place 阶段警告。它的意思是工具发现从某个 io pin 到 bufgclock buffer之间的路径在当前的布局下布线会非常困难可能因为距离太远、中间有 blockage、或者绕行路径太长。这个警告不能忽略因为 io pin 到 bufg 的路径通常是 clock path 的一部分如果这条路径的 insertion delay 太大或者 skew 太差会影响整个 clock tree 的质量。处理这个警告的思路是先确认这个 io pin 是不是真的需要连到 bufg如果是 clock 输入 pin那就要确保 bufg 的位置离 io pin 足够近中间没有 macro 或者 blockage 阻挡。如果 bufg 是工具自动插入的可以手动把它挪到 io pin 附近或者用create_clock的时候指定 source latency 来放宽约束。如果这个路径不是关键路径也可以在 place 阶段先忽略等 CTS 之后再看实际影响。3. place 阶段实操过程与核心环节实现3.1 place 前的准备工作与检查清单在跑 place 之前我会做一轮完整的检查确保输入文件和环境没有问题。这个检查清单包括floorplan 的 DEF 是否包含正确的 row 和 track 定义、SDC 是否覆盖了所有时钟和 io 约束、工艺库的 lef 和 lib 是否匹配、power plan 是否已经完成并且没有 DRC 问题、blockage 和 endcap 是否已经放置好。这些检查看起来琐碎但任何一个环节出问题place 的结果都不可信。具体命令上我会先跑checkDesign做整体检查然后checkPlace看 floorplan 的合法性再用reportCongestion看初始拥塞情况。如果初始 congestion 就很差说明 floorplan 需要调整不要硬跑 place。另外我会确认setPlaceMode里的关键参数比如-congEffort设成 high、-timingDriven打开、-maxDensity设成 0.75 左右。这些参数决定了 place 引擎的优化力度和方向。3.2 place_opt_design 的关键参数与运行策略place_opt_design是 place 阶段的主命令它的参数设置直接决定了优化效果。我常用的参数组合是setPlaceMode -congEffort high \ -timingDriven true \ -maxDensity 0.75 \ -placeIOPins false \ -modulePlan false place_opt_design -outDir ./place_result-congEffort high会让工具在 place 时更积极地分散 cell降低 congestion但代价是线长可能略微增加。-timingDriven true打开时序驱动工具会根据 slack 去推动 cell 移动。-maxDensity 0.75限制最大密度避免局部过密。-placeIOPins false表示不移动 io pin因为 io pin 的位置通常在 floorplan 阶段已经定好了。跑完place_opt_design之后我会先看 summary 报告里的 WNS、TNS、congestion overflow 这三个指标。如果 WNS 差于 -100ps 或者 overflow 超过 1%我会先分析原因而不是直接跑第二轮优化。常见的做法是如果 congestion 差先加 blockage 或者降低局部密度如果 setup 差先看关键路径的 cell 分布确认是不是 legalization 挪动太大导致的。3.3 optDesign -preCTS 增量优化与 setup 修复place_opt_design跑完之后通常还需要一轮optDesign -preCTS来做增量优化。这一轮的重点是修 setup同时控制 congestion 不恶化。命令大概是这样setOptMode -effort high \ -fixCap true \ -fixTran true \ -fixSetup true \ -setupTargetSlack 0.0 optDesign -preCTS -outDir ./opt_result-fixCap和-fixTran会修 max cap 和 max tran 的 violation这些 violation 如果不修到了 route 阶段会变成 DRC 问题。-fixSetup true打开 setup 修复-setupTargetSlack 0.0表示目标是把 slack 修到 0 以上。实际项目中我一般会把 target slack 设成 0.05ns 左右留一点余量给后面的 CTS。这一轮跑完之后我会对比 place 前后的 congestion map确认 setup 修复没有导致新的 hotspot。如果发现某个区域 congestion 明显恶化就要定位是哪些 cell 被挪过去了必要时手动加 blockage 或者调整 cell 位置。3.4 congestion 分析与 hotspot 定位实操congestion 分析我一般用两种方式一种是看reportCongestion的文本报告它会列出 overflow 最严重的区域和具体的 gcell 坐标另一种是看 GUI 里的 congestion map用颜色直观地显示热点分布。文本报告适合定位具体坐标GUI 适合看整体趋势。定位到 hotspot 之后我会先分析成因。如果是 macro 周围 channel 太窄就考虑调整 macro 位置或者加宽 channel如果是 std cell 密度过高就加 partial blockage 或者降低局部利用率如果是 pin density 太高就看看是不是某些高 pin 密度的 cell 扎堆了可以考虑分散它们。有时候 hotspot 是因为 power stripe 占用了太多 routing track这时候需要和 power plan 的同事确认能不能调整 stripe 宽度或者间距。提示congestion 修复不要一次加太多 blockage否则会把 cell 挤到别的地方形成新的 hotspot。建议每次只处理一个区域修完再看整体 map。3.5 place 结果的质量评估与交付标准place 跑完之后怎么判断结果好不好我一般看这几个指标WNS 和 TNS 是否在预期范围内、congestion overflow 是否低于 0.5%、max cap 和 max tran 的 violation 是否清零、cell density 是否均匀、有没有 unplaced cell 或者 overlap。这些指标里WNS 和 congestion 是硬指标其他是辅助指标。如果这些指标都达标就可以把 placed DEF 和相关的报告交付给 CTS 阶段。交付的时候我会附上一份简短的说明包括 place 阶段用的关键参数、当前的 WNS/TNS、congestion 情况、以及已知的风险点。这份说明能帮 CTS 工程师快速了解 place 的结果避免重复排查。4. 常见问题与排查技巧实录4.1 place 后 setup 恶化严重的排查思路place 后 setup 恶化严重最常见的原因是 legalization 挪动太大。你可以对比 global placement 和 legalization 之后的 cell 位置如果发现关键路径上的 cell 被挪了很远说明局部密度太高legalization 被迫做了大范围调整。解决办法是降低局部密度或者给关键路径上的 cell 加 region 约束让它们待在理想位置附近。另一个常见原因是 cell sizing 过度。工具为了修 setup会把很多 cell 换成强驱动版本强驱动 cell 的输入 cap 更大会加重前级驱动负担形成新的 violation。这时候需要检查reportCap和reportTran看看是不是有新的 max cap 或者 max tran violation。如果有就要在optDesign里打开-fixCap和-fixTran让工具同时修这些 violation。4.2 congestion 在 place 阶段压不下去的应对策略congestion 压不下去通常不是 place 参数的问题而是 floorplan 的问题。我遇到过好几次place 参数怎么调都没用最后发现是某个 macro 的 channel 只有 5um而实际布线需要 15um。这种情况下唯一的办法是回到 floorplan 阶段调整 macro 位置或者 channel 宽度。如果 floorplan 没问题那就要看是不是 power plan 占用了太多 routing 资源。有些项目为了 IR drop 达标会把 power stripe 做得很密结果 signal routing 的 track 不够用。这时候需要和 power 工程师协商看能不能在某些区域减少 stripe 或者换用更窄的 stripe。还有一种情况是 pin density 过高。某些 std cell 的 pin 特别密如果它们扎堆在一起局部布线需求会远超供给。解决办法是用setPlaceMode -placeIoPin或者手动加 density screen把这些 cell 分散开。4.3 io pin 到 bufg 路径的修复方法io pin 到 bufg 的 poor placement 警告修复方法取决于这条路径的性质。如果是 clock path那就要确保 bufg 离 io pin 足够近中间没有阻挡。你可以手动把 bufg 挪到 io pin 附近或者用create_clock的-source选项指定 source latency让工具知道这条路径有额外的延迟预算。如果这条路径不是 clock path而是普通的数据路径那就要看它的 slack 是否紧张。如果 slack 很松可以忽略这个警告如果 slack 紧张就要考虑调整 io pin 的位置或者加 buffer 来改善布线。4.4 place 阶段常见问题速查表问题现象可能原因排查方法解决手段WNS 恶化超过 100pslegalization 挪动太大对比 global 和 legal 后的 cell 位置降低局部密度加 region 约束congestion overflow 1%floorplan channel 太窄看 congestion map 定位 hotspot调整 macro 位置或加宽 channelmax cap violation 增多cell sizing 过度跑 reportCap 看 violation 分布打开 -fixCap 同时修unplaced cell 存在row 定义或 blockage 问题跑 checkPlace 看报告修正 floorplan 的 row 和 blockageio pin 到 bufg 警告bufg 离 io pin 太远看路径距离和中间阻挡挪 bufg 或加 source latency4.5 实操心得与避坑经验做了这么多项目我在 place 阶段踩过的坑总结下来有几个。第一个是不要迷信工具的默认参数place_opt_design的默认congEffort是 medium对于高利用率设计来说不够一定要手动设成 high。第二个是不要等到 place 跑完才看 congestion最好在 floorplan 阶段就用reportCongestion预估一下提前发现风险。第三个是 setup 修复不要一次修太狠分两轮做中间检查 congestion避免时序修上去了但布线爆了。还有一个经验是place 阶段的报告一定要仔细看尤其是 warning 和 info 级别的消息。很多问题在 warning 里已经提示了比如某个 cell 被挪到了很远的地方、某条路径的 estimated delay 异常大这些信息能帮你提前定位问题而不是等到 CTS 或者 route 阶段才发现。最后分享一个小技巧如果 place 之后 congestion 和 setup 都达标但你对结果不太放心可以跑一次route -global做快速全局布线看看实际的 routing overflow 和 via 数量。这个步骤花不了多少时间但能给你一个更接近真实的 congestion 评估比单纯看 place 阶段的估算更靠谱。