【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 之后，工作就结束了。

真实情况是：

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

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

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

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 的本质：多视图一致性交接

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

这个数据库里同时包含：

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

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

常见 handoff 文件包括：

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 : 已知例外和豁免记录

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

可以抽象成：

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 擅长表达：

polygon path cell hierarchy layer/datatype text label structure reference

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

例如，它不直接告诉你：

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

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

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

design.gds

而应该交付一个完整 package：

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。

它应该明确说明：

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

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

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

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

关键输入通常包括：

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

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

后端工具内部可能使用：

M1 VIA1 M2 VIA2 M3

而 GDS 中可能是：

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

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

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

常见后果包括：

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

因此 DRC handoff 必须检查：

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。

它检查的是：

layout extracted connectivity 是否等价于 source netlist connectivity

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

关键输入通常包括：

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 中常见问题包括：

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 叫：

VDD VSS

但 layout label 里叫：

vdd! gnd!

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

所以 LVS handoff 必须提前定义：

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 是寄生参数提取。

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

resistance capacitance coupling capacitance device parasitic interconnect parasitic

这些数据最终会进入：

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

PEX handoff 关注的是：

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

常见 PEX 输出包括：

SPEF DSPF SPICE extracted netlist reduced parasitic model

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

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

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

所以 PEX handoff 要特别关注：

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

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

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

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

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 交付包的说明书。

它至少应包括：

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

它的价值是：

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

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

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

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

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

建议 demo 输入：

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

建议 demo 执行逻辑：

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 输出：

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。

建议检查：

文件存在性 文件时间戳 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

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

常见名称问题包括：

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 回流：

violation marker rule name cell / coordinate layer severity repair suggestion

LVS 回流：

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

PEX 回流：

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

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

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 的很多问题都会变成沟通问题；这一步做扎实，物理签核才能进入真正的工程闭环。