Formal verification assertions Could be applied in checking
Formal verification: assertions Could be applied in checking properties. . . Digitaalsüsteemide verifitseerimise kursus 1
Simulation-based verification: assertions … but also during simulation Digitaalsüsteemide verifitseerimise kursus 2
Assertion • Set of expressions that check the validity of certain conditions for variables over a period of time • If a condition is violated then an error message will be displayed that will report the location of the error • Assertions could be used during simulation or in checking properties formally Digitaalsüsteemide verifitseerimise kursus 3
Assertion • Allows observing internal signals: – Before they propagate to outputs • Applied in HW and SW debugging for long • Only recently standardized Digitaalsüsteemide verifitseerimise kursus 4
Assertion-based Verification • Completeness problem – Who/what and when should specify assertions? – When is it enough? • In practice design engineer writes them for VHS (Verification Hot Spots). Such spot: – contains a great number of sequential states; – deeply hidden in the design, making it difficult to control from the inputs – has many interactions with other state machines and external agents – has a combination of these properties
How to create assertions Two opposite strategies: 1. Find from spec properties that should hold in the implementation (liveness) 2. Find from spec properties that should not occur in the implementation (safety) + fairness properties Digitaalsüsteemide verifitseerimise kursus 6
Combinational and Sequential Assertions • Assertions not depending on time combinational: N. (A != 0 ) && ( A & (A-1)) • Assertions depending on previous (following) clock cycles - sequential: N. (A-1 != A) -> (A == A+1) • The interwal between the 1 st and last clockcycles: time-window Digitaalsüsteemide verifitseerimise kursus 7
Hierarchy of assertions • As specs can be represented at different abstraction levels so can assertions: – Behavioral level – RTL – Logic level – etc. . . Digitaalsüsteemide verifitseerimise kursus 8
Assertion components • 1. 2. 3. 4. Assertion consists of 4 components: Activating condition Signal register Assertion statement Reaction Digitaalsüsteemide verifitseerimise kursus 9
Assertion components Digitaalsüsteemide verifitseerimise kursus 10
Sequential assertions • Cyclic list: Digitaalsüsteemide verifitseerimise kursus 11
Assertions on signal change pattern Sequence Description Assertion Coding Gray code Täpselt üks bitt muutub S^S-1 is one-hot Hamming code, H H bits change S^S-1 has H ones Increment/decre- A signal increments/ ment decrements by a step size N S-S-1 = N / S-1 -S = N Change delta A signal’s change in a range R |(S-S-1)| ≤ R Transition sequence A signal’s transition follows a certain value pattern Signal membership check Cause and effect Signal A asserting at time T causes B to assert at T+N A-N –> B Digitaalsüsteemide verifitseerimise kursus 12
More assertions • Check if a signal changed within a timewindow • Check causality (change of one signal causes change in another) within a timewindow Digitaalsüsteemide verifitseerimise kursus 13
Container Assertions • Check correctness after additional processing Digitaalsüsteemide verifitseerimise kursus 14
Assertion languages • Although any HDL (VHDL, Verilog, etc. ) will do, it may need a lot of coding … • …and the assertions can not be reused. • System. Verilog. Assertions (IEEE std 1800) and PSL (IEEE std 1850) offer standard assertions Digitaalsüsteemide verifitseerimise kursus 15
Assertion languages • OVL Open Verification Library assertions • include PSL and VHDL checkers – A part of OVM/UVM from Mentor & Cadence – Synopsys: Open Vera Language assertions (OVA) • HDLs – assert statement s to print messages at the simulation console • severity levels • System C assertions, e, etc. Digitaalsüsteemide verifitseerimise kursus 16
System. Verilog Assertions • Two types of assertions in SVA: 1. Procedural assertions 2. Declarative assertions Digitaalsüsteemide verifitseerimise kursus 17
SVA: procedural assertions • Written to the code to be simulated – applied in simulation-based verification. • Example: assert (WR == 1'b 1 && CS == 1'b 0) $display ("INFO: memory ready"); // pass clause else $display ("ERROR: cannot write"); // fail clause Digitaalsüsteemide verifitseerimise kursus 18
SVA: declarative assertions • Declarative assertions (similar to modules) – applied in property checking. • Syntax: assert property (property_definition_or_instance) action : : = [statement] | [statement] else statement Digitaalsüsteemide verifitseerimise kursus 19
SVA: declarative assertions, sequences • Declarative assertions describe temporal behavior • Main concept is a sequence: • Sequence = {(Bi, Ti), i V}, • Bi is Boolean expression at time step Ti, and V is a set of integers (e. g. clock cycle index) Digitaalsüsteemide verifitseerimise kursus 20
SVA: sequences and waveforms • SVA sequence constructor: ##N, where N is the delay • x ##4 z is equivalent to (x, t), (z, t+4) • Ranges can be described • E. g. x ##[1, 3] z stands for x ##1 z or x ##2 z or x ##3 z • Many waveforms generally corresponding to a sequence! Digitaalsüsteemide verifitseerimise kursus 21
SVA: sequences and waveforms Digitaalsüsteemide verifitseerimise kursus 22
Analogy with Boolean functions Digitaalsüsteemide verifitseerimise kursus 23
SVA. Sequence Operators: AND • s 1 AND s 2 is true if s 1 and s 2 have both become true: Digitaalsüsteemide verifitseerimise kursus 24
SVA. Sequence Operators : OR • s 1 OR s 2 is true if s 1 or s 2 has become true: OR true Digitaalsüsteemide verifitseerimise kursus true 25
SVA. Sequence Operators: intersect • Similar to AND, but requires that the sequences begin and end at the same time: Digitaalsüsteemide verifitseerimise kursus 26
SVA. Sequence Operators: first_match • Is true when a sequence becomes true the first time: Digitaalsüsteemide verifitseerimise kursus 27
SVA. Sequence operators: implication • S 1 S 2, i. e. ¬S 1 + S 1·S 2 • If S 1 becomes true at time t then start evaluating S 2, whose result determines the result of the implication. • If S 1 is false, then the implication is true. Digitaalsüsteemide verifitseerimise kursus 28
SVA. Sequence operators: throughout • S = {(Bi, Ti), i V} • E throughout S is{(E · Bi, Ti), i V} • E. g. (x 1 + x 2) throughout (##1 x 3 ##2 x 4) is equivalent to: (##1 (x 1 + x 2)x 3 ##2 (x 1 + x 2)x 4) Digitaalsüsteemide verifitseerimise kursus 29
SVA. Sequence operators: within • s 1 within s 2 checks whether s 1 is found in s 2 and whether both sequences are true • s 1 must begin after s 2 begins and end after the end of s 2! Digitaalsüsteemide verifitseerimise kursus 30
PSL. Property Specification Language Label When to check reqack: assert always (req -> next ack); Verification directive Property to be checked • Property Specification Language IEEE-1850 (2005) – Originated from Sugar (IBM), Accellera • Foundation Language (FL) – LTL, SERE – PSL Simple Subset for simulation • Time advances monotonically, it is finite, (operands restrictions) • Optional Branching Extension – CTL (for formal verification) 31
PSL. Property Specification Language • Flavors: – System. Verilog, Verilog , VHDL, System. C, GDL • 4 layers – Boolean layer –Boolean expressions in HLD: (a&&(b||c)) • Boolean operators: AND, OR, -> – Temporal layer – sequences of Boolean expressions over multiple clock cycles • Temporal operators (e. g. next_e, until, next_event) – invariance operators: always, never • SERE: ({A[*3]; B}|->{C}) Sequential Extended Regular Expressions – Verification layer - directives for verification tool telling what to do with specified properties • assert, assume, cover, restrict – Modeling layer – models environment 32
PSL Standardization Sugar created at IBM Haifa Research Labs FVTC formed in Accellera (OVI) 1994 1998 Syntactic sugaring of CTL Branching-time semantics plus regular expressions Jasper Design Automation© 2005 FVTC considers: Temporal e PSL CBV based on For. Spec Sugar 2. 0 Sugar 2001 Linear-time semantics Added to Sugar 2002 PSL 1. 01 Approved 2003 PSL and SVA alignment 33 PSL 1. 1 Approved IEEE 1850 PSL 2004 2005 PSL enhancements and clarifications
LTL • Linear-Time (temporal) Logic (first introduced in 1981) • No branches, time is a path 34
CTL • Computational Tree Logic (first introduced in 1977) – branching-time logic, meaning that its model of time is a treelike structure – there are different paths in the future, any one of which might be an actual path that is realized A[φUψ] == ( E[(ψ)U(φψ)] EG(ψ) ) • temporal operators: – – – – A φ - φ has to hold on all paths (starting from the current state) E φ - there exists at least one path (-”-) where φ holds. X φ - φ has to hold at the next state G φ - Globally: φ has to hold on the entire subsequent path F φ - Finally: φ eventually has to hold φ U ψ - φ has to hold until at some position ψ holds φ W ψ - Weak until: φ has to hold until ψ holds (= "unless". ) 35
What We can Express in LTL • All Boolean logic properties. “Process 2 is in the critical section” • next p – p holds in the next state. “Process 2 will be in the critical section in the next state” • eventually! p – eventually p holds. “eventually process 2 will enter the critical section” Jasper Design Automation© 2005
What We Cannot Express in LTL? • Counting example: “p is asserted in every even cycle” All the following traces satisfy this property !p, p, …. p, p, !p, p, p, p… • No linear-time temporal formula can express this property. Jasper Design Automation© 2005
Extended Regular Expressions • Extended regular expressions overcome some of the limitations in linear-time temporal logic’s lack of expressiveness. • They are a convenient way to define a temporal pattern that can match (or more aptly put, specify) sequences of states. • Regular expressions let us describe design behavior that involves counting. – Such as modulo n type behavior, with the * operator. • For example, the PSL extended regular expression: {a ; b ; [*3] ; c ; [*2: 3] ; d} Jasper Design Automation© 2005
What Cannot be Express with Regular Expressions The property: “eventually p holds forever” • The following property cannot be expressed with regular expressions: – “Eventually, p holds forever” !p !p !p p • Can be expressed in LTL. For example, in PSL: – eventually always p Jasper Design Automation© 2005
What We Can Express in LTL and CTL • “Always if req is received, then ack must be received sometime in the future” – LTL: G (req -> F ack) – CTL: AG(req -> AF ack) • Most useful properties are in the common fragment of LTL and CTL (Maidl, 2000). Jasper Design Automation© 2005
Vacuity • Vacuity is a philosophical concept (not specific to PSL) • Vacuous pass occurs if a passing property contains Boolean expression that, in frames of the given simulation trace, has no effect on the property evaluation. req ack PASSED req ack NOT FAILED ACTIVATED vacuous pass 41
PSL is a Layered Language Modeling Verification Temporal Boolean Jasper Design Automation© 2005 42
Boolean Layer q The Boolean layer is used to: o Specify logic expressions without specific timing information using a standard HDL syntax such as Verilog -HDL and VHDL Example (Verilog): // A and B are mutually exclusive ( !(A & B) ) Example (VHDL): -- A and B are mutually exclusive ( not (A and B) ) Jasper Design Automation© 2005 43
Temporal Layer q The temporal layer is used to: Specify when the Boolean expression must be valid o Remove time ambiguities o Example: // A and B are always mutually exclusive always ( !(A & B) ) q There are many temporal operators: always property o never property o next property o Jasper Design Automation© 2005 o until property o … 44
Verification Layer q The verification layer is used to: o Specify how to use the property: – Assertion to be verified against the implementation – Assumption to be used as constraint during the verification – Or functional coverage metric to improve the overall verification coverage Example: // A and B must always be mutually exclusive assert always ( !(A & B) ) ; Jasper Design Automation© 2005 45
Modeling Layer q The modeling layer is used to: o Write auxiliary HDL code required to specify complex properties q You can define HDL functions that are used in your properties, model complex FSMs or expressions Example: // If req is asserted, ack must be asserted the next cycle wire req; assign req = read. A_req || read. B_req; assert always (req -> next (ack && gnt)) ; Jasper Design Automation© 2005 46
PSL Layers wire req; assign req = read. A_req || read. B_req; assert always (req -> next (ack && gnt)) ; Boolean layer Temporal layer Verification layer Modeling layer Jasper Design Automation© 2005 47
PSL Sequences Jasper Design Automation© 2005 48
PSL Sequences q PSL sequences enable us to: o Describe a sequence of Boolean expression (that is, states) q PSL sequences are marked by curly braces ‘{’ and ‘}’ q Advancement of time occurs with each concatenation operator ‘; ’ Example: { req; busy; gnt } Jasper Design Automation© 2005 49
PSL Sequences Matching q A PSL sequence can have multiple matching diagrams Example: { req; busy; gnt } req busy gnt This diagram represents one possible match This diagram represents another possible match q To explicitly match the waveform, we would need to specify the following Example: { req && !busy && !gnt ; !req && !busy && gnt } Jasper Design Automation© 2005 req busy gnt 50
Temporal Operators for Sequences q PSL supports the following temporal operators for sequences: Overlapping implication o Non-overlapping implication o |-> |=> Example(s): sequence S 1 = { req; ack } ; sequence S 2 = { start; busy; end } ; // Event “start” occurs on the same clock cycle as “ack” property P 1 = always S 1 |-> S 2 ; // Event “start” occurs on the next clock cycle after “ack” property P 2 = always S 1 |=> S 2 ; Jasper Design Automation© 2005 51
Operators for SERE q PSL supports the following operators for SERE: o Repetition in n consecutive clock cycles [*n] Repetition in n non-consecutive clock cycles o Repetition for 0 or any number of clock cycles [=n] [->n] [*] Repetition for 1 or any number of clock cycles o Repetition for n to m clock cycles [+] [*n: m] o o q The number of repetitions must be a positive integer q Keyword inf stands for an infinite number of clock cycles Example(s): sequence S 1 = { rd[*5] } ; sequence S 2 = { rd[->3] } |=> { wr } ; // {!rd[*]; rd; !rd[*]; rd} sequence S 3 = { req} |=> { ack[=1]; done} ; // {!ack[*]; ack; !ack[*]} sequence S 4 = { rd[*]; rd; wr }; sequence S 5 = { rd[+]; wr } ; sequence S 6 = { rd[*2: 5] } |=> { wr } ; Jasper Design Automation© 2005 52
Example property P 1 = { req[+]; ack; wr[*4] } |=> { (wait && !req)[*]; done } ; assert always P 1; clock req 1 or more 0 or more ack write wait 0 or more done Jasper Design Automation© 2005 53
Example Properties are Derived from Specification Receiving Data: q When the reception of data is complete, then an interrupt should occur: property done_rcving_implies_int = always rose(done_rcving) -> rose(int) ; assert done_rcving_implies_int ; Jasper Design Automation© 2005 54
Example Properties are Derived from Specification Receiving Data: q If the signal that indicates a reception in progress is active, then it should remain active until the reception is complete: property rcving_until_done_rcving = always rose(rcving) -> (rcving until done_rcving) ; assert rcving_until_done_rcving ; Jasper Design Automation© 2005 55
Example RTL Implementation Queue q Design intent o“If Queue is full, then an attempt to insert data is ignored. ” (Overflow) o“If Queue is empty, then an attempt to remove data is ignored. ” (Underflow) q. Data. In q RTL implementation fragment: function [3: 0] q. Next; input [3: 0] p; q. Next = ((p + 1) mod `q. Size); endfunction; assign q. Full = (q. Next(q. Last) == q. First); assign q. Empty = (q. Last == q. First); … q PSL implementation assertions: q. Last 7 6 5 4 3 2 1 0 cntrl q. First q. Data. Out assert always (q. Full && q. Insert -> next !q. Empty) abort ~rst. N ; assert always (q. Empty && q. Remove -> next !q. Full) abort ~rst. N; Jasper Design Automation© 2005 56 q. Insert q. Remove q. Error q. Empty q. Full
Verification Units for Grouping Properties and Directives q Verification with PSL is based on using verification units vunit <name> [(<module binding>)] { <declarations and verification layer directives> }; Usually a separate file from RTL vunit Example: inputs outputs RTL module vunit my_unit (my_module) { default clock = posedge clk; assume never read & write; property P 1 = never (full & write); assert P 1; assert always (read -> ! empty); A vunit binds to a module or an instance }; Jasper Design Automation© 2005 57
Types of Assertions and PSL Expressiveness Data Integrity High-level requirements • End-to-end • Black box • Based on design intent • Generally require modeling+assertions Packet Ordering Design Intent RTL Implementation RTL implementation assertions • Localized • Implementation-specific • Generally can be expressed using only assertions One Hot Increment By 1 FIFO Overflow Design Behavior Jasper Design Automation© 2005 58
- Slides: 58