我们做数模混合验证的都知道真正的痛不在单点电路能不能仿真而在于“系统级验证”这件事该怎么组织。一个 SoC 里嵌着 PLL、ADC、LDO、DAC 这些模拟 IP背后还有几百个数字模块如果每个模拟 IP 都用 SPICE 跑法整个芯片的回归验证根本不可能按期收敛。这就逼出了 MSDVMixed-Signal Design Verification这条路而 RNMReal Number Modeling实数建模和 Verilog-on-Top 架构正是这条路最核心的两个抓手。这篇文章我想把一条完整的实操链路讲清楚RNM 抽象怎么搭、Verilog-on-Top 环境怎么组织、模型最终怎么落成一份工具链认得的网表并跑起来。这里没有太多玄学更多的是我在项目里踩坑踩出来的“该这么做”和“不该那么做”以及对每一个选择背后的理由拆解。适合两类人看一类是被混合信号回归折磨的验证工程师另一类是想弄清楚 RNM 模型和真正网表之间是什么关系、想把手头模型“做扎实”的 IC 设计工程师。看完你能收获的是一套可以直接搬到自己项目里的方法而不是一堆悬在空中的概念。1. 整体设计思路为什么是 RNM为什么是 Verilog-on-Top1.1 MSDV 的痛点与 RNM 的定位混合信号验证最难的地方在于模拟世界和数字世界的“时间观”和“精度观”完全不一样。数字仿真器的时间是事件驱动的时钟沿一到就触发状态是 0/1/X/ZSPICE 仿真是连续时间域的步长由收敛算法自动控制可以小到飞秒级。你如果拿 SPICE 跑一个带数字逻辑的锁相环系统级场景跑上几毫秒的仿真时间实际要等好几天。这在现代 SoC 验证流程里是“不可接受”的。RNM 的出现就是把模拟 IP 的行为抽象成数字仿真器能认识的 real 变量——电压、电流、相位、频率都变成实数信号在标准数字仿真器里跑仿真。这样做的好处是压倒性的不需要专门的 AMS 仿真器 license回归速度能比 SPICE 快几个数量级而且整个环境的搭建方式、覆盖率收集方式、回归管理方式全部向数字验证流程看齐。说得直白一点RNM 不是要替代 SPICE而是在系统级验证这个位置上放弃晶体管级的精确度换来整颗芯片可跑、可回归的能力。我曾经在项目里把一颗 PLL 加上数字控制环路拿出来做对比SPICE 跑 100us 花了十多个小时RNM 模型跑同样的场景只要几十秒。代价确实有——RNM 里看不到环路噪声、失配、非理想效应。但你验证的目标是数字逻辑和模拟 IP 之间的交互时序、上下电顺序、寄存器配置流程这些非理想效应本来就不是在系统级仿真里看的。先把交互关系跑对再回到模拟级别做精细验证这才是工程上合理的拆分。1.2 Verilog-on-Top 到底是什么架构Verilog-on-Top 这个说法我最早是在混合信号验证架构讨论里频繁见到的它是一种“以数字仿真器为顶层”的验证架构。与之相对的还有 SPICE-on-Top、AMS-on-Top 这些组织方式但它们各有各的约束。Verilog-on-Top 的核心思想是整个芯片验证环境的顶层文件是用 Verilog/SystemVerilog 写出来的里面把数字模块当成 RTL 正常编译把模拟模块替换成 RNM 模型或包装成 RNM 模型的 wrapper把模拟 IP 与数字 IP 之间的物理连接转换成数字事件域中可见的 real 信号或 logic 信号。为什么我们优先选 Verilog-on-Top一个最直接的理由是系统级验证的重点几乎永远是数字逻辑的行为、状态机跳转、寄存器读写的正确性。把顶层控制权交给数字仿真器意味着整个回归环境可以把模拟 IP 当“可以被配置、被观测、有行为响应”的黑盒组件而不是需要一个专门模拟求解释器来“伺候”的娇贵物件。再加上目前主流数字仿真器包括 Xcelium、VCS 这些都已经能原生支持 real 类型建模的编译与仿真Verilog-on-Top 在落地成本上远比搭一套完整 AMS 环境要低得多。当然Verilog-on-Top 也有它的问题。最典型的是“模拟精度被人为折叠进一个 real 变量里”。你必须在模型层面想清楚一个 wreal 信号背后要表达的是完整的电压波形还是只表达关键电平跳变。这是整个架构里最需要判断力的地方也是后面模型设计部分要重点解决的。1.3 对比三种架构SPICE-on-Top、Verilog-on-Top、AMS Cosim我把三种常见架构放在一张表里梳理一下方便你在选型的时候对照。这张表并不是说谁一定好而是看你项目最关注什么。如果是小规模 IP 级验证SPICE-on-Top 没有太大问题一旦进入 SoC 数字回归Verilog-on-Top 的优势极其明显。架构顶层环境模拟部分仿真器代表特点适用场景SPICE-on-TopSPICE 网表晶体管级SPICE/AMS 混合仿真器精度高、速度慢、环境封闭模拟 IP 级验证、工艺角仿真AMS Cosim工具协调层可以是 RNM/晶体管级混合混合仿真器协作灵活但配置复杂需要局部高精度的系统场景Verilog-on-TopSystemVerilogRNM 模型为主数字仿真器速度快、环境统一、复用好SoC 系统回归、数字逻辑验证、上电时序验证从我自己的经验看绝大多数项目的最终形态是“Verilog-on-Top 架构 关键路径局部 cosim”的组合。也就是说系统级回归用 RNM 跑当发现某个模拟行为需要特别关注时再把那一小块电路换成晶体管级网表拿出来细查。一旦你接受了这个组合思路RNM 模型就不再是“随便写写的一个临时件”而是整套验证体系里的一等公民它的结构、规范、交付方式都必须认真对待。2. 从模拟电路到 RNM 模型抽象过程与建模规范2.1 建模前的三个核心决策什么抽、什么不抽、精度给到哪拿到一个模拟 IP比如一个 ADC 或 LDO你不可能把它的全部行为都塞进 RNM 模型那样模型复杂度和仿真时间都失控了。RNM 建模的第一步是决定抽象范围这次仿真要验证什么哪些行为必须保真哪些行为可以用理想化近似。这个决策通常要验证工程师和模拟设计工程师坐在一起对着 IP 的 spec 一页一页过。以一颗 12-bit SAR ADC 为例系统级验证关心的是转换启动信号到来之后多少纳秒能输出有效数据输入电压范围映射到输出 code 的关系是否线性busy/eoc 信号时序是否满足数字侧的要求。至于 ADC 内部的电容失配、比较器噪声、参考电压建立纹波在系统级模型里完全可以不建。重点是只保留“输入电压 - 数字 code”这个映射函数用 real 输入、logic 输出把它实现出来。这种程度的抽象仿真速度飞快对验证目标的覆盖率也是够用的。反过来如果有一次验证是要看带隙基准启动时间对 LDO 输出建立过程的影响那就不能把 LDO 简化为一个理想电压源至少要把软启动过程、限流行为、跌落行为建模进去。所以抽象范围不是越简越好而是“够验证目标用”就好少一步漏掉行为多一步拖慢仿真。2.2 wreal、realnet 与 SystemVerilog 实数建模基础RNM 在代码层面主要靠 SystemVerilog 的 real 类型以及专门的 wrealwire real类型来承载模拟信号。wreal 可以简单理解成一根“能传输 real 值”的 wire它和 logic wire 最大的区别是逻辑线的值是离散的 0/1/X/Z而 wreal 线的值是连续的浮点数用于表示电压或电流等模拟量。这个区别往深想一层你就明白为什么 RNM 能接住混合信号验证数字世界里没有“1.8V”这个概念但 wreal 有。在建模时还需要关心 wreal 的方向性。一个 wreal 端口既可以作为输入从外部接收模拟值也可以作为输出去驱动下一级模型。模型内部逻辑一般用 real 变量缓存再用 assign 把它连接到 wreal 端口上。需要特别注意的是很多 reg 型 real 变量不能直接在 always 块里驱动 wreal 端口而是要借助中间信号或特定的连续赋值方式来完成。不同仿真器对 wreal 的语法支持大同小异但工具版本低的时候坑会特别多后面排查部分我再展开。此外SystemVerilog 标准里还有一个与 wreal 相关的 nettype 概念用它可以自定义实数网络的解析规则。在简单的模型里用不上但如果要做跨模型的总线式模拟信号连接比如多路模拟通道汇聚进一个 ADCnettype 能帮你统一接力和赋值的规则是个值得了解的方向。2.3 一个典型 ADC 的 RNM 建模过程拆解用一个 12 位 SAR ADC 来做个实战拆解。首先定义模型端口模拟输入 vin 是 wreal 类型参考电压 vref 也是 wreal 类型控制侧有转换启动信号 convert_startlogic数据输出 data_ologic [11:0]以及转换完成标志 eoclogic。模型内部要做的事情只有两件采样和量化。在 convert_start 到来时模拟侧已经假设输入电压已经建立稳定所以模型在时钟沿取一次 vin 的实时值把它缓存到一个 real 变量 sample 里。接下来做量化把 sample 除以 vref得到比值再按 12 位量化精度映射成整数 code。这里有一个细节量化公式要按 AD 转换的真正关系来写——通常 SAR ADC 的输出 code 对应的是 floor(sample / vref * 4096)输入范围上限接近 vref 时 code 接近满量程超过范围时要做饱和处理而不是让 code 溢出。饱和这部分非常容易漏如果接入的模拟电压超过范围但模型不饱和会给出一个毫无物理意义的错误码还会把数字侧逻辑带偏。我给一段核心代码框架方便你对照理解module sar_adc_rnm ( input logic clk, input logic convert_start, input wreal vin, input wreal vref, output logic [11:0] data_o, output logic eoc ); real sample; real ratio; integer code; logic converting; always (posedge clk) begin if (convert_start !converting) begin sample vin; // 采样时刻直接把 wreal 值读进 real 变量 converting 1b1; end else if (converting) begin if (vref ! 0.0) begin ratio sample / vref; if (ratio 1.0) code 4095; // 饱和到满量程 else if (ratio 0.0) code 0; // 饱和到零 else code $rtoi(ratio * 4096.0); end else begin code 0; end data_o code[11:0]; eoc 1b1; converting 1b0; end else begin eoc 1b0; end end endmodule这里我把采样、量化、饱和处理放在同一拍完成是因为系统级验证阶段我们默认 ADC 的转换过程已经由模拟工程师保证过不需要在 RNM 里模拟逐次逼近的时钟周期。如果你要验证数字侧对转换延时的敏感性那就需要在模型里引入一个 timing parameter用 localparam 或 field 配置把从 convert_start 到 eoc 的延迟做成可调。这种参数化设计在 RNM 里非常实用一个模型可以在不同场景下翻出不同侧重点。2.4 建模时易漏的核心细节上电、上下拉、毛刺抑制和范围检查建模做到“功能正确”不算完真正让 RNM 模型从玩具变成工具是那一堆平时没人注意的边界行为。上电行为是第一个漏网之鱼。很多 RNM 模型一上电就有输出但真实模拟 IP 在上电后需要几十微秒甚至几毫秒建立稳定。如果你在验证上下电时序而模型里没有这个建仓延时就会错误地让数字逻辑在模拟尚未稳定的窗口里开始采样跑出一堆莫名其妙的问题。毛刺抑制也是重点。现实里的模拟比较器输出会有抖振但 RNM 模型里如果直接对 wreal 信号做 if 判断输入端一个小噪声就会形成多个毛刺沿。工程上的做法是给模型内部信号加一个固定死区hysteresis或者用一个小的延时滤波把输入在短时间内反复穿越阈值的情况吸收掉。这样既不影响功能又能防止毛刺冲击到数字逻辑。还有输入范围检查。模型里不能假设 wreal 信号永远在预期范围内因为你永远不知道 testbench 里下一个激励会造出什么电平。在输入端做一个 $display 或断言当 vin 超过“电源0.3V”或低于“地-0.3V”时打印一条 warning能让你在 trace 问题时省下大量时间。这些小细节单个看很简单但十几个模块叠加起来就是项目能不能顺利 debug 的分水岭。3. Verilog-on-Top 集成环境从零搭一个能跑的混合信号仿真3.1 顶层结构设计与目录规划Verilog-on-Top 环境的顶层结构可以理解为“一座大厦的骨架”。顶层 module 里不写具体业务逻辑只负责例化所有数字 RTL 模块和模拟包装模块同时把片内外的连接关系表达清楚。我习惯的顶层组织分成三层dut_top 放真实设计实例testbench_top 放激励和时钟复位生成bench 层放断言、监测和 scoreboard。DUT 层里模拟 IP 不直接例化 RNM 模型而是例化一个 wrapper 模块wrapper 内部再根据编译选项去选择加载 RNM 模型还是别的类型的模型。用 wrapper 而不是直接例化 RNM是为了应对“同一颗模拟 IP 在不同场景下使用不同模型”的常见需求。仿真阶段你可能用 RNM网表集成阶段可能要换成行为级 verilog 网表后仿阶段可能要换成带模拟行为描述的门级网表。带一个 wrapper 层切换模型就像改一个 define 或一个 filelist 一样简单不需要动顶层结构。这个设计上的前置投入很低后面换模型的时候能省非常多事。目录规划上我给一个常用模板project/ ├── rtl/ # 数字 RTL 代码 ├── analog_ip/ # 模拟 IP 相关文件 │ ├── rnm/ # RNM 模型 │ ├── wrapper/ # 模拟 IP wrapper │ ├── netlist/ # 模拟 IP 网表 │ └── behavior/ # 行为级 verilog/VAMS 模型 ├── tb/ # testbench 和 testcase ├── scripts/ # 编译运行脚本 └── results/ # 仿真输出、日志、覆盖率目录分层清晰之后回归脚本和 filelist 管理会非常顺滑。我见过太多项目把 RNM 模型和 RTL 混放在同一个目录里结果改模型时误提交、回归时漏编译、查 log 时找不到文件所有不该浪费的时间全部浪费了一遍。3.2 Wrapper 设计与 RNM 接入的接口约定Wrapper 的设计要点是让“模拟世界”和“数字世界”在一个受控的边界上完成转换。RNM 模型输出的 wreal 信号不能直接驱动数字逻辑端口——数字逻辑认识的是 logic 类型不认识 1.8V。所以 wrapper 里要承担几个固定任务wreal 到 logic 的阈值转换、logic 到 wreal 的电平映射、输入引脚的过滤与限幅。一个常见做法是在 wrapper 内部把模拟的 wreal 信号通过比较器逻辑转换成 digital 的 logic 信号再接给数字模块。比如一个 LDO 的 power_good 信号在 RNM 模型里是一个 wreal 电压值wrapper 里把它和 1.0V 做比较大于则输出 1小于则输出 0中间可以再加一段迟滞或滤波。这样数字侧看到的 power_good 就是一个普通的 logic 信号验证逻辑完全不需要感知 LDO 内部行为。另一方向的反向转换同样常见数字侧输出的配置信号要转成模拟侧能识别的电压或电流。比如一个片上 LDO 的参考电压配置digital 寄存器写入 codewrapper 需要把 code 按照 LSB 权重映射成一个 real 电压值再赋给 wreal 输出端口。这个过程必须用真实的换算关系不能拍脑袋写一个固定值否则模型和真实芯片之间的映射关系会失真。3.3 仿真环境搭建编译选择、混淆选项与回归管理environment 搭建阶段几个关键的编译选项值得多说一句。wreal 这类语法在不同仿真器上有不同的开关有的仿真器需要打开禁止 warning 选项有的则默认开启。你在集成环境时不要直接照抄别的项目的 filelist 和编译命令先在自己环境里用最小 case 跑通一个 wreal 模型的编译确认 syntax check 通过之后再往上叠加更多模块。这一步能帮你迅速定位问题范围而不是等整套环境搭完再去排错。回归管理方面我强烈建议从一开始就把覆盖率收集考虑进去。RNM 模型里模拟 IP 的行为很少比如 ADC 有没有跑满转换、LDO 有没有经历软启动这些边界行为在功能覆盖率里应该有所体现。你可以在 wrapper 里加一些 covergroup针对模型的关键状态转换做采样。这些覆盖率数据和数字逻辑的覆盖率数据合并后就是一张完整的系统验证进度表。否则验证做完了你根本说不清哪些模拟场景测过、哪些没有。3.4 最小可运行示例Verilog-on-Top 环境跑通流程为了让你有一个整体感知我给一个最小化的流程示例。假设你有一个 LDO 的 RNM 模型和一段数字逻辑 ldo_ctrl顶层需要把二者连起来。最简单的 Verilog-on-Top 环境大致长这样module chip_top ( input logic clk, input logic rst_n, input wreal vbat, // 顶层输入是模拟量 output logic power_good, output logic [1:0] cfg ); // 数字控制模块 ldo_ctrl u_ctrl ( .clk (clk), .rst_n (rst_n), .pg (pg_from_wrapper), .cfg (cfg_internal), .enable (en_from_wrapper) ); // LDO wrapper ldo_wrapper u_ldo ( .vbat (vbat), .enable (cfg_internal), .pg (pg_from_wrapper), .vout (vout_internal) ); endmodule在这个顶层里vbat 和 vout_internal 是 wreal 类型pg_from_wrapper 是 logic 类型。数字模块完全不感知 vbat 的存在它只看到 power_good 信号。testbench 里给 vbat 一个实际电压激励比如 initial vbat 3.3; 然后在指定时间拉低到 2.8V看 LDO 模型的输出和数字逻辑的响应。这种 environment 就是一个最典型的 Verilog-on-Top 雏形先跑通它再扩展到大型 SoC 集成思路完全一致。4. 模型落地成网表从抽象模型到一份能跑的网表4.1 “网表”在混合信号流程里的多层含义“网表”这个词在不同语境下指的东西其实不太一样这也是混合信号验证里一个容易产生歧义的点。在纯数字流程里网表通常指综合工具产生的门级网表比如 Verilog 门级网表里面是标准单元和它们之间的连线。在模拟流程里网表通常指晶体管级电路描述比如 CDL 格式或 SPICE 格式里面是 MOSFET、电阻、电容这些器件。而在混合信号流程里我们很可能面对的是“两层网表的集成”数字部分用门级网表模拟部分用晶体管级网表两者最终要被描述在一份统一的顶层网表里。标题里说的“模型怎么落地成一份能跑的网表”我理解的重点是在于RNM 模型不可能永远停留在行为级抽象它最终要和真实电路实现建立对应关系。最简单的形式是同一颗模拟 IP在验证阶段用 RNM在交付阶段把 RNM 替换成真实的晶体管级网表然后做最终签核仿真。你要有一根清楚的线说明 RNM 模型与最终网表之间的一致性由什么来保证。从纯模拟流程看这里的过程很像 PCB 设计里的 OrCAD 导出网表、Allegro 导入网表原理图阶段你用 OrCAD 画好连接关系导出一份网表后端用 Allegro 导入网表开始布局布线。芯片流程里RNM 模型就相当于“原理图级的抽象”后端工具要吃的“网表”则是包含真实器件信息的实现网表。如果前者和后者的命名、端口、连接关系对不上导入就会断线、丢 pin、甚至整个层级都错乱这跟 Allegro 导入 OrCAD 网表报警缺网络是一模一样的感觉。4.2 从 RNM 模型到模拟网表一致性保证与替换流程RNM 模型替换成真实模拟网表不是一个简单的“文件替换”动作。你需要一套流程来保证二者行为上的一致性。首先是接口一致性检查RNM 模型的端口名、方向、位宽必须和最终网表的 schematics 一致一个 pin 没对上后面的验证就是白做。我会在项目里专门放一个脚本自动提取 RNM 模型端口列表和 CDL 网表端口列表做比对把不一致项直接标红报错。其次是行为一致性测试。在替换之前要准备一组“公共测试用例”在 RNM 模型上跑一遍记录关键波形和关键数值然后在真实网表上再跑一遍对比结果差异在可接受范围内。这个步骤和数字后端里的等价性检查思路类似只是混合信号这边不是用 formality而是用仿真结果对比。工作量大但极为必要——很多模型和电路行为对不上都是在这个环节被拦下来的。替换过程本身则取决于你的环境组织方式。前面提到的 wrapper 层在这里会发挥重要作用当你需要从 RNM 切到真实网表时只需要修改编译 filelist让 wrapper 例化 CDL 网表对应的行为 verilog 模型或直接走 AMS 仿真器而不需要改动顶层和测试用例。这样“验证模型”和“签核模型”就做到了平滑切换没有破坏性变化。4.3 数字网表与模拟网表的顶层集成步骤与工具链当数字部分和模拟部分都已经具备真实网表之后混合信号网表集成会有两条路线数字网表为主 模拟行为模型或者模拟网表为主 数字门级网表。绝大多数系统签核会选择前一种因为数字回归环境更容易提速模拟部分只在真正需要精度的地方切到晶体管级。集成步骤可以拆成五步。第一步把数字 RTL 做逻辑综合得到门级数字网表。第二步把模拟 IP 的 CDL 网表、或行为描述准备好与 wrapper 中对应的端口一一对齐。第三步在顶层网表里保持 Verilog-on-Top 结构将 wrapper 内部从 RNM 模型替换为模拟网表模型完成顶层连接。第四步做连接性和电学规则检查包括电源地是否接全、输入输出端口是否悬空、有没有意外的短路。第五步跑顶层混合信号仿真验证集成后的行为与原 RNM 环境一致同时检查时序收敛、建立保持时间是否满足要求。工具链方面模拟网表一般用 SPICE 仿真器或 AMS 仿真器跑数字网表则用数字仿真器。在 Verilog-on-Top 架构下混合跑往往需要 AMS 工具支持顶层 Verilog 例化 SPICE 子电路。不同厂家工具在这个环节的配置文件和指令格式差异比较大但这部分技术细节属于需要开具体 EDA 工具再说的内容不在文章里展开了。4.4 网表落地最常见的失败模式与防错机制网表落地阶段失败模式非常集中几乎每一个我都亲眼见过。第一种是端口名称错位——模拟网表里的 pin 名和 wrapper 里例化名对不上这是最典型的 OrCAD 导出网表、Allegro 导入网表时也会遇到的同名问题。第二种是电源域不一致——模拟 IP 的电源 pin 接在错误的电源网络上仿真结果可能是正常的但物理实现后就会出大问题。第三种是模型方向定义错误把输入输出搞反了仿真不出报错但数据永远是错的这类问题最隐蔽。防错机制上我建议在集成完成之后强制跑一轮“空跑仿真”就是不加任何激励只做上电和复位然后检查所有关键节点电压是否在预期范围内。这一步虽然听起来简单却能在跑完整回归之前揪出绝大部分连接性错误和电源域问题。另外在 wrapper 里加一些结构性的断言也有帮助比如“模拟 IP 在未上电情况下绝对不允许输出有效信号”这类断言能在仿真早期自动报警而不至于等你跟踪好几个小时才发现是电源问题。5. 常见问题与排查技巧我在实战中踩过的坑5.1 仿真极慢甚至卡死原因在事件密度而不在模型复杂度RNM 模型刚上手时一个特别容易踩的坑是模型功能没问题但是整个仿真跑得特别慢甚至像卡死一样。问题根源往往不在模型本身的复杂度而在于 real 信号的事件密度超过了数字仿真器的调度能力。数字仿真器的调度器是为逻辑事件设计的当 real 信号每纳秒都产生一个更新事件时调度器会被海量事件淹没时间推进变得极慢。解决思路是“节流”。在模型内部对 real 信号做事件过滤只在关键事件发生时更新输出比如电压变化超过一定阈值时才触发更新或者只在时钟沿采样后进行更新。这样既保证了功能精度又把事件数量降下来。另一个思路是尽量省去多余的 assign 链避免 real 信号被一层一层地复制和传播少一跳中间事件仿真速度都能明显提升。5.2 波形工具里看不到 wreal 波形这个坑几乎是每个 RNM 新手都会碰到的。你在 testbench 里明明打印了 wreal 信号的值但打开波形工具那个信号却什么都看不到或者只显示成数字跳变。原因是很多数字波形格式默认按 logic 类型处理信号而 wreal 是实数信号需要以 analog 波形方式保存和显示。解决办法是在仿真脚本里把需要观测的 wreal 信号显式地声明成 FSDB 的 analog 类型或者在波形文件配置里把 wreal 信号映射到模拟波形组。这样打开波形工具后那些信号才能显示成连续的电压曲线。我给个建议在你做第一个 RNM 仿真时就花点时间把这个问题解决掉否则后面做波形分析会一直很痛苦。5.3 模型更新后回归突然大规模失败接口同步检查永远是第一步项目进行到中后期模拟设计工程师会把 IP 的 spec 更新一版RNM 模型跟着改了端口或映射关系结果一夜之间回归挂掉一大片。这种时候最忌讳直接去翻 testcase 代码你要做的第一件事永远是检查模型接口有没有变。端口名字变了、位宽变了、方向变了任何一项都会导致编译或运行时静默失败。我们在项目里规定任何 RNM 模型接口变更必须同步更新一份接口变更记录表并且 wrapper 层要跑一次编译连通性检查所有端口必须严格匹配。这个习惯养成之后模型更新引起的回归失败从“需要半天排查”降低到“十分钟定位”。5.4 模型行为与实际电路差异永远保留一份“模型能力边界文档”RNM 模型是抽象必然有不能覆盖的行为。我在实际项目中吃过最大的亏就是模型里没建上电延迟行为导致数字逻辑在仿真中提前开始工作掩盖了一个真实的时序问题。后来我们建立了一个机制每个 RNM 模型除了代码本身还必须附带一份“能力边界文档”里面逐条列出这个模型建了什么、没有建什么、理想化处理了什么。例如“不建噪声、不建失配、上电延时建模为固定值 XXX”。这份文档的作用是让所有使用者知道模型的可信边界在哪避免把模型的不足当成芯片的 bug或者反过来把模型的理想化当成真实行为去依赖。5.5 工具版本与 wreal 兼容性的避坑策略wreal 在给到不同仿真器、不同版本时支持度可能会有细微差异。一个在旧版本工具上编译通过的模型在新版本上可能报出一堆关于 real 端口和 logic 端口互联的 warning 甚至 error。避坑策略很简单给模型加一套“兼容性编译头”在模型文件里用条件编译方式处理 wreal 声明或者在编译脚本里做版本判断。更重要的是在你升级工具版本之前先用一个包含典型 RNM 模型的最小回归集做全量编译验证工具升级没有破坏现有模型行为。5.6 常见问题速查表现象可能原因快速排查/解决编译报 wreal 相关错误仿真器版本过低/未开wreal支持检查编译选项、升级工具或用realassign替代仿真极慢real 事件过密模型加事件节流减少实时 assign 链波形看不到模拟量波形格式未识别 wreal存 FSDB设 analog 类型显示回归大面积 fail模型接口变更未同步先比端口再看文件list绝不先改 testcase模型行为与电路差异大模型能力边界不清对照能力边界文档逐条确认抽象假设网表集成后仿真异常端口错位/电源域接错跑空转上电仿真检查关键节点电平6. 回归验证体系与最终交付6.1 一个“能跑”的网表判定标准是什么一份网表能跑起来不是说仿真命令执行完不报错就算完。我在项目里对“能跑”的定义包含三个层次第一编译无致命错误所有调用关系正确没有悬空连接和端口失配第二仿真结果可预期在标准激励下关键节点的电压值和状态跳变符合 spec第三性能可接受在规定时间内能完成批量回归而不是等一个用例就要一晚上。这三条缺一条网表就不算真正达到交付状态。尤其最后一条性能可接受最容易被忽略。RNM 模型已经大幅提速了但如果你的顶层环境没有做好事件节流、没有优化文件结构、没有合理的编译粒度整个回归时间依然会膨胀到不可用。回到工程本质验证环境的价值是“快速反馈”如果环境本身慢到没法迭代再精确的模型也没有意义。6.2 回归验证的层级与策略从功能到签核的推进路径落地回归体系的时候我习惯把验证分成三个递进层级。第一层是模型级验证针对单个模拟 IP 的 RNM 模型做定向测试确保模型本身行为可信这层跑得快、跑得勤每次模型更新都要全集回归。第二层是 SoC 融合验证在 Verilog-on-Top 环境里把数字 RTL 和模拟 IP 模型放在一起做系统级回归覆盖各种配置组合与边界场景。第三层是签核验证用替换了真实网表的环境做最终确认不要求全量回归但关键用例必须完整跑一遍。这个分层策略的核心价值是把“验证成本”和“验证价值”做了一次合理的再分配。模型级回归随时可跑帮你快速抓住模型回归系统级回归代价适中帮你验证交互行为签核回归代价最大所以只保留最关键的一批用例。这样一个项目里你既不会因为模型天天改而陷入饱和回归的泥潭也不会因为最后没有用真实网表跑过而心里没底。6.3 交付物清单模型、文档、脚本与网表的一揽子配套最后讲交付。RNM 模型落地产出网表这个过程的交付物不只是一份网表文件。我整理了一份检查清单RNM 模型源码、行为描述文档、能力边界文档、模型更新记录、wrapper 源码、编译脚本、接口比对脚本、公共测试用例集、回归报告。每一项都要和最终网表放在一起移交缺一样接手的同事就得花时间重新踩你踩过的坑。我特别想把“能力边界文档”再强调一次因为这是最容易在赶进度时省略、但后期最痛苦的文件。你想想三个月后你打开一个自己写的 RNM 模型如果没有文档你还能准确说出它没有建哪些行为吗大概率不能。与其那时靠回忆不如现在每写一个模型就在文档里同步更新一条边界说明。这个过程几乎不增加额外时间但长期收益极其可观。网表落地这件事本质上是把“验证世界的抽象”和“实现世界的真实”对齐。RNM 模型不是终点网表也不是终点真正的终点是你能在新设计里复用这套方法让它从一个项目的临时方案变成团队里可复制、可依赖的流程资产。 RNM实数建模与Verilog-on-Top混合信号验证及网表落地指南
我们做数模混合验证的都知道真正的痛不在单点电路能不能仿真而在于“系统级验证”这件事该怎么组织。一个 SoC 里嵌着 PLL、ADC、LDO、DAC 这些模拟 IP背后还有几百个数字模块如果每个模拟 IP 都用 SPICE 跑法整个芯片的回归验证根本不可能按期收敛。这就逼出了 MSDVMixed-Signal Design Verification这条路而 RNMReal Number Modeling实数建模和 Verilog-on-Top 架构正是这条路最核心的两个抓手。这篇文章我想把一条完整的实操链路讲清楚RNM 抽象怎么搭、Verilog-on-Top 环境怎么组织、模型最终怎么落成一份工具链认得的网表并跑起来。这里没有太多玄学更多的是我在项目里踩坑踩出来的“该这么做”和“不该那么做”以及对每一个选择背后的理由拆解。适合两类人看一类是被混合信号回归折磨的验证工程师另一类是想弄清楚 RNM 模型和真正网表之间是什么关系、想把手头模型“做扎实”的 IC 设计工程师。看完你能收获的是一套可以直接搬到自己项目里的方法而不是一堆悬在空中的概念。1. 整体设计思路为什么是 RNM为什么是 Verilog-on-Top1.1 MSDV 的痛点与 RNM 的定位混合信号验证最难的地方在于模拟世界和数字世界的“时间观”和“精度观”完全不一样。数字仿真器的时间是事件驱动的时钟沿一到就触发状态是 0/1/X/ZSPICE 仿真是连续时间域的步长由收敛算法自动控制可以小到飞秒级。你如果拿 SPICE 跑一个带数字逻辑的锁相环系统级场景跑上几毫秒的仿真时间实际要等好几天。这在现代 SoC 验证流程里是“不可接受”的。RNM 的出现就是把模拟 IP 的行为抽象成数字仿真器能认识的 real 变量——电压、电流、相位、频率都变成实数信号在标准数字仿真器里跑仿真。这样做的好处是压倒性的不需要专门的 AMS 仿真器 license回归速度能比 SPICE 快几个数量级而且整个环境的搭建方式、覆盖率收集方式、回归管理方式全部向数字验证流程看齐。说得直白一点RNM 不是要替代 SPICE而是在系统级验证这个位置上放弃晶体管级的精确度换来整颗芯片可跑、可回归的能力。我曾经在项目里把一颗 PLL 加上数字控制环路拿出来做对比SPICE 跑 100us 花了十多个小时RNM 模型跑同样的场景只要几十秒。代价确实有——RNM 里看不到环路噪声、失配、非理想效应。但你验证的目标是数字逻辑和模拟 IP 之间的交互时序、上下电顺序、寄存器配置流程这些非理想效应本来就不是在系统级仿真里看的。先把交互关系跑对再回到模拟级别做精细验证这才是工程上合理的拆分。1.2 Verilog-on-Top 到底是什么架构Verilog-on-Top 这个说法我最早是在混合信号验证架构讨论里频繁见到的它是一种“以数字仿真器为顶层”的验证架构。与之相对的还有 SPICE-on-Top、AMS-on-Top 这些组织方式但它们各有各的约束。Verilog-on-Top 的核心思想是整个芯片验证环境的顶层文件是用 Verilog/SystemVerilog 写出来的里面把数字模块当成 RTL 正常编译把模拟模块替换成 RNM 模型或包装成 RNM 模型的 wrapper把模拟 IP 与数字 IP 之间的物理连接转换成数字事件域中可见的 real 信号或 logic 信号。为什么我们优先选 Verilog-on-Top一个最直接的理由是系统级验证的重点几乎永远是数字逻辑的行为、状态机跳转、寄存器读写的正确性。把顶层控制权交给数字仿真器意味着整个回归环境可以把模拟 IP 当“可以被配置、被观测、有行为响应”的黑盒组件而不是需要一个专门模拟求解释器来“伺候”的娇贵物件。再加上目前主流数字仿真器包括 Xcelium、VCS 这些都已经能原生支持 real 类型建模的编译与仿真Verilog-on-Top 在落地成本上远比搭一套完整 AMS 环境要低得多。当然Verilog-on-Top 也有它的问题。最典型的是“模拟精度被人为折叠进一个 real 变量里”。你必须在模型层面想清楚一个 wreal 信号背后要表达的是完整的电压波形还是只表达关键电平跳变。这是整个架构里最需要判断力的地方也是后面模型设计部分要重点解决的。1.3 对比三种架构SPICE-on-Top、Verilog-on-Top、AMS Cosim我把三种常见架构放在一张表里梳理一下方便你在选型的时候对照。这张表并不是说谁一定好而是看你项目最关注什么。如果是小规模 IP 级验证SPICE-on-Top 没有太大问题一旦进入 SoC 数字回归Verilog-on-Top 的优势极其明显。架构顶层环境模拟部分仿真器代表特点适用场景SPICE-on-TopSPICE 网表晶体管级SPICE/AMS 混合仿真器精度高、速度慢、环境封闭模拟 IP 级验证、工艺角仿真AMS Cosim工具协调层可以是 RNM/晶体管级混合混合仿真器协作灵活但配置复杂需要局部高精度的系统场景Verilog-on-TopSystemVerilogRNM 模型为主数字仿真器速度快、环境统一、复用好SoC 系统回归、数字逻辑验证、上电时序验证从我自己的经验看绝大多数项目的最终形态是“Verilog-on-Top 架构 关键路径局部 cosim”的组合。也就是说系统级回归用 RNM 跑当发现某个模拟行为需要特别关注时再把那一小块电路换成晶体管级网表拿出来细查。一旦你接受了这个组合思路RNM 模型就不再是“随便写写的一个临时件”而是整套验证体系里的一等公民它的结构、规范、交付方式都必须认真对待。2. 从模拟电路到 RNM 模型抽象过程与建模规范2.1 建模前的三个核心决策什么抽、什么不抽、精度给到哪拿到一个模拟 IP比如一个 ADC 或 LDO你不可能把它的全部行为都塞进 RNM 模型那样模型复杂度和仿真时间都失控了。RNM 建模的第一步是决定抽象范围这次仿真要验证什么哪些行为必须保真哪些行为可以用理想化近似。这个决策通常要验证工程师和模拟设计工程师坐在一起对着 IP 的 spec 一页一页过。以一颗 12-bit SAR ADC 为例系统级验证关心的是转换启动信号到来之后多少纳秒能输出有效数据输入电压范围映射到输出 code 的关系是否线性busy/eoc 信号时序是否满足数字侧的要求。至于 ADC 内部的电容失配、比较器噪声、参考电压建立纹波在系统级模型里完全可以不建。重点是只保留“输入电压 - 数字 code”这个映射函数用 real 输入、logic 输出把它实现出来。这种程度的抽象仿真速度飞快对验证目标的覆盖率也是够用的。反过来如果有一次验证是要看带隙基准启动时间对 LDO 输出建立过程的影响那就不能把 LDO 简化为一个理想电压源至少要把软启动过程、限流行为、跌落行为建模进去。所以抽象范围不是越简越好而是“够验证目标用”就好少一步漏掉行为多一步拖慢仿真。2.2 wreal、realnet 与 SystemVerilog 实数建模基础RNM 在代码层面主要靠 SystemVerilog 的 real 类型以及专门的 wrealwire real类型来承载模拟信号。wreal 可以简单理解成一根“能传输 real 值”的 wire它和 logic wire 最大的区别是逻辑线的值是离散的 0/1/X/Z而 wreal 线的值是连续的浮点数用于表示电压或电流等模拟量。这个区别往深想一层你就明白为什么 RNM 能接住混合信号验证数字世界里没有“1.8V”这个概念但 wreal 有。在建模时还需要关心 wreal 的方向性。一个 wreal 端口既可以作为输入从外部接收模拟值也可以作为输出去驱动下一级模型。模型内部逻辑一般用 real 变量缓存再用 assign 把它连接到 wreal 端口上。需要特别注意的是很多 reg 型 real 变量不能直接在 always 块里驱动 wreal 端口而是要借助中间信号或特定的连续赋值方式来完成。不同仿真器对 wreal 的语法支持大同小异但工具版本低的时候坑会特别多后面排查部分我再展开。此外SystemVerilog 标准里还有一个与 wreal 相关的 nettype 概念用它可以自定义实数网络的解析规则。在简单的模型里用不上但如果要做跨模型的总线式模拟信号连接比如多路模拟通道汇聚进一个 ADCnettype 能帮你统一接力和赋值的规则是个值得了解的方向。2.3 一个典型 ADC 的 RNM 建模过程拆解用一个 12 位 SAR ADC 来做个实战拆解。首先定义模型端口模拟输入 vin 是 wreal 类型参考电压 vref 也是 wreal 类型控制侧有转换启动信号 convert_startlogic数据输出 data_ologic [11:0]以及转换完成标志 eoclogic。模型内部要做的事情只有两件采样和量化。在 convert_start 到来时模拟侧已经假设输入电压已经建立稳定所以模型在时钟沿取一次 vin 的实时值把它缓存到一个 real 变量 sample 里。接下来做量化把 sample 除以 vref得到比值再按 12 位量化精度映射成整数 code。这里有一个细节量化公式要按 AD 转换的真正关系来写——通常 SAR ADC 的输出 code 对应的是 floor(sample / vref * 4096)输入范围上限接近 vref 时 code 接近满量程超过范围时要做饱和处理而不是让 code 溢出。饱和这部分非常容易漏如果接入的模拟电压超过范围但模型不饱和会给出一个毫无物理意义的错误码还会把数字侧逻辑带偏。我给一段核心代码框架方便你对照理解module sar_adc_rnm ( input logic clk, input logic convert_start, input wreal vin, input wreal vref, output logic [11:0] data_o, output logic eoc ); real sample; real ratio; integer code; logic converting; always (posedge clk) begin if (convert_start !converting) begin sample vin; // 采样时刻直接把 wreal 值读进 real 变量 converting 1b1; end else if (converting) begin if (vref ! 0.0) begin ratio sample / vref; if (ratio 1.0) code 4095; // 饱和到满量程 else if (ratio 0.0) code 0; // 饱和到零 else code $rtoi(ratio * 4096.0); end else begin code 0; end data_o code[11:0]; eoc 1b1; converting 1b0; end else begin eoc 1b0; end end endmodule这里我把采样、量化、饱和处理放在同一拍完成是因为系统级验证阶段我们默认 ADC 的转换过程已经由模拟工程师保证过不需要在 RNM 里模拟逐次逼近的时钟周期。如果你要验证数字侧对转换延时的敏感性那就需要在模型里引入一个 timing parameter用 localparam 或 field 配置把从 convert_start 到 eoc 的延迟做成可调。这种参数化设计在 RNM 里非常实用一个模型可以在不同场景下翻出不同侧重点。2.4 建模时易漏的核心细节上电、上下拉、毛刺抑制和范围检查建模做到“功能正确”不算完真正让 RNM 模型从玩具变成工具是那一堆平时没人注意的边界行为。上电行为是第一个漏网之鱼。很多 RNM 模型一上电就有输出但真实模拟 IP 在上电后需要几十微秒甚至几毫秒建立稳定。如果你在验证上下电时序而模型里没有这个建仓延时就会错误地让数字逻辑在模拟尚未稳定的窗口里开始采样跑出一堆莫名其妙的问题。毛刺抑制也是重点。现实里的模拟比较器输出会有抖振但 RNM 模型里如果直接对 wreal 信号做 if 判断输入端一个小噪声就会形成多个毛刺沿。工程上的做法是给模型内部信号加一个固定死区hysteresis或者用一个小的延时滤波把输入在短时间内反复穿越阈值的情况吸收掉。这样既不影响功能又能防止毛刺冲击到数字逻辑。还有输入范围检查。模型里不能假设 wreal 信号永远在预期范围内因为你永远不知道 testbench 里下一个激励会造出什么电平。在输入端做一个 $display 或断言当 vin 超过“电源0.3V”或低于“地-0.3V”时打印一条 warning能让你在 trace 问题时省下大量时间。这些小细节单个看很简单但十几个模块叠加起来就是项目能不能顺利 debug 的分水岭。3. Verilog-on-Top 集成环境从零搭一个能跑的混合信号仿真3.1 顶层结构设计与目录规划Verilog-on-Top 环境的顶层结构可以理解为“一座大厦的骨架”。顶层 module 里不写具体业务逻辑只负责例化所有数字 RTL 模块和模拟包装模块同时把片内外的连接关系表达清楚。我习惯的顶层组织分成三层dut_top 放真实设计实例testbench_top 放激励和时钟复位生成bench 层放断言、监测和 scoreboard。DUT 层里模拟 IP 不直接例化 RNM 模型而是例化一个 wrapper 模块wrapper 内部再根据编译选项去选择加载 RNM 模型还是别的类型的模型。用 wrapper 而不是直接例化 RNM是为了应对“同一颗模拟 IP 在不同场景下使用不同模型”的常见需求。仿真阶段你可能用 RNM网表集成阶段可能要换成行为级 verilog 网表后仿阶段可能要换成带模拟行为描述的门级网表。带一个 wrapper 层切换模型就像改一个 define 或一个 filelist 一样简单不需要动顶层结构。这个设计上的前置投入很低后面换模型的时候能省非常多事。目录规划上我给一个常用模板project/ ├── rtl/ # 数字 RTL 代码 ├── analog_ip/ # 模拟 IP 相关文件 │ ├── rnm/ # RNM 模型 │ ├── wrapper/ # 模拟 IP wrapper │ ├── netlist/ # 模拟 IP 网表 │ └── behavior/ # 行为级 verilog/VAMS 模型 ├── tb/ # testbench 和 testcase ├── scripts/ # 编译运行脚本 └── results/ # 仿真输出、日志、覆盖率目录分层清晰之后回归脚本和 filelist 管理会非常顺滑。我见过太多项目把 RNM 模型和 RTL 混放在同一个目录里结果改模型时误提交、回归时漏编译、查 log 时找不到文件所有不该浪费的时间全部浪费了一遍。3.2 Wrapper 设计与 RNM 接入的接口约定Wrapper 的设计要点是让“模拟世界”和“数字世界”在一个受控的边界上完成转换。RNM 模型输出的 wreal 信号不能直接驱动数字逻辑端口——数字逻辑认识的是 logic 类型不认识 1.8V。所以 wrapper 里要承担几个固定任务wreal 到 logic 的阈值转换、logic 到 wreal 的电平映射、输入引脚的过滤与限幅。一个常见做法是在 wrapper 内部把模拟的 wreal 信号通过比较器逻辑转换成 digital 的 logic 信号再接给数字模块。比如一个 LDO 的 power_good 信号在 RNM 模型里是一个 wreal 电压值wrapper 里把它和 1.0V 做比较大于则输出 1小于则输出 0中间可以再加一段迟滞或滤波。这样数字侧看到的 power_good 就是一个普通的 logic 信号验证逻辑完全不需要感知 LDO 内部行为。另一方向的反向转换同样常见数字侧输出的配置信号要转成模拟侧能识别的电压或电流。比如一个片上 LDO 的参考电压配置digital 寄存器写入 codewrapper 需要把 code 按照 LSB 权重映射成一个 real 电压值再赋给 wreal 输出端口。这个过程必须用真实的换算关系不能拍脑袋写一个固定值否则模型和真实芯片之间的映射关系会失真。3.3 仿真环境搭建编译选择、混淆选项与回归管理environment 搭建阶段几个关键的编译选项值得多说一句。wreal 这类语法在不同仿真器上有不同的开关有的仿真器需要打开禁止 warning 选项有的则默认开启。你在集成环境时不要直接照抄别的项目的 filelist 和编译命令先在自己环境里用最小 case 跑通一个 wreal 模型的编译确认 syntax check 通过之后再往上叠加更多模块。这一步能帮你迅速定位问题范围而不是等整套环境搭完再去排错。回归管理方面我强烈建议从一开始就把覆盖率收集考虑进去。RNM 模型里模拟 IP 的行为很少比如 ADC 有没有跑满转换、LDO 有没有经历软启动这些边界行为在功能覆盖率里应该有所体现。你可以在 wrapper 里加一些 covergroup针对模型的关键状态转换做采样。这些覆盖率数据和数字逻辑的覆盖率数据合并后就是一张完整的系统验证进度表。否则验证做完了你根本说不清哪些模拟场景测过、哪些没有。3.4 最小可运行示例Verilog-on-Top 环境跑通流程为了让你有一个整体感知我给一个最小化的流程示例。假设你有一个 LDO 的 RNM 模型和一段数字逻辑 ldo_ctrl顶层需要把二者连起来。最简单的 Verilog-on-Top 环境大致长这样module chip_top ( input logic clk, input logic rst_n, input wreal vbat, // 顶层输入是模拟量 output logic power_good, output logic [1:0] cfg ); // 数字控制模块 ldo_ctrl u_ctrl ( .clk (clk), .rst_n (rst_n), .pg (pg_from_wrapper), .cfg (cfg_internal), .enable (en_from_wrapper) ); // LDO wrapper ldo_wrapper u_ldo ( .vbat (vbat), .enable (cfg_internal), .pg (pg_from_wrapper), .vout (vout_internal) ); endmodule在这个顶层里vbat 和 vout_internal 是 wreal 类型pg_from_wrapper 是 logic 类型。数字模块完全不感知 vbat 的存在它只看到 power_good 信号。testbench 里给 vbat 一个实际电压激励比如 initial vbat 3.3; 然后在指定时间拉低到 2.8V看 LDO 模型的输出和数字逻辑的响应。这种 environment 就是一个最典型的 Verilog-on-Top 雏形先跑通它再扩展到大型 SoC 集成思路完全一致。4. 模型落地成网表从抽象模型到一份能跑的网表4.1 “网表”在混合信号流程里的多层含义“网表”这个词在不同语境下指的东西其实不太一样这也是混合信号验证里一个容易产生歧义的点。在纯数字流程里网表通常指综合工具产生的门级网表比如 Verilog 门级网表里面是标准单元和它们之间的连线。在模拟流程里网表通常指晶体管级电路描述比如 CDL 格式或 SPICE 格式里面是 MOSFET、电阻、电容这些器件。而在混合信号流程里我们很可能面对的是“两层网表的集成”数字部分用门级网表模拟部分用晶体管级网表两者最终要被描述在一份统一的顶层网表里。标题里说的“模型怎么落地成一份能跑的网表”我理解的重点是在于RNM 模型不可能永远停留在行为级抽象它最终要和真实电路实现建立对应关系。最简单的形式是同一颗模拟 IP在验证阶段用 RNM在交付阶段把 RNM 替换成真实的晶体管级网表然后做最终签核仿真。你要有一根清楚的线说明 RNM 模型与最终网表之间的一致性由什么来保证。从纯模拟流程看这里的过程很像 PCB 设计里的 OrCAD 导出网表、Allegro 导入网表原理图阶段你用 OrCAD 画好连接关系导出一份网表后端用 Allegro 导入网表开始布局布线。芯片流程里RNM 模型就相当于“原理图级的抽象”后端工具要吃的“网表”则是包含真实器件信息的实现网表。如果前者和后者的命名、端口、连接关系对不上导入就会断线、丢 pin、甚至整个层级都错乱这跟 Allegro 导入 OrCAD 网表报警缺网络是一模一样的感觉。4.2 从 RNM 模型到模拟网表一致性保证与替换流程RNM 模型替换成真实模拟网表不是一个简单的“文件替换”动作。你需要一套流程来保证二者行为上的一致性。首先是接口一致性检查RNM 模型的端口名、方向、位宽必须和最终网表的 schematics 一致一个 pin 没对上后面的验证就是白做。我会在项目里专门放一个脚本自动提取 RNM 模型端口列表和 CDL 网表端口列表做比对把不一致项直接标红报错。其次是行为一致性测试。在替换之前要准备一组“公共测试用例”在 RNM 模型上跑一遍记录关键波形和关键数值然后在真实网表上再跑一遍对比结果差异在可接受范围内。这个步骤和数字后端里的等价性检查思路类似只是混合信号这边不是用 formality而是用仿真结果对比。工作量大但极为必要——很多模型和电路行为对不上都是在这个环节被拦下来的。替换过程本身则取决于你的环境组织方式。前面提到的 wrapper 层在这里会发挥重要作用当你需要从 RNM 切到真实网表时只需要修改编译 filelist让 wrapper 例化 CDL 网表对应的行为 verilog 模型或直接走 AMS 仿真器而不需要改动顶层和测试用例。这样“验证模型”和“签核模型”就做到了平滑切换没有破坏性变化。4.3 数字网表与模拟网表的顶层集成步骤与工具链当数字部分和模拟部分都已经具备真实网表之后混合信号网表集成会有两条路线数字网表为主 模拟行为模型或者模拟网表为主 数字门级网表。绝大多数系统签核会选择前一种因为数字回归环境更容易提速模拟部分只在真正需要精度的地方切到晶体管级。集成步骤可以拆成五步。第一步把数字 RTL 做逻辑综合得到门级数字网表。第二步把模拟 IP 的 CDL 网表、或行为描述准备好与 wrapper 中对应的端口一一对齐。第三步在顶层网表里保持 Verilog-on-Top 结构将 wrapper 内部从 RNM 模型替换为模拟网表模型完成顶层连接。第四步做连接性和电学规则检查包括电源地是否接全、输入输出端口是否悬空、有没有意外的短路。第五步跑顶层混合信号仿真验证集成后的行为与原 RNM 环境一致同时检查时序收敛、建立保持时间是否满足要求。工具链方面模拟网表一般用 SPICE 仿真器或 AMS 仿真器跑数字网表则用数字仿真器。在 Verilog-on-Top 架构下混合跑往往需要 AMS 工具支持顶层 Verilog 例化 SPICE 子电路。不同厂家工具在这个环节的配置文件和指令格式差异比较大但这部分技术细节属于需要开具体 EDA 工具再说的内容不在文章里展开了。4.4 网表落地最常见的失败模式与防错机制网表落地阶段失败模式非常集中几乎每一个我都亲眼见过。第一种是端口名称错位——模拟网表里的 pin 名和 wrapper 里例化名对不上这是最典型的 OrCAD 导出网表、Allegro 导入网表时也会遇到的同名问题。第二种是电源域不一致——模拟 IP 的电源 pin 接在错误的电源网络上仿真结果可能是正常的但物理实现后就会出大问题。第三种是模型方向定义错误把输入输出搞反了仿真不出报错但数据永远是错的这类问题最隐蔽。防错机制上我建议在集成完成之后强制跑一轮“空跑仿真”就是不加任何激励只做上电和复位然后检查所有关键节点电压是否在预期范围内。这一步虽然听起来简单却能在跑完整回归之前揪出绝大部分连接性错误和电源域问题。另外在 wrapper 里加一些结构性的断言也有帮助比如“模拟 IP 在未上电情况下绝对不允许输出有效信号”这类断言能在仿真早期自动报警而不至于等你跟踪好几个小时才发现是电源问题。5. 常见问题与排查技巧我在实战中踩过的坑5.1 仿真极慢甚至卡死原因在事件密度而不在模型复杂度RNM 模型刚上手时一个特别容易踩的坑是模型功能没问题但是整个仿真跑得特别慢甚至像卡死一样。问题根源往往不在模型本身的复杂度而在于 real 信号的事件密度超过了数字仿真器的调度能力。数字仿真器的调度器是为逻辑事件设计的当 real 信号每纳秒都产生一个更新事件时调度器会被海量事件淹没时间推进变得极慢。解决思路是“节流”。在模型内部对 real 信号做事件过滤只在关键事件发生时更新输出比如电压变化超过一定阈值时才触发更新或者只在时钟沿采样后进行更新。这样既保证了功能精度又把事件数量降下来。另一个思路是尽量省去多余的 assign 链避免 real 信号被一层一层地复制和传播少一跳中间事件仿真速度都能明显提升。5.2 波形工具里看不到 wreal 波形这个坑几乎是每个 RNM 新手都会碰到的。你在 testbench 里明明打印了 wreal 信号的值但打开波形工具那个信号却什么都看不到或者只显示成数字跳变。原因是很多数字波形格式默认按 logic 类型处理信号而 wreal 是实数信号需要以 analog 波形方式保存和显示。解决办法是在仿真脚本里把需要观测的 wreal 信号显式地声明成 FSDB 的 analog 类型或者在波形文件配置里把 wreal 信号映射到模拟波形组。这样打开波形工具后那些信号才能显示成连续的电压曲线。我给个建议在你做第一个 RNM 仿真时就花点时间把这个问题解决掉否则后面做波形分析会一直很痛苦。5.3 模型更新后回归突然大规模失败接口同步检查永远是第一步项目进行到中后期模拟设计工程师会把 IP 的 spec 更新一版RNM 模型跟着改了端口或映射关系结果一夜之间回归挂掉一大片。这种时候最忌讳直接去翻 testcase 代码你要做的第一件事永远是检查模型接口有没有变。端口名字变了、位宽变了、方向变了任何一项都会导致编译或运行时静默失败。我们在项目里规定任何 RNM 模型接口变更必须同步更新一份接口变更记录表并且 wrapper 层要跑一次编译连通性检查所有端口必须严格匹配。这个习惯养成之后模型更新引起的回归失败从“需要半天排查”降低到“十分钟定位”。5.4 模型行为与实际电路差异永远保留一份“模型能力边界文档”RNM 模型是抽象必然有不能覆盖的行为。我在实际项目中吃过最大的亏就是模型里没建上电延迟行为导致数字逻辑在仿真中提前开始工作掩盖了一个真实的时序问题。后来我们建立了一个机制每个 RNM 模型除了代码本身还必须附带一份“能力边界文档”里面逐条列出这个模型建了什么、没有建什么、理想化处理了什么。例如“不建噪声、不建失配、上电延时建模为固定值 XXX”。这份文档的作用是让所有使用者知道模型的可信边界在哪避免把模型的不足当成芯片的 bug或者反过来把模型的理想化当成真实行为去依赖。5.5 工具版本与 wreal 兼容性的避坑策略wreal 在给到不同仿真器、不同版本时支持度可能会有细微差异。一个在旧版本工具上编译通过的模型在新版本上可能报出一堆关于 real 端口和 logic 端口互联的 warning 甚至 error。避坑策略很简单给模型加一套“兼容性编译头”在模型文件里用条件编译方式处理 wreal 声明或者在编译脚本里做版本判断。更重要的是在你升级工具版本之前先用一个包含典型 RNM 模型的最小回归集做全量编译验证工具升级没有破坏现有模型行为。5.6 常见问题速查表现象可能原因快速排查/解决编译报 wreal 相关错误仿真器版本过低/未开wreal支持检查编译选项、升级工具或用realassign替代仿真极慢real 事件过密模型加事件节流减少实时 assign 链波形看不到模拟量波形格式未识别 wreal存 FSDB设 analog 类型显示回归大面积 fail模型接口变更未同步先比端口再看文件list绝不先改 testcase模型行为与电路差异大模型能力边界不清对照能力边界文档逐条确认抽象假设网表集成后仿真异常端口错位/电源域接错跑空转上电仿真检查关键节点电平6. 回归验证体系与最终交付6.1 一个“能跑”的网表判定标准是什么一份网表能跑起来不是说仿真命令执行完不报错就算完。我在项目里对“能跑”的定义包含三个层次第一编译无致命错误所有调用关系正确没有悬空连接和端口失配第二仿真结果可预期在标准激励下关键节点的电压值和状态跳变符合 spec第三性能可接受在规定时间内能完成批量回归而不是等一个用例就要一晚上。这三条缺一条网表就不算真正达到交付状态。尤其最后一条性能可接受最容易被忽略。RNM 模型已经大幅提速了但如果你的顶层环境没有做好事件节流、没有优化文件结构、没有合理的编译粒度整个回归时间依然会膨胀到不可用。回到工程本质验证环境的价值是“快速反馈”如果环境本身慢到没法迭代再精确的模型也没有意义。6.2 回归验证的层级与策略从功能到签核的推进路径落地回归体系的时候我习惯把验证分成三个递进层级。第一层是模型级验证针对单个模拟 IP 的 RNM 模型做定向测试确保模型本身行为可信这层跑得快、跑得勤每次模型更新都要全集回归。第二层是 SoC 融合验证在 Verilog-on-Top 环境里把数字 RTL 和模拟 IP 模型放在一起做系统级回归覆盖各种配置组合与边界场景。第三层是签核验证用替换了真实网表的环境做最终确认不要求全量回归但关键用例必须完整跑一遍。这个分层策略的核心价值是把“验证成本”和“验证价值”做了一次合理的再分配。模型级回归随时可跑帮你快速抓住模型回归系统级回归代价适中帮你验证交互行为签核回归代价最大所以只保留最关键的一批用例。这样一个项目里你既不会因为模型天天改而陷入饱和回归的泥潭也不会因为最后没有用真实网表跑过而心里没底。6.3 交付物清单模型、文档、脚本与网表的一揽子配套最后讲交付。RNM 模型落地产出网表这个过程的交付物不只是一份网表文件。我整理了一份检查清单RNM 模型源码、行为描述文档、能力边界文档、模型更新记录、wrapper 源码、编译脚本、接口比对脚本、公共测试用例集、回归报告。每一项都要和最终网表放在一起移交缺一样接手的同事就得花时间重新踩你踩过的坑。我特别想把“能力边界文档”再强调一次因为这是最容易在赶进度时省略、但后期最痛苦的文件。你想想三个月后你打开一个自己写的 RNM 模型如果没有文档你还能准确说出它没有建哪些行为吗大概率不能。与其那时靠回忆不如现在每写一个模型就在文档里同步更新一条边界说明。这个过程几乎不增加额外时间但长期收益极其可观。网表落地这件事本质上是把“验证世界的抽象”和“实现世界的真实”对齐。RNM 模型不是终点网表也不是终点真正的终点是你能在新设计里复用这套方法让它从一个项目的临时方案变成团队里可复制、可依赖的流程资产。