assertions part4

Assertions act like automatic monitors that continuously observe signals during simulation or formal verification and report violations whenever the expected behavior is not satisfied. The first section introduces the purpose of SVA, highlighting that assertions help detect functional bugs, protocol violations, timing issues, and incorrect signal behavior. The second section explains the five fundamental building blocks of SVA: Boolean Expressions, which check whether a condition such as req && ready is true at a particular sampling point; Sequences, which describe temporal patterns of events across multiple clock cycles using operators such as ##1; Properties, which combine Boolean expressions and sequences to describe the expected design behavior over time; Assertion Keywords, such as assert property, which activate property checking during simulation or formal verification; and optional Action Blocks, which use system tasks such as $display, $error, and $fatal to print messages, report failures, or terminate simulation. The third section explains Boolean expressions and their common operators, including logical AND (&&), logical OR (||), logical NOT (!), equality (==), inequality (!=), relational operators , and set membership using inside. It also demonstrates how to define a property that checks whether req and ready are high together at a positive clock edge. The fourth section introduces sequences and temporal operators, which are essential for checking signal relationships across clock cycles; for example, req ##1 ack means that whenever a request occurs, an acknowledgement must occur in the next clock cycle, while ##2 represents a delay of two clock cycles, ##[1:3] represents a delay of one to three cycles, ##0 represents the same cycle, and repetition operators such as [*3], [*1:4], and [*0:$] represent consecutive repetitions, bounded repetitions, and zero or more repetitions, respectively. The fifth section provides practical sequence examples, including a simple request-acknowledgement sequence, a sequence in which valid remains asserted for three consecutive cycles, a variable-delay acknowledgement sequence, and a multiple-condition sequence that checks request and enable signals together. The sixth section explains properties as design requirements by combining sequences and temporal operators to express expected behavior over time; for example, req | ##[1:3] ack checks that an acknowledgement occurs within one to three clock cycles after a request, where is an overlapped implication and | is a non-overlapped implication, meaning that the consequent starts in the same clock cycle or the next clock cycle, respectively. The seventh section explains the assert property keyword and action blocks, demonstrating how to report successful or failed assertion checks using $display, $error, and $fatal; $display prints informational messages, $info reports informational events, $warning reports warnings, $error reports errors while allowing simulation to continue, and $fatal terminates the simulation. The eighth section covers advanced SVA applications, including bounded response checking, AXI VALID stability, and APB setup-to-access phase checking; for example, an AXI assertion verifies that once valid is asserted and ready is low, the VALID signal and associated transaction data remain stable until the handshake completes, while an APB assertion checks that the transition from the setup phase (PSEL) to the access phase (PENABLE) follows the protocol requirements. The ninth section introduces important sampled-value functions such as $past(signal), which retrieves the previous sampled value; $stable(signal), which checks whether a signal remains unchanged; $rose(signal), which detects a rising transition; $fell(signal), which detects a falling transition; $changed(signal), which detects any value change; and $isunknown(signal), which detects X or Z values. These functions are particularly useful for checking data stability, reset behavior, handshake transitions, and unknown-state conditions. The tenth section explains the difference between an Assertion Property and a Cover Property: an assertion checks whether a design requirement is satisfied and reports violations, whereas a cover property records whether a particular scenario has actually occurred during simulation, helping verification engineers measure scenario execution and identify missing test scenarios. Finally, the eleventh section summarizes the key takeaways: Boolean expressions check conditions at a sampling point, sequences describe temporal patterns, properties represent design requirements, assertion keywords activate checking, action blocks provide debugging information, and sampled-value functions provide additional capabilities for checking previous values, signal stability, and transitions.