Systemverilog断言介绍（二）

3.2 IMMEDIATE ASSERTIONS

        即时断言是最简单的断言语句类型。它们通常被认为是SystemVerilog过程代码的一部分，并在代码评估期间访问时进行评估。它们没有时钟或复位的概念（除非有时钟/复位控制其封闭的过程块），因此无法验证跨越时间的行为。它们还容易受到SystemVerilog过程代码通常存在的风险的影响，包括“delta-time”故障（这里可以看绿皮书4.3.4 测试平台一设计间的竞争状态），即由于过程块（always或always_*)的多次评估而受到时间步长中间临时值的影响。通常情况下，我们建议尽可能使用并发断言而不是即时断言。这个建议有几个原因：

• 使用相对于已知时钟的断言是并发断言直接支持的功能，有助于保持预期行为的清晰和理解。

• 时间差异风险，即即时断言可能报告临时值，这些临时值在时间步长结束时会发生变化，可能导致错误的失败报告，并增加调试的困难。

• 由于即时断言不是相对于时钟来说明的，除非位于定时过程块中，模型或测试台架的时序行为的变化可能导致不可预测的结果。

然而，有一些特定情况下需要使用即时断言：

• 在函数或其他真正无时钟结构中：可能希望在函数内部添加即时断言；例如，检查其参数的安全性或检查计算结果。

• 用于状态匹配形式等价验证（FEV）工具：状态匹配的FEV工具将逻辑分解为组合逻辑锥，因此其中许多工具只能处理无时钟假设以证明等价性。

        出于这些原因，在此处描述即时断言而不是完全跳过它们。但请记住，必须谨慎使用它们，只建议在上述情况下使用。

3.2.1 WRITING IMMEDIATE ASSERTIONS

        虽然即时断言通常只应在上面描述的情况下使用，但当您确实需要使用它们时，正确使用它们非常重要。建议始终使用称为“最终延迟即时断言”的即时断言变体。最终延迟即时断言语句相对简单：只需使用assert final，后面跟随任何布尔表达式，可选地在之前添加一个标签和在之后添加一个失败消息。因此，如果想编写一个即时断言来检查当代理0没有请求时是否授予了他们的访问权限，可以编写以下语句：

grant0_ok: assert final (!(gnt[0] && !req[0])) else$error(“Grant without request for agent 0.”);
或者
grant0_ok: assert #0 (!(gnt[0] && !req[0])) else$error(“Grant without request for agent 0.”);

        标签grant0_ok是断言的一个可选名称；如果没有标签，大多数EDA工具会自动生成一个名称，但我们建议始终包含一个标签。

    else $error ...的动作块也是可选的，如果没有它，大多数仿真工具会为断言失败生成默认消息。但建议始终在这里包含一些有意义的内容，以帮助仿真调试。

        这个断言可以放在任何模块内的always块中，只要gnt和req信号是可见的，或者放在具有访问这些信号权限的函数内。也可以将其放在模块内的always块之外；在这种情况下，它将被视为在隐含的always_comb块中。每当执行其过程代码时，将检查该断言。

        插个题外话，理解 assert #0 or assert final，这里需要复习一下Time Slot的概念（具体细节可以看绿皮书4.4章节）。

根据IEEE1800里对于assert #0 or assert final的描述如下：

• #0 : for an observed deferred assertion

• fina1: for a final deferred assertion

        可以看到两者区别在于采样region的不同，实际上大多数case中使用assrt #0还是asset final都是一样的。通过deferred assertion就可以避开delta-time可能导致的问题。

3.2.2 COMPLICATIONS OF PROCEDURAL CODE AND MOTIVATION FOR ASSERT FINAL

        在SystemVerilog中执行过程代码（主要是always块）的方式可能会让许多用户感到惊讶，甚至包括那些在这种语言中设计多年的用户。您需要记住以下三个关键概念：

• 在单个always块中，语句按照它们出现的顺序执行，就像软件代码一样。

• 对于多个always块，没有保证执行顺序；它们可以以任何顺序执行。

• 如果always块的敏感列表中的信号发生变化（由于另一个always块或其他类型的赋值导致），它将在同一时间步重新执行。

        这些特性可能会导致某些立即断言的行为令人惊讶，除非用户对LRM非常熟悉。这就是为什么语言的较新版本引入了延迟断言的概念。延迟断言是一种立即断言的形式，遵循以下特殊规则：如果包含它们的过程在单个仿真时间步内执行多次，只有最后执行的结果会被报告。

        为了更清楚地说明这一点，以下是一个非常糟糕的RTL代码片段示例，其中使用了非延迟的立即断言：

always_comb begin : add_1_to_evens
 if (f_even(i) && i < 9) begin
   i = i + 1;
   a1: assert (i >= 10) else $error(“i is %0d”,i);
 end
end
always_comb begin : add_1_to_odds
 if (f_odd(i) && i < 10) begin
   i = i + 1;
   a2: assert (i >= 10) else $error(“i is %0d”,i);
 end
end

        假设f_even正确地对偶数返回true，f_odd正确地对奇数返回true，如其名称所示。如果i在某个地方被赋予小于10的值，上述一对始终计数块将一直被执行，每次交替地将i增加1，并且每次在i增加但尚未达到最大值时都会出现断言失败：

Assertion failure in myfile.v:40: i is 4
Assertion failure in myfile.v:34: i is 5
Assertion failure in myfile.v:40: i is 6
Assertion failure in myfile.v:34: i is 7
Assertion failure in myfile.v:40: i is 8
Assertion failure in myfile.v:34: i is 9

        用户会发现上述信息非常令人困惑，因为在仿真器的每个时间步骤结束时，他们会发现i的值始终至少为10。在时间步骤期间发生变化的中间值触发了这些断言。这就是为什么引入延迟断言的原因：对于延迟断言，在任何仿真时间步骤中，只报告给定过程中每个断言最终执行的结果。在上述示例中，如果每个assert被替换为assert final，那么将看不到任何违规行为：对于任何给定时间步骤中每个过程的最终执行，要么i将具有合法值，要么不会检查任何断言。

原创 Junxiao Zhang 芯片验证笔记