VC Formal 形式验证教程
1. 形式验证基本原理与关键概念
形式验证（Formal Verification）使用数学模型对电路进行 exhaustive 分析，无需完整仿真即可发现设计缺陷
或证明无缺陷。其关键概念包括：
• 有界模型检测（BMC）：将设计状态机展开为固定深度 $k$ 的有穷前缀，用 SAT/SMT 求解器检查在
$k$ 步内是否存在违例。换言之，BMC 检查是否存在某种输入序列使得断言在 $k$ 步内被打破
1
。如
果未发现违例，可增加 $k$ 继续探索；这是一种渐进搜索策略。
• 属性检查（Property Checking）：形式验证将设计视为模型，属性（由断言指定的规范）为要满足的
条件，检查设计是否满足这些属性
2
。若属性永远成立，则称“证明（PROVEN）”；若存在反例，则
称“失败（FAIL）”。属性检查保证设计在所有可能场景下均满足规格。
• 不可达性分析（Unreachability）：用于检测设计中永远无法到达的代码或状态，即死代码。形式工具
（如 VC Formal 的 FCA 应用）可以自动识别未被仿真覆盖的语句或条件，并证明其不可达
3
4
。这
样可生成覆盖率排除列表，有助于覆盖率闭合。
• 覆盖（Coverage）：在形式验证中，常用覆盖指标包括行覆盖、条件覆盖、FSM 状态/转移覆盖等。
VC Formal 的覆盖分析（FCA）能够证明仿真未覆盖目标确实不可达，并生成“排除”报告
4
。形式覆盖
与仿真覆盖互补：仿真可发现大部分行为，形式分析证明剩余目标不可达，从而达到近 100% 覆盖度。
以上概念构成形式验证的基础：设计被建模为有限状态机，属性（通常用 SVA 断言描述）为规范，工具通过有
界展开和 SAT/SMT 求解来验证属性是否恒真，并对未覆盖目标进行不可达分析
1
3
。
2. VC Formal 工具架构与工作流程
Synopsys VC Formal 与 VCS/Verdi 深度集成，使用 VCS 的编译器解析并展开 RTL/网表。基本流程如下：首先
通过 read_file 读取设计文件列表（包括 RTL、断言等），工具自动完成编译、参数计算和层次展开；接着
用专门的 SAT/SMT 引擎验证属性或执行覆盖分析；最终生成验证报告并可在 Verdi 中调试。VC Formal 提供多
种“应用（App）”模式（FPV、AEP、FCA
等），针对不同任务调用不同算法
5
6
。典型的运行流程可以用
Tcl 脚本控制，例如：
# 1. 载入设计和断言
read_file -top arbiter -format sverilog -sva -vcs -f filelist.f
# 2. 创建时钟和复位
create_clock clk -period 100
create_reset rst -high
# 3. 仿真初始化（释放复位）
sim_run -stable
sim_save_reset
# 4. 正式验证（例如运行 FPV 模式）
check_fv -app FPV
# 5. 报告生成
report_fv -list > results.txt
1
上例中， read_file 会解析 filelist.f 中指定的设计源文件， create_clock/create_reset 为时
序分析创建时钟与复位信号， sim_run
report_fv
输出结果列表
7
8
-stable
将设计复位（如必要）， check_fv
。实际用户还可使用
run_fv
运行形式证明，
启动验证、 set_fv_param
设置参数
（如深度、超时等）、 check_fv_setup 检查配置等命令控制流程。
VC Formal 内部包含多个应用：如 FPV（Formal Property Verification）用于验证用户编写的断言；AEP
（Automatic Extracted Properties）自动从设计中提取并验证常见属性；FCA（Formal Coverage Analyzer）
用于不可达性覆盖分析；CC（Connectivity
Checking）用于顶层互联检查；SEQ（Sequential
Equivalence
Checking）用于网表等价比对；FRV（Register Verification）等。每种模式调用不同算法，高效处理对应任务
5
6
。
3. SystemVerilog 断言和约束
SystemVerilog
断言（SVA）用于以形式化方式描述设计行为规范，常用关键字有
assert 、 assume 、
cover （以及模拟环境中的 restrict 等）。它们虽然语法相似（均基于 sequence/property），但作用
不同：
• assert：检查属性在所有运行中均为真。如属性失败，模拟报告错误，形式验证输出反例并标记失败
9
。例如：
property p_out_valid;
@(posedge clk) disable iff (rst) (in_vld && rdy) |-> (out_vld ==
4'b1111);
endproperty
p_out_valid_A: assert property(p_out_valid);
上例断言：“在复位结束后，只要 in_vld&&rdy 为真，则下一个时钟周期 out_vld 必须等于
1111 ”。如果该属性被违背（例如预期无 out_vld=1111 ），formal 会报告失败并产生反例波形。
• assume：定义对输入或环境的约束。在仿真中， assume 表面上像 assert 一样检查条件；但在形
式验证中， assume 作为假设条件，将设计输入空间限制在符合约束的情况 10 。例如：
assume stable_op: assume property (@(posedge clk) disable iff(rst)
(op_sel == $previous(op_sel)));
上例假设 op_sel 在时钟沿上不发生突变，为设计引入了一个输入约束；形式验证会在此假设下证明
其它断言。
• cover：用于覆盖率收集，指定一个需要“发生”以达成覆盖目标的序列或属性 11 。例如：
cover_out_ff: cover property (@(posedge clk) disable iff(rst)
(out_sel==2'b11 && out_c == 8'hFF));
该覆盖断言追踪何时设计的 out_sel=3 且 out_c=0xFF 成立，每次成立时计一次 Coverage。形
式工具会尝试找到满足该条件的路径并记录是否覆盖成功。
下表总结了 SVA 关键字的用途：
2
关键字
功能说明
assert
检查属性在所有运行中始终成立，不满足时报告失败
assume
对输入/环境施加约束（形式验证中为假设），不直接报告错误
cover
收集覆盖信息，指定希望达到的条件，帮助验证覆盖目标
上述行为可参考 Doulos 和 VLSI-Verify 等资料 12
11 。编写 SVA 时应注意：将复杂长序列拆分成多个简单属
性，合理使用 disable iff(rst) 等避免模型饥饿（vacuity），也可用 Verdi 中的 Formal Navigator 等工
具辅助编写和分组断言。
4. VC Formal 支持的验证模式
VC Formal 提供多种验证模式（App），每种模式侧重不同应用场景：
• FPV (Formal Property Verification)：形式属性验证模式，用于对设计级断言（SVA）进行证明
6
。FPV 主要面向控制逻辑验证，如总线协议、仲裁器、FSM 等。用户编写要求，工具在不需要仿真
的情况下穷尽所有输入可能，对每个 assert property 给出 Proven/Fail 结果
6
。FPV 是最常用
的静态 ABV（静态断言验证）流程。
• AEP (Automatic Extracted Properties)：自动提取属性模式 13 。该模式无需用户手工编写断言，工
具会自动分析 RTL 中的常见错误（如算术溢出、数组越界、X传播、fullcase/parallel-case遗漏等）并
生成检查断言 14 。AEP 模式适合在早期快速找出明显问题，如示例脚本会为每个加减乘除操作自动创
建溢出检查断言 14 。
• CTG (Constrained Test Generation)：约束测试生成模式。该模式利用约束信息自动生成测试向量以
覆盖设计状态，通常与覆盖率分析结合使用。VC 文档中对 CTG 提及较少，但可理解为形式化条件下的
覆盖驱动测试生成，用于探索不同输入场景。
• ABV (Assertion-Based Verification)：基于断言的验证，包括静态和动态两类 15 。静态 ABV即形式
验证（比如 FPV）；动态 ABV指模拟过程中使用断言检查。VC Formal 实际上是静态 ABV 工具，但用
户也可将仿真断言移植进形式环境。总之，ABV 表示用断言语言直接描述验证需求的流程。
除了上述主要模式，VC Formal 还提供 FCA（覆盖分析）、CC（连通性检查）、SEQ（等价检测）等多种应
用，每种通过不同策略加速相应任务
5
6
。用户可根据需要在 Tcl 脚本中通过 set_fml_appmode <模式
> 选择不同验证模式。
5. 脚本编写与运行控制
使用 Tcl 脚本控制 VC Formal 运行有助于流程自动化和复现。一个典型的启动脚本包含以下部分：
• 文件列表（filelist）管理：将所有设计文件、断言文件、测试文件罗列在一个文件列表（如 .f 文
件）中。示例 filelist.f 可包括 +incdir 设定、设计文件和测试文件路径。然后在脚本中用
read_file -f filelist.f 一次性载入所有源。 16
• 读文件与展开：脚本中用 read_file -top <顶层模块> -format sverilog -sva -vcs -f
filelist.f 读取 RTL 和断言。 -sva 选项开启对 SVA 语法的支持（VC Formal 默认支
持）， -vcs 使用 VCS 兼容模式。 16
• 时钟与复位：使用 create_clock clk -period 100 、 create_reset rst -high 等命令声
明时钟周期和复位信号（高电平复位示例）。这样工具才能正确展开时序模型。
• 仿真初始化：若设计在复位后才有效，可调用 sim_run -stable 让复位信号翻转至稳定状态，
sim_save_reset 保存复位后的状态。这对于 AEP 或含测试平台的验证流程尤为重要 17 。
3
• 执行形式验证：通过 check_fv 或 run_fv 等命令启动验证。可用 -app 指定模式（如 -app
FPV ）。例如 check_fv -app FPV 命令进入 FPV 模式运行。
• 结果报告：用 report_fv -list 输出检查结果列表到终端或文件。此外常用 report_fv -wlf
output.wlf 将波形信息记录至文件，以便后续在 Verdi 中查看。
常用的控制命令还包括： set_fv_param
<name>
<value>
用于设置选项（如 BMC 深度、超时时间
等）， check_fv_setup 检查当前设置是否满足运行条件。整个流程可通过执行形如 vcf -f run.tcl
的命令启动，其中 vcf 是启动 VC Formal 的 Shell 工具。以上示例命令可参考开源教程
7
8
。
6. 结果分析与调试
完成验证后，需要解读验证状态并定位问题。VC
Formal
对每条断言或覆盖目标给出状态信息，常见状态包
括：
• PROVEN（已证明）：断言在所有可行情况下都成立，无反例。
• FAIL（失败）：找到了违反断言的反例路径。工具会输出一个违反该断言的输入序列或波形供分析。
• NOT_RUN（未运行）：断言由于约束条件不满足、禁用或其他原因未被检查。例如，假设输入永远不
满足 assume 中的条件，会导致相关断言标记为 NOT_RUN。
• UNREACHABLE（不可达）：常出现在覆盖分析结果中，表示对应的覆盖点（代码分支、条件等）在约
束下被证明永远不可达
4
。
对失败断言，VC Formal 会生成一个反例波形。通常可使用 report_fv -wlf example.wlf 将反例记录
到 WLF 文件，并在 Verdi 中打开观察时序波形。通过对比反例中的输入激励和输出结果，可以定位设计错误或
断言自身的问题。例如，若断言提示输出不符合预期，可查看反例波形判断是输入时序问题还是逻辑错误。
对于可达性/覆盖分析，可结合仿真覆盖率工具：VC Formal 的 FCA 应用可以从 VCS 的覆盖数据库提取未覆盖
项，并证明其不可达
4
。生成的覆盖排除文件可与仿真覆盖数据库在 Verdi 或 URG 等工具中一并加载查看，
直观展示哪些代码是真正的“死代码”。通过上述方式，工程师可针对失败场景编写更精确的断言或调整设计，直
到所有目标均 PROVEN 或合理标记为 UNREACHABLE 。
7. Grid 模式与性能优化技巧
VC Formal 支持本地模式和分布式(Grid)模式运行。对于小规模设计或快速迭代，本地运行即可；对于大设计
或长距离传播问题，可启用 Grid 模式利用多台机器并行计算。工具提供运行控制功能，允许用户暂停/恢复验
证任务、保存/恢复中间状态，方便长期运行。
Synopsys 声称 VC Formal 在大型设计上的性能和容量领先业界（对比常规方法有至少 5 倍提升） 18 。但形式
验证仍计算密集，优化非常重要。常见优化技巧包括：
• 覆盖驱动优化：如果已有仿真覆盖数据库，应首先由仿真获得高覆盖后，将未覆盖项交给形式工具分析
19 。FCA 可以读取 VCS 覆盖结果，只针对未覆盖的行/条件进行不可达性证明，有效缩减验证范围。
• 覆盖指标分解：VC FCA 支持多种指标（行、条件、FSM 状态/转移、toggle 等）。可在编译时打开所需
指标，对于 toggle 覆盖建议单独分析 20
21 。如果不需要 toggle 分析，应禁用以节省资源。
• 分层分析：对于过大的模块，可按层次拆分或聚焦子模块运行。使用 VCS 的 -cm_hier 等选项按模块
区分覆盖也很有用 22 。没有可用覆盖数据库时，也可根据模块重要性分块分析 23 。
• 环境约束优化：在不影响关键逻辑的前提下，可屏蔽不利于形式分析的大型记忆块（如RAM）为黑盒
24 ，减少状态空间。
• 资源利用：尽量在服务器集群上运行（Grid 模式） 25 ；启用多核并行（使用
set_fv_param -name max_cores <n> 等参数）。
4
• 运行预期：对较大设计的不可达分析通常耗时较长，可能需要几十小时甚至一整天才能完成 26 。因此
应合理规划，使用 run_fv 的保存/恢复功能分阶段调试。
综上，通过覆盖分析缩小验证目标范围、合理配置参数和硬件资源，可以显著提高 VC Formal 的运行效率 19
18 。
8. 与仿真的协同验证
虽然形式验证是无须完整仿真的，但与仿真环境配合可互补提升验证效率。VC Formal 支持在有仿真环境时复
用断言/约束，也可将形式分析结果与仿真结果对齐：
• ABV 断言整合：可以将编写好的 SVA 断言既用于仿真检查，也用于 VC Formal 中进行证明。在同一个
SystemVerilog 测试平台下，一套断言既可以在 VCS 仿真中作为检查点，也可以在 VC Formal 中作为属
性测试。这样验证规范只需维护一份声明。
• 波形回放：VC Formal 生成的反例波形（WLF）可以导入 Verdi 中，与仿真波形对比。这种“回放”功能
让工程师在熟悉的波形界面看到形式验证发现的问题，方便与仿真结果一一对照，从而进行问题定位和
验证需求的调整。例如，可以将反例波形作为输入重新输入仿真模型，验证仿真平台的覆盖情况或用于
调试设计。
• 测试平台复用：有些验证平台可以同时用于仿真和形式。VC Formal 的 AEP 应用可直接读取内嵌在设计
中的测试平台代码（如 arbiter 的示例脚本中所示），实现形式验证前无需额外编写测试驱动
7
。亦
可在正式验证后将形式产生的测试矢量或覆盖点用于仿真生成测试向量，促进不同验证技术的互补。
需要注意的是，官方文档对“波形回放”功能讲解不多，但实际中通常使用 Verdi 等工具加载 WLF 波形进行对比
分析。综上，仿真与形式验证可以共享断言和平台，利用形式的 exhaustive 优势和仿真的可视化优势协同工作
27 。例如，VC Formal 的 Formal Navigator 允许用户在 Verdi 中无论是否存在仿真环境，都能单纯使用 RTL
与断言进行调试 27 ，并可叠加使用仿真覆盖数据。
9. 项目级实践案例：仲裁器示例
下面以一个简单的“仲裁器”模块（arbiter.sv）为例，展示 VC Formal 验证流程：该模块根据输入信号计算运算
结果，并在有效时输出。
• 设计介绍： arbiter.sv 接受输入 in_a 、 in_b （8位数据）、 op_sel （2位操作选择）、
in_vld （输入有效）等信号。模块内部计算加、减、与、或四种运算结果，由 op_sel 选择输出，
最终通过 out_sel 决定输出哪些数据或固定值； rdy =~ rst 表示复位后始终准备就绪；
out_vld 在 in_vld && rdy 时为四比特全1，否则全0。核心代码片段如下（为简化示意，此处
省略详细逻辑）：
always_ff @(posedge clk or posedge rst) begin
if (rst) out_vld_reg <= 4'b0000;
else if (in_vld && rdy) out_vld_reg <= 4'b1111;
else out_vld_reg <= 4'b0000;
end
assign out_vld = out_vld_reg;
// 运算逻辑见源文件 arbiter.sv
• 断言示例：基于设计功能，我们可以编写断言来验证重要性质。例如，若输入有效且准备就绪，则所有
输出有效位应为1：
5
property p_out_valid;
@(posedge clk) disable iff (rst)
(in_vld && rdy) |-> (out_vld == 4'b1111);
endproperty
p_out_valid_A: assert property (p_out_valid);
此断言检查：在非复位状态下，只要 in_vld&&rdy 为真，下一个时钟时刻 out_vld 必须为
1111 。另外，可以添加覆盖属性，例如：
property p_cover_ff;
@(posedge clk) disable iff (rst)
(out_sel == 2'b11) |-> (out_c == 8'hFF);
endproperty
p_cover_ff_C: cover property (p_cover_ff);
[示例参考 28 ，其中使用类似写法定义属性并用 assert property / cover property 实例化。]
• 运行脚本：以 FPV 模式为例，可编写脚本（vc_fpv.tcl）进行验证：
set design arbiter
read_file -top $design -format sverilog -sva -vcs -f filelist.f
create_clock clk -period 100
create_reset rst -high
sim_run -stable
sim_save_reset
check_fv -app FPV
report_fv -list > arbiter_results.txt
其中 filelist.f 包含设计源 arbiter.sv 和可能的验证组件（如示例中的 fv_arbiter.sv ）
16 。
• 结果解读：执行脚本后，如果所有断言都成立，相应条目会显示为
示
FAIL
PROVEN ；如果某断言失败，则显
并可通过生成的反例定位问题。覆盖项如果条件可达则标为
UNREACHABLE 。例如，上述
p_out_valid_A
如果存在符合条件的路径就会标为
p_cover_ff_C
COVERED ，否则可能为
若设计逻辑正确，应显示
PROVEN；覆盖属性
COVERED。可以用
Verdi
加载
arbiter_results.txt 或生成的 .wlf 波形文件进行可视化查看。通过分析报告和反例，用户可
以确认仲裁器模块是否符合规范，及时修改设计或断言。
通过此示例，初学者可了解从编写
约束到运行脚本再到分析报告的完整流程。可参考上传文件
SVA
arbiter.sv、filelist.f 和 vc_aep.tcl 中的具体写法和设置（vc_aep.tcl 示例中使用了 AEP 模式
7
）。上述过
程也可应用于其他模块（如 FIFO、FSM 等），只需根据其时序关系和协议需求编写相应断言和约束，即可使用
VC Formal 验证其正确性。
参考资料
- Synopsys VC Formal 官方文档和数据手册
- SystemVerilog 断言教程
9
5
6
；
11 ；
6
- 开源形式验证实践教程
28 ；
7
- 技术论坛与博客文章（VC Formal 覆盖分析、不可达性技巧等）
1
2
3
4
29 。
Model checking - Wikipedia
https://en.wikipedia.org/wiki/Model_checking
3
4
19
20
21
22
23
24
25
26
29
Eight tips for performing effective unreachability analysis - Tech
Design Forum Techniques
https://www.techdesignforums.com/practice/technique/eight-tips-for-performing-effective-unreachability-analysis/
5
18
VC Formal
https://www.synopsys.com/content/dam/synopsys/verification/datasheets/vc-formal-ds.pdf
6
13
27
VC Formal: Formal Verification Solution | Synopsys
https://www.synopsys.com/verification/static-and-formal-verification/vc-formal.html
7
8
14
16
17
28
A Blueprint for Formal Verification - systemverilog.io
https://www.systemverilog.io/verification/blueprint-for-formal-verification/
9
12
SystemVerilog Assertions Tutorial
https://www.doulos.com/knowhow/systemverilog/systemverilog-tutorials/systemverilog-assertions-tutorial/
10
11
Assume and Cover Statements - VLSI Verify
https://vlsiverify.com/system-verilog/assertions/assume-and-cover-statements/
15
Getting started with formal verification | ignitarium.com | by Ignitarium | Medium
https://medium.com/@Ignitarium/getting-started-with-formal-verification-ignitarium-com-d2441957b4eb
7