【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
随着芯片规模不断增大，Backend 实现不再是简单把 flat flow 放大运行就能解决的问题。
对于一个小规模 block，下面这样的 flat 流程可能已经足够：
import design
floorplan
placement
CTS
routing
signoff
但是对于一个大型 SoC，设计中可能包含：
多个 CPU cluster
多个 DSP / NPU / GPU block
大规模 SRAM 和 ROM 阵列
模拟或混合信号 macro
高速接口 IP
多个 power domain
多个 clock domain
多个物理 partition
多个外部 vendor IP block
如果每个 cell、每条 net、每个 pin、每个 clock、每个 macro、每条 route、每条 timing arc、每个物理验证 marker 都放在一个 flat database 中处理，整个流程很快就会达到实际工程上的极限。
这里的问题不仅是工具容量。更深层的问题是工程可控性。
一个大规模芯片 Backend Flow 需要一种机制，用来：
把设计划分成可管理的工程单元
保留正确的接口信息
在合适的时候隐藏内部细节
把 block 结果合并回 top level
验证多个 view 之间的一致性
在 block 级和 full-chip 级同时完成 timing 与 physical verification closure
这就是 hierarchical design flow 的目的。
层次化 Backend Flow 不只是“把大设计切成小块”。它是一个通过明确的抽象和 release contract，在 block 与 top level 之间传递 logical、physical、timing、power 和 verification 信息的工程系统。
1. 为什么 flat flow 存在实际极限
Flat flow 有一个很大的优点：简单。
所有对象都在同一个 design database 中：
all instances
all nets
all pins
all ports
all macros
all clocks
all routes
all constraints
all scenarios
all reports
对于小规模和中等规模设计，这种方式很方便。工具可以看到完整设计状态，命令也可以直接作用在整个数据库上。
但是当设计规模继续增加，flat flow 会遇到几个结构性限制。
2. 容量限制
Backend 工具内部维护的是大规模 object graph。
一个 physical implementation database 可能包含：
instances
library masters
nets
pins
ports
rows
sites
macros
blockages
vias
wire shapes
route guides
timing arcs
clock paths
power structures
constraints
scenarios
physical verification markers
这些对象不是相互独立的。它们之间存在密集关系。
对于 timing analysis，工具会构建 timing graph：
pin nodes
cell arcs
net arcs
clock arcs
constraint edges
scenario-specific arrival times
scenario-specific required times
derates
exceptions
对于 routing，工具会维护 routing resource graph：
routing tracks
layer capacity
gcell capacity
blockages
preferred directions
via rules
spacing rules
congestion maps
DRC windows
当所有这些内容都在 full-chip scale 下以 flat 方式加载和优化时，memory usage、runtime 和 debug complexity 都会快速增长。
对于某些设计，flat implementation 仍然可能可行；但随着规模增加，它会越来越难以控制。
3. 收敛限制
大型 SoC 不只是“更大”。它们通常更加异构。
芯片不同区域可能具有完全不同的实现特征：
| 区域 / Block 类型 | 典型 Backend 挑战 |
|---|---|
| CPU cluster | timing 紧、逻辑密度高、clock 要求激进 |
| GPU / NPU block | datapath 密度高、routing 压力大 |
| NoC / bus fabric | 宽互连、长距离全局 routing |
| SRAM 区域 | macro pin access、channel planning |
| analog / mixed-signal macro | keepout、boundary rule、integration constraint |
| low-power island | isolation、level shifter、power switch、retention |
| high-speed interface | IO 对齐、clocking、特殊 routing rule |
如果所有这些问题都放在一个 flat run 中求解，debug 会变得非常困难。
一个 timing violation 可能来自：
block 内部 critical path
top-level interconnect path
不现实的 timing budget
不合适的 boundary pin location
clock latency mismatch
过期的 block timing model
一个 routing congestion issue 可能来自：
macro channel 过窄
top-level route 跨越 block boundary
block pin 过度集中在某一侧
block obstruction data 不完整
block 内部过度占用上层 routing layer
一个 DRC issue 可能来自：
block 内部 routing
top-level routing
block 与 top shape 之间的 boundary spacing
GDS merge mismatch
错误的 abstract obstruction data
Flat flow 会让这些根因更难分离。
Hierarchical flow 通过让每个 block 拥有更清晰的本地 closure target，同时保留受控的 top-level integration path，从而改善收敛性。
4. 协作限制
大型 SoC 通常不可能由一个人或一个团队完成实现。
不同团队可能分别负责：
CPU block
interconnect block
memory subsystem
peripheral subsystem
top integration
clocking
power network
PV signoff
timing signoff
ECO closure
如果 full chip 只以一个 flat backend database 的形式存在，并行工作会非常困难。
Hierarchical flow 允许 block 团队独立工作，同时由 top-level 团队控制集成。
关键不只是目录分开。真正关键的是 interface discipline：
每个 block 接收什么
每个 block 必须交付什么
top 可以对每个 block 做哪些假设
merge 时必须重新检查什么
5. Hierarchical Flow 的核心思想
Hierarchical flow 把一个大型实现问题，转换为多个 block-level 问题加一个 integration 问题。
一个简化结构如下：
Top Design
├── Block A
│ ├── local standard cells
│ ├── local macros
│ ├── local clock tree
│ ├── local routing
│ └── local reports
├── Block B
│ ├── local placement
│ ├── local timing closure
│ └── local physical verification
├── Block C
│ └── local implementation database
└── Top-Level Implementation
├── block placement
├── top-level routing
├── global power network
├── global clock / reset
└── full-chip signoff
Top 在每次迭代中并不总是需要看到每个 block 的所有内部细节。
相反，每个 block 提供 abstract view。
Top-level flow 使用这些 view 完成集成。
这形成了一个受控分离：
block internal implementation
↓
block abstraction
↓
top-level integration
↓
full-chip verification
↓
feedback to blocks if needed
6. Hierarchical Flow 架构
这个架构说明 hierarchical flow 是一个迭代系统。
不是 block 实现一次后简单贴回 top 就结束了。Top 与 block 需要不断交换 constraints、abstracts、reports 和 feedback，直到 local closure 和 global closure 都一致。
7. 三个关键词：Partition、Abstract、Integration
Hierarchical flow 可以通过三个核心概念理解：
Partition
Abstract
Integration
8. Partition：把设计切成工程单元
Partitioning 定义 block 结构。
好的 partition 不应只考虑 logical hierarchy。
常见 partitioning 标准包括：
logical function
team ownership
clock domain
power domain
macro grouping
physical region
dataflow direction
timing criticality
routing channel availability
IP reuse boundary
verification boundary
不好的 partition 会带来大量 top-level 问题。
例如：
太多 signal 跨越 block boundary
critical path 频繁跨 partition
block pin 集中在一个区域
power domain 被物理 partition 切开
clock tree 被迫穿过尴尬边界
top-level routing channel 过载
好的 partition 能减少 cross-boundary complexity。
目标不是简单让 block 变小。目标是让它们可以被独立实现，并且能够干净地集成。
9. Partition 质量检查清单
| 问题 | 为什么重要 |
|---|---|
| cross-block net 是否有限且清楚？ | 过多 crossing 会制造 routing 和 timing 压力。 |
| critical path 是否主要在 block 内部，或者已经预算化？ | 不受控的 cross-block timing 很难收敛。 |
| 物理区域是否合理匹配 logical hierarchy？ | 映射不佳会导致 pin 和 routing 混乱。 |
| power domain 是否被尊重？ | Low-power 结构需要一致的 domain boundary。 |
| clock domain 是否处理清楚？ | Clock distribution 和 skew group 依赖边界选择。 |
| macro 是否自然成组？ | Macro placement 强烈影响 channel 和 block shape。 |
| block 是否能被团队拥有和 release？ | Hierarchical flow 也是一种协作模型。 |
10. Abstract：在不暴露全部细节的情况下表示 block
Block abstract 是对已完成或部分完成 block 的简化但足够的模型。
Top-level 工具并不总是需要 block 内部所有 standard cell、route 和 timing graph。
但它必须知道足够的信息，才能正确集成 block。
一个 block abstract 可能包括：
physical boundary
pin locations
routing obstructions
placement obstructions
power pins
clock pins
block-level timing model
logical black-box model
power intent fragment
PV-relevant layout view
Abstract 的目的，是受控的信息压缩。
信息太少，会让 top integration 不安全。
信息太多，会让 top integration 过重，削弱 hierarchy 的意义。
11. Physical Abstract
Physical abstract 表示 block 在 top-level physical implementation 中的物理视图。
它通常提供：
block boundary
block origin and size
block pins
pin layers
pin shapes
routing blockages
placement blockages
macro obstructions
power pin shapes
keepout regions
allowed routing layers
Top-level 工具需要这些信息来：
放置 block instance
把 top-level net 连接到 block pin
避免 routing 穿过被阻塞区域
构建 top-level power structure
检查 boundary legality
避免 pin access 问题
Physical abstract 不只是 block outline 的图片。它是 block 的 top-level physical contract。
12. Physical Abstract 模型
Abstract 必须保留会影响 top-level placement、routing、power connectivity 和 PV merge 的信息。
13. Timing Abstract
Timing abstract 把 block 内部 timing 行为压缩为 top-level flow 可用的模型。
它可能描述：
input-to-register timing requirements
register-to-output timing behavior
input-to-output combinational paths
generated clocks
clock latency assumptions
interface constraints
mode/corner/scenario-specific timing data
Top 不能忽略 block timing。
但 top 也不一定能展开每个 block 的完整 timing graph。
Timing abstraction 在容量和准确度之间取得平衡。
有用的 timing abstract 应该回答：
block 对输入 timing 有什么要求？
block 在输出端提供什么 timing 行为？
哪些 clock 是 generated 或 propagated？
哪些 path 纯属内部并已 closed？
哪些 path 对接口敏感？
14. Logical Abstract
Logical abstract 定义 block 的 netlist-level interface。
它可能包含：
module name
port list
port directions
bus definitions
black-box declaration
power/ground ports
test ports
clock/reset ports
interface constraints
Logical abstract 允许 top-level netlist integration 不暴露内部实现。
但它必须与以下内容保持一致：
RTL module interface
physical abstract pins
timing abstract ports
LVS source netlist
block GDS top cell
如果 logical abstract 与 physical abstract 不一致，top integration 可能通过早期检查，但在 LVS 或 timing signoff 阶段失败。
15. Power Abstract
对于 low-power SoC，每个 block 可能还需要 power abstract。
它可以包括：
block 内部 power domains
power pins
ground pins
always-on supply requirements
isolation boundary assumptions
level shifter requirements
retention supply requirements
power switch interface
power state assumptions
这些信息对于 top-level power network construction 和 power-aware verification 非常关键。
一个 block 可能在物理上集成正确，但如果它的 supply semantics 不清晰，仍然会在 power-aware checks 中失败。
16. Integration：重建 top-level context
Top-level integration 使用 block abstract 构建 full-chip design context。
它必须解决：
block placement
top-level connectivity
global clock and reset
top-level routing
global power network
cross-block timing
block boundary DRC
full-chip LVS
PV merge
top-level ECO
Integration 不是文件拼接。
它是多 view 一致性的重建过程。
Top 必须确保每个 block abstract、top netlist、top constraints、power intent、GDS、DEF 和 timing model 都描述同一个设计。
17. Top-Down 和 Bottom-Up 必须协同工作
Hierarchical flow 既不是纯 top-down，也不是纯 bottom-up。
它需要两个方向同时工作。
18. Top-Down Planning
Top-down planning 从 full chip 出发。
它定义：
block placement
block size
block aspect ratio
block boundary
pin planning
timing budget
routing channel
power distribution strategy
clock distribution strategy
IO alignment
inter-block connection plan
Top-down planning 防止 block-level implementation 破坏全局设计。
例如，如果一个 block 没有 top-level pin planning 就直接实现，它的 pin 可能落在让 top-level routing 极其困难的位置。
19. Bottom-Up Implementation
Bottom-up implementation 在本地完成每个 block 的 closure。
它关注：
block floorplan
block placement
block CTS
block routing
block timing
block DRC
block LVS
block abstract generation
block release package
Bottom-up implementation 通过确保每个 block 都是可信的实现单元，使整体问题变得可管理。
20. Top 与 Block 之间的迭代
真实流程是迭代的：
这个状态机很重要。
Hierarchical flow 不是一次性 pipeline。它是 constraints 与 implementation evidence 的受控交换。
21. Boundary Pin 是 interface contract
Block pin 是 hierarchical flow 中最重要的部分之一。
它们定义 top 如何连接 block。
Block pin planning 会影响：
top-level route quality
inter-block timing
pin access
boundary congestion
clock/reset entry
power connectivity
cross-domain signal handling
ECO impact
差的 pin plan 会让 top integration 非常困难。
常见 pin planning 问题包括：
pin 集中在某一边
高速信号远离 source 或 destination
clock pin 放在不方便的位置
bus bit 排序不合理
power pin 与 top-level grid 不对齐
pin 被内部 obstruction 阻挡
pin group 附近 routing channel 不足
Block pin planning 应该被视为 engineering contract，而不是外观上的 layout 细节。
22. Budgeting：把全局目标分配到 block
Hierarchical flow 需要预算。
Budget 把 top-level 目标转换为 block-level target。
典型 budget 包括：
area budget
timing budget
power budget
pin budget
routing layer budget
clock latency budget
congestion budget
IR drop budget
PV cleanliness target
没有 budget，每个 block 可能局部优化得很好，但 full-chip 目标失败。
例如：
block 内部 timing closed，但 boundary pin 放得很差
block 使用了过多 top routing layer
block 功耗过高
block 面积扩大，挤压 global routing channel
block 假设了不现实的 clock latency
Budgeting 是 hierarchical backend flow 的治理机制。
23. 示例 Budget 表
| Budget 类型 | Block-Level 含义 | 缺失时的 Top-Level 风险 |
|---|---|---|
| Timing budget | input/output delay target | inter-block timing 失败 |
| Area budget | block size 和 utilization limit | floorplan 不受控增长 |
| Power budget | dynamic/leakage target | IR drop 和热风险 |
| Pin budget | pin count 和 pin side planning | boundary congestion |
| Routing budget | allowed layer usage | top-level routing resource 不足 |
| Clock budget | latency/skew assumptions | post-integration timing mismatch |
| PV budget | DRC/LVS cleanliness target | merge signoff 延迟 |
24. Merge 不是简单拼接
Merge 常被误解为：
combine top GDS and block GDS
实际上，merge 必须保持多个 view 的一致性。
一次 merge 操作必须检查：
coordinate system
database units
origin alignment
cell naming
hierarchy naming
layer mapping
block boundary
top route to block pin connection
power/ground net naming
physical obstruction consistency
abstract versus full-view consistency
如果其中任一项错误，full-chip signoff 都可能失败。
常见 merge failure 包括：
GDS overlap
missing block layout
wrong top cell
cell name collision
short/open at block boundary
boundary DRC violation
wrong power net stitching
LVS mismatch caused by hierarchy mismatch
top route entering blocked block area
因此，merge 是 signoff-critical operation。
25. Abstract-to-Full 一致性
Hierarchical flow 中最重要的检查之一，是 abstract view 是否与最终 full block implementation 匹配。
例如：
| Abstract 项 | Full Block 项 | 不一致的风险 |
|---|---|---|
| block boundary | final GDS boundary | merge 时 overlap 或 gap |
| pin location | final layout pin | top route 连接到错误区域 |
| obstruction | internal metal shapes | top route 产生 DRC |
| power pin | actual power geometry | power connectivity mismatch |
| timing model | final block timing | top STA 不准确 |
| logical port | final netlist port | LVS 或 connectivity 失败 |
Top integration 不应该接受未通过 abstract-to-full consistency 检查的 block release。
26. Hierarchical Signoff
Hierarchical signoff 有两个层级：
block-level signoff
top-level signoff
Block-level signoff 检查：
block timing
block DRC
block LVS
block antenna
block extraction
block IR/EM
block abstract correctness
block release completeness
Top-level signoff 检查：
inter-block timing
top-level DRC
top-level LVS
global power network
top-level routing
boundary DRC
top-level extraction
full-chip PV merge
full-chip timing
一个 block 自身可以是 clean 的，但仍可能产生 top-level issue。
典型 boundary-level issue 包括：
top route 与 block shape 之间的 spacing
错误的 block obstruction
pin access conflict
power connection mismatch
top-level clock route conflict
inter-block timing budget violation
因此：
block clean + top clean + boundary clean = hierarchical closure
三者缺一不可。
27. Hierarchical Data Architecture
一个可维护的 hierarchical flow 应该显式组织数据。
典型结构如下：
backend-flow-engineering-practice/
blocks/
block_a/
input/
scripts/
db/
abstract/
reports/
logs/
release/
block_b/
input/
scripts/
db/
abstract/
reports/
logs/
release/
top/
input/
scripts/
db/
reports/
logs/
integration/
signoff/
common/
tech/
libraries/
constraints/
pv_config/
methodology/
目录结构应反映工程 ownership：
block implementation data stays with the block
abstract data is released to top
top integration uses released views
reports record version and closure status
28. Block Release Contract
一个 block release 不应该只是一个 database file。
一个稳健的 block release package 应该包括：
release manifest
block netlist or black-box model
block DEF
block LEF / physical abstract
block GDS / OASIS
timing abstract
SDC fragment or interface constraints
power intent fragment
PV summary
STA summary
known issues
version tag
change log
owner information
Release manifest 应该回答：
block version 是什么？
包含哪些文件？
使用了哪些 tool 和 library version？
top cell / module name 是什么？
覆盖了哪些 timing scenario？
哪些 PV check 已通过？
还有哪些 known limitation？
没有 release contract，hierarchical integration 会非常脆弱。
29. Top Integration Contract
Top-level flow 也应该有 integration contract。
对于每个 block，top 应检查：
required files exist
manifest is present
abstract can be loaded
pin names match top netlist
pin locations are valid
block boundary matches placement
power pins are declared
timing abstract matches scenario setup
GDS cell name is unique
PV views are available
known issues are reviewed
Block 不应该只是因为“文件存在”就被集成。
只有当 release package 通过结构化检查后，block 才应该进入 integration。
30. Demo 设计：LAY-BE-26_hierarchical_flow
LAY-BE-26_hierarchical_flow 的目的，是演示 hierarchical backend flow 的工程骨架。
它不需要实现完整 SoC。它应该展示 top/block 结构、abstract 文件、manifest 和 integration check 如何协同工作。
建议输入数据
data/top/sample_top.v
data/blocks/block_a_blackbox.v
data/blocks/block_b_blackbox.v
data/blocks/block_a.abstract.lef
data/blocks/block_b.abstract.lef
data/blocks/block_a.interface.sdc
data/blocks/block_b.interface.sdc
data/manifests/block_a_manifest.yaml
data/manifests/block_b_manifest.yaml
建议脚本
scripts/run_hierarchical_demo.csh
scripts/clean.csh
tcl/01_read_top_structure.tcl
tcl/02_check_block_manifest.tcl
tcl/03_check_abstract_files.tcl
tcl/04_check_top_block_pins.tcl
tcl/05_generate_integration_report.tcl
建议报告
reports/hierarchy_tree.rpt
reports/block_manifest_check.rpt
reports/abstract_file_check.rpt
reports/abstract_pin_check.rpt
reports/top_block_interface.rpt
reports/integration_checklist.rpt
reports/hierarchical_flow_summary.rpt
Demo 应验证：
top design contains block instances
each block has a release manifest
each block has required abstract views
block pins match top-level connections
top integration has a checklist
release and integration status are reportable
31. Demo Flow Diagram
这个 demo 有意聚焦工程结构。
Hierarchical flow 的失败，更多时候来自缺失或不一致的 view，而不是单条命令失败。
Demo 应该把这些依赖显式化。
32. 常见失败模式
| Failure Pattern | 典型根因 | 工程动作 |
|---|---|---|
| Block abstract missing | block release 不完整 | 拒绝 release，要求更新 manifest |
| Pin mismatch | top netlist 与 block abstract 不同步 | 重新生成 abstract 或更新 top netlist |
| Boundary DRC after merge | abstract obstruction 不完整 | 更新 physical abstract 并重新 merge |
| Timing mismatch | timing abstract 过期 | 从最新 block 重新生成 timing model |
| GDS cell collision | 不同 block 存在重复 cell name | 强制命名规范 |
| Power net mismatch | VDD/VSS 命名不一致 | 定义 global power net map |
| Top route enters block | abstract 中缺少 obstruction | 修正 abstract generation |
| LVS mismatch | hierarchy 或 black-box policy 不一致 | 对齐 LVS source 与 layout hierarchy |
| Wrong block version | release tracking 缺失 | 强制 manifest 和 version check |
这些不是随机错误。它们是 hierarchical contract 薄弱的症状。
33. 方法论：把 hierarchy 视为 contract system
成熟的 hierarchical backend flow 是围绕 contract 构建的。
Partition Contract
哪些 logic 属于哪个 block
哪个团队拥有哪个 block
哪些 boundary 是稳定的
Abstract Contract
block 必须提供哪些 view
每个 view 必须保留哪些信息
如何检查 abstract-to-full consistency
Budget Contract
每个 block 必须满足哪些 timing、area、power、route 和 clock target
Release Contract
哪些文件和报告定义了有效的 block release
Merge Contract
block 被 top integration 接受前必须通过哪些检查
Signoff Contract
哪些检查在 block level closed
哪些检查在 top level closed
哪些检查需要 full-chip verification
用 contract 思考，hierarchical flow 才可管理。
如果没有 contract，hierarchy 只是一堆断开的文件。
34. 方法论：区分 Local Closure 与 Global Closure
一个 block 可以局部 clean，但全局仍然有问题。
因此，closure 必须从两个维度评估。
| Closure 类型 | 核心问题 |
|---|---|
| Local block closure | block 内部是否合法、timed、routed、verified？ |
| Interface closure | block boundary、pins、timing model、power pins 是否正确？ |
| Top integration closure | top 能否基于这个 block 完成 route、time、power 和 verify？ |
| Full-chip signoff closure | merge 后的 layout 是否通过最终 signoff？ |
这是 hierarchical flow 中最重要的概念之一：
local success is not automatically global success
Interface contract 是连接 local success 与 global success 的桥梁。
35. 工程要点
大型芯片 Backend 复杂度不能用放大版 flat flow 管理，因此 hierarchical design flow 是必要的。
核心工程思想包括：
把设计 partition 成可管理的 block
用合适的信息层级 abstract 每个 block
把全局目标 budget 到本地实现目标
用 manifest 和 reports release block
通过结构化检查 merge block
验证 block-level 与 top-level 一致性
把 integration failure 反馈给正确 owner
Hierarchy 的真正价值不只是减少 runtime。它的真正价值是工程控制。
一个设计良好的 hierarchical flow 可以让团队判断：
问题属于哪里
哪个 view 不一致
哪个团队拥有修复责任
哪个 report 证明 closure
哪个 release version 可以安全集成
36. 总结
大型 SoC Backend Flow 不能被视为“instance 更多的小 block flow”。
随着规模增加，flat implementation 会面临 capacity、convergence 和 collaboration 限制。
Hierarchical design flow 通过引入以下机制解决这些限制：
partitioning
block implementation
physical abstraction
timing abstraction
power abstraction
top integration
block release contracts
merge checks
hierarchical signoff
feedback loops
核心思想是：
block 内部在本地实现
block interface 被 abstract 并 release
top-level integration 使用这些 abstract
full-chip signoff 验证组合后的结果
成熟的 hierarchical backend flow 不只是技术流程。它是一个控制复杂度的工程系统。
Final Thought
大规模芯片 Backend 实现不是 flat-flow scaling problem。
它是 complexity-management problem。
Partitioning、abstraction、merging 和 signoff 是把不可管理的 full-chip database 转换为受控工程 closure loop 的关键机制。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
13
0- 0
已为社区贡献17条内容
所有评论(0)