第4章 物理验证（DRC/LVS/ERC）面试：验证流程、违例分析、自动化验证脚本
物理验证是芯片从设计到流片的最后一道“安检门”，面试中重点考察对验证流程的全局理解、违例根因分析能力以及脚本化自动化思维。本章围绕DRC/LVS/ERC三大核心验证场景，结合TCL/Skill脚本实战，拆解高频追问与避坑要点。
常规问答卡片
面试问题 1：请描述完整的DRC验证流程，包括Runset选择、运行方式和Debug步骤。
面试官考察点： 是否理解DRC在大规模芯片中的实际执行流程，能否区分不同Runset（如Prime/Base/PERC），以及是否具备高效Debug思维。
回答框架： 流程分四阶段：① Runset加载（按设计规则选择）；② Calibre/Pegasus并行运行；③ 违例分类（Short/Spacing/Density/Wire）；④ Debug与Signoff。
简短示例回答： 使用Calibre DRC，先加载Foundry提供的Prime Runset，配置-threads 16分核运行。运行后导出.asc违例文件，使用TCL脚本按违例类型归类，优先修复Short和最小间距违例，最后用Waive规则管理假错，生成DRC Clean报告后签核。
可能追问： ① 如何处理海量违例（>10万个）？② 是否自己写过Waive文件？③ 如何区分真实违例和假错（False Positive）？
面试问题 2：LVS验证中遇到“短路”违例，你如何系统性定位并修复？
面试官考察点： 短路是最致命也最常见的LVS问题，考察逻辑推理、版图阅读能力和修复策略。
回答框架： ① 分析LVS Report中短路节点名称 → ② 在Calibre RVE中高亮短路路径 → ③ 检查电源地是否跨层短路 → ④ 检查不同电压域隔离是否失效 → ⑤ 修复后重新运行LVS。
简短示例回答： LVS显示VDD与VSS短路。使用RVE高亮报告路径，发现M2层电源地平行跨接超长区域有桥接缺陷。立即检查DRC是否漏报最小间距违例，手动挖孔隔离后重新LVS通过。
可能追问： ① 如果短路是跨多个模块的全局性短路怎么追踪？② 有没有用过hcell/xcell加速LVS？③ 如何确认短路是版图还是网表问题？
面试问题 3：你如何用自动化脚本（TCL/Skill）批量处理DRC违例分类或Waive管理？
面试官考察点： 自动化能力是技术专家的分水岭，考察工程思维和脚本实现细节。
回答框架： ① 读取DRC结果文件（.asc/.summary）→ ② 按违例类型、层次、规则ID解析 → ③ 统计违例分布 → ④ 生成分类报告（Excel/HTML）→ ⑤ 批量输出Waive文件或自动产生修复脚本。
简短示例回答： 我用TCL编写了“drc_analyzer.tcl”：读取calibre.drc.summary，提取违例总数并按rule_id分组，输出违例热力图。对同一类型假错自动生成Waive语句，整合到Waive_rule.gds中，使手动Debug时间从3天缩短到半天。
可能追问： ① 如何处理不同工艺的Rule命名差异？② 脚本是否集成到CI/CD流程？③ 如果某个违例跨层但没有被识别为假错怎么办？
项目案例章节
项目名称：7nm 高性能计算芯片物理验证自动化Signoff平台
| 业务背景 | 芯片面积>400 mm²，超过100亿晶体管，DRC/LVS/ERC验证周期占整体后端流程40%。传统手动验证流程在7nm层级下效率极低，违例量超20万，Signoff周期长达6周。 |
| 规模指标 | 120+个hard macro，500+个power domain，1200+个clock domain，使用M1-M14共14层金属，DRC Runset包含2500+条规则。 |
| 技术栈 | Calibre nmDRC/nmLVS + Pegasus（备用验证） + TCL/Skill自动化脚本 + Python报表生成 + Jenkins CI/CD |
| 核心难点 | ① 全芯片LVS存在“假短路”因跨域隔离不完善；② DRC违例中大量多层耦合违例（如Via POK规则）；③ 多电压域ERC检查出现异常浮空/电平转换违例。 |
| 面试高频追问 | ① 你们如何管理Waive规则的版本和审批？② 自动化脚本如何与Calibre命令行集成？③ 是否做过并行性优化？举例说明。 |
| 可迁移回答话术 | “我们在7nm项目中遇到跨电源域短路假错，原因是低电压域内的信号线被错误标记。我编写了TCL脚本自动提取所有域边界信号，与LVS报告交叉比对，过滤掉95%的假错，最终将手动Debug时间缩短80%。这套方法可迁移到任意多域设计。” |