iverilog SystemVerilog 子集：-g2012 打开了哪些特性，19 项真机实测
更新时间：2026-11-04。很多从教程里抄来的 testbench 一上来就是
logic、always_ff、enum，用iverilog直接编译却撞上syntax error；而把商业仿真器里的interface、std::randomize搬过来，即使加了开关仍然过不了。Icarus Verilog 不是完整的 SystemVerilog 仿真器，它实现的是 IEEE 1800 的一个可用子集。仿真这一步在流程里的位置可先读 仿真是什么，编译选项的完整盘点见 iverilog 编译选项实战；本篇只回答一个问题：加了-g2012之后，哪些 SV 特性在 13.0 上真的能编、能跑，哪些会被当面拒绝。
本文要回答的问题
-g2012这个开关到底打开了什么，不加会怎样？logic、always_ff、typedef、enum、package、interface这些常见特性各自能不能过？- class、动态数组、队列、
string这些偏验证平台的特性支持到什么程度？ assert property、std::randomize、covergroup编译期被拒时该怎么改写？- Icarus Verilog 与 VCS/Questa 这类商业仿真器的差距具体落在矩阵的哪几行？
一、这一步在流程里的位置
判断「某句 SV 能不能用」发生在编译这一步：上游是带 SV 语法的 RTL 或 testbench，iverilog -g2012 按 IEEE 1800 子集解析、生成 .vvp 汇编，再交给 vvp 执行。解析器不认识的语法在编译期就报错，根本到不了运行期。
这张图有两个红色入口：一是忘了开关，解析器按旧标准读 SV 文件；二是语法本身超出 Icarus 的子集，加不加开关都一样拒。后文的矩阵就是把这两个入口逐个特性钉死。
这张卡是全篇的索引：14 个特性落在四块可用区，5 类特性落在拒绝线之外。选型时先在卡上定位你要用的语法，落在线外就直接改写或换工具，不要等编译报错再猜。
二、命令逐段解读
验证一个特性片段的完整命令只有两步：
iverilog -g2012 -Wall -o sim.vvp features/07_package.sv
vvp sim.vvpiverilog：编译器本体，把源文件翻译成 vvp 汇编。多个文件按依赖顺序列出，多文件工程的组织方式见 iverilog 多文件工程与宏包含。-g2012：本篇主角。告诉解析器按 SystemVerilog 子集接受新语法；不写时默认标准下always_ff、enum、package都会在编译期报syntax error。另有-g2005可显式锁回 Verilog-2005，适合验证代码是否保持了可综合的老语法。-Wall：打开常用告警，如悬空端口、隐式线网。探针脚本统一加上，让「能编但写法可疑」的片段也留下痕迹。-o sim.vvp：产物路径。不写时默认生成a.out（名字虽像原生二进制，内容仍是 vvp 汇编），工程里始终显式命名。vvp sim.vvp：运行时引擎，真正执行 initial/always 过程。编译被拒时没有产物，这一步不会执行。
一个容易误判的细节：单独写 logic a; 在默认模式下也能编过，logic 作为关键字被宽松容忍；但同文件一旦出现 always_ff，立刻在该行报 syntax error。所以「logic 编过了」不能证明工程处于 SV 模式，命令行统一显式写 -g2012 才可靠。
三、输入输出文件与支持矩阵
输入是每个特性一个的最小 .sv 片段（约 10 行，含自检测打印），输出是 /tmp 下的 .vvp 与运行结果。19 个片段在 Icarus Verilog 13.0 上逐个真机编译、运行，结果如下表，每条都能在运行记录里找到对应输出。
| 特性 | 最小写法 | -g2012 实测 |
|---|---|---|
| logic 四态类型 | logic [7:0] b; | 支持，打印 PASS logic |
| always_ff 时序块 | always_ff @(posedge clk) | 支持，计数到 5 |
| always_comb 组合块 | always_comb + case | 支持，译码输出正确 |
| always_latch 锁存块 | always_latch if (en) q=d; | 支持，使能关闭后保持 0x3c |
| typedef 自定义类型 | typedef logic [7:0] byte_t; | 支持 |
| enum 枚举 | typedef enum {IDLE,BUSY,DONE} state_t; | 支持，.name() 打印 BUSY |
| package + import | package mypkg / import mypkg::* | 支持，包内函数位反转正确 |
| packed struct | struct packed {…} + '{} 赋值 | 支持，整体可当 8 位向量 |
| string | 拼接、.len() | 支持，得到 iverilog-13 长度 11 |
| 块内声明与增强赋值 | for (int i…)、sum += i | 支持，1 到 5 求和为 15 |
| immediate assert | assert (x > 0) else $error(...) | 支持，条件成立正常通过 |
| class 基础 | class Packet、new、成员函数 | 支持，实例方法返回 7 |
| 动态数组 | int arr[]; arr = new[4]; | 支持，size() 为 4 |
| 队列 | int q[$]; push_back/push_front | 支持，队首 5、队尾 20 |
| interface/modport 端口 | module rcv(itf.sink p) | 不支持，端口声明处 syntax error |
| case inside | case (x) inside 与 case inside (x) | 两种写法都不支持 |
| concurrent assert property | assert property (@(posedge clk) …) | 不支持，property_spec 报错 |
| std::randomize 约束随机 | std::randomize(x) with {…} | 不支持，整段 Malformed statement |
| covergroup 功能覆盖 | covergroup cg; coverpoint … | 不支持，Invalid module item |
14 项支持、5 类不支持。注意 class、动态数组、队列虽然可用，含义是「基础语法和内建方法可用」——一旦在 class 里写 rand 字段加 randomize() with 约束，就落进了拒绝线，这条边界与商业仿真器差距最大。
四、常见错与检查点
| 现象 | 先查什么 | 纠正 |
|---|---|---|
always_ff 行直接 syntax error | 命令行有没有 -g2012 | 加上开关；CI 脚本里固定写全，别依赖默认值 |
用了 interface 连模块，报 Errors in port declarations | 是否把接口类型放进了模块端口表 | 13.0 不支持 interface 端口；临时改法是把接口内信号按 .clk(clk) 逐根连出，长期换 VCS/Questa |
testbench 里 std::randomize 一片 Malformed statement | 是否照搬了 UVM 风格验证平台 | 约束随机整条缺席：改用 $urandom/$urandom_range 自己写分布，或用 cocotb/Python 在外部产生激励 |
case (x) inside 报 Incomprehensible case expression | 是否用了集合成员判定 | 改写为并列 casez 加通配分支，或多级 if 比较；两种 inside 语法位置都实测过，均不支持 |
| 加了开关仍有语法错 | 特性是否落在矩阵拒绝线 | 不是开关问题，是子集边界；assert property 退回 immediate assert，覆盖率统计换商业工具 |
五、真实跑一遍：14 项通过、5 类被拒、默认模式对照
所有片段由一条脚本串行编译运行，成功的打印 PASS 与期望值，失败的保留编译器原始报错。先看通过侧的连续证据，logic 与 always_ff 两个片段都编译成功并由 vvp 跑出预期结果：
PASS logic: a=1 b=0x5a 与 PASS always_ff: q=5 (expect 5) 各自紧跟一次干净的退出码 0。拒绝侧同样是明确失败而不是悄悄忽略，interface 在端口声明处即被拒，并发断言卡在 property_spec：
----- [08_interface] iverilog -g2012 -o /tmp/08_interface.vvp features/08_interface.sv
features/08_interface.sv:9: syntax error
features/08_interface.sv:9: Errors in port declarations.
----- [14_assert_concurrent] iverilog -g2012 -o /tmp/14_assert_concurrent.vvp features/14_assert_concurrent.sv
features/14_assert_concurrent.sv:6: syntax error
features/14_assert_concurrent.sv:6: error: Error in property_spec of concurrent assertion item.行号直接定位到越界语法本身，说明是特性未实现而非片段写错；interface 的基础端口写法（不带 modport）作为 08b 复测，同样在端口行被拒，排除了「modport 写法不对」的偶然。最后做默认标准对照：同一份 always_ff 文件去掉 -g2012，编译器在旧标准下连报 8 个错误并放弃：
Invalid module instantiation、generate else is missing matching if 这些次生错误都源于第一件事：旧语法把 always_ff 当成了实例化。这也印证了第二节的提醒——判断工程是否真的处在 SV 模式，要看 always 块关键字而不是 logic。断言方面 Verilator 的边界与 iverilog 不同（它支持单拍采样的并发断言、拒绝多拍序列），对照可读 Verilator 断言开启流程 与 SystemVerilog Assertion 断言模板。
实验环境
- 机器/系统：macOS（Darwin 25.5，Apple Silicon），本机原生工具链
- 工具版本：
Icarus Verilog version 13.0 (stable) (v13_0)，运行时Icarus Verilog runtime version 13.0 (stable) (v13_0)（iverilog -V/vvp -V首行照抄） - 日期：2026-11-04
- 完整命令：
bash run.sh，依次对features/01_logic.sv到features/19_covergroup.sv（含08b、11b两个备选写法复测）执行/usr/local/bin/iverilog -g2012 -Wall -o /tmp/<名>.vvp <片段>，编译成功者执行/usr/local/bin/vvp /tmp/<名>.vvp；对照段对01_logic、02_always_ff、06_enum不带-g各编译一次
代码获取
全部 21 个特性片段、探针脚本与 Makefile 已同步到公开仓库：geek-doc.cn/experiments/flow-iverilog-g2012-sv，克隆后进入该目录执行 make run（需要 Icarus Verilog 13.0 的 iverilog 与 vvp）即可复现 14 条 PASS、5 类编译拒绝与默认标准对照的完整输出。
这一篇在知识体系里的位置
- 想看
-g2012之外-I/-D/-P/-o/-Wall的逐条对照：读 iverilog 编译选项实战； - 多个 SV 文件、package、include 怎么组织工程：读 iverilog 多文件工程与宏包含；
- 断言在另一条开源链路上的子集边界：读 Verilator 断言开启流程；
- 想系统了解仿真在设计流程中的位置：读 仿真是什么 与 testbench 与仿真。
总结
iverilog SystemVerilog 子集一句话：命令行显式加 -g2012，13.0 实测支持 14 项日常 RTL 与轻量验证特性——logic、三种 always_*、typedef/enum/package、packed struct、string、块内声明、immediate assert，以及基础的 class、动态数组与队列；明确不支持 interface 端口、case inside、concurrent assert property、std::randomize 约束随机和 covergroup，编译期即报 syntax error，需要改用 $urandom、手写激励或换商业仿真器。唯一的错觉陷阱是 logic 一词在默认标准下也能编过，判断开关是否生效要看 always 块关键字，工程命令统一写全 -g2012。