【Backend Flow工程实践 23】Backend-to-PV Handoff：从 DEF/GDS 到物理验证，后端如何完成签核交接？

作者：Darren H. Chen

方向：Backend Flow / 后端实现流程 / EDA 工具工程 / Physical Verification Handoff

demo：LAY-BE-23_backend_to_pv_handoff

标签：Backend Flow、EDA、Physical Verification、PV Handoff、DEF、GDS、LVS、DRC、PEX、Signoff

在后端实现流程中，Backend-to-PV Handoff 是一个非常关键但经常被低估的环节。

很多人以为后端工具导出 GDS 之后，工作就结束了。

真实情况是：

text 复制代码

GDS 只是交付物之一
DEF 只是物理状态之一
netlist 只是逻辑视图之一
PV rule deck 只是验证入口之一
真正困难的是：这些视图必须互相一致

后端到物理验证的交接，不是把一个文件丢给 PV 工具，而是把一个已经实现的芯片设计，用一组标准文件、规则配置、环境参数和约定关系，准确传递给 signoff 流程。

如果 handoff 做得不好，会出现很多典型问题：

text 复制代码

DRC 工具读到的 layer 和后端工具不一致
LVS 中 layout netlist 和 source netlist 名称不匹配
top cell 名称不一致
GDS hierarchy 和 netlist hierarchy 不一致
power/ground net 识别错误
black box / macro 处理方式不一致
PEX 输出无法回注 STA
waiver 和 violation 追踪混乱

这些问题表面上是"PV 报错"，本质上是后端交付包没有定义清楚。

本文从底层原理、架构模型和工程方法论角度解释：Backend-to-PV Handoff 到底要交接什么，以及如何把它做成可复现、可审计、可闭环的工程步骤。

一、Backend-to-PV Handoff 的本质：多视图一致性交接

后端工具内部维护的是一个复杂设计数据库。

这个数据库里同时包含：

text 复制代码

逻辑连接
物理位置
routing geometry
cell instance
macro hierarchy
power network
clock network
constraints
parasitic estimate
technology layer

而物理验证工具通常不会直接读取这个内部数据库，而是读取导出的标准数据。

常见 handoff 文件包括：

text 复制代码

GDS / OASIS     : 最终版图几何
DEF             : 设计物理状态、placement、routing、rows、tracks 等
Verilog netlist : source / implementation netlist
LEF             : macro / stdcell abstract
SPICE netlist   : LVS source 或 extracted netlist 场景
SPEF / DSPF     : 寄生参数文件
SDF             : 延迟回注文件
Layer map       : 后端层名到 PV 层号的映射
Rule deck config: DRC/LVS/PEX 规则配置
Runset          : PV 运行参数集合
Waiver database : 已知例外和豁免记录

这些文件不是孤立文件，而是同一个设计的不同视图。

可以抽象成：

text 复制代码

Backend Database
    ├─ logical view      → Verilog / SPICE
    ├─ physical view     → DEF
    ├─ geometry view     → GDS / OASIS
    ├─ abstract view     → LEF
    ├─ parasitic view    → SPEF / DSPF
    ├─ delay view        → SDF
    └─ verification view → rule deck / runset / waiver

Handoff 的核心目标就是保证这些视图描述的是同一个设计。

二、为什么只交 GDS 不够？

GDS 记录的是版图几何。

它非常重要，但它不是完整设计语义。

GDS 擅长表达：

text 复制代码

polygon
path
cell hierarchy
layer/datatype
text label
structure reference

但 GDS 不天然表达完整的设计意图。

例如，它不直接告诉你：

text 复制代码

哪些 net 是 power
哪些 net 是 ground
哪个 Verilog module 是 top
某个 polygon 对应哪个 logical net
某个 macro 是否应作为黑盒处理
某些 IP 是否有独立 LVS rule
哪些 violation 已经被 waiver
哪个 SPEF 对应哪个 corner

这些信息需要通过其他文件和约定补充。

所以 Backend-to-PV Handoff 不能只交：

text 复制代码

design.gds

而应该交付一个完整 package：

text 复制代码

pv_handoff/
├─ layout/
│  ├─ design.gds
│  └─ design.oas
├─ def/
│  └─ design.def
├─ netlist/
│  ├─ design.v
│  └─ lvs_source.sp
├─ lef/
│  ├─ stdcell.lef
│  └─ macro.lef
├─ pv_config/
│  ├─ layer.map
│  ├─ drc.runset
│  ├─ lvs.runset
│  └─ pex.runset
├─ constraints/
│  └─ design.sdc
├─ parasitic/
│  └─ design.spef
├─ waiver/
│  └─ waiver.db
└─ reports/
   └─ handoff_manifest.rpt

这里最关键的是 handoff_manifest.rpt。

它应该明确说明：

