introduction
This article briefly introduces assertions in SystemVerilog.
Previous link:
My System Verilog learning record (1)
My System Verilog learning record (2)
My System Verilog learning record (3)
My System Verilog learning record (4)
My System Verilog learning record (5)
My System Verilog learning record (6)
My System Verilog learning record (7)
My System Verilog learning record (8)
My System Verilog learning record (9)
My System Verilog learning record (10)
My System Verilog learning record (11)
My System Verilog learning record (12)
introduce
The behavior of the system can be written as assertions that should be true at all times. Assertions are therefore used to verify system behavior defined as properties and can also be used for functional coverage.
What are the design parameters?
An assertion will fail if the property of the design it is examining does not behave as expected. For example, suppose a design requests arbitration and expects an ack within the next four cycles. However, if the design gets an ack in the fifth cycle, the property of returning an ack within 4 clocks is violated and the assertion will fail.
An assertion will fail if the design property it is checking is prohibited from occurring. For example, suppose a small processor decodes an instruction read from memory, encounters an unknown instruction, and causes a fatal error. If such a scenario does not occur in the design, the property of the design that only valid instructions can be read from memory is violated, and the assertion fails.
From the two examples above it is evident that the properties of a given design are checked by writing SV assertions.
Why do you need assertions?
Assertions are nothing more than a more succinct representation of feature checkers. The functionality represented by assertions can also be written as a system verifier task or checker involving more lines of code. Some disadvantages of doing this are as follows:
- SV is very verbose, hard to maintain, and scales the code based on the number of attributes
- As a procedural language, it is difficult to write checkers that involve many parallel events in the same time period
SystemVerilog assertions are a declarative language for specifying temporal conditions that are very concise and easier to maintain.
Assertion statement type
construct assertion block
timing
The timing of multiple logic events typically forms the functionality of any design. These events may span multiple clocks, or only exist in one clock cycle. To keep things simple, simple assertions can be used to describe smaller events, which can then be used to build more complex patterns of behavior.
properties/parameters
These events can be represented as a sequence, and multiple sequences can be combined to create more complex sequences or properties. In order to assert a sequence or property, clock events must be included in the sequence or property.
There are two types of assertions - immediate and simultaneous.
assert immediately
Immediate assertions execute like statements in procedural blocks and follow emulated event semantics. These assertions are used to verify immediate properties during simulation.
while asserting
Concurrent assertions are based on clock semantics and use sampled values of their expressions. Circuit behavior is described using SystemVerilog properties that are evaluated every time on a given clock, and failures in simulation indicate that the described functional behavior is violated.
Steps to create an assertion:
- Create boolean expressions
- Create sequence expressions
- Create properties
- Assertion property
example
The first sequence s_ab confirms that the next clock b is high when a is high, and the second sequence s_cd confirms that d is high 2 clocks after c is found high.
assert immediately
Immediate assertions are performed based on simulation event semantics and need to be specified in a program block. During simulation, it is the same as the expression in the if statement.
The immediate assertion will pass if the expression holds true while executing the statement, and will fail if the expression evaluates to false (X, Z, or 0). These assertions are intended for simulation and are not suitable for formal verification. It can be used in RTL code and testbenches to flag errors in simulations.
usage
Immediate Assertions in Design
Below is an example where the design uses an immediate assertion to check if a push request to the FIFO arrives when the FIFO is already full. The first begin end block is executed if the expression in the assert statement evaluates to true, and the else part is evaluated if the expression evaluates to false. This is very similar to the if construct, except that the user does not need to place a display statement to flag the error.
In the absence of such immediate assertions, use additional effort and resources for concurrent assertions to replicate the logic leading to that particular point.
Simulation results:
Immediate assertions in Testbench
Suppose a class called Packet is created and randomized. However, this example has a constraint error and the randomization will fail. However, failures will be displayed as warning messages, and if the user is not careful, the test may show incorrect behavior, and may even appear to pass.
Simulation results:
Instead, an immediate assertion can be placed on the randomization method call to ensure that the return value is always 1, indicating that the randomization was successful. If an assertion fails, it prompts the user to see the failure first, reducing debugging effort.
Concurrent (Simultaneous) Assertions
Concurrent assertions describe behavior that spans simulation time and are only evaluated when the clock cue occurs.
SV concurrent assert statements can be specified in modules, interfaces, or program blocks that run concurrently with other statements. The following are properties of concurrent assertions:
- Evaluate a test expression on a clock edge based on the value in a sampled variable
- Variables are sampled in the prepare region and expressions are evaluated in the observe region of the simulated scheduler.
- It can be placed in a block, module, interface or block
- It can be used in dynamic and formal verification techniques
Example 1
Two signals a and b are asserted and driven on the positive edge of the clock to illustrate how concurrent assertions work. Assertions are written with assert statements on immediate properties that define the relationship between signals in a clock event.
In this example, the signal ab is expected to be pulled high on the positive edge of the clock throughout the simulation. The assertion will fail for all instances where a, b are found to be zero.
The assertion executes on each positive edge of CLK and evaluates the expression using the value of the variable in the preset region, which is the increment period before the given edge of the clock. So if it goes from 0 to 1 on the same edge as the clock, the value of Take for Assertion will be zero because it was zero just before the clock edge.
It can be seen that the assertion fails for all cases where either a or b is found to be zero, because the expression given in the assertion statement is expected to be true for the entire duration of the simulation.
Example 2
The expression defined as an attribute of the ASSERT statement is modified from the above example to an OR condition.
Example 3
Expressions defined as attributes of ASSERT statements are modified from the above example to XNOR conditions;
$rose,$fell,$stable
Sequences are a simple building block in SystemVerilog assertions that can represent certain expressions to help create more complex properties.
simple sequence
$rose
The system task $rose is used to detect the positive edge of a given signal. In this case, $rose indicates that a trailing edge is expected to be seen on every trailing edge of CLK. Because SystemVerilog assertions are evaluated in preset regions, it can only check the value of a given signal in preset regions. A positive edge is assumed to have occurred when the value of the signal is 0 on the first edge and then 1 on the next edge. So this requires 2 clocks to be identified.
As you can see in the figure below, a positive edge is detected and the assertion passes at 30 ns. This is because the value of AIS is 0 at 10 ns and 1 at 30 ns, and the assertion completes and proves successful.
$fell
The system task $felli is used to detect negative edges of a given signal. In this case, $fell means that the negative edge of a is expected to occur at each pose of clk. Because a SystemVerilog assertion is evaluated in a preset region, it can only check the value of a given signal in the preset region. A negative edge is assumed to have occurred when the value of the signal is 1 on the first edge and then 0 on the next edge. So this requires 2 clocks to be identified. Opposite of $rose
$stable
It means that there is no jump in the level of the detected signal.
Assertion Latency##
## operator
If a is not high on any given clock cycle, the sequence starts and fails on the same cycle. However, if a is high on any clock, after two clocks, if b is high, the assertion starts and succeeds. If b is low after two clocks, the assertion fails.
