Operation-based formal verification (OFV) uses operation properties to formally verify VHDL designs at the register-transfer level. It constructs an abstract VHDL model from the code by identifying the start and end states of operations and the properties connecting them. Property checking and completeness tests are used to prove the equivalence between the VHDL code and abstract model, finding any errors. OFV supports the full verification process from pre-proof to proof to theory formation. It has been applied successfully to verify an industrial processor with over 100,000 lines of code. However, its adoption is limited by design practices focusing on integration rather than module construction, and verification methods relying more on simulation than formal analysis.

1. Theory, Practice and Perspectives of
Operation-Based Formal Circuit Verification
Wolfram Büttner
wolfram-buettner@aon.at
December 2012

2. Principles of Mathematical Work
Overall objective
- Construct mathematical object
- Document understanding of object in terms of theorems
Process of gaining understanding
- Pre-proof: Set up hypothesis, constraints, assertions
- Proof: Prove hypothesis or adjust hypothesis, constraints, assertions until proof succeeds
- Theory formation: Develop hierarchy of theorems to achieve good understanding of object
Formal verification
- Analyze mathematical models capturing key functionality of technical systems – most
important models are FSM‘s describing discrete control
- Emphasis is on finding errors – proof as termination criterion for successful verification
- Automated proof is essential for acceptance in Engineering
- Automated proof is necessary, but is it sufficient for a good verification solution?
December 2012
Page 2

3. Model Checking: Automated Debugging/Proof
Temporal Logic as Property Description Language for FSM‘s
AGp - p holds for all EGp - p holds for all AFp - p holds for some
states of all traces states of some trace state in every trace
More complex properties
e.g. AG(p AFq), AGAFp, AGEFp
EFp - p holds for some
state in some trace
December 2012
Page 3

4. Model Checking: Automated Debugging/Proof
Does temporal logic formula hold for FSM ?
AGp - p holds for all Basic Model Checking:
states of all traces if p does not hold for z0 then reset activation defines counterexample,
else for i > 0 … {
• calculate Zi+1
z0 • if Zi+1 = Zi proof holds, stop else
• examine all new z that can be reached from Zi in one step
if p does not hold for z then calculate trace to z,
stop
}
}
z0 = reset state
Z0 = {z0} Symbolic Model Checking:
…. • Identify sets Zi with their characteristic (Boolean) functions
Zi+1 = Zi plus new • f Boolean then f(x1, …, xn) = ite (x1=1, f(1, ……, xn), f(0, …… , xn))
states reachable • Iterated decomposition represents f as directed acyclic graph (BDD)
from states in Zi • Graph is often compact; permits efficient build-up of Zi, comparison
in one step of Zi and Zi+1 and intersection of Zi+1 with set of states violating p
December 2012
Page 4

5. Model Checking: Automated Debugging/Proof
Assessment
Status of approach
• Best known automated formal verification paradigm
• Bound to be an add-on to conventional simulation-based testing
• Applied in various domains by experts verifying critical functionality – no
generally accepted engineering practice
• Often faces state-explosion requiring problem specific abstractions
• Finding safe abstractions requires deep knowledge of tool and application
Conclusions
• Push-button verification solution based on MC works only for simple properties
• Additional support of „process of gaining understanding“ is essential for broad
acceptance of formal verification in industry
• In early 1990s new circuit verification approach emerged supporting pre-proof,
proof and theory formation – OFV (operation-based formal circuit verification)
December 2012
Page 5

6. OFV: Running Example - Memory Controller
Processor
request rw address wdata rdata ready
SDRAM Controller
(for e.g., DDR 2 RAMs)
sd_addr sd_wdata sd_ctrl sd_rdata
SDRAM
December 2012
Page 6

