第4章 SystemVerilog断言

4、SystemVerilog断言：断言基础语法，立即断言与并发断言，断言在调试中的应用

说到断言，我刚开始做验证那会儿，总觉得这东西可有可无。不就是检查几个信号嘛，用if语句也能搞定。直到有一次，一个时序问题在仿真里跑了三天才复现，我盯着波形看了两个小时愣是没看出毛病。后来老同事过来看了一眼，加了两行断言，五分钟就定位到了问题。嗯，从那以后，我再也不敢小看断言了。

说白了，断言就是把你脑子里的「预期行为」写成代码，让工具帮你盯着。你想想看，人眼盯波形能盯多久？十分钟就花了。但断言可以24小时不间断地检查，而且一抓一个准。

4.1 断言基础语法

SystemVerilog断言分两种：立即断言和并发断言。先看最基础的写法。

// 立即断言 - 像if语句一样执行
always_comb begin
    a_ready: assert (ready == 1'b1) else $error("ready信号在应该为高时被拉低了");
end

// 并发断言 - 基于时钟沿采样
a_valid_ready: assert property (@(posedge clk) 
    valid |=> ready ##[1:3] done
) else $error("valid之后ready未在3个周期内拉高");

我个人习惯，立即断言用在组合逻辑检查上，比如状态机的非法状态、数据总线的三态冲突。并发断言则用在时序交互上，比如握手协议、流水线控制。

  核心要点：
  立即断言：过程性语句，在仿真执行的时刻立即检查
并发断言：基于时钟沿，在整个仿真周期内持续监控
断言名（如a_ready）可选，但强烈建议加上，方便定位

4.2 立即断言与并发断言

这两者的区别，我经常用一句话概括：立即断言是「现在查」，并发断言是「盯着查」。

特性	立即断言	并发断言
执行时机	代码执行到该行时	每个时钟沿采样检查
适用场景	组合逻辑、状态检查	时序协议、序列检测
性能开销	小	较大（需持续监控）
调试友好度	直接定位到代码行	可查看时序波形

我在项目中遇到过一个问题：用立即断言检查一个跨时钟域的信号，结果仿真报了上百个假错。为什么？因为立即断言在组合逻辑里执行，跨时钟域信号有毛刺，一拍就抓到了。后来改成并发断言，用目标时钟域采样，问题就解决了。

我的小技巧：

调试阶段，我习惯把断言级别设成$error，这样一报错就停仿真，直接看波形。回归测试时改成$warning，避免频繁中断。用`ifdef控制，很方便。

4.3 断言在调试中的应用

断言最大的价值，不是验证功能对不对，而是帮你快速定位「什么时候开始错的」。你想想看，一个bug从发生到被观测到，中间可能隔了几百个时钟周期。你盯着波形看，看到的是错误的结果，但根本不知道源头在哪。

断言就不一样了。它可以在错误发生的瞬间就抓住现场。我曾经调试过一个DMA控制器，数据偶尔会错位。加了一个简单的断言：

property check_data_alignment;
    @(posedge clk) disable iff (!rst_n)
    dma_active |=> (data_byte_offset % 4 == 0);
endproperty

a_data_align: assert property (check_data_alignment)
    else $error("DMA数据未对齐，地址偏移=%0d", data_byte_offset);

这个断言一跑，不到十分钟就抓到了问题：某个配置寄存器在特定条件下被错误地写入了非对齐地址。如果没有断言，这种偶发问题可能要排查好几天。

注意：

断言不是万能的。我曾经犯过一个错：断言写得太多太密，仿真速度慢了5倍。后来学乖了，只在关键接口和状态机上加断言，内部数据通路用覆盖率来保证。

4.4 实战建议

说了这么多，总结几条我个人的经验：

先加接口断言：模块边界最容易出问题，协议握手、数据有效信号这些地方必须加
状态机必加：非法状态、状态跳转超时，这些用断言一抓一个准
不要过度断言：内部数据通路用断言检查边界值就够了，别每拍都查
善用$error和$fatal：$error可以继续跑，$fatal直接停，看场景选

最后说一句：断言这东西，用好了是神器，用不好是累赘。我见过有人一个模块写了200条断言，结果仿真跑不动，最后全删了。也见过有人只加了10条关键断言，每次debug都靠它们快速定位。你想想看，哪种更实用？