System Verilog Assertions(SVA) 简介
SystemVerilog语言简介(doc26)-25页精选文档
SystemVerilog语言简介SystemVerilog是一种硬件描述和验证语言（HDVL），它基于IEEE 1364-2001 Verilog硬件描述语言（HDL），并对其进行了扩展，包括扩充了C语言数据类型、结构、压缩和非压缩数组、接口、断言等等，这些都使得SystemVerilog在一个更高的抽象层次上提高了设计建模的能力。
SystemVerilog由Accellera开发，它主要定位在芯片的实现和验证流程上，并为系统级的设计流程提供了强大的连接能力。
下面我们从几个方面对SystemVerilog所作的增强进行简要的介绍，期望能够通过这个介绍使大家对SystemVerilog有一个概括性的了解。
1. 接口（Interface）Verilog模块之间的连接是通过模块端口进行的。
为了给组成设计的各个模块定义端口，我们必须对期望的硬件设计有一个详细的认识。
不幸的是，在设计的早期，我们很难把握设计的细节。
而且，一旦模块的端口定义完成后，我们也很难改变端口的配置。
另外，一个设计中的许多模块往往具有相同的端口定义，在Verilog中，我们必须在每个模块中进行相同的定义，这为我们增加了无谓的工作量。
SystemVerilog提供了一个新的、高层抽象的模块连接，这个连接被称为接口（Interface）。
接口在关键字interface和endinterface之间定义，它独立于模块。
接口在模块中就像一个单一的端口一样使用。
在最简单的形式下，一个接口可以认为是一组线网。
例如，可以将PCI总线的所有信号绑定在一起组成一个接口。
通过使用接口，我们在进行一个设计的时候可以不需要首先建立各个模块间的互连。
随着设计的深入，各个设计细节也会变得越来越清晰，而接口内的信号也会很容易地表示出来。
当接口发生变化时，这些变化也会在使用该接口的所有模块中反映出来，而无需更改每一个模块。
下面是一个接口的使用实例：实际上，SystemVerilog的接口不仅仅可以表示信号的绑定和互连。
sva断言$past 用法
sva断言$past 用法断言是作为事实的陈述，是对某种观点或主张的肯定陈述。
在软件开发中，断言是一种常见的编程技术，用于检测代码中的错误和逻辑问题。
SV(Assertion)断言是一种在SystemVerilog 硬件描述语言（HDL）中使用的语句，它允许开发者定义和验证特定的条件，以确保设计的正确性和可靠性。
SV断言通常用于验证设计中的假设条件，帮助开发者找到潜在的错误和设计缺陷。
SV断言的语法和用法与其他编程语言中的断言相似，但在SystemVerilog中有一些特定的关键字和约定。
下面是关于SV 断言用法的一些参考内容：1. 在SV中，断言通常使用关键字`assert`来定义和验证条件。
例如，我们可以使用下面的语句来断言某个信号的状态：```systemverilogassert(signal_state == 1) else $display("Signal state is not valid!"); ```这个断言语句将检查`signal_state`是否等于1，如果不满足条件，则显示一个错误消息。
2. SV断言还可以使用关键字`assume`来表示某个条件需要满足。
例如，在设计中，我们可能需要假设某个输入信号在沿着时钟上升沿之前必须保持稳定：```systemverilogassume(input_signal == 0) else $display("Input signal is notstable!");```这个断言语句将假设`input_signal`在时钟上升沿之前必须保持为0，如果不满足条件，则显示一个错误消息。
3. 除了`assert`和`assume`关键字，SV还提供了其他一些有助于断言编写和调试的关键字，如`cover`和`sequence`。
`cover`关键字用于验证特定的条件是否得到满足，而`sequence`关键字用于定义和验证时间序列中的事件顺序。
sva断言基础
sva断言基础SVA（SystemVerilog Assertions）是一种强大的验证工具，用于在设计和验证过程中检测和诊断错误。
SVA断言是使用SVA编写的一种声明，用于指定系统行为的一种期望。
如果系统的实际行为与断言声明的期望行为不符，则断言将失败。
基础SVA断言在SystemVerilog代码中起着至关重要的作用，它们是验证流程中的关键组成部分。
这些断言用于验证设计的各个方面，包括接口、功能和时序行为。
通过使用基础SVA断言，可以捕获设计中的错误、不一致性和缺陷，从而加快验证过程并提高设计的可靠性。
基础SVA断言的语法相对简单，但功能非常强大。
以下是一些常见的SVA 断言示例：静态断言（Static Assertion）：用于在编译时检查变量或表达式的值。
例如，使用assert关键字可以检查某个条件是否为真。
如果条件为假，则编译器将生成错误。
动态断言（Dynamic Assertion）：用于在仿真时检查变量或表达式的值。
使用assert关键字可以在仿真过程中触发断言检查。
如果条件为假，则断言将失败并生成错误消息。
时间断言（Temporal Assertion）：用于在特定时间点检查变量的值或事件的发生。
例如，使用(posedge clk)可以在时钟信号的上升沿触发断言检查。
除了上述示例之外，还可以使用更复杂的逻辑表达式和操作符来编写更高级的SVA断言。
这些断言可用于验证设计的中的各种复杂条件和行为。
总之，SVA断言是一种强大的验证工具，可以帮助设计者和验证工程师检测和诊断设计中的错误和缺陷。
通过使用基础SVA断言，可以确保设计的正确性和可靠性，从而提高设计的质量和性能。
System Verilog Assertions(SVA) 简介
为什么要使用断言呢？
• 原有的Verilog 语言是一种过程性语言，设计它的目的是用 • •
于硬件描述，不是用于仿真验证，因此它不能很好地控制时 序。要描述复杂的时序关系，Verilog语言需要编写冗长的 代码，很容易出错，且不易维护。 SVA 是一种描述性语言，可以完美地描述和控制时序相关 的问题，而且语言本身简洁易读，容易维护。 SVA 还提供了许多内嵌的函数用于测试特定的时序关系和 自动收集功能覆盖率数据。并且当断言失败时，仿真系统会 根据失败断言的严重程度来决定是打印一条错误提示信息还 是退出仿真过程，便于定位出错的位置。
蕴含操作符
• 蕴含操作符的左边项为“先行算子”（antecedent），右
•
•
•
•
边项为“后序算子”（consequent）。 先行算子是约束条件，当先行算子匹配（成功）时，后序算 子才能被计算。如果先行算子不成功，那么整个属性就被默 认成功，叫“空成功”（vacuous success）。蕴含结构 只能被用在属性定义中，不能用在序列定义中。 蕴含操作符分为两类：交叠蕴含操作符（|->）和非交叠蕴 含操作符（|=>）。 非交叠蕴含操作符“|->”表示：如果先行算子匹配，后序 算子在同一个时钟周期开始计算。 交叠蕴含操作符“|=>”表示：如果先行算子匹配，后序算 子在下一个时钟周期开始计算。
序列重复操作符
• 使用序列的重复操作符进行检查序列的重复操作符分为3 类：
• • •
连续重复，跳转重复和非连续重复。 “[*m]”为连续重复操作符。“a[*3]”表示a 被连续重复3 次，“a[*1:3]”表示a 被连续重复1～3 次。连续重复的相 邻两次重复之间只有一个时钟间隔。 “[->m]”为跳转重复操作符。“a[->3]”表示a 被跳转重 复3 次，“a[->1:3]”表示a被跳转重复1～3 次。跳转重 复的每一次重复之前可以有任意个时钟周期的间隔。 “[=m]”为非连续重复操作符。“a[=3]”表示a 被非连续 重复3 次，“a[=1:3]”表示a被非连续重复1～3 次。非连 续重复的每一次重复之前可以有任意个时钟周期的间隔，最 后一次重复之后可以有任意个时钟周期的间隔。
sva first match 构造
文章题目：探讨 SVA First Match 构造的重要性和应用1. SVA First Match 构造的概念SVA（SystemVerilog Assertions）是一种在硬件描述语言中用于验证设计行为的形式化语言。
SVA First Match 构造是 SVA 中的一种用法，用于指定一种在给定情况下首次匹配的属性。
在硬件验证中，SVA First Match 构造可以用于检测设计中的意外或不符合规范的行为，从而提高设计的可靠性和稳定性。
2. SVA First Match 构造的深度评估SVA First Match 构造在硬件验证中的应用十分广泛，可以用于各种复杂的设计场景。
通过对设计中可能出现的各种情况进行全面评估，可以确定哪些情况是必须首次匹配的，以及需要满足的条件是什么。
这种深度评估可以帮助确保设计在各种情况下都能正常工作，并且能够快速、准确地发现设计中可能存在的问题。
3. SVA First Match 构造的广度应用SVA First Match 构造不仅可以用于单一设计单元的验证，还可以用于整个系统的验证。
在复杂的系统设计中，各个设计单元之间的交互和通信非常重要，而 SVA First Match 构造可以帮助我们检测这些交互和通信中可能存在的问题。
通过在整个系统级别上应用 SVA First Match 构造，可以确保系统各个部分都能够正确地工作，并且在各种情况下保持一致性和可靠性。
4. 个人观点和理解在我看来，SVA First Match 构造是硬件验证中非常重要的一部分，它可以帮助我们快速、准确地发现设计中可能存在的问题，并且提高设计的可靠性和稳定性。
通过深度和广度的评估，我们可以更好地理解设计中可能出现的各种情况，并且及时采取措施进行修复或优化。
在进行硬件验证时，我们应该充分利用SVA First Match 构造的优势，以提高设计的质量和可靠性。
5. 总结SVA First Match 构造在硬件验证中具有重要的意义，它可以帮助我们检测设计中的问题，并且提高设计的可靠性和稳定性。
SystemVerilog Assertions (SVA) EZ-Start Guide英文精品课件
SystemVerilog Assertions (SVA) EZ-Start GuideAugust 2006© 1995-2006 Cadence Design Systems, Inc. All rights reserved.Printed in the United States of America.Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, CA 95134, USATrademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadence’s trademarks, contact the corporate legal department at the address shown above or call 800.862.4522.All other trademarks are the property of their respective holders.Restricted Print Permission: This publication is protected by copyright and any unauthorized use of this publication may violate copyright, trademark, and other laws. Except as specified in this permission statement, this publication may not be copied, reproduced, modified, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence. This statement grants you permission to print one (1) hard copy of this publication subject to the following conditions:1.The publication may be used solely for personal, informational, and noncommercial purposes;2.The publication may not be modified in any way;3.Any copy of the publication or portion thereof must include all original copyright, trademark, and otherproprietary notices and this permission statement; and4.Cadence reserves the right to revoke this authorization at any time, and any such use shall bediscontinued immediately upon written notice from Cadence.Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence. The information contained herein is the proprietary and confidential information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadence’s customer in accordance with, a written agreement between Cadence and its customer. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of such information.Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.SystemVerilog Assertions (SVA)EZ-Start GuideIn general, there are three components to efficient verification: stimulus generation, coverage, and checking. Cadence Design Systems, Inc. provides companion EZ-Start packages for each of these three areas. The focus of this EZ-Start package and its accompanying executable example is assertion-based verification (ABV). Specifically, dynamic ABV simulation using the SystemVerilog assertion language (SVA).This document is a self-guided introduction to using dynamic ABV and writing SVA. The following sections describe the three major steps involved in ABV:!Picking a focus area!Identifying behavior and mapping to property types!Implementing assertionsPicking a Focus AreaThe first step in ABV is to pick a focus area for your assertions. In general, you want to start with areas that are likely to contain bugs or that will benefit from additional visibility. For example, the following lists areas that typically have a good ROI for assertions and, therefore, represent good starting points for assertions.!Interfaces between blocks!Control logic that contains corner cases!Critical functions within the designNote: If the schedule permits, this list can be expanded to include other areas within the design.Identifying Behavior and Mapping to Property TypesAfter you choose a focus area, you can then identify interesting behavior within the focus area and then express them in natural language form. Once you have expressed the behavior in natural language form, you can map the behavior to various property types. A property is a description of the functional behavior of signals over time. An assertion states that a given property is an important aspect of the behavior of the design, and that the design must behave consistently with this property. Writing assertions starts with defining the properties of a design.The following table lists questions that can help identify the different types of properties in a design. Each of these questions map to a property type that can be used to create templates for your assertions.Table 1 Basic Questions and Property TypesQuestion Property TypeAre there signals that have a set behavior thatInvariantsmust occur independent of time?Bounded InvariantsAre there signals that have a set behavior thatmust occur within a certain time frame?Boundary CasesDoes the design contain boundary conditionsthat must trigger a set behavior?Bug IdentificationAre there ways to specify values or sequencesthat would describe an error condition?Signal ValuesIs the behavior of certain signals critical to thefunctionality of the design?Note: Although this set of questions is not exhaustive, it is a good starting point for developing assertions.The following sections describe each of these property types.InvariantsAn invariant is a condition that must always (or never) occur. Invariants are one of the easier property types to describe, because they do not involve time. Examples of invariants are:!One-hot signals!Boolean conditions that must always occur, or never occur!Special cases where an object must hold true, given a particular conditionBounded InvariantsA bounded invariant is a condition that must be invariant during a bounded period of time. Most often there are signals within the register transfer level (RTL) that can help identify this window of time. Otherwise, you can use auxiliary code to create a start and end signal that will identify this window and improve readability.Boundary CasesBugs often hide in boundary cases. You can develop an assertion that ensures a boundary condition produces the expected behavior.Bug IdentificationBug identification assertions describe behavior that must never occur in a design. The advantage of this type of assertion, opposed to describing behavior that must happen, is that RTL code does not get duplicated, which is usually a concern when you are writing RTL assertions.Signal ValuesOne of the most basic ways to describe a signal’s behavior is to identify when the signal:!Must have a value of 0 or 1!Transitions from 0 to 1, and from 1 to 0!Retains its current value!Changes valueIf this can be done without duplicating the RTL (or by a person other than the designer), then this is the most complete way to develop an assertion. This technique might be best for critical signals.Implementing AssertionsNow that you have selected your focus areas, extracted interesting behavior, translated that behavior into natural language form, and mapped the behavior to the various property types, you can express these property types in actual SVA syntax. Before doing this, you need to understand some basic SVA syntax.Basic SVA SyntaxThis section uses a sample Signal Value assertion to illustrate the fundamental SVA constructs.The following assertion is derived from the following natural-language statement: “If there is a rising edge on the request, then a grant must be issued within 1 to 3 cycles.”1. 2. 3. 4. 5. Figure 1 Sample Signal Value AssertionYou can then break down the example into the following:Assertion Label—Identifies the assertion. This is used for reports and debugging.(required)Directive— Specifies how the assertion is used during the verification process--as anassertion or constraint, or for collecting coverage information (required)Clocking—Indicates how or when the signals in the assertion are sampled (required)Disabling Condition—Disables the assertion during certain conditions (optional)Property Expressions (required)a. System Functions—Indicates one of the SVA system functions that are used toautomate some common operations. For example: $rose, $fell, $past, and$onehot. Refer to the “Writing SystemVerilog Assertions” chapter of the Assertion Writing Guide for information on the SVA system and sampled-value functions that are supported in the current release.b. Implication Operator ( |-> or |=>)—Specifies that the behavior defined on the right-hand side of the operator be checked only if the condition on the left-hand sideoccurs. There are two forms of the implication operator: overlapping (|->) and non-overlapping (|=>).The overlapping operator indicates that the last cycle of the LHS sequenceoverlaps the first cycle of the RHS sequence.The non-overlapping operator indicates that there is no overlap and that the firstcycle of the RHS sequence must occur one cycle after the LHS sequencecompletes.6.Note: When you are trying to capture an assertion in the standard written form,the implication operator typically maps to the word “then”.c. Cycle Operator (##)—Distinguishes between cycles of a sequence. Cycles arerelative to the clock defined in the clocking statement. Use a fixed number (##n) to specify a specific delay or a range operator (as specified in the next sub-bullet) to specify a range.d. Non-consecutive repetition operator ([*])—Enables the repetition of signals. Usethe form [*n] to represent a fixed repetition, or [*n:m]to specify a range ofrepetition from n to m. You can also apply the range operator to the cycleoperator.End of Statement Delimiter—Indicates the end of an assertion (required)Implementing Property TypesYou can leverage the syntax described in the previous section to create templates for each of the property types discussed earlier. The following table maps the different property types to SVA constructs that you can use in property expressions.Note: This table suggests SVA syntax that can be used in property expressions. This table does not cover the other aspects on an assertion, which were discussed in the previous section (such as assertion labels, directives, clocking, disabling conditions, and so on). Table 2 Property Types and SVA SyntaxQuestion Property Type Useful SVA SyntaxInvariant (onehot) $onehot(), $onehot0()Invariant (Illegal Combinations) ! (Boolean condition)Are there signals that are supposed to behave a certain way independent of time?Invariant (Special Cases) (special case) |-> (expected behavior) (special case) |=> (expected behavior)Are there signals that are supposed to behave a certain way within some window of time? BoundedInvariants(start) |-> ((!finish && cond)[*n:m] ##1finish && cond)(start) |-> ((!finish && cond)[*n:m] ##1finish)(start && !finish) |=> ((!finish &&cond)[*n:m] ##1 finish)Note: ##1 indicates a delimiter—not a 1-cycledelayAre there any boundary conditions in the design in which some behavior needs to be exhibited when that condition is reached? Boundary Cases (boundary case sequence) |-> (expectedsequence)Are there ways todescribe values orsequences that woulddescribe an errorcondition?Bug Identification Not (sequence)Are there signals that are critical to the functionality of the design? Signal Values (condition |=> $rose(sig))(condition |=> $fell(sig))(condition |=> sig == $past(sig))(condition |=> sig != $past(sig))Arbiter ExampleYou can now apply this ABV process to the arbiter example described in the Arbiter Specification,.which is included with this document. The arbiter example is typically a very good focus area for assertions, because it is control logic that often contains many corner case conditions.Mapping the BehaviorThe following lists arbiter example’s interesting behavior and maps this behavior to the various property types.Table 3 Arbiter Behavior MappingBehavior Property TypeGrant signals are zero one hot. InvariantOnce granted, the Busy signal must beasserted until Done.Bounded invariantThe arbiter must be fair for B. Boundary CasesYou must never see a GntB, when only ReqA is asserted.Bug IdentificationBusy must be asserted one cycle after agrant. Signal ValuesCreating the Assertion SyntaxAfter you map the behavior to a property type (Table 3), you can create the actual syntax for the assertion.! Invariant —Grant signals are zero one hot.assert_grant_zeroonehot : assert property (@(posedge clk) disable iff (!ResetN) $onehot0({GntA, GntB}));! Bounded invariant: Once granted, the Busy signal must be asserted until Done.assert_Busy_until_Done : assert property (@(posedge clk) disable iff (!ResetN) (GntA || GntB) |=> Busy[*0:$] ##1 Busy && Done); ! Boundary cases —The arbiter should be fair for B.assert_fair_for_B : assert property (@(posedge clk) disable iff (!ResetN)(GntA ##1 Busy[*0:$] ##1 Done&&ReqA&&ReqB |=> GntB));! Bug identification —You must never see a GntB, when only ReqA is asserted.assert_never_grant_wo_req : assert property (@(posedge clk) disable iff (!ResetN) not (ReqA && !ReqB ##1 GntB));! Signal values —Busy must be asserted one cycle after a grant.assert_Busy_active : assert property (@(posedge clk)disable iff (!ResetN) (GntA || GntB) |=> $rose(Busy)); Running the Assertions in the SimulatorUse the following steps to run these assertions in the Incisive Design Team Simulator:1. 2. 3. Go to the directory that contains the arbiter example:cd <example_install_dir>/iusUse the following command to run the example:run_simIn the console window, observe that the assertion –summary command shows that all the assertions have been executed, but one assertion fails.From the toolbar, click the Assertion Browser button . The Assertion Browserdisplays a flat list of all of the assertions in a design and provides the assertion’s name,4.5.6. module, instance, class, finished count, failed count, and so on. The assertions are listed in table format.Double-click any assertion. This displays the source code for the assertion. Notice how the assertions are embedded directly into the arbiter RTL file.Close the Source Browser.Select the assert_fair_for_B assertion. Add it to the waveform by selecting it and clicking on the Waveform button from the toolbar.Note: The waveform displays the state of the given assertion. The red circle indicates where the assertion fails and represents the starting point for debug.7. Using the steps discussed in this document and in the arbiter specification, you can addmore assertions to the <example install dir>/rtl/arbiter.v file and rerun.ConclusionThrough the course of this document, you have been exposed to an ABV process that uses SVA. This includes picking focus areas for assertions, identifying properties that are characteristic to the design, implementing assertions using SVA, and viewing assertions in a real example. After completing these steps, you can try implementing SVA in your own designs.。
systemverilog assertion语法
SystemVerilog assertion (SVA)语法概述1. 引言SystemVerilog是一种硬件描述语言（HDL），用于硬件设计和验证。
在SystemVerilog中，assertion（断言）被广泛用于验证设计中的属性。
断言是一种描述设计中期望行为的形式化语句，用于检查设计的正确性。
本文将介绍SystemVerilog assertion的语法和用法。
2. 断言的基本语法在SystemVerilog中，使用`assert`关键字来引入断言。
下面是断言的基本语法：```systemverilogassert property_name : condition;```其中，`property_name`是断言的名称，`condition`是要验证的条件。
3. 条件表达式条件表达式可以是一个逻辑表达式，用于描述设计中的属性。
以下是一个简单的条件表达式：```systemveriloga b |-> c```上面的表达式表示当`a`和`b`同时为真时，`c`必须为真。
4. 断言属性在断言中，可以使用多种属性来描述设计中的行为。
下面是一些常见的断言属性：- ``：指定条件的时序性质。
`(posedge clk)`表示在时钟上升沿检查条件。
- `disable iff`：指定在某些情况下禁用断言。
`disable iff (reset_n == 0)`表示当复位信号为低电平时禁用断言。
- `strong`和`weak`：指定断言的强度。
`strong`断言必须被满足，而`weak`断言可以被忽略。
5. 示例下面是一个使用SystemVerilog assertion的简单示例：```systemverilogmodule dut (input logic a,input logic b,output logic c);assert property_name : (a b) |-> c;endmodule```在上面的例子中，我们定义了一个名为`property_name`的断言，要求当`a`和`b`同时为真时，`c`必须为真。
system_verilog_assertion
1什么是断言：断言就是在模拟过程中根据我们事先安排好的逻辑是不是发生了,如果发生断言成功，否则断言失败。
2断言的执行分为：预备（preponed）观察(observed)响应(reactive).3断言的分类：并发断言（基于时钟）和即时断言（基于语义）。
4SVA（system Verilog assertions）：块的建立：序列：Sequence name_of_sequence;<test expression>EndsequenceProperty name _of_ property<test expression>Or<sequence>EndpropertyAssertions _name: assert property (property_name) or test_expression;执行块：Assertion_name:Assert property(property_name)<success message>Else<fail message>注：保持序列独立于时钟，属性中定义时钟是好的编码风格。
5 SVA检测器的步骤：建立布尔表达式->建立序列表达式->建立属性->断言属性；6常用语句及函数：$rose()：检测信号上升沿$fell(): 检测信号下降沿$stable(); 检测信号是否稳定。
##n：表示延迟N个时钟周期。
##[n1:n2]:延时在n1到n2个时钟周期之内。
##[n1:$]:延时在n1到无穷个时钟周期之内。
not：检测属性不为真的情况（禁止属性）|->: 如果先行算子匹配在同一个时钟周期检测后续算子|=>:如果先行算子匹配在下一个时钟周期检测后续算子ended: 以序列的结尾作为多个序列的连接点xx？xx:xx：问号表达式与c相同。
`define true 1:利用true表达式可实现序列延时n个周期。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
测试向量
传统上，对被测设计（DUT）的验证都是通过在DUT 的输入端口加上具有特定时序激励，然后观察DUT 的内部状态变化和最后的输出信号，以确定DUT 工作是否正确。 这种方法对简单的小规模的设计很有用。
• 当设计规模变大时，要想使用这种方法来验证DUT
性语言来描述设计的属性。在仿真过程中，如果一 个被描述的属性不是我们期望的那样，那么断言就 会失败；或者在仿真过程中，如果出现了一个不应 该出现的属性，那么断言也会失败。
SystemVerilog Assertions
• Enhance SystemVerilog to support
Assertion-Based Verification
断言分类
SVA 分为并发断言和即时断言。 • 并发断言的计算基于时钟周期，在时钟边沿根据变 量的采样值计算表达式。 • 并发断言可以在静态（形式化）验证工具和动态 （仿真）验证工具中使用。 • 上面的例子就是并发断言。
• 即时断言基于事件的变化，表达式的计算就像
Verilog 中的组合逻辑赋值一样，是立即被求值的， 而不是时序相关的。 • 必须放在过程块的定义中，只能用于动态仿真。
例
• 如:来的2～4个时钟周 期内，信号b 应该为高电平”。 • 用Verilog 语言描述这样一个属性需要一大段代码， 而用SVA 描述就只需要几行代码。下面的代码为 SVA。
property a2b_p; @(posedge sclk) $rose(a) |-> [2:4] $rose(b); endproperty a2b_a: assert property(a2b_p); a2b_c: cover property(a2b_p); • property 和endproperty 为SVA 的关键字，描述属性。 • a2b_p 为属性的名字。 • $rose 为SVA 的内嵌函数，用于检查信号的上升沿。 • assert property 也为SVA 的关键字，表示并发断 • a2b_a 为断言的名字，它把属性a2b_p 作为参数。 • a2b_c 为覆盖语句，它用于记录断言的成功。下图为本断 言在ModelSim 6.1b 环境中的仿真波形和断言出错信息。
• 检查如果信号a 在某个时钟周期为高电平，两个时
钟周期后信号b 也必须为高电平。 sequence s2_s; @(posedge sclk) a ##2 b; endsequence a2_a: assert property(s2_s); c2_c: cover property(s2_s);
序列重复操作符
• 使用序列的重复操作符进行检查序列的重复操作符分为3 类：
• • •
连续重复，跳转重复和非连续重复。 “[*m]”为连续重复操作符。“a[*3]”表示a 被连续重复3 次，“a[*1:3]”表示a 被连续重复1～3 次。连续重复的相 邻两次重复之间只有一个时钟间隔。 “[->m]”为跳转重复操作符。“a[->3]”表示a 被跳转重 复3 次，“a[->1:3]”表示a被跳转重复1～3 次。跳转重 复的每一次重复之前可以有任意个时钟周期的间隔。 “[=m]”为非连续重复操作符。“a[=3]”表示a 被非连续 重复3 次，“a[=1:3]”表示a被非连续重复1～3 次。非连 续重复的每一次重复之前可以有任意个时钟周期的间隔，最 后一次重复之后可以有任意个时钟周期的间隔。
• Syntactic compatibility
White-box (inside block) assertions Black-box (at interface boundaries) assertions
Easy to code directly in-line with RTL
• 在sclk(0)处，仿真刚开始，a 还没有被赋值，为
不定态x，所以在sclk(0)处，断言失败。 • 在sclk(1)处，采样当a 为0，断言失败。在其余时 钟上升沿处，分析方法类似。 • 最后断言在第0、1、2、7、12、13、14 个时钟 上升沿失败，在其余时钟上升沿成功。
除了可以使用仿真环境默认的断言错误提示信息外， 还可以在断言中添加自己的提示信息。 例： sequence s1_s; @(posedge sclk) a; endsequence a1_a: assert property(s1_s) $display (“assertion success”,$time) else $display(“assertion faild”,$time);
• rose_a 用于检测信号a 的上升沿，它只在“a 在当前时钟 •
• • •
周期为高电平，在前一个时钟周期为低电平”的情况下才成 功，如第3、8、11 个时钟周期，在其它情况下失败。 fell_a 用于检测信号a 的下降沿，它只在“a 在当前时钟周 期为低电平，在前一个时钟周期为高电平”的情况下才成功， 如第3、8、11 个时钟周期，在其它情况下失败。 在sclk(0)处，采样到a 为不定态x。在sclk(1)处，采样到 a 为0。a 从x 变到0，本仿真环境认为是a 的下降沿，所 有断言成功。 stable_a 用于检查信号a 不变的情况，它只在“a 在当前 时钟周期为一个电平，在前一个时钟周期也为同样的电平” 的情况下成功。如第0、2、4、5、6、8、10、11、13 个 时钟周期。 在sclk(0)处，采样到a 为不定态x，仿真系统认为在0 时刻 之前a 同样为不定态x，所有在sclk(0)处断言成功。
是不现实的。因为对于规模大的设计，要想遍历设 计将遇到的各种情况，验证其正确性，需要成千上 万的特定时序激励。 • 如果设计稍有一点变动，这些时序激励就得重新编 写。 • 设计的复杂性迫使验证工程师使用随机测试平台来 生成更多的验证激励。
什么是断言Assertion
• 断言就是对设计属性（行为）的描述，它是用描述
sequence s1_s; @(posedge sclk) a ##1 b ##4 c ##[1:5] z; endsequence a1_a: assert property(s1_s);
假设要检查“信号a 在每个时钟上升沿都为高电平， 如果信号在任何一个时钟上升沿不为高电平，断言 将失败”。这可以通过下面的代码实现： 例： sequence s1_s; @(posedge sclk) a; endsequence a1_a: assert property(s1_s); c1_c: cover property(s1_s);
蕴含操作符
• 蕴含操作符的左边项为“先行算子”（antecedent），右
•
•
•
•
边项为“后序算子”（consequent）。 先行算子是约束条件，当先行算子匹配（成功）时，后序算 子才能被计算。如果先行算子不成功，那么整个属性就被默 认成功，叫“空成功”（vacuous success）。蕴含结构 只能被用在属性定义中，不能用在序列定义中。 蕴含操作符分为两类：交叠蕴含操作符（|->）和非交叠蕴 含操作符（|=>）。 非交叠蕴含操作符“|->”表示：如果先行算子匹配，后序 算子在同一个时钟周期开始计算。 交叠蕴含操作符“|=>”表示：如果先行算子匹配，后序算 子在下一个时钟周期开始计算。
• Support for design and assertion reuse • Monitoring the design
Support for assertion “binding” to design from separate file
Concurrent (“standalone”) assertions Procedural (“embedded”) assertions
sequence rose_s; @(posedge sclk) $rose(a); endsequence sequence fell_s; @(posedge sclk) $fell(a); endsequence sequence stable_s; @(posedge sclk) $stable(a); endsequence rose_a: assert property(rose_s); fell_a: assert property(fell_s); stable_a: assert property(stable_s)；
断言的组成和建立过程
• 任何复杂的时序模型，其功能总是由多个逻辑事件的组合来
表示的。这些事件可以是简单的同一时钟沿被求值的布尔表 达式，也可以是经过几个时钟周期求值计算得到的事 --SVA 使用关键字sequence（序列）来表示这些事件。 • 许多序列可以被有序地组合起来形成设计的属性， --SVA 用关键字property 来表示属性。最后属性要在断言中 被调用才能真正发挥作用。 • 用覆盖语句来记录断言成功的次数。 断言的建立过程为： “编写布尔表达式 —> 编写序列（sequence）－> 编写属 性（property）—> 编写断言（assert property）和覆 盖语句（cover property）”。
• overloap_impli_a
• non_overlap_impli_a
用于检测“信号a 在某个时钟周期为高电平，并且信号 b 在同一个时钟周期也为高电平”的情况。 整个断言只有在检测到信号a 为高电平时才能被激活。 在所有被激活的断言中，一共有8 次成功，5 次失败。 用于检测“信号a 在某个时钟周期为高电平，并且信号 b 在下一个时钟周期也为高电平”的情况。 整个断言只有在检测到信号a 为高电平时才能被激活。 在所有被激活的断言中，一共有6 次成功，6 次失败。
为什么要使用断言呢？