1. 数字后端里 place 到底在解决什么问题数字后端流程里place布局这一步经常被新手当成把标准单元摆到芯片上的机械操作实际上它是整个后端流程里对最终 PPAPower、Performance、Area影响最大的环节之一。我见过太多项目综合出来的网表时序看着还行一进 place 就崩或者 place 阶段时序勉强收敛到 CTS 和 route 阶段又全面反弹。根本原因往往不是工具不行而是对 place 阶段到底在优化什么、约束什么、牺牲什么没有清晰认知。先把位置摆正place 处在综合synthesis和时钟树综合CTS之间。它拿到的是综合后的门级网表、工艺库、时序约束SDC、物理约束floorplan、DEF。它要交付的是一个合法的、拥塞可控的、时序初步收敛的布局结果供后续 CTS 和 route 使用。注意初步收敛这四个字——place 阶段不可能也不应该追求时序完全干净因为此时时钟还是理想时钟ideal clock真正的时钟树还没建。place 阶段的核心任务是给后续步骤打好物理基础同时把明显的时序违例压下去。关键词里出现了 std cell、setup、congestion这三个词基本概括了 place 阶段的三大战场标准单元的合法摆放、建立时间setup的优化、拥塞congestion的控制。这三者天然互相拉扯——你把单元摆密了省面积拥塞就上来了你把关键路径的单元拉近改善 setup可能就制造了局部拥塞你为了降拥塞把单元摊开面积和线长又上去了。place 的功夫本质上就是在这三者之间找平衡点。还有一个热词是poor placement for routing between an io pin and bufg这是工具报出的典型布局警告说的是 IO pin 和 BUFG全局时钟缓冲之间的布线资源分配不合理。这类问题在 place 阶段就要预判等到 route 阶段再救代价极大。所以这篇内容我会围绕 place 阶段的实际操作展开讲清楚流程、约束、拥塞处理、时序优化以及那些文档里不会写、只有踩过坑才知道的经验。适合读这篇的人刚入行做数字后端的工程师、从综合转后端的朋友、需要理解 place 阶段在干什么的验证或前端人员以及准备后端面试、想把 place 这块讲明白的候选人。2. place 之前的准备工作约束和文件一个都不能少2.1 输入文件清单与常见缺失项place 跑之前输入文件必须齐。少一个要么工具报错要么结果完全不可信。标准清单如下文件类型作用缺失后果门级网表 (.v)综合后的电路连接关系无法读入设计工艺库 (.lib/.db)标准单元时序、功耗信息无法做时序分析物理库 (LEF)单元和宏的物理尺寸、引脚位置无法布局时序约束 (SDC)时钟、IO、例外路径定义时序优化无目标floorplan (DEF)芯片尺寸、宏位置、IO 位置布局无边界工艺技术文件 (tech LEF)金属层、布线规则布线资源无法计算我踩过最典型的坑是 LEF 和 lib 版本不匹配。有一次项目里 LEF 用的是某个库的早期版本lib 用的是更新版本单元引脚位置对不上place 能跑完但 route 阶段大量 DRC 违例查了两天才定位到是库版本问题。所以进 place 之前务必确认 LEF、lib、网表三者来自同一套库、同一版本。2.2 SDC 约束里 place 阶段真正起作用的部分SDC 里约束一大堆但 place 阶段真正吃紧的是这几类create_clock定义时钟周期和波形。place 阶段时钟是理想的但周期决定了 setup 优化的目标。set_input_delay / set_output_delayIO 时序约束直接影响 IO 路径的优化力度。set_clock_uncertainty时钟不确定性place 阶段通常给一个预估值比如 0.1~0.2ns给后续 CTS 留余量。set_false_path / set_multicycle_path例外路径减少无效优化让工具把精力放在真路径上。这里有个经验place 阶段的 clock uncertainty 不要设得太乐观。我一般会按目标周期的 5%~8% 来给比如 1GHz1ns的设计给 0.05~0.08ns。给太小place 阶段时序看着漂亮CTS 一加真实时钟树延迟就崩给太大place 阶段过度优化面积和功耗浪费。2.3 物理约束floorplan 质量决定 place 上限floorplan 是 place 的地基。宏单元macro摆得好不好直接决定 place 阶段拥塞能不能压住。几个硬性经验宏之间留出足够的布线通道一般宏间距不小于布线 pitch 的 20~30 倍具体看工艺。宏的朝向要统一规划避免引脚朝向内部造成局部拥塞。IO pin 的位置要和内部逻辑的分布匹配别把大量逻辑堆在远离对应 IO 的一侧。给标准单元区域预留 10%~15% 的利用率余量别一上来就摆满。热词里那个poor placement for routing between an io pin and bufg警告很多时候就是 floorplan 阶段 IO 和时钟资源没规划好导致的。BUFG 通常要靠近它驱动的时钟区域如果 IO pin 和 BUFG 被摆到了芯片两端布线资源自然紧张。3. place 的核心阶段拆解从全局到细节3.1 全局布局Global Placement先粗后细的数学优化全局布局的目标是给每个标准单元确定一个大致位置允许单元重叠。工具在这一步用的是解析式或二次规划类的算法把线长wirelength作为主要优化目标同时考虑密度density约束。这个阶段你要关注的核心指标是线长总半周长线长HPWL越小越好。密度分布有没有局部密度过高。时序预估工具会做初步的时序分析看 setup 违例情况。全局布局阶段工具会反复迭代平衡线长和密度。我一般会在这个阶段观察 density map如果出现明显的红色高密度区域说明 floorplan 或约束有问题要尽早干预别等到 detailed placement 才发现。3.2 详细布局Detailed Placement合法化与局部优化详细布局要把重叠的单元分开让每个单元落在合法的 row 和 site 上同时尽量不破坏全局布局的优化结果。这一步的核心是合法化legalization和局部微调。详细布局之后单元位置就固定了时序和拥塞的真实情况才显现出来。这时候要重点看setup 违例路径哪些路径还差多少。congestion map哪些区域布线资源紧张。利用率整体和局部的标准单元密度。3.3 时序驱动布局Timing-Driven Placement现代工具默认都是时序驱动的。它会在布局过程中对关键路径上的单元施加引力让它们靠得更近减少线延迟从而改善 setup。时序驱动布局的关键在于权重设置。工具会给关键路径更高的权重但权重给太高会导致这些单元过度聚集制造局部拥塞。我的经验是先让工具自动跑一轮看时序和拥塞的平衡情况再针对性调整。3.4 拥塞驱动布局Congestion-Driven Placement拥塞是 place 阶段最头疼的问题之一。拥塞的本质是某个区域的布线需求超过了可用的布线资源。工具在布局时会预估布线需求如果发现某区域需求过高会把单元往外推。拥塞驱动的核心手段调整单元密度降低高拥塞区域的利用率。宏通道预留宏之间留够通道。引脚密度控制避免大量单元引脚朝向同一方向。我处理拥塞的经验是先看 congestion map 定位热点再分析热点成因——是宏摆得太近还是某类单元比如多引脚的标准单元扎堆还是 IO 约束导致逻辑聚集。对症下药比盲目调参数有效得多。4. 拥塞问题的定位与实战处理4.1 读懂 congestion map颜色背后的含义congestion map 是 place 阶段最重要的诊断工具。通常用颜色表示布线资源的占用率绿色资源充足占用率低。黄色资源偏紧需要关注。红色资源超载必然产生 DRC 违例。看 congestion map 不能只看颜色要结合层次。全局的红色可能只是局部热点局部的红色才是真问题。我一般会从全局到局部逐层放大定位到具体的 row 和区域。4.2 拥塞的四大成因与对应策略成因表现处理策略宏通道不足宏之间红色带状区域增大宏间距调整宏朝向单元密度过高大面积黄色/红色降低利用率扩大 die 面积引脚密度集中局部点状红色打散高引脚密度单元加 paddingIO 逻辑聚集靠近 IO 的区域红色调整 IO 约束或逻辑分布这里重点说引脚密度。有些标准单元比如多路选择器、复杂门引脚多如果大量这类单元扎堆局部布线需求会暴增。处理办法是给这类单元加 placement paddinghalo让它们之间留出额外空间。4.3 那个io pin 和 bufg 之间布线差的警告怎么破热词里提到的 poor placement for routing between an io pin and bufg本质是 IO pin 到 BUFG 的布线路径资源不足。BUFG 是全局时钟缓冲通常驱动大片时钟区域。如果 IO pin比如时钟输入引脚离 BUFG 太远或者中间被宏挡住布线就会很困难。处理思路物理上拉近把 BUFG 摆到靠近时钟输入 IO 的位置。预留通道IO 到 BUFG 之间预留专用布线通道别让宏或高密度单元挡路。约束引导用物理约束或 region 约束把相关逻辑引导到合理区域。检查时钟规划确认时钟网络规划是否合理BUFG 的数量和位置是否匹配时钟域划分。这个警告如果在 place 阶段出现一定要处理别拖到 route。route 阶段再改可能要重新布局代价翻倍。4.4 拥塞优化的迭代节奏拥塞优化不是一次调好的要迭代。我的节奏一般是第一轮默认参数跑看 baseline 的 congestion map 和时序。第二轮针对红色热点调整 floorplan 或加 padding。第三轮微调布局参数density target、congestion effort。第四轮确认时序没有因为降拥塞而恶化。每一轮都要对比时序和拥塞两个维度别只顾一头。我见过为了降拥塞把单元摊得太开结果线长暴涨setup 全面违例得不偿失。5. setup 时序优化在 place 阶段的分寸把握5.1 为什么 place 阶段不能追求时序全清place 阶段时钟是理想的没有时钟树延迟和时钟偏斜skew。此时时序干净不代表 CTS 之后还干净。CTS 会引入时钟树延迟可能让原本勉强满足的路径违例。所以 place 阶段的目标是留有余量而不是全部清零。我一般会把 place 阶段的 setup 目标设为WNS最差负 slack控制在目标周期的 5% 以内TNS总负 slack尽量小但不强求为零。给 CTS 和 route 留出优化空间。5.2 关键路径的识别与针对性优化place 阶段优化 setup核心是识别关键路径并让工具重点照顾。手段包括设置路径权重给关键路径更高权重。逻辑重组在不改变功能的前提下调整逻辑层级减少路径级数。单元尺寸调整把关键路径上的单元换成驱动能力更强的版本upsize。物理拉近让关键路径的单元靠得更近。这里有个经验upsize 要谨慎。换大驱动单元能改善延迟但会增加功耗和面积还可能加剧局部拥塞。我一般只在关键路径的瓶颈单元上做 upsize不做全局替换。5.3 setup 和 hold 在 place 阶段的取舍place 阶段主要优化 setuphold 一般留到 CTS 之后修。原因是 hold 依赖真实时钟树place 阶段修 hold 没有意义。但要注意place 阶段如果 setup 优化过度比如大量插入 buffer可能给后续 hold 修复制造麻烦。所以 place 阶段的 buffer 插入要克制。5.4 时序优化的常见误区误区一slack 越正越好。过度优化浪费面积和功耗还可能导致后续步骤没有优化空间。误区二只看 WNS 不看 TNS。WNS 好但 TNS 差说明违例路径多整体质量不行。误区三忽略时钟不确定性。uncertainty 给太小place 时序虚好CTS 崩盘。6. 工具实操以主流流程为例的关键命令与参数6.1 读入设计与约束以常见的数字后端流程为例place 之前要先读入网表、库、约束# 读入工艺库和物理库 read_lib typical.lib read_lef tech.lef read_lef stdcell.lef read_lef macro.lef # 读入门级网表 read_verilog design.v link_design design # 读入时序约束 read_sdc design.sdc # 读入 floorplan read_def floorplan.def顺序很重要先库后网表先约束后布局。顺序错了工具可能报找不到单元或约束不生效。6.2 place 主命令与关键参数# 基础布局 place_opt_design # 或分步执行 place_design -congestion -timing_driven关键参数说明-congestion开启拥塞驱动。-timing_driven开启时序驱动。-effort high提高优化力度耗时增加。我一般先用默认 effort 跑一轮看结果再决定是否提高。6.3 布局后的检查命令# 检查时序 report_timing -max_paths 100 -nworst 10 # 检查拥塞 report_congestion # 检查利用率 report_utilization # 检查 DRC布局合法性 check_placement -verbosecheck_placement一定要跑确认没有单元重叠、没有非法位置。布局不合法后面全白搭。6.4 保存结果# 保存布局后的设计 save_design place_result.enc write_def place_result.def保存 DEF 是为了给后续 CTS 和 route 用。建议每轮优化都存一个版本方便回退对比。7. 那些文档不写的 place 实战经验7.1 利用率不是越低越好新手常以为利用率越低越安全其实不然。利用率太低单元摊得开线长增加时序变差面积浪费。我一般把标准单元区域利用率控制在 70%~80%具体看工艺和设计复杂度。太高拥塞太低浪费。7.2 宏的摆放要留白宏周围一定要留白。宏的引脚密集布线需求高如果紧贴标准单元局部拥塞必然严重。我一般会在宏周围留出相当于几个 row 高度的空间作为布线缓冲。7.3 别忽视 power plan 对 place 的影响电源规划power plan在 place 之前或同时进行。电源网格power grid会占用布线资源如果电源网格太密留给信号线的资源就少拥塞加剧。所以 power plan 要和 place 协同考虑别各干各的。7.4 迭代时保留中间结果place 优化往往要跑很多轮。每轮都存 DEF 和报告方便对比。我习惯用版本号命名比如 place_v1、place_v2配合一个简单的记录表记下每轮的参数和关键指标。这样出问题能快速定位是哪轮改坏的。7.5 面试常问的 place 问题准备后端面试的朋友place 这块高频问题包括place 阶段为什么用理想时钟拥塞的成因有哪些怎么处理setup 和 hold 在 place 阶段怎么取舍利用率一般控制在多少为什么时序驱动布局的原理是什么这些问题没有标准答案要结合项目经验回答。我建议准备一两个自己踩过的坑讲清楚排查过程比背概念有说服力。8. 从 place 到后续流程的衔接要点place 做完不是终点要顺利交接给 CTS 和 route。几个衔接要点DEF 要干净布局合法没有重叠和非法位置。时序报告要留档作为 CTS 的 baseline。拥塞热点要记录告诉后续步骤重点关注哪些区域。约束要同步SDC 如果有更新要确保 place 和 CTS 用的是同一版。我个人的体会是place 阶段多花一天把基础打牢后面 CTS 和 route 能省好几天。反过来place 阶段糊弄过去后面每一步都在还债。这个账做过几个项目就明白了。最后分享一个小技巧place 阶段每次改参数别一次改多个。一次只改一个变量观察结果变化才能知道到底是哪个参数起了作用。一次改一堆结果好了不知道为啥好坏了不知道为啥坏等于白跑。这个习惯我在带新人的时候反复强调比任何工具手册都管用。