芯片行业做验证的，尤其是搞数模混合的，最近几年应该都绕不开“MSDV”这个词。手头这个项目，本质上就是想解决一个很实际的问题：模拟电路在数字仿真环境里，怎么个跑法才又快又准？标题里几个关键词把路径标得很清楚——从 RNM 抽象、Verilog-on-Top 架构，一直到最终把模型落地成能跑的网表。这条链路走通了，混合信号验证的效率能上一个台阶；走不通，那就只能在 SPICE 仿真器里熬时间，或者被模型精度问题折腾得焦头烂额。
这篇文章我就以实际做过的项目为底，把整个流程掰开揉碎讲清楚：RNM 到底是什么、怎么抽象；Verilog-on-Top 平台怎么搭；最关键的一步——模型怎么变成网表、中间有哪些坑、参数怎么映射。顺便把 OrCAD 导出网表、Allegro 导入网表这类工具链操作和芯片验证里真正的网表诉求也理一理，免得新手把这几个概念搅在一起。做混合信号验证的朋友可以拿这份内容当一份实践参考，少走点弯路。
1. MSDV 的思路起点：为什么非要用混合信号验证
1.1 数模混合芯片验证的痛点
做过混合信号芯片的人都知道，纯模拟仿真的天花板非常明显。一个带 ADC、DAC、PLL 或者电源管理模块的芯片，如果全部用 SPICE 级的晶体管网表去跑一次完整的系统级验证，仿真时间往往是天级别起步，跑完一个测试用例就得等上半天甚至更久。而纯数字验证环境又没办法精确描述模拟信号连续变化的特性——你把一个比较器的输出当成 0/1 数字量来看，某些边界情况下它可能在一个区间内来回跳变，数字仿真器根本捕捉不到这种亚稳态。
这就是 MSDV（Mixed-Signal Design Verification）要解决的问题：把模拟模块用一种合适的抽象方式放进数字验证环境里，既保证必要的精度，又让仿真速度可控。现实中大多数 SoC 芯片的数模接口验证、寄存器级联调、上电时序检查、中低频模拟信号环路响应，都可以靠 MSDV 来覆盖。它填补了“纯 SPICE 仿真太慢”和“纯数字仿真不真实”之间的空白地带。
1.2 RNM 与 Verilog-on-Top 在整个验证链中的定位
RNM（Real Number Modeling，实数建模）解决的是模拟信号在数字仿真器里怎么表示的问题。传统 Verilog 里 wire 只有 0/1/X/Z 四种状态，精度明显不够。RNM 的思路是引入 real 类型，让信号在数字仿真器里也能带上连续数值——3.3V 就是 3.3，2.5V 就是 2.5，中间过渡过程也可以用斜坡函数来描述。这样 ADC 输入端的电压、LDO 的输出值、PLL 的锁定电压变化，都能在数字验证环境里被精确表达。
Verilog-on-Top 则是一种平台架构：验证的顶层是 Verilog 环境，模拟模块要么用 RNM 模型替换，要么把模拟的子电路封装成一个带数字接口的壳（wrapper），然后像挂一个普通 IP 一样挂在总线或引脚上。这个架构的好处是验证工程师可以用熟悉的 SystemVerilog/UVM 方法学去搭平台、写用例、做断言，而不需要深入 SPICE 的世界。
有了 RNM 抽象和 Verilog-on-Top 平台，下一步就是“模型怎么落地成一份能跑的网表”。这里有个关键区别：验证前期用的行为级 RNM 模型，和最终用于签核（signoff）或者后仿真的结构级网表，它们之间不是自动等同的关系。前者是工程师快速写出来的行为描述，后者是经过综合、映射到具体工艺库后的真实器件连接关系。从模型到网表的过渡，需要做大量的参数提取、映射与连接关系修正。
2. RNM 抽象的具体做法：从连续信号到实数模型
2.1 RNM 到底在抽象什么
RNM 的本质一句话能讲清楚：用数学运算和时间延迟，把模拟模块的输入输出关系映射成实数信号的变化。你不需要关心管子工作在哪个区、偏置电流是多少毫安，你只需要知道“当输入超过某一阈值时，输出会在多少纳秒内从低电平转到高电平”。这个过程很像拍照片——你不需要知道相机内部传感器的每个像素怎么工作，你只需知道拍出来的照片长什么样。
拿一个比较器来举例：真实电路里，输入电压从低于阈值到高于阈值，输出会经过一个由运放摆率决定的过渡带。RNM 模型不需要模拟这个过渡带的物理机理，它可以定义一个阈值电压 vth，然后用一条斜率可控的 transfer 函数把输出拉高或拉低。仿真器看到的是：当 Vin > vth 时，Vout 在 N 纳秒内从 0 升到 3.3V；当 Vin < vth 时，Vout 在 M 纳秒内降到 0。这样一个模型就足够支撑数字侧的逻辑验证需求了。
2.2 精度与仿真代价的权衡
做 RNM 建模最怕走两个极端：一个是把模型写得过于简单，比如把所有模拟行为都退化成理想开关，结果数字验证里根本发现不了模拟侧的真实延迟或毛刺问题；另一个是模型写得过于精细，把每个模拟参数都用公式复现一遍，导致 RNM 模块的计算量不亚于跑一个小型 SPICE 仿真，速度优势完全丧失。
实际项目中，我会对模块做分级处理。电源相关的 LDO、DCDC，需要保留线性调整率和负载跳变时的瞬态响应特性，这些用 transfer 函数 + 延迟足够；而对精度极其敏感的 ADC 量化过程，仅靠 RNM 的 transfer 函数往往不够，还要结合查表法或者分段线性逼近来保证不同输入范围内的误差可控。
一个可复用的做法是：先分析一个模块在数字侧真正关心的接口参数有哪些，看是电压阈值、电流极限、延时还是建立时间，然后只针对这些参数建立数学模型。其他与数字验证无关的细节，比如失配、温度漂移、工艺角对某些模拟参数的影响，可以留到后仿真的结构网表阶段再去覆盖。
2.3 可维护、可复用的 RNM 建模原则
RNM 模型最大的优势之一是它可以被复用。一个写得好的比较器模型，不只在 block level 的验证里能用，在 chip level 的验证里同样能挂上去。为了让模型具备这种通用性，我有几个习惯：
第一，参数不要写死。阈值电压、上升下降时间、输出高电平等都定义成 parameter 或者 define，这样在不同项目、不同工艺角下可以灵活替换。第二，模型文件里要留清晰的注释，标明这个模型是参考哪个版本的原理图、哪些参数来自哪个工艺角，否则半年后回来看，根本想不起参数从哪来。第三，接口信号类型要统一约定，RNM 模型的输入输出端口与该模块在 Verilog-on-Top 平台里的连接要保持一致的物理量纲，千万不要出现一边是电压、另一边逻辑上当成电流用的混乱。
3. Verilog-on-Top 平台的搭建与模块封装
3.1 为什么选择 Verilog 作为顶层语言
很多团队在搭混合信号验证平台时会纠结：要不要用 SPICE 作为顶层，把数字模块作为简化模型嵌进去？我的经验是，除了极少数以模拟为主、数字量极少的小规模测试，Verilog-on-Top 几乎总是更好的选择。
理由很直接：验证主战场在数字侧。大多数混合信号芯片的数字逻辑规模远大于模拟模块，测试用例要处理寄存器配置、状态机跳转、总线协议，这些工作在纯 SPICE 环境里做起来极度痛苦。Verilog-on-Top 让你可以把模拟模块当成黑盒或灰盒，用一套统一的验证语言和验证方法学去调度。同时，数字仿真器的编译时间、运行速度、调度能力远强于 SPICE 仿真器，这让大规模回归成为可能。
3.2 模拟模块的封装技巧：wrapper 与接口
Verilog-on-Top 平台里，一个模拟模块通常要被包进一个 Verilog wrapper 中。Wrapper 的作用是双重的：对外，它提供一个标准化的接口，让模块可以像挂 IP 一样连到总线上；对内，它根据验证需要，可以切换连接对象——连 RNM 行为模型、连结构级网表、或者连一个模拟功能测试用的 SPICE 视图。
封装时最重要的细节是接口信号的电气类型声明和极性定义。模拟侧的输入输出可能是双向 pin（比如开漏输出的比较器），也可能是纯模拟输入。在 wrapper 中需要把这类信号明确声明为 inout 或者 wire，并且在顶层测试平台里保证驱动强度与方向正确。如果这一步搞错，最常见的问题就是仿真出现 X 态或者高阻态误判。
接口的命名规范也值得花功夫统一。每个模拟信号的名字最好能在 wrapper、RNM 模型、结构网表、波形配置文件里保持一致。命名不一致是混合信号验证里非常消耗排查时间的低级错误——波形里明明有信号，grep 配置却因为大小写或后缀差异找不到，这种经历我相信很多人都有。
3.3 断言与覆盖率策略：跑起来只是第一步
Verilog-on-Top 平台跑通一把波形只是验证的开始，真正的功夫在断言和覆盖率。混合信号模块的断言和纯数字模块不太一样，它不光要检查信号跳变的时序关系，还要验证模拟量的数值范围。比如一个 LDO 的输出，在上电后 200us 内必须稳定在 1.8V ± 5% 范围内。这种断言用 SystemVerilog 的 concurrent assertion 可以直接写出来，但需要把模拟电压信号通过 real 类型传进断言表达式。
覆盖率方面，混合信号验证需要特别关注模拟边界条件的覆盖。功能覆盖率可以定义 ADC 输入电压的几个典型分区、DCDC 负载电流的跳变范围、PLL 锁定时间的区间等。验证计划里要明确这些边界条件哪些必须被一个 test 覆盖，哪些可以分散在多个 test 中。否则你会发现功能覆盖率虽然到了百分之九十多，但最关键的几个模拟边界根本没有在回归里被踩到，后患无穷。
4. 模型落地成网表：从行为级到结构级的完整路径
4.1 行为级 RNM 模型与结构级网表的本质差异
很多验证工程师第一次接触“把模型落地成网表”这个需求时，会下意识认为：把 RNM 模型用某种工具自动转换成网表不就行了？实际上完全不是这样。RNM 模型是行为级的，它描述的是“输入输出之间的数学关系”，本质上是抽象的、理想化的。网表是结构级的，它描述的是“哪些器件用哪条线连起来”，每一颗管子、每一个电阻电容都对应到工艺库中的具体单元。
两者之间的关系更像是“地图”和“实际道路”的关系：地图告诉你从 A 到 B 大约 10 公里，但实际道路上可能有红绿灯、单行道、修路绕行。RNM 模型告诉数字验证者这个模块的行为符合预期，但结构级网表要回答的是“在特定工艺角落下，器件是否能真实地完成这个行为”。
所以在实际流程中，RNM 模型到网表之间通常要经过两层转化：第一层是从行为级模型到电路级描述（SPICE 网表在原理图设计完成后就有了），第二层是从电路级描述到带寄生参数的版图后网表。验证工程师拿到结构级网表后，要做的不是把它当黑盒直接接入平台，而是要做参数校准：把结构网表的仿真结果和 RNM 模型的行为特性做对比，两者之间的差异要在可接受范围之内。
4.2 网表生成的两种路径：SPICE 网表与 CDL 网表的取舍
做混合信号验证的网表，通常有两种来源：SPICE 网表（通常带各种器件模型参数，可以直接用于模拟仿真器）和 CDL 网表（电路设计语言网表，主要用于 LVS 检查，一般不带完整的仿真模型参数）。在 Verilog-on-Top 平台里接入网表时，我需要先搞清楚手头这份网表是哪种，因为它们的清洗程度和仿真适配度完全不同。
SPICE 网表可以直接被模拟仿真器调用，也能在混合仿真模式（比如 AMS 模式）下使用。CDL 网表的侧重点在器件尺寸和拓扑结构，缺少很多必要的仿真模型参数，一般不能直接拿来做仿真。实际项目里最省心的做法是让模拟设计组提供一份干净的、仿真可用的 SPICE 网表，并且确保网表里没有 CDL 专有的伪节点、特殊标注和死代码。如果确实只有 CDL，那就需要做一次网表清洗，这个过程最大的作用是剔除冗余信息、统一节点命名，让工具能够正确读取。
4.3 参数映射：从行为级的抽象参数到工艺级的真实值
RNM 模型里的参数往往是抽象化的“理想值”：比较器上升时间直接写 2ns，LDO 的负载调整率直接用固定系数，ADC 的量化噪声直接用一个简单的随机变量模拟。到了结构级网表里，这些行为必须依赖具体的器件参数来实现，而器件参数又来自工艺库的工艺角定义。
这个阶段最核心的工作就是参数映射。具体做法是：先从工艺库中提取目标模块在不同工艺角（tt / ss / ff / sf / fs）、不同温度、不同电压下的关键行为参数，比如传播延迟、输出摆幅、上升下降时间、功耗、建立保持时间等。然后把写死在 RNM 模型里的参数替换成一组可配置的变量，让验证环境可以通过后门或者配置文件加载某个工艺角下的参数值。
参数映射表是必须有的文档。每一行对应一个行为参数，列上标注 RNM 模型里的默认值、结构网表在 tt corner 下的仿真值、在 ss corner 下的仿真值、以及在 ff corner 下的仿真值。有了这张表，当结构网表回归跑出来的波形和 RNM 模型不一致时，就能快速定位：是模型里某个参数设得太乐观，还是网表在某个 corner 下确实表现出这个差异。
4.4 仿真设置与实际跑通的细节
网表接入平台后，仿真设置有几个特别容易出问题的细节。第一是模拟模块的时间步长控制。结构级网表的最小时间步长往往很敏感，需要给模拟部分设置独立的时间步长上限，避免仿真器为了数字侧的快速逻辑而过度压缩模拟部分的时间步长，导致仿真速度骤降。第二是初始状态，结构网表里的电容、电感初始电压电流状态的设置很重要，如果初始化不对，第一条跳变可能就会出现非正常的瞬态过程。第三是模拟模块的电源和地的处理方式——结构网表里电源网络往往是显式的，不像 RNM 模型里默认电源理想化，所以在 Verilog-on-Top 平台里要给模拟模块正确连接电源引脚并设置上电位序。
跑通之后，还要做一次一致性检查：用同一个激励分别跑 RNM 模型和结构网表，对比两者的输出波形，记录关键时间点的误差比例。这个检查结果直接决定你现在用的 RNM 模型还有没有继续用于下一轮回归验证的资格。如果误差超过预设阈值，比如 5%，就不要硬撑了，赶紧回头修正模型参数。
5. 实战中容易踩的坑与排查方法
5.1 典型问题一：RNM 模型和网表连接时的“零零散散”
在 Verilog-on-Top 平台中同时挂 RNM 模型和结构网表时，最常遇到的问题是连线的电气类型不匹配。RNM 模型的输出口通常是 real 类型，而网表的输出口可能是 bit 类型；或者反过来，网表的模拟输出是 wreal（wire real），而顶层平台里连接的信号却没有声明为 wreal。这种问题在编译阶段不会报错，但波形在显示时会出现无法解析的毛刺，或者数值被截断为 0/1。
排查方法很简单：把所有跨边界的信号打印到日志文件里，看它们在事件变化时的实际值。如果是 wreal 和 real 之间的混用，就统一用 wreal；如果网表的输出是模拟电压而后面接的是一个数字逻辑输入，中间必须要加一个电平转换逻辑（比如用阈值比较产生 0/1）或者用 connect module 来桥接。
5.2 典型问题二：网表仿真的收敛性和速度取舍
结构级网表在混合仿真环境里，尤其是做跑大回归时，经常遇到收敛性问题。典型现场是仿真器在某一个时间点反复迭代、无法推进，或者直接报“timestep too small”错误。这通常与网表中某个高增益节点或大电感电容回路有关，纯数字验证环境对这种行为的容忍度很低。
一个直接的解决方法是给这个节点增加一个较小的并联电容（通常叫 convergence capacitor 或者 damping element），把高增益节点的瞬态变化率压一压。但注意不要加太大，否则会影响真实瞬态波形。另一个方法是在混合仿真器里设置模拟模块独立的收敛容差参数，把电压容差或者电流容差适当放宽一点，很多时候不影响信号宏观行为，却能大幅提升收敛速度。
5.3 典型问题三：OrCAD 导出网表、Allegro 导入网表这类操作不是仿真网表
这里有必要澄清一个事情：搜索“MSDV / 网表”相关关键词时，弹出的很多结果其实是 OrCAD 导出网表、Allegro 导入网表这类 板级设计 的操作，它们和本文说的芯片级验证网表是两码事。Allegro 导入网表是 PCB 设计的走线和布局工作，OrCAD 导出网表是把原理图连接关系转给 PCB 工具，核心是物理连接和封装库的匹配。而混合信号验证里说的网表，是晶体管/门级电路结构描述，包含器件模型、工艺参数、互连寄生，两者层级完全不同，别搞混。
如果你的项目目标是“把 RNM 模型落地成能跑的网表”，那么网表来源应该是模拟设计团队提供的 SPICE 网表或版图后提取网表。OrCAD 这类 EDA 工具链里的网表，更适合用于硬件板级验证的语境。在写验证计划时，明确网表的来源、格式、版本、清洗级别，能省掉后面大量的沟通成本。
5.4 排查工具与效率技巧
混合信号验证的调试效率很大程度上取决于波形查看工具和日志分析技巧。我的习惯是：导出的波形文件按测试用例分目录存放，并配合一个总索引文件列出每个用例的编译时间、运行时间和 pass/fail 状态。当出现仿真失败时，第一件事不是打开波形，而是先看仿真日志中的 error 段和 warning 段。很多混合信号的问题在编译阶段就有征兆，只是 warning 被淹没了。
此外，RNM 模型和结构网表的波形做对比时，不要同时显示所有信号，先挑 3 到 5 个关键点，比如 ADC 数字输出的第一位变化时刻、LDO 输出电压的稳定点、比较器翻转沿的时间差。如果这几个关键点对不上，再逐步扩大排查范围。这样比在波形窗口里漫无目的地缩放鼠标要高效得多。
6. 这个流程我在实际项目里的体会
说实话，MSDV 这套东西最大的价值不是让混合信号验证变得“高端”，而是让验证节奏变得可控。以前做一个带模拟模块的系统级验证，回归周期动辄一周，出一次 bug 要等下一轮。引入 RNM 抽象后，大部分功能验证在行为模型阶段就可以完成，回归时间压缩到小时级；结构网表阶段只需要聚焦于工艺参数导致的时序变化和模拟边界行为，关注面窄了，定位问题的速度自然快得多。
最后再分享一个操作习惯：RNM 模型的参数不要只放在验证环境里，一定要和模拟设计团队共享同一份参数基准。我见过太多次因为模型参数与原理图设计值不一致，导致验证通过了但芯片回来功能异常的案例。把参数映射表作为交付物之一，放进验证计划里，每次结构网表更新后强制跑一次参数一致性检查，这个习惯能帮你挡掉无数后仿真阶段的雷。
