用哪个软件做网站好,便宜网站建设公司,网站建设的7个基本流程,做不规则几何图形的网站3.2 IMMEDIATE ASSERTIONS 即时断言是最简单的断言语句类型。它们通常被认为是SystemVerilog过程代码的一部分#xff0c;并在代码评估期间访问时进行评估。它们没有时钟或复位的概念#xff08;除非有时钟/复位控制其封闭的过程块#xff09;#xff0c;因此无法验证跨越时…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_evensif (f_even(i) i 9) begini i 1;a1: assert (i 10) else $error(“i is %0d”,i);end
end
always_comb begin : add_1_to_oddsif (f_odd(i) i 10) begini i 1;a2: assert (i 10) else $error(“i is %0d”,i);end
end 假设f_even正确地对偶数返回truef_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 芯片验证笔记