7. OFV: Operation Properties/Abstract VHDL
sd_ctrl <= nop; req = '0' / pnop / mnop
ready <= '0'; sd_ctrl <= nop; reset
ready <= '0'; IDLE
reset
req = '1' / pwrite(R,C,D) /
sd_ctrl <= activate; activate(R),
sd_ctrl <= nop; idle pnop / pread(R,C) /
sd_addr <= row(address); mwrite(C,D),
ready <= '0'; precharge activate(R) &
last_row <= row(address); actrow <= R
mread(C),
ready <= '0';
pread(R,C) actrow = R
pwrite(R,C,D)
and R = actrow /
(req = '0' or ROW_ACT and R = actrow /
sd_ctrl <= nop; mread(C)
row(address /= mwrite(C,D)
ready <= '0'
last_row) / pwrite(R,C,D)
sd_ctrl <= row_act
req = '1' and rw = '1‚ pread(R,C) and R ≠ actrow /
precharge; and row(address) and R ≠ actrow / precharge,
ready <= '0'; = last_row / precharge, activate(R),
sd_ctrl <= read; activate(R), mwrite(C,D),
sd_addr <= col(address) mread(C), actrow <= R
ready <= '0'; actrow <= R
(req = '1' and rw = '0'
and row(address) = t T
last_row) / sd_ctrl <= nop;
sd_ctrl <= write; state ROW_ACT
ready <= '0';
sd_addr <= col(address); actrow R
ready <= '1'; request R ≠ actrow
sd_wdata <= wdata; sd_ctrl <= nop; rw
ready <= '0'; ready
address R,C
rdata D
rdata <= sd_rdata; wdata
ready <= '1'; sd_ctrl prech nop activate nop read nop nop
Sd_ctrl <= nop;
sd_addr R C
sd_ctrl <= stop; sd_rdata
ready <= '0'; sd_ctrl <= nop; D
ready <= '0'; sd_wdata
December 2012
Page 7

8. OFV: Formal Verification of Single
Operation Property
Verification of single operation property is reduced to SAT-problem
• A = A(z0, Z, I, O, R(z0, Z, I, O)) (Mealy automaton of VHDL program)
R defines transition equations zj+1 = zj+1(zj, ij), oj = oj(zj, ij) (polynomials in zj, ij)
• P = P(it, it+1, …, it+n, zt, zt+1, … zt+n, ot, ot+1, …, ot+n) ε { True, False}
Property describes behaviour of an operation over n cycles (usually n ≤ 50)
• By inserting transition equations of A into P a property P‘ of A arises with
P‘ = P‘(it, it+1, …, it+n, zt)
• Application of SAT solver:
P holds for A iff P‘ = True otherwise solver computes trace T (counter example)
triggered by it‘, it+1‘, …, it+n ‘ such that T starts at zt‘ and P fails for T
• Complexity shifted from BDD representation to SAT search; heuristics deal with
many thousand variables; few properties run longer than 5 minutes
December 2012
Page 8

9. OFV: Methodology to Systematically Find
Operation Properties
Review VHDL/spec and automatically verify identified behavior
• Verification engineer searches in VHDL for start and ending states of operations
of abstract VHDL
• Incremental build-up of these states and connecting operations by firstly
inspecting state machine (s) of code and then taking data path into account:
– Suspected (stage of) operation is formalized by – possibly partial - operation property
– Property checking reveals errors or ensures correct behavior of code fragments
• This way engineer walks through code, operation by operation, and covers
behaviour of VHDL by operation properties
• Review stops once automated completeness check confirms coverage of full
functionality of code by properties
• Productivity: 2000-4000 lines of fully verified VHDL per person month
December 2012
Page 9

10. OFV: Completeness of Set of Operation
Properties
Set of operation properties of an automaton A describing a VHDL program is
complete iff for every input trace of A a chain of properties exists which uniquely
determines A‘s output trace – i.e. A and its Abstract VHDL have same I/O behavior.
In order to gap-free chain operation properties for any such property P its ending
and starting states must comprise conditions which permit tests ensuring
completeness of a property set:
For every property P
1. and for every input stimulus there exist successor properties Qi such that the ending state
condition of P fulfills the starting state condition of Qi (successor test)
2. and for every input stimulus any successor Qi of P uniquely determines the output trace in
the considered interval (determination test)
3. the input conditions of the successors Qi of P cover all possible inputs (case split test)
Similarly as for property checking completeness tests amount to solving SAT problems
December 2012
Page 10

11. OFV: Success Story
Operation-Based Formal Verification of Large Industrial Processor
• Verisoft-Project funded by German Ministry
MMU FPU
Data
for Education and Research to challenge
Program
TriCore 1.3 formal techniques
Interface
Cache
Interface
Cache
Program Core Data
Scratch RAM Scratch RAM • Testcase due to Verisoft-Partner Infineon:
Program Bus Interface Unit Data
Scratch RAM Scratch RAM – New superscalar 32-bit microcontroller-DSP, 3
pipelines, 850 instructions
Interrupt &
Interrupts
Debug Unit – Around 100k lines VHDL/1000 pages spec
Other IP Crossbar (64 bit) Other IP – Widely used in automotive applications
• Effort: 4 PY vs. significantly higher effort
Bridge needed for simulation
• Critical bugs found by OFV in spec and RTL
System Bus
• 1532 properties; 5 processes; 30 k lines of
formally verified
property code
Source: Infineon; Verisoft project 2007 • Correctness proven on single WS in 5 days
December 2012
Page 11

12. Chip Development and Main Hurdle for OFV
Early phase
• set up/assess functional prototypes
Architecture
• explore architectural choices
• specify modules and communication for
target architecture
Design
• Development and verification or re-use of
modules (e.g. VHDL programs)
• Verification engineers used to black-box
verification (random test generation)
• system integration, communication
structures
Lower-Level Activities
• Automated implementation of logic firstly
by gates then by transistors
• Generation of production data and tests
December 2012
Page 12

13. Further Perspectives of Abstract VHDL
Operation-Based Design, Optimization wrt. Area, Speed, Power,
Functional Safety Analysis
sd_ctrl <= nop; req = '0' / pnop / mnop
ready <= '0'; sd_ctrl <= nop; reset
ready <= '0'; IDLE
reset
req = '1' / pwrite(R,C,D) /
sd_ctrl <= row_act; activate(R),
sd_ctrl <= nop; idle pnop / pread(R,C) /
sd_addr <= row(address); mwrite(C,D),
ready <= '0'; precharge activate(R) &
last_row <= row(address); actrow <= R
mread(C),
ready <= '0';
pread(R,C) actrow = R
pwrite(R,C,D)
and R = actrow /
(req = '0' or ROW_ACT and R = actrow /
sd_ctrl <= nop; mread(C)
row(address /= mwrite(C,D)
ready <= '0'
last_row) / pwrite(R,C,D)
sd_ctrl <= row_act
req = '1' and rw = '1‚ pread(R,C) and R ≠ actrow /
precharge; and row(address) and R ≠ actrow / precharge,
ready <= '0'; = last_row / precharge, activate(R),
sd_ctrl <= read; activate(R), mwrite(C,D),
sd_addr <= col(address) mread(C), actrow <= R
ready <= '0'; (ready <= '1') actrow <= R
(req = '1' and rw = '0'
and row(address) = t T
last_row) / sd_ctrl <= stop;
sd_ctrl <= write; state ROW_ACT
ready <= '0';
sd_addr <= col(address); actrow R
ready <= '1'; request R ≠ actrow
sd_wdata <= wdata; sd_ctrl <= nop; rw
ready <= '0'; ready
address R,C
rdata D
rdata <= sd_rdata; wdata
ready <= '1'; sd_ctrl prech nop activate nop read nop nop
ctrl <= nop;
sd_addr R C
sd_ctrl <= stop; sd_rdata
ready <= '0'; sd_ctrl <= nop; D
ready <= '0'; sd_wdata
December 2012
Page 13

14. Summary
• Modules are built to implement operations - often computing results within few cycles.
• Functional essence of an operation is captured by concept of operation property.
• Start/end states of operations and operation properties define abstract automaton -
tool-supported code review extracts this Abstract VHDL from VHDL and spec.
• SAT-based property checking and completeness tests guarantee functional equivalence
between VHDL and Abstract VHDL or reveal errors in code or spec – respective tools
are supported and marketed by OneSpin Solutions GmbH.
• OFV is a full verification solution supporting pre-proof, proof, theory formation -
reliably yields top quality at reasonable effort.
• Two barriers prevent OFV from entering mainstream engineering:
– Chip manufacturers now focus on system construction – most modules exist as re-use blocks
– Verification engineers got used to black box verification - automated random test simulation
• Way forward: Operation-based design, exploitation of full potential of Abstract VHDL
Reference: J. Bormann: "Vollständige funktionale Verifikation", Dissertation, TU Kaiserslautern, 2009
December 2012
Page 14

15. Danke!
December 2012
Page 15