作者Darren H. Chen方向Backend Flow / 后端实现流程 / EDA 工具工程 / Hierarchical DesigndemoLAY-BE-26_hierarchical_flow标签Backend Flow、EDA、Hierarchical Flow、Physical Abstract、Top Down、Bottom Up、Partition、Merge、Signoff、Large SoC芯片规模变大之后后端实现最先遇到的问题不是某个命令不会用而是整个设计空间已经大到无法用单一 flat flow 处理。一个小设计可以直接import design floorplan placement CTS routing signoff但一个大型 SoC 往往包含多个 CPU cluster 多个 DSP / NPU / GPU block 多个 SRAM / ROM / analog macro 多个高速接口 多个电源域 多个时钟域 多个 physical partition 多个 IP vendor block如果全部扁平化到一个后端工程中处理会很快遇到数据库容量过大 运行时间过长 内存不可控 拥塞难以定位 时序收敛困难 跨团队协作困难 block 版本难以管理 top-level signoff 难以推进因此大芯片后端必须进入 hierarchical design flow。分层后端的本质不是简单把大设计切成小设计而是建立一套能够在 block 与 top 之间传递逻辑、物理、时序、电源和验证信息的工程体系。本文从底层原理、架构模型和方法论角度解释为什么大芯片后端必须分层、抽象、合并和签核。一、Flat Flow 的上限在哪里Flat Flow 的优点是简单。所有对象都在一个数据库里所有 cell 所有 net 所有 pin 所有 macro 所有 clock 所有 route 所有 constraint 所有 report这种方式在中小规模设计中很直接。但随着规模增加flat flow 会遇到几个根本瓶颈。1. 容量瓶颈设计规模增加后工具内部需要维护的对象数量急剧增加instances nets pins timing arcs routing tracks vias shapes constraints scenarios这些对象之间还有复杂关联。例如 STA 不是只看 cell而是要构建 timing graphpin arc cell arc net arc clock arc constraint edge scenario-specific arrival / required timerouting 也不是只画线而是要维护grid graph capacity blockage preferred direction via rule spacing rule congestion map DRC check window当所有对象堆在一个 flat database 中内存、运行时间和调试复杂度都会快速上升。2. 收敛瓶颈大设计不是只有“大”还会有多种局部特性。例如CPU cluster 时序紧 bus fabric 拥塞重 SRAM 区域 pin access 难 IO 周边有特殊规则 analog block 需要 keepout low power boundary 有 isolation / level shifter如果所有问题都在 top flat flow 中一起解决很难判断问题来自哪里。时序不好是 block 内部路径问题还是 top-level interconnect 问题拥塞严重是 macro 摆放问题还是 top-level channel 不足DRC 失败是 block 内 route 问题还是 block boundary merge 问题Flat flow 让问题定位变得很困难。3. 协作瓶颈大型 SoC 通常不是一个人完成。会有不同团队负责CPU block NoC / bus block memory subsystem peripheral block top integration PV / STA / ECO如果只有一个 flat 工程团队之间很难并行推进。所以分层 flow 不只是技术选择也是组织协作方式。二、Hierarchical Flow 的本质把大设计拆成可管理的工程单元Hierarchical Flow 的目标可以概括为把一个不可直接管理的大问题拆成多个可独立实现、可抽象交付、可重新合并的小问题。典型结构如下Top Design ├─ Block A │ ├─ standard cells │ ├─ local macros │ ├─ local clock tree │ └─ local route ├─ Block B │ ├─ standard cells │ ├─ local macros │ └─ local timing closure ├─ Block C └─ Top-level interconnect / IO / power / clock每个 block 可以被独立实现同时向 top 提供抽象模型。Top 不需要知道 block 内部每一个 detail cell 和 route segment但必须知道block boundary block pins block obstruction block timing model block power pins block physical abstract block GDS / DEF / LEF view这就是 hierarchical flow 的核心block 内部详细实现top 看到抽象视图。三、分层后端中的三个关键词Partition、Abstract、IntegrationHierarchical Flow 可以用三个关键词理解。1. PartitionPartition 是把设计划分成可独立处理的 block。划分依据可能包括逻辑层次 功能边界 时钟域 电源域 物理区域 宏单元分布 团队责任边界 时序关键路径 数据通路结构好的 partition 应该减少跨边界复杂度。如果一个 block 与外部信号交互过多边界 pin 数量巨大或者 critical path 大量跨 block那么这个 partition 可能不合理。2. AbstractAbstract 是 block 对外提供的简化模型。它不是随意裁剪而是保留 top integration 所需的信息。常见 abstract 包括Physical abstract : boundary / pins / blockages / metal shapes Timing abstract : interface timing / constraint model Power abstract : power pins / power domains / supply model Logical abstract : module interface / black box model PV abstract : GDS / layout boundary / rule-relevant shapesAbstract 的质量决定 top-level flow 是否可信。3. IntegrationIntegration 是把多个 block abstract 合并到 top 中并完成 top-level 实现和签核。Top integration 关注block placement top-level routing global clock / reset power network inter-block timing IO planning PV merge ECO consistencyIntegration 不是把 block 文件简单拼起来而是重新建立 top-level 一致性。四、Top-Down 与 Bottom-Up两种方向必须结合Hierarchical Flow 通常同时包含 top-down 和 bottom-up。1. Top-DownTop-down 从全芯片角度规划 block。它回答每个 block 放在哪里 block 边界多大 macro 如何分布 top-level channel 是否够 IO 和 block pin 如何对齐 power grid 如何跨 block clock / reset 如何进入 blockTop-down 的价值在于保证局部实现不会破坏全局结构。2. Bottom-UpBottom-up 从 block 内部实现开始把 block 做成可交付单元。它回答block 内部 placement 是否合法 block 内部 CTS 是否收敛 block 内部 route 是否干净 block timing 是否满足 interface budget block 是否能导出 abstract block 是否能通过局部 signoffBottom-up 的价值在于让每个 block 先局部闭合。3. 两者之间的迭代真实 flow 不是单向的。常见过程是Top initial floorplan ↓ block partition / budget ↓ block implementation ↓ abstract generation ↓ top integration ↓ feedback to block ↓ block update ↓ top re-integration这是一种分层迭代系统。五、Physical Abstract为什么 top 不需要知道 block 内部全部细节Physical abstract 的作用是在 top-level flow 中代表 block。Top 通常需要知道block size block boundary block pins placement blockage routing blockage power pins metal obstruction keepout region但不一定需要知道block 内部每一个 standard cell block 内部每一根 detail route block 内部每一个局部优化细节这是一种信息压缩。可以类比为block full database: 详细内部世界 block abstract: 对 top 有意义的边界合同Physical abstract 的关键不是“少”而是“刚好够”。太少会导致 top integration 缺信息。例如pin 信息缺失top 无法连线 obstruction 缺失top route 穿进 block 内部 power pin 缺失top power network 无法连接 boundary 不准确merge 后 DRC 爆炸太多则会失去 abstract 的意义top database 又变重。六、Timing Abstract为什么 block 必须有接口时序模型分层 flow 中top 无法每次都展开 block 内部完整 timing graph。因此 block 需要提供 timing abstract。它至少要表达input pin 到内部寄存器的时序需求 内部寄存器到 output pin 的时序行为 input pin 到 output pin 的组合路径 clock latency / uncertainty / generated clock 信息 mode / corner / scenario 相关接口模型如果没有 timing abstracttop-level STA 会面临两个极端。完全不看 block 内部top timing 不可信 完全展开 block 内部容量和运行时间不可控Timing abstract 的作用就是在两者之间找到平衡。它把 block 内部复杂 timing graph 压缩成 top 可以使用的接口模型。七、Boundary Pin分层 flow 的接口合同在 hierarchical flow 中block pin 非常关键。Block pin 是 top 和 block 的接口合同。它决定top-level routing 如何接入 block inter-block timing 如何计算 block 内部 route 如何收口 pin access 是否可达 cross-domain signal 如何处理 ECO 是否影响接口一个糟糕的 pin plan 会导致后续大量问题。例如pin 集中在一侧造成 top route 拥塞 高速信号 pin 太远导致 interconnect delay 过大 clock pin 位置不合理导致 skew 难控制 power pin 不清晰导致 power connection 问题 block pin 与 macro obstruction 冲突所以分层 flow 里pin planning 不是小事而是 top/block 协同的核心。八、Budget把全局目标分配给局部实现分层实现必须有 budget。Budget 的本质是把 top-level 目标拆给 block。常见 budget 包括area budget pin budget timing budget power budget congestion budget route layer budget clock latency budget IR drop budget如果没有 budgetblock team 只能各自闭合局部目标。但局部最优不等于全局最优。例如某个 block 内部 timing 很好但 boundary pin 放错导致 top route 很差 某个 block 用了过多上层 metal导致 top-level routing 资源不足 某个 block 功耗超出预期导致 top IR drop 不收敛 某个 block 面积扩大压缩了相邻 block channelBudget 是分层工程的契约机制。九、Merge为什么合并不是简单拼接很多人会把 merge 理解为把 block GDS 拼到 top GDS但真正的 merge 要复杂得多。合并时需要保证坐标系统一致 层定义一致 cell name 不冲突 power / ground net 命名一致 block boundary 对齐 route shape 不冲突 top-level net 与 block pin 对应 abstract 与 full view 一致 PV rule deck 能识别 hierarchy如果其中一个环节错了可能出现GDS overlap LVS mismatch missing connection short / open DRC at boundary cell name collision power net split所以 merge 是一次多视图一致性操作而不是文件拼接。十、Hierarchical Signoff局部通过不代表全局通过分层 signoff 要同时考虑 block-level 和 top-level。Block-level signoff 关注block 内部 DRC block 内部 LVS block 内部 STA block 内部 IR / EM block abstract 正确性 block interface timingTop-level signoff 关注inter-block timing top-level routing DRC global power network full-chip LVS boundary DRC chip-level clock/reset IO / pad / package interface局部通过不代表全局通过。因为全局问题往往发生在边界block boundary spacing pin access top route 与 block obstruction inter-block timing path power connection crossing full-chip LVS net namingHierarchical signoff 的核心是block 内部闭合 block 接口可信 top 集成闭合。三者缺一不可。十一、分层 flow 的底层数据架构从数据架构看hierarchical flow 至少要管理这些视图。block_full_db/ full detail implementation block_abstract/ physical abstract timing abstract logical blackbox power abstract block_reports/ timing report DRC report LVS report utilization report abstract verification report top_db/ top floorplan block placements top routes global power network top_reports/ inter-block timing top DRC top LVS merge check更系统地看Block Implementation ↓ Abstract Generation ↓ Abstract Verification ↓ Top Integration ↓ Full-Chip Signoff ↓ Feedback / ECO每一个箭头都需要报告和检查。十二、工程方法论如何设计一个可维护的分层 flow1. 先定义 hierarchy contract在开始实现前要明确每个 block 对 top 提供什么。boundary pin list clock/reset interface power pins abstract format timing model signoff criteria2. 再定义 directory contract每个 block 应该有固定目录结构。block_A/ ├─ input/ ├─ scripts/ ├─ db/ ├─ abstract/ ├─ reports/ ├─ logs/ └─ release/3. 然后定义 release contractBlock release 不能只交一个数据库。应该至少包括version manifest netlist DEF / LEF / GDS view timing abstract power intent fragment SDC fragment DRC / LVS / STA summary known issues change log4. 最后定义 merge checkTop 每次吸收 block release都应该运行 merge check。版本是否匹配 文件是否齐全 坐标和单位是否一致 pin 是否一致 abstract 是否能加载 top route 是否避让 boundary DRC 是否干净 inter-block timing 是否合理十三、Demo 26 应该验证什么LAY-BE-26_hierarchical_flow适合做成一个分层数据结构和 abstract 检查 demo。输入可以包括sample_top.v block_a_blackbox.v block_b_blackbox.v block_a.abstract.lef block_b.abstract.lef block_a.interface.sdc block_b.interface.sdc block_manifest.yaml过程可以包括读取 top netlist 识别 block instance 检查 block abstract 是否存在 检查 block pin 是否匹配 检查 top/block boundary 信息 生成 hierarchy summary 生成 abstract consistency report 生成 top integration checklist输出可以包括reports/hierarchy_tree.rpt reports/block_manifest_check.rpt reports/abstract_pin_check.rpt reports/top_block_interface.rpt reports/integration_checklist.rpt这个 demo 的重点不是完成真实大型 SoC 分层实现而是展示 hierarchical flow 的工程骨架。十四、常见分层 flow 风险常见风险包括block boundary 变化但 top 没更新 pin 位置变化但 abstract 没重新生成 block timing model 过旧 top 使用了错误版本 block block 内部 ECO 后接口不一致 power net 命名规则不统一 GDS cell name 冲突 block obstruction 缺失导致 top route 穿越 boundary DRC 在 merge 后才出现这些问题的共同点是不是单个命令错误而是多视图版本一致性问题。所以 hierarchical flow 的成熟度取决于版本、manifest、abstract、report、merge check 是否形成闭环。十五、总结Hierarchical Design Flow 的目标不是为了把流程变复杂而是为了让大芯片后端变得可管理。它解决的是这些问题容量问题 运行时间问题 团队协作问题 局部收敛问题 top-level 集成问题 多视图一致性问题 full-chip signoff 问题从底层架构看分层 flow 的关键不是“切 block”而是建立Partition Abstract Budget Release Merge Signoff Feedback这一整套工程机制。没有 abstracttop 无法高效集成。没有 budgetblock 无法服务全局目标。没有 release contract团队协作会失控。没有 merge checkfull-chip signoff 风险会集中爆发。结尾一句话大芯片后端不是把小芯片 flow 放大而是必须通过分层、抽象、合并和签核把不可管理的全局复杂度拆成可控制的工程闭环。