1. 数模混合版图LVS的真实痛点拆解1.1 为什么数模混合的LVS比纯数字或纯模拟更难搞做版图验证的同行都有个共识纯数字电路的LVS相对省心因为标准单元库的版图跟网表一一对应工具跑起来基本不会出什么幺蛾子纯模拟电路虽然器件匹配要求高但结构简单、器件数量少手工排查也扛得住。真正让人头疼的是数模混合——一颗芯片里既有数字标准单元、存储器阵列又有模拟模块、电源管理、ADC/DAC版图层次深、器件类型杂、连接关系绕LVS跑出来的结果往往是一堆看不懂的报错。我在实际项目中遇到过最典型的情况数字部分LVS干净利落过了模拟部分单独跑也没问题但一合到顶层就炸了。报错信息里全是“unmatched net”“unmatched instance”数量动辄几百上千条看着就让人头皮发麻。更麻烦的是有些错误是假错——版图本身没问题是验证环境配置或者网表处理方式不对导致的误报。如果你分不清真错和假错就会陷入无休止的无效排查。数模混合LVS难做的根本原因在于三个层面。第一是网表来源不统一数字部分的网表通常从综合工具导出模拟部分的网表从原理图提取两边的命名规则、端口顺序、参数格式可能完全不同。第二是器件模型不一致数字标准单元在LVS里通常用简化的MOS模型或者宏模型处理而模拟器件需要精确的SPICE模型两者混在一起时工具容易“认错人”。第三是版图层次结构复杂数字部分往往是扁平的或者层次很浅模拟部分可能嵌套了七八层顶层做LVS时工具需要正确识别每个层次的边界和连接关系。1.2 网表修改和Box使用为什么是核心解法面对数模混合LVS的报错有经验的人不会一上来就改版图而是先从网表和验证环境入手。原因很简单版图修改成本高、周期长而且很多报错根本不是版图的问题。网表修改和Box使用是两种最常用、最有效的“非版图手段”。网表修改的核心思路是让LVS工具看到的网表跟版图的实际结构对齐。比如数字部分综合出来的网表里可能包含了很多物理上不存在的缓冲器或者测试逻辑这些在版图里根本没有对应实例LVS自然会报unmatched。这时候就需要在网表里把这些多余的部分注释掉或者替换成工具能识别的形式。再比如模拟部分的某些器件在版图里做了合并或者拆分网表里还是原始结构也需要手动调整。Box使用则是另一种思路把某些不需要做LVS的模块“黑盒化”。数模混合芯片里总有一些模块是外购的IP、或者已经验证过的硬核这些模块内部不需要重新验证但它们的端口连接必须正确。用Box在Calibre里叫Black Box在Virtuoso里叫Cell Box或者Stop Cell把这些模块框起来LVS工具就只检查端口连接不深入内部。这样做的好处是大幅减少LVS的复杂度把精力集中在真正需要验证的部分。注意Box使用不是万能的。如果被Box的模块端口连接有问题LVS照样会报错而且因为内部被屏蔽了排查起来反而更麻烦。所以Box的粒度要控制好不能什么都往里塞。1.3 本文适合哪些人参考这篇内容主要面向正在做或者即将做数模混合芯片版图验证的工程师。如果你刚接触LVS建议先把纯模拟或者纯数字的LVS流程跑熟理解LVS的基本原理和常见报错含义再来看数模混合的场景。如果你已经做过几个项目但每次遇到数模混合LVS都要花大量时间试错那这篇内容应该能帮你理清思路、少走弯路。另外版图工程师、电路设计工程师、CAD工程师都能从中找到有用的部分。版图工程师关注的是怎么改版图配合LVS电路设计工程师关注的是网表怎么给、参数怎么设CAD工程师关注的是验证环境怎么搭、规则文件怎么配。数模混合LVS从来不是一个人的事需要多方配合才能高效解决。2. 网表修改的核心逻辑与实操细节2.1 网表不匹配的常见根因分析在动手改网表之前必须先搞清楚网表为什么不匹配。根据我的经验数模混合LVS中网表不匹配的原因可以归为以下几类第一类是器件命名不一致。数字综合工具导出的网表里MOS管可能命名为“M1”“M2”“M3”而模拟原理图提取的网表里可能是“MM1”“MM2”或者带层次路径的名字。LVS工具默认按名字匹配器件名字对不上就直接报unmatched。这种情况在顶层合并时特别常见因为两边的命名空间是独立的。第二类是端口顺序或名称差异。数字模块的端口可能是“A[0]”“A[1]”“A[2]”这种总线形式模拟模块的端口可能是“A0”“A1”“A2”这种展开形式。虽然电气上等价但LVS工具不认需要做映射或者重命名。第三类是器件参数格式不同。比如MOS管的宽长比数字网表里可能写成“W0.5u L0.1u”模拟网表里可能写成“w5e-7 l1e-7”。数值一样但格式不同有些LVS工具能自动识别有些就会报参数不匹配。第四类是多余的器件或连接。数字网表里可能包含了扫描链、边界扫描、测试逻辑等这些在功能版图里可能被省略了或者用其他方式实现了。模拟网表里可能有理想电流源、电压源、行为级模型这些在版图里没有物理对应。第五类是层次结构不一致。数字部分可能是扁平化网表模拟部分是层次化网表顶层合并时工具无法正确建立层次对应关系。理解这些根因之后改网表就有了方向。不是盲目地删删改改而是有针对性地做“翻译”和“对齐”。2.2 网表修改的四种常用手法根据不同的不匹配类型网表修改有四种常用手法我按使用频率从高到低排列手法一注释或删除多余器件。这是最简单的操作。比如数字网表里有一堆测试缓冲器版图里没有直接在网表里用“*”注释掉或者删掉就行。但要注意删除器件后可能会留下悬空的net这些net如果还连着其他器件LVS会报悬空节点错误。所以删除器件的同时要把相关的连接也清理干净。手法二重命名器件和端口。当命名不一致时可以用文本编辑器的批量替换功能或者写个简单的脚本做映射。比如把所有“MM”开头的器件名改成“M”开头把所有“A0”改成“A[0]”。Virtuoso的网表导出功能支持自定义命名规则如果提前配置好可以省去很多手动修改的工作。手法三替换器件模型。有些器件在LVS里需要用特定的模型名才能被识别。比如数字标准单元里的MOS管可能需要替换成工艺厂提供的LVS专用模型。模拟部分的理想器件需要替换成实际器件的模型。这个操作需要参考工艺厂的LVS规则文件确认每个器件对应的模型名。手法四调整层次结构。如果数字部分是扁平的模拟部分是层次的可以在网表里给数字部分加上层次包裹或者把模拟部分打平。Virtuoso的网表导出支持“flat”和“hierarchical”两种模式根据LVS规则文件的要求选择。Calibre的LVS也支持“flatten”选项可以在验证时自动打平。实操心得改网表之前一定要备份原始网表。我习惯用“网表名_日期_修改人”的格式保存每次修改的版本这样出问题可以快速回退也方便追溯是谁改的、改了什么。2.3 用脚本自动化处理网表修改手动改网表在器件数量少的时候还行一旦涉及几百上千个器件手动操作不仅效率低还容易出错。这时候写个简单的脚本来自动化处理就很有必要。最常用的脚本语言是Python和Perl。Python的可读性更好适合团队协作Perl在文本处理方面更老练很多老工程师习惯用。我个人的选择是Python因为现在年轻工程师普遍熟悉Python维护起来方便。一个典型的网表修改脚本需要做以下几件事# 示例批量重命名网表中的器件 import re def rename_devices(netlist_path, output_path, rename_map): with open(netlist_path, r) as f: content f.read() for old_name, new_name in rename_map.items(): # 使用正则表达式确保只替换完整的器件名 pattern r\b re.escape(old_name) r\b content re.sub(pattern, new_name, content) with open(output_path, w) as f: f.write(content) # 使用示例 rename_map { MM: M, A: A[, : ] } rename_devices(input.scs, output.scs, rename_map)这个脚本虽然简单但已经能解决大部分命名不一致的问题。实际项目中可能还需要处理更复杂的情况比如根据器件类型做条件替换、处理多行器件定义、保留注释和格式等。写脚本的时候有几个坑要注意。第一是正则表达式的边界问题如果不加\b替换“M1”的时候可能会把“M10”也误伤。第二是大小写敏感SPICE网表通常不区分大小写但有些工具区分脚本里要统一处理。第三是注释行处理网表里以“*”开头的行是注释不应该被修改脚本里要先判断再处理。2.4 网表修改后的验证闭环改完网表不能直接扔给LVS跑要先做一轮自检。自检的内容包括网表语法是否正确用SPICE仿真器或者网表解析工具跑一遍看有没有语法错误。器件数量是否与预期一致统计修改前后的器件数量确认没有误删或漏改。关键net的连接是否正确挑几个重要的net手动追踪一下连接关系确认没有被脚本改坏。端口列表是否完整对比修改前后的端口列表确认没有丢失或多余。自检通过后再跑LVS如果还有报错至少可以排除网表语法和基本结构的问题把精力集中在真正的连接错误上。注意网表修改是“治标”的手段不是“治本”。如果同一个模块每次LVS都要改网表说明前端设计或者网表导出流程有问题应该从源头解决而不是每次都手动补丁。3. Box使用策略与Virtuoso实操配置3.1 Box的适用场景与粒度控制Box黑盒在数模混合LVS里是一把双刃剑。用得好LVS复杂度直线下降用不好问题被掩盖后期调试更痛苦。所以第一步是搞清楚什么模块适合Box什么模块不适合。适合Box的模块通常满足以下条件之一已经独立验证过的硬核IP比如PLL、SerDes、存储器编译器生成的SRAM这些模块内部已经做过完整的DRC和LVS顶层不需要重复验证。外购的第三方IP你没有内部版图和网表只有端口信息不Box也没法验证。数字标准单元库标准单元内部结构固定工艺厂已经验证过顶层LVS时通常用Box或者特殊的LVS规则处理。模拟模块中的无源器件阵列比如大面积的电容阵列、电阻阵列内部结构规则且重复Box掉可以大幅减少器件数量。不适合Box的模块包括自己设计的模拟模块这些模块需要完整验证Box掉等于没做LVS。电源和地网络电源连接必须完整验证Box掉可能导致短路或开路漏检。关键信号路径比如时钟树、复位路径这些连接错误会导致芯片功能失效必须验证。Box的粒度控制是个经验活。我的原则是能Box的模块尽量Box但Box的边界要清晰端口要完整。一个模块如果端口有几十个Box掉之后LVS只需要检查这几十个端口的连接比检查内部几千个器件轻松得多。但如果一个模块只有三五个端口Box掉省不了多少事反而增加了配置工作量就不值得。3.2 Virtuoso中配置Box的三种方式在Virtuoso平台做LVSBox的配置有三种方式分别适用于不同的场景。方式一在原理图中设置Cell Box属性。这是最直观的方式。打开需要Box的模块原理图在CIW窗口或者属性编辑器里找到“LVS Box”或者“Black Box”选项勾选后保存。这样在导出网表时这个模块会被自动处理成Box形式。这种方式的优点是配置简单、跟原理图绑定缺点是只对当前原理图生效如果模块被多处引用需要确保每个引用都正确继承属性。方式二在LVS规则文件中指定Box Cell。Calibre的LVS规则文件支持“LVS BOX”语句可以列出所有需要Box的模块名。比如LVS BOX CELL1 CELL2 CELL3或者在Virtuoso的Assura LVS里可以在规则文件里用“box”关键字指定。这种方式的优点是集中管理、一目了然缺点是修改规则文件需要重新跑LVS而且如果模块名变了要同步更新。方式三在网表中手动添加Box标记。有些LVS工具支持在网表里用特殊注释标记Box模块。比如在模块定义前加一行“* LVS BOX”工具解析网表时就会把这个模块当作Box处理。这种方式最灵活但容易出错适合对网表格式非常熟悉的人。实操心得我通常优先用方式一因为跟原理图绑定最不容易出错。如果模块很多再用方式二集中管理。方式三只在特殊情况下用比如网表是从第三方拿到的没法改原理图。3.3 Box配置的常见错误与排查Box配置看起来简单但实际操作中经常遇到问题。以下是我踩过的几个典型坑坑一Box模块的端口方向不对。如果原理图里把输入端口设成了输出或者把双向端口设成了单向LVS会报端口方向不匹配。这种错误在Box模块上特别隐蔽因为内部被屏蔽了只能看到端口报错。排查方法是检查原理图端口的direction属性确保跟实际使用一致。坑二Box模块的电源端口被遗漏。有些模块的电源和地端口在原理图里是隐藏的或者用全局网络连接的Box配置时如果没有显式包含这些端口LVS会报电源连接错误。解决方法是确保Box模块的端口列表包含所有电源和地端口或者在LVS规则里配置全局电源网络。坑三Box模块的层次路径不对。如果模块在版图里的层次路径跟原理图不一致LVS找不到对应的Box定义会报“box cell not found”。这种情况通常发生在版图做了层次调整或者模块被移动之后。排查方法是检查版图和原理图的层次结构确保路径一致。坑四多个Box模块同名。如果两个不同的模块用了相同的Cell名LVS会混淆。这种情况在团队协作时容易出现比如两个人各自建了一个叫“AMP”的模块。解决方法是统一命名规范或者在LVS规则里用完整路径区分。坑五Box模块内部有LVS错误但被屏蔽了。这是最危险的情况。Box模块内部如果有短路、开路、器件参数错误LVS不会报错但芯片流片后功能会失效。所以Box之前一定要确认模块已经独立验证通过不能把未验证的模块Box掉。3.4 Box与网表修改的配合使用Box和网表修改不是互斥的实际项目中经常需要配合使用。比如一个数模混合顶层数字部分用Box处理标准单元模拟部分通过网表修改对齐器件命名顶层再用Box屏蔽掉已经验证过的IP。这样三层处理下来LVS的复杂度可以降低一个数量级。配合使用的关键是处理顺序。我的习惯是先做网表修改再做Box配置。因为网表修改可能会改变模块的端口或者器件如果先Box了再改网表Box的端口信息可能就过期了。先改网表、确认网表正确再根据最终网表配置Box这样最稳妥。另外Box配置和网表修改都要有文档记录。我见过太多项目因为人员流动后来的人不知道哪些模块被Box了、哪些网表被改过导致LVS环境无法复现。建议在项目目录下放一个“LVS_README”文件记录每次修改的内容、原因、修改人、日期这样即使换了人也能快速上手。4. 完整LVS实操流程与关键环节4.1 验证环境搭建与规则文件配置数模混合LVS的第一步是搭好验证环境。环境搭不好后面全是坑。我通常按以下步骤来第一步确认工艺厂提供的LVS规则文件版本。规则文件通常叫“lvs规则文件”或者“calibre.lvs”里面定义了器件识别、连接提取、比较规则等核心内容。要确认版本跟当前使用的工艺节点匹配不能拿旧版本的规则跑新工艺的版图。第二步配置LVS运行目录结构。我习惯用这样的目录结构lvs_run/ ├── runset/ # LVS运行脚本 ├── netlist/ # 网表文件 ├── layout/ # 版图GDS ├── results/ # LVS结果 ├── logs/ # 运行日志 └── scripts/ # 辅助脚本这样分门别类出问题的时候容易定位。第三步配置LVS运行脚本。Calibre的LVS运行脚本通常是一个Shell脚本或者TCL脚本里面定义了输入文件、输出文件、规则文件路径、运行选项等。关键配置包括# Calibre LVS 运行脚本示例 calibre -lvs -hier -turbo 8 \ -runset lvs_runset \ -layout layout.gds \ -source netlist.cdl \ -rules calibre.lvs \ -report results/lvs.rep \ -log logs/lvs.log其中-hier表示层次化LVS-turbo 8表示用8个CPU核心并行加速。数模混合版图通常很大不开并行会跑很久。第四步准备网表。网表来源可能是Virtuoso导出的CDL、综合工具导出的Verilog网表、或者第三方提供的SPICE网表。不同来源的网表格式不同需要统一成LVS工具能识别的格式。Calibre支持CDL、SPICE、Verilog等多种格式但混合格式的网表需要特殊处理。第五步准备版图GDS。版图GDS要从Virtuoso导出确保导出时包含了所有需要的层次和器件。有些工艺厂的LVS规则需要版图里包含特定的识别层导出前要确认这些层已经正确生成。4.2 首次LVS运行与报错分类环境搭好后跑第一次LVS大概率会报一堆错。这时候不要慌先把报错分类。我通常把LVS报错分为四类第一类语法和格式错误。比如网表语法错误、GDS格式错误、规则文件路径错误。这类错误通常在LVS运行的早期阶段就会报出来日志里会有明确的错误行号和描述。解决方法是根据日志提示修正语法或路径。第二类器件识别错误。比如版图里的某个器件在网表里找不到对应或者网表里的器件在版图里找不到。这类错误通常报“unmatched device”或者“device not recognized”。解决方法是检查器件模型名、参数格式、识别层是否正确。第三类连接错误。比如某个net在版图里连接了三个器件在网表里只连接了两个。这类错误报“unmatched net”或者“net connection mismatch”。解决方法是追踪这个net在版图和网表里的连接关系找出差异点。第四类端口错误。比如顶层端口的数量、名称、方向不匹配。这类错误报“port mismatch”或者“top level port error”。解决方法是检查顶层原理图和版图的端口定义。分类之后按优先级处理。先解决语法和格式错误因为这类错误会导致LVS无法正常运行。然后解决器件识别错误因为器件识别不对连接比较就没有意义。最后解决连接和端口错误。4.3 逐层排查与增量验证数模混合LVS不要指望一次跑通要用“逐层排查、增量验证”的策略。具体做法是第一步单独验证数字部分。把数字部分的版图和网表单独拿出来跑LVS确保数字部分干净。数字部分通常问题少跑通了可以建立信心。第二步单独验证模拟部分。模拟部分单独跑LVS解决所有器件识别和连接问题。模拟部分的问题通常比较隐蔽需要耐心排查。第三步验证数字和模拟的接口。把数字和模拟的接口部分单独拿出来验证跨模块的连接。这一步最容易出问题因为两边的命名规则、端口定义可能不一致。第四步顶层全芯片LVS。前面三步都通过后再跑顶层全芯片LVS。这时候如果还有报错数量应该已经很少了排查起来也容易。增量验证的好处是每次只关注一个部分问题定位快。如果一上来就跑顶层几百个报错混在一起根本无从下手。实操心得我习惯在每一步验证通过后打一个tag或者保存一个快照这样如果后续修改引入了新问题可以快速回退到上一个通过的状态。4.4 LVS通过后的检查清单LVS报“CORRECT”不代表万事大吉。我见过太多LVS过了但芯片回来不工作的情况。所以LVS通过后还要做一轮人工检查检查清单如下检查项检查内容常见问题器件数量版图和网表的器件总数是否一致Box模块内部器件被漏算器件参数关键器件的W/L/M是否匹配参数格式不同导致误判电源连接所有电源和地网络是否完整隐藏端口导致漏连端口列表顶层端口数量、名称、方向总线端口展开不一致Box模块被Box的模块是否都已独立验证未验证模块被Box网表修改所有修改是否有记录修改未文档化规则文件使用的规则文件版本是否正确版本过旧或过新这个清单看起来简单但每一条都对应着实际项目中踩过的坑。比如“Box模块是否都已独立验证”这一条我就见过因为Box了一个未验证的模块芯片回来发现这个模块完全不工作最后不得不改版。4.5 数模混合LVS的自动化脚本框架项目大了之后手动跑LVS效率太低。我通常会搭一个自动化框架把LVS运行、结果解析、报错分类都自动化。框架的核心是一个Python脚本做以下几件事import subprocess import re import os from datetime import datetime class LVSRunner: def __init__(self, config): self.config config self.timestamp datetime.now().strftime(%Y%m%d_%H%M%S) def run_lvs(self): 运行LVS并返回结果 cmd self._build_command() result subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue) return result def _build_command(self): 根据配置构建LVS命令 cmd fcalibre -lvs -hier -turbo {self.config[cpu]} cmd f-layout {self.config[layout]} cmd f-source {self.config[netlist]} cmd f-rules {self.config[rules]} cmd f-report {self.config[report]} cmd f-log {self.config[log]} return cmd def parse_report(self, report_path): 解析LVS报告提取报错信息 with open(report_path, r) as f: content f.read() errors { unmatched_device: [], unmatched_net: [], port_mismatch: [], syntax_error: [] } # 根据报告格式提取报错 # 具体正则表达式根据实际报告格式调整 for line in content.split(\n): if unmatched device in line.lower(): errors[unmatched_device].append(line) elif unmatched net in line.lower(): errors[unmatched_net].append(line) # ... 其他类型 return errors def generate_summary(self, errors): 生成报错摘要 summary fLVS运行时间: {self.timestamp}\n summary f未匹配器件: {len(errors[unmatched_device])}\n summary f未匹配网络: {len(errors[unmatched_net])}\n summary f端口错误: {len(errors[port_mismatch])}\n return summary这个框架可以根据项目需求扩展比如自动发送邮件通知、自动对比两次LVS结果的差异、自动生成修复建议等。有了自动化框架LVS从“体力活”变成了“脑力活”工程师可以把精力放在真正需要判断的问题上。5. 常见问题速查与避坑经验实录5.1 LVS报错速查表数模混合LVS的报错五花八门但常见的就那么几十种。我整理了一个速查表遇到报错先查表能解决80%的问题。报错关键词可能原因排查方向解决方法unmatched device器件命名不一致对比版图和网表的器件名重命名或加映射unmatched device器件模型不识别检查LVS规则中的模型定义替换模型名或加识别层unmatched net连接关系不一致追踪net在版图和网表的连接修正版图或网表unmatched net悬空节点检查是否有未连接的net删除或连接悬空netport mismatch端口数量不一致对比顶层端口列表补充或删除端口port mismatch端口方向错误检查端口direction属性修正方向box cell not foundBox模块路径不对检查层次路径修正路径或Box配置soft connect软连接未定义检查soft connect配置添加soft connect规则property error器件参数不匹配对比W/L/M参数修正参数或格式short circuit版图短路检查版图连接修正版图open circuit版图开路检查版图连接修正版图这个表不是万能的但能帮你快速定位方向。实际排查时还要结合LVS报告的详细信息和版图/网表的具体内容。5.2 软连接Soft Connect的处理技巧软连接是数模混合LVS里一个容易被忽视但很关键的概念。所谓软连接是指两个net在物理上没有直接连接但在电气上应该被视为连接。比如数字部分的电源网络和模拟部分的电源网络在版图上可能是分开的但在系统层面是同一个电源。LVS工具默认不识别软连接会把它们当作两个独立的net导致报错。解决方法是配置soft connect规则。在Calibre的LVS规则文件里可以用“SOFT CONNECT”语句定义SOFT CONNECT VDD_DIG VDD_ANA SOFT CONNECT VSS_DIG VSS_ANA或者在Virtuoso的Assura里可以在LVS选项里配置“Join Nets”规则。软连接的处理有几个注意点。第一是不要滥用软连接应该只用于确实等电位的net如果两个net实际不等电位强行软连接会掩盖真正的短路错误。第二是要文档化每个软连接都要有明确的理由记录在验证文档里。第三是要跟设计确认软连接的设置会影响LVS结果必须跟电路设计工程师确认后再配置。5.3 数模混合LVS的独家避坑经验以下是我在实际项目中总结的几条经验常规文档里不会写但每条都价值不菲。经验一先跑通再优化。不要一上来就追求完美的LVS环境。先用最简配置跑通一次哪怕报错很多至少证明流程是通的。然后再逐步优化网表、配置Box、调整规则。我见过有人花了一周时间搭环境结果第一次跑LVS发现规则文件版本不对全部重来。经验二保留每次LVS的完整日志。LVS日志里包含了大量信息不只是报错。比如器件识别过程、net提取过程、比较过程这些信息在排查复杂问题时非常有用。我习惯把每次LVS的日志按时间戳保存出问题的时候可以对比不同版本的日志快速定位变化点。经验三跟电路设计工程师保持沟通。很多LVS报错其实是电路设计的问题比如网表里多了器件、端口定义错了、参数写错了。版图工程师自己闷头排查可能花几个小时都找不到原因问一下设计工程师五分钟就解决了。所以遇到不确定的报错及时沟通不要自己硬扛。经验四建立自己的LVS检查清单。每个项目结束后把遇到的LVS问题和解决方法整理成清单下次项目开始前先过一遍清单能避免很多重复踩坑。我的清单已经从最初的十几条扩展到了现在的上百条覆盖了各种数模混合场景。经验五不要迷信LVS的“CORRECT”。LVS过了不代表版图没问题。LVS只能验证连接关系不能验证器件参数是否满足性能要求、不能验证寄生参数的影响、不能验证版图是否满足DRC以外的工艺要求。所以LVS通过后还要做DRC、ERC、寄生提取、后仿真等一系列验证。经验六Box模块要定期复查。项目初期Box的模块到了项目后期可能已经修改过多次但Box配置没有同步更新。我习惯在每次流片前把所有Box模块重新过一遍确认端口、连接、验证状态都是最新的。5.4 从失败案例中学习一次典型的数模混合LVS翻车记录最后分享一个我亲身经历的翻车案例希望能给大家提个醒。那是一个数模混合的电源管理芯片数字部分是一个简单的状态机模拟部分包含LDO、基准源、振荡器。项目初期LVS一直跑不通数字和模拟的接口报了几百个unmatched net。当时为了赶进度我们决定把数字部分整体Box掉只验证模拟部分和接口。LVS很快过了项目继续推进。流片回来后芯片功能测试发现状态机偶尔会卡死。排查了很久最后发现是数字部分的一个复位信号在版图上接错了但因为数字部分被Box了LVS没有检查内部连接这个错误被漏掉了。改版花了三个月项目延期损失惨重。这个案例的教训是Box可以简化LVS但不能替代验证。被Box的模块必须已经独立验证通过而且Box的端口连接必须完整验证。如果当时我们单独跑一遍数字部分的LVS这个错误就能提前发现。从那以后我给自己定了一条规矩任何被Box的模块必须有独立的LVS通过记录否则不允许Box。这条规矩后来帮我们避免了好几次类似的错误。数模混合LVS没有捷径只有把每个环节做扎实把每次报错都搞清楚才能真正提高效率、保证质量。网表修改和Box使用是手段不是目的目的是让LVS真正起到验证作用而不是走个过场。