【Backend Flow工程实践 26】Hierarchical Design Flow：为什么大芯片后端必须分层、抽象、合并和签核？

作者：Darren H. Chen
方向：Backend Flow / 后端实现流程 / EDA 工具工程 / Hierarchical Design
demo：LAY-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 graph：

pin arc cell arc net arc clock arc constraint edge scenario-specific arrival / required time

routing 也不是只画线，而是要维护：

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、Integration

Hierarchical Flow 可以用三个关键词理解。

1. Partition

Partition 是把设计划分成可独立处理的 block。

划分依据可能包括：

逻辑层次 功能边界 时钟域 电源域 物理区域 宏单元分布 团队责任边界 时序关键路径 数据通路结构

好的 partition 应该减少跨边界复杂度。

如果一个 block 与外部信号交互过多，边界 pin 数量巨大，或者 critical path 大量跨 block，那么这个 partition 可能不合理。

2. Abstract

Abstract 是 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 shapes

Abstract 的质量决定 top-level flow 是否可信。

3. Integration

Integration 是把多个 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 consistency

Integration 不是把 block 文件简单拼起来，而是重新建立 top-level 一致性。

四、Top-Down 与 Bottom-Up：两种方向必须结合

Hierarchical Flow 通常同时包含 top-down 和 bottom-up。

1. Top-Down

Top-down 从全芯片角度规划 block。

它回答：

每个 block 放在哪里？ block 边界多大？ macro 如何分布？ top-level channel 是否够？ IO 和 block pin 如何对齐？ power grid 如何跨 block？ clock / reset 如何进入 block？

Top-down 的价值在于：保证局部实现不会破坏全局结构。

2. Bottom-Up

Bottom-up 从 block 内部实现开始，把 block 做成可交付单元。

它回答：

block 内部 placement 是否合法？ block 内部 CTS 是否收敛？ block 内部 route 是否干净？ block timing 是否满足 interface budget？ block 是否能导出 abstract？ block 是否能通过局部 signoff？

Bottom-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 abstract，top-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

如果没有 budget，block team 只能各自闭合局部目标。

但局部最优不等于全局最优。

例如：

某个 block 内部 timing 很好，但 boundary pin 放错，导致 top route 很差 某个 block 用了过多上层 metal，导致 top-level routing 资源不足 某个 block 功耗超出预期，导致 top IR drop 不收敛 某个 block 面积扩大，压缩了相邻 block channel

Budget 是分层工程的契约机制。

九、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 timing

Top-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 naming

Hierarchical 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

每一个箭头都需要报告和检查。

十二、工程方法论：如何设计一个可维护的分层 flow？

1. 先定义 hierarchy contract

在开始实现前，要明确每个 block 对 top 提供什么。

boundary pin list clock/reset interface power pins abstract format timing model signoff criteria

2. 再定义 directory contract

每个 block 应该有固定目录结构。

block_A/ ├─ input/ ├─ scripts/ ├─ db/ ├─ abstract/ ├─ reports/ ├─ logs/ └─ release/

3. 然后定义 release contract

Block release 不能只交一个数据库。

应该至少包括：

version manifest netlist DEF / LEF / GDS view timing abstract power intent fragment SDC fragment DRC / LVS / STA summary known issues change log

4. 最后定义 merge check

Top 每次吸收 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

这一整套工程机制。

没有 abstract，top 无法高效集成。

没有 budget，block 无法服务全局目标。

没有 release contract，团队协作会失控。

没有 merge check，full-chip signoff 风险会集中爆发。

结尾一句话

大芯片后端不是把小芯片 flow 放大，而是必须通过分层、抽象、合并和签核，把不可管理的全局复杂度拆成可控制的工程闭环。