Functional and Formal

Verification of Digital Designs

Sudeendra kumar K
Department of Electronics and Communication
Engineering

1
FUNCTIONAL AND FORMAL
VERIFICATION OF DIGITAL DESIGNS
Building Properties

Unit-II Session -V

Sudeendra kumar K
Department of Electronics and Communication Engineering
2
 Functional and Formal Verification of Digital Designs
Review of Session IV

• Sequences
• Operators on Sequences
• Properties
• Implication operators

3
 Functional and Formal Verification of Digital Designs
Contents

• Negated Sequences
• Building Properties
• Names Sequences and Properties
• Implicit Multi-threading
• Embedded Properties in RTL development
• “Bind” feature

4
 Functional and Formal Verification of Digital Designs
Cautions on Implication operator and triggering conditions
• An overlapping |->. operation is logically equivalent to a
simple Boolean operation, as in the example below:

a1_boolean: assert property (!cat || dog);

a1_trigger: assert property (cat |->. dog);

• Simulation debug tools can indicate cycles when the

assertion was triggered, as well as when it passed or
failed.
• FV tools can generate an implicit cover point to check
whether the triggering condition is possible.
• Thus, it is recommend that whenever you have multiple
potential ways to write a property, you try to state it as a
triggered implication if possible.
5
Courtesy: - Erik Seligman Formal Verification
Functional and Formal Verification of Digital Designs
Liveness Property using Linear Temporal Logic (LTL)
• LTL operators are critical if you want to create “liveness
properties”: properties that specify aspects of potentially
infinite execution traces.

• Probably the most useful LTL operators in practice are • Logic in Computer
s_until and s_eventually. Science by Huth and
Ryan.
• Proportional logic
• s_until specifies that one property must be true until • Predicate logic
another property (which must occur) is true, and • Temporal logic
• CTL: Computation
s_eventually specifies that some expression must Tree Logic
eventually be true. • LTL: Linear
Temporal Logic
• The s_ prefix on these operators stands for “strong,”
indicating that in an infinite trace the specified conditions
must happen at some point.
6
Courtesy: - Erik Seligman, Formal Verification
Functional and Formal Verification of Digital Designs
Example of Liveness Property

7
Courtesy: - Erik Seligman, Formal Verification
 Functional and Formal Verification of Digital Designs
Negated Sequences
• SVA sequences have a not operator, to enables us to
check cases when the sequence is not matched.
• A negated sequence is often very useful as a property to
check that some unsafe condition never occurs.

8
Functional and Formal Verification of Digital Designs
Negated Sequences

9
 Functional and Formal Verification of Digital Designs
Named Sequences and Properties

10
Courtesy: - Erik Seligman, Formal Verification
Functional and Formal Verification of Digital Designs
Assertions and Implicit Multi-threading
• To describe complex behaviors that happen over time, a
question has probably occurred to you: what happens if
multiple behaviors overlap?
• For example: - Suppose we implement a version of the
arbiter that accepts each request as a one-cycle pulse and
expects a grant precisely 10 cycles after any request. Here
is an example assertion describing this behavior for agent
0:
delayed_gnt: assert property (req[0] |-> ##10 gnt[0]);
• Due to the 10-cycle gap between the request and the
grant, though, it is possible that another request will
arrive within that window.
• That second request should also get a grant precisely 10
cycles after it arrived. So in effect, we need two
overlapping evaluations of this assertion. 11
 Functional and Formal Verification of Digital Designs
Assertions and Implicit Multi-threading

• We can see that the first evaluation thread is launched

after the request pulse on req [0] in cycle 1, and
completes when the corresponding grant is seen in cycle
11.

12
Courtesy: System Verilog Assertions, Erik Seligman
 Functional and Formal Verification of Digital Designs
Application of Sequences

• Similarly, the second thread is launched after the request

in cycle 5, and ends after seeing the corresponding grant
in cycle 15.
• Even though these two evaluations of the assertion are
happening at the same time, they do not interfere with
each other: if the grant had failed to arrive at cycle 11 or
at cycle 15, a failure would have been reported. 13
Courtesy: Formal Verification, Erik Seligman
Functional and Formal Verification of Digital Designs
Writing the Properties

• Planning Properties at specification phase

• Embedded Properties during RTL development

• Validation focused properties

14
 Functional and Formal Verification of Digital Designs
Planning Properties at Specification Phase
• Whenever you are describing a concrete requirement that
will describe the behavior of signals in your design, think
about whether it is something that you could potentially
write as an assertion.

• Also remember to think about potential cover points at Importance of

this stage: both typical conditions that will be useful as a Concurrency

general sanity check on your validation, as well as

interesting corner cases that you are worried your
validation might miss.

15
Courtesy: System Verilog Assertions, Ashok Mehta
Functional and Formal Verification of Digital Designs
Embedded Properties in RTL development

• In place of comments, designers can write assertions to

make understand the verification engineers job easy.
• When the RTL is passed on to a future project for reuse,
the new users will see assertion failures in simulation or
FV if they use it in a way that violates the original
author’s assumption.
• Whether a particular statement needs to be an assertion
or an assumption depends on the hierarchy level in FV
and assertions and assumptions are equivalent during
simulation.
• Thus, it is recommend that, just write assertions and
cover points, rather than Assumptions during RTL
development.
16
Functional and Formal Verification of Digital Designs
Validation related Properties
• When we have such a specification, we should usually try to
write “end-to-end” assertions that will specify how our design’s
outputs look in terms of its inputs.
• These will be the most effective in helping to find if some
unexpected or overlooked part of our design causes incorrect
behavior.
• While white-box assertions based on internal nodes can also be
useful validation and debug aids, using these exclusively can be
dangerous because they focus on the designer’s low-level
thought processes instead of the overall design intent.

17
 Functional and Formal Verification of Digital Designs
Connecting Properties to design
• Once you have written your assertions and cover points,
you must insert them into your RTL model.
• The most direct way to do this is simply to paste them
inside the code of your top-level module.
• If you are writing embedded assertions as you design the
code, inserting them in the actual RTL as you write it does
make the most sense.
• SystemVerilog provides a nice feature to enable you to
connect externally written code inside a module: the bind
statement.
• Binding allows you to separate design code from
verification code. A bind essentially forces a remote
module to instantiate another module inside it, and be
treated just like any other sub-module instance.
18
Functional and Formal Verification of Digital Designs
Summary

• Negated Sequences
• Building Properties
• Names Sequences and Properties
• Implicit Multi-threading
• Embedded Properties in RTL development
• “Bind” feature

19
THANK YOU

Sudeendra kumar K
Department of Electronics and Communication
Engineering
[email protected]

20