8.2.2. Property Checking

Property checking involves verifying that certain properties or assertions, which describe the expected behavior of a design, hold true for all possible inputs. These properties are generally specified using temporal logic such as Linear Temporal Logic (LTL) or Computation Tree Logic (CTL).

Property checking is a verification method to ensure that specific expected behaviors of a design are met under all circumstances. It uses formal languages, called temporal logic, to describe these behaviors. Linear Temporal Logic (LTL) and Computation Tree Logic (CTL) are examples of such languages that help express how the system should behave over time.

Imagine a school policy stating that 'students must be in class during school hours.' This policy must hold true at all times and for every student. In the same way, property checking examines if the design adheres to its intended rules, ensuring it behaves correctly in every possible scenario.

Property checking is commonly used for verifying complex designs, ensuring that safety and liveness properties are met in an RTL design. For example, it can be used to check that a counter never overflows or that a signal is always stable within a certain time window.

In practical scenarios, property checking is vital for verifying RTL designs. It ensures that safety properties (like preventing overflow in counters) are adhered to, and liveness properties (like ensuring signals remain stable) are maintained throughout the operation of the design. This makes it possible to catch potential failures before they occur in real-world applications.

Consider a traffic light system: we want to ensure that the light never stays red and green at the same time (safety property) and that every light will eventually turn green (liveness property). Property checking assesses whether these rules continually apply.

Designers specify properties such as 'always A implies B' or 'eventually X will happen.' Formal tools exhaustively check if these properties hold for all possible input combinations and timing scenarios.

To perform property checking, designers articulate specific logical properties they expect the design to satisfy. The property 'always A implies B' means that whenever condition A holds true, condition B must also hold. The verification tools then rigorously assess the design, checking every possible input and timing scenario to confirm if these properties are consistently maintained during operation.

Think of a game with strict rules. If a rule states 'if the player has a key (A), they can enter the door (B),' property checking would ensure that this rule holds every time a player with a key encounters the door, no matter when they try to enter.

Tools: Cadence JasperGold, Mentor Graphics Questa Formal, Synopsys Formality are used for property checking.

There are several specialized tools designed to facilitate property checking. Cadence JasperGold, Mentor Graphics Questa Formal, and Synopsys Formality are among the commonly used ones. These tools automate the process, allowing designers to input their specified properties and receive feedback on whether their designs comply.

Imagine using a software application to check your homework. Just as an app can highlight errors and suggest corrections, property checking tools analyze the design and point out any violations of the stated properties, helping ensure everything functions as intended.

For a design involving a FIFO (First-In-First-Out) queue, a property might state that 'when the FIFO is not empty, the data output should always be valid.' Formal tools can verify this property across all possible states of the FIFO design.

In this example, the property being checked for the FIFO queue highlights a critical feature: that as long as there is data in the queue, the outputs will be valid (meaning that the data being accessed is accurate). Property checking tools evaluate all possible operational scenarios to ensure this condition is never violated, contributing to reliable system design.

Think of a delivery service. The rule is 'if there are packages in the van (FIFO not empty), they must be properly labeled (data output valid)'. Property checking ensures that regardless of how many packages are loaded or unloaded, every package is always labeled correctly when the van is in use.

--