text 复制代码

top cell 是什么
每个文件是什么版本
每个文件从哪个 backend run 导出
使用哪个 technology / layer map
使用哪个 PV rule deck
power/ground net 名称是什么
macro/IP 如何处理
哪些检查必须运行
哪些 waiver 已存在

没有 manifest 的 handoff，很容易变成一堆无法追踪来源的文件。

三、DRC Handoff：几何规则检查的交接重点

DRC handoff 的核心是让 PV 工具能正确理解版图几何和规则。

关键输入通常包括：

text 复制代码

GDS / OASIS
rule deck
layer map
top cell
run directory
result database path
check selection
waiver configuration

其中最容易出错的是 layer map。

后端工具内部可能使用：

text 复制代码

M1
VIA1
M2
VIA2
M3

而 GDS 中可能是：

text 复制代码

layer 10 datatype 0
layer 11 datatype 0
layer 20 datatype 0

PV rule deck 又可能使用自己的 layer 定义。

如果 layer map 错了，DRC 看到的几何世界就错了。

常见后果包括：

text 复制代码

金属层被识别成错误层
via 被识别成普通 metal
text label 层不匹配
density check 结果异常
某些规则完全没有作用到正确 layer

因此 DRC handoff 必须检查：

text 复制代码

layer name 与 GDS layer/datatype 是否一致
rule deck 中的 layer 定义是否匹配
top cell 是否正确
GDS hierarchy 是否完整
所有 required IP layout 是否包含
waiver 是否应用到正确 database

DRC 的 handoff 不是"跑一下规则"，而是确认 PV 工具看到的版图世界和后端导出的版图世界一致。

四、LVS Handoff：逻辑连接和版图连接的一致性检查

LVS 是 Layout Versus Schematic。

它检查的是：

text 复制代码

layout extracted connectivity
        是否等价于
source netlist connectivity

LVS handoff 比 DRC 更复杂，因为它不仅要读几何，还要理解连接。

关键输入通常包括：

text 复制代码

GDS / OASIS
source netlist
LVS rule deck
top cell / top module
power / ground net name
black box definition
standard cell / macro recognition
device extraction rule
text label rule

LVS 中常见问题包括：

text 复制代码

layout top cell 与 source top module 不一致
power/ground 名称不同
bus 命名规则不同
hierarchy flatten 策略不同
macro black box 处理不一致
标准单元 recognition 失败
text label 没有正确绑定到 net
short / open 导致 net mismatch

例如，后端 netlist 中 power net 叫：

text 复制代码

VDD
VSS

但 layout label 里叫：

text 复制代码

vdd!
gnd!

如果没有明确映射，LVS 可能会认为它们不是同一个 net。

所以 LVS handoff 必须提前定义：

text 复制代码

global net name
power/ground alias
case sensitivity
bus delimiter
hierarchy mapping
black box policy
macro source handling

LVS 失败时，不要第一时间怀疑 layout 错。

很多 LVS failure 的根因其实是 handoff 语义不一致。

五、PEX Handoff：从版图几何提取寄生参数

PEX 是寄生参数提取。

它的目标是从最终版图中提取：

text 复制代码

resistance
capacitance
coupling capacitance
device parasitic
interconnect parasitic

这些数据最终会进入：

text 复制代码

post-layout STA
signal integrity analysis
power analysis
gate-level simulation

PEX handoff 关注的是：

text 复制代码

layout geometry 是否完整
extraction rule 是否匹配 technology
netlist 是否能和 extracted view 对齐
coupling 模型是否正确
corner / mode 是否明确
输出格式是否符合后续 STA 工具要求

常见 PEX 输出包括：

text 复制代码

SPEF
DSPF
SPICE extracted netlist
reduced parasitic model

PEX 的特殊之处在于，它不仅是 PV 的输出，也会成为后续 timing closure 的输入。

因此它在流程中形成一个回路：

text 复制代码

Backend route
      ↓
Export layout
      ↓
PEX extraction
      ↓
SPEF / DSPF
      ↓
STA / SI / power analysis
      ↓
Timing ECO / Route ECO

所以 PEX handoff 要特别关注：

text 复制代码

文件命名
corner 命名
net name mapping
hierarchy mapping
unit consistency
RC scaling
coupling reduction policy

如果 PEX 文件无法稳定回注 STA，后端 timing signoff 就无法闭环。

六、Backend-to-PV Handoff 的架构模型

可以把 handoff 看成一个边界协议。

text 复制代码

Backend Implementation System
        │
        │ export
        ▼
Handoff Package
        │
        ├─ layout geometry
        ├─ physical state
        ├─ logical source
        ├─ technology mapping
        ├─ verification config
        ├─ waiver / exception
        └─ manifest
        │
        ▼
Physical Verification System
        │
        ├─ DRC
        ├─ LVS
        ├─ PEX
        └─ Result Review
        │
        ▼
Violation / Extracted Data / Closure Feedback
        │
        ▼
Backend Fix Loop

这个架构说明：

Handoff 不是单向文件传递，而是实现系统和验证系统之间的工程接口。

只要接口定义不清，后面 DRC/LVS/PEX 的很多问题都会变成沟通成本。

七、Handoff Manifest：最容易被忽略但最关键的文件

一个成熟 handoff package 必须有 manifest。

Manifest 可以理解为 PV 交付包的说明书。

它至少应包括：

text 复制代码

project name
run id
export time
tool version summary
top cell
top module
layout file
source netlist
DEF file
LEF files
technology version
layer map
rule deck version
power net list
ground net list
macro/IP list
black box list
waiver list
expected PV checks
known limitations
owner / contact

它的价值是：

text 复制代码

让 PV 工程师知道该读哪个文件
让后端工程师知道交了什么
让每次 handoff 可追溯
让不同 run 可以比较
让失败问题有上下文
让 tapeout 前交付可审计

没有 manifest，PV handoff 往往会变成口头协作。

口头协作在项目早期可以勉强工作，但在 tapeout 前非常危险。

八、Demo 设计：LAY-BE-23_backend_to_pv_handoff

这个 demo 的目的不是运行真实 signoff，而是生成一个结构化 PV handoff package。

建议 demo 输入：

text 复制代码

data/export/design.def
数据中的 design.gds 摘要
数据中的 source netlist 摘要
数据中的 layer map
数据中的 PV rule config 摘要
数据中的 macro list
数据中的 waiver list

建议 demo 执行逻辑：

text 复制代码

1. 检查 handoff 所需文件是否存在
2. 检查 top cell / top module 是否一致
3. 检查 layer map 是否包含关键 routing layer
4. 检查 power/ground net 是否在 manifest 中声明
5. 检查 macro/IP 是否有 layout 和 logical view
6. 生成 DRC/LVS/PEX handoff checklist
7. 生成 handoff manifest

建议 demo 输出：

text 复制代码

reports/pv_handoff_manifest.rpt
reports/drc_handoff_checklist.rpt
reports/lvs_handoff_checklist.rpt
reports/pex_handoff_checklist.rpt
reports/file_inventory.rpt
logs/pv_handoff.log

这个 demo 的核心价值是把 handoff 从"人工交文件"变成"结构化交付包"。

九、Handoff 方法论：先检查一致性，再交给 PV

不要等 PV 工具报错后才发现交付包有问题。

后端导出后应该先做 handoff precheck。

建议检查：

text 复制代码

文件存在性
文件时间戳
top cell / top module
GDS hierarchy
DEF design name
LEF macro list
source netlist module list
power/ground net list
layer map coverage
rule deck config path
output directory write permission
waiver database version

其中最重要的是名称一致性。

常见名称问题包括：

text 复制代码

design top 名称不一致
cell instance 名称转义不同
bus delimiter 不一致
hierarchy separator 不一致
power net 大小写不一致
macro 名称在 GDS / LEF / netlist 中不同

这些问题如果在 handoff 前发现，修复成本很低。

如果进入 PV 后才发现，往往会消耗大量沟通时间。

十、Handoff 方法论：PV 结果必须回流后端

Backend-to-PV Handoff 不是终点。

PV 工具输出的 violation 和 extracted parasitic 还要回流后端。

DRC 回流：

text 复制代码

violation marker
rule name
cell / coordinate
layer
severity
repair suggestion

LVS 回流：

text 复制代码

short / open
missing device
extra device
net mismatch
pin mismatch
black box mismatch

PEX 回流：

text 复制代码

SPEF / DSPF
net capacitance
coupling capacitance
resistance
corner information
extraction summary

这些回流信息应该进入后端修复闭环：

text 复制代码

PV result
   ↓
classify issue
   ↓
map to backend object
   ↓
generate repair plan
   ↓
rerun local fix
   ↓
export again
   ↓
PV recheck

如果 PV 结果不能映射回后端对象，handoff 就是不完整的。

十一、总结

Backend-to-PV Handoff 的核心不是导出一个 GDS，也不是简单启动一个 PV 工具。

它的本质是多视图一致性交接。

可以用一句话概括：

后端交付给 PV 的不是一个文件，而是一个带有逻辑、物理、几何、工艺、规则和例外说明的完整验证上下文。

从架构角度看，handoff package 是后端实现系统和物理验证系统之间的接口协议。

从方法论角度看，必须用 manifest、checklist、file inventory 和回流机制保证交接可复现、可审计、可闭环。

这一步做不好，后面 DRC/LVS/PEX 的很多问题都会变成沟通问题；这一步做扎实，物理签核才能进入真正的工程闭环。