Hardware/Software Co-design Formal Verification Techniques

1. Hardware/Software Co-designFormal Verification Techniques Chung-Yang (Ric) Huang 黃鐘揚 http://cc.ee.ntu.edu.tw/~ric April 20, 2004

2. Gate GDSII RTL Design Creation Design Implementation Physical Implementation Functional Specification Design Flow RTL Gate GDSII What is Design Verification? To verify the correctness of your design (Find as many design bugs as possible)

3. Where are the Bugs? • Functional specification • English/Algorithms  Timing diagrams, system or behavior-level descriptions • Design creation • Inconsistent with spec • RTL coding error (typo, X, logical error) • Assumption on the environment • Design/Physical implementation • Synthesis tools • Manual optimization

4. Gate GDSII RTL Design Creation Design Implementation Physical Implementation Functional Specification Design Flow RTL Gate GDSII What is Design Verification? To verify the correctness of your design (Find as many design bugs as possible)

5. Design Specification Design Creation Design Implementation Chip Manufacture Verification vs. Testing High-level spec RTL design Synthesis/P&R ICs Testing Verification • Object  design • Methodologies • Simulation • Emulation • Formal techniques • Object  chip • Methodologies • ATPG • Fault Simulation • Scan / BIST

6. Types of Verification • Functional (Focus in today’s lecture) • Consider functional correctness only • Usually doesn’t consider timing (i.e. 0-delay model) • Sequential circuit (i.e. multi-cycles) • Timing • Reg-to-reg timing constraints • Clock domain checking • Physical • Layout vs. Schematics (LVS) • Design Rule Checking (DRC) • Signal integrity

7. How do you verify/debug your design?

8. A “Typical” Verification Practice • Defining spec --- Chief architect or manager (or sometimes designer) • Verified by proof-reading • Write a behavior model and verify by simulation • RTL coding • Designer writes the testbench for his blocks • Designer writes/copies the behavior level model of the surrounding blocks • Verification engineer creates the verification environment (tool integration, scripts, etc) • Designer/Verification engineer runs the RTL simulation • Designer fixes the bugs • (maybe) Designer/Verification engineer writes more testbenches

9. A “Typical” Verification Practice • Synthesis to gates • Designer/Verification engineer runs the gate level simulation • Very slow (e.g. 2 frames a week) • Designer/Verification engineer maps the design to emulator (FPGA) and run the simulation • Very expensive

10. Yes, most people verify their designs by simulation and debug by looking at the waveforms

11. - diff ? Verify by Simulation 1 0 0 0 1 1 1 0 1 0 0 0 1 0 1 1 0 1 1 0 0 1 Circuit 01100011 11000011 11000011 01100011 expected result

12. Any Problem? Whose Problem? “My biggest problem about design verification is that the time is never enough. I can only do my best to run more simulation, but I don’t know whether it is sufficient.” --- Broadcom designer (similar comments from many others) “It is very hard to write the testbenches and assertions for the design, since I am not a designer. Ask the designer to do it more? No way!!” --- Sun Microsystems verification engineer (similar comments from many others)

13. What are the problems? • Gap between designers and verification engineers • (For designers) I thought I have fixed all the bugs… • (For verification engineers) Find ways to understand the design better • Verification methodologies are not optimal • Need to learn more alternatives Verfication usually takes up to 70% of resource during the design flow

14. Let’s do some math • Suppose a circuit has 100 registers (this is considered tiny in modern design) • Total number of states = 2100 = 1030 = 1024M • Requires (in the worse case) at least 1024M cycles to exhaust all the possible states • Let alone the input combinations • Running simulation (million cycles per second) can only cover a very small portion of state space

15. “100%” Verification Question: is there “100%” verification? Try: Run the simulation for a very long time • Coverage the entire state space? • Eventuality type of properties • e.g. At the crossroad, every car should see the green light eventually More about “100%” verification later… in 2 minutes

16. Any alternative to simulation?

17. Formal Verification • Comparison with simulation • Simulation • Input  output  compare expected result • Formal • Expected behavior  property  prove

18. What is “expected behavior”? What is a property?

19. P P P P P P 0 0 Observability Problem • Bugs are detected at the observation points like POs and registers assert always (count < 16); P P P P P P P 0 assertion Output 1 1 0

20. Observability Problem • Insert “assertions” in the middle of the circuit, and flag the simulator whenever the violation occurs • Increase the observability of the bugs The difference between hardware and software simulations

21. Properties in a Circuit • Describe the expected behavior of signals in a circuit • Assertion (always): something bad should never happens • Witness (eventually): something good should eventually happens • Temporal logic (property in general) • Logic + temporal operators (always, eventually, until, etc) • Can be nested • e.g. eventually (always (req  ack within [0: 12])) • However, 90% of important properties are assertions!!

22. Assertion-Based Verification (ABV) • An emerging methodology in design community to boost verification efficiency • Requires designers to write “assertions” in the design • Assertions can be reused as verification IPs (VIPs) • Also a good way to document the design • Simulators and formal verification tools to support the assertion languages

23. Objectives of Writing Assertions • To find as many bugs as possible • “100%” verification?  Do I write enough assertions? (Forget it!!) • Which one is golden? Spec?  What if there is a bug in spec? (Who knows) • A difficult-to-prove assertion is a good assertion? (NO!!) Write assertions to facilitate bug hunting

24. “Where am I going to find time to write assertions? I don’t even have time to write comments!” --- Conexant design engineer

25. Open Verification Library (OVL) • A HDL library containing predefined assertion modules • Assert_always • Assert_never • Assert_next • Assert_frame • Assert_handshaking • Assert_cycle_sequence • etc

26. OVL Example module assert_always (clk, reset_n, test_expr); input clk, reset_n, test_expr; always @(posedge clk) begin if (reset_n != 1'b0) begin if (test_expr != 1'b1) begin ovl_error(""); end end end endmodule

27. OVL Usage • Instantiate OVL assertions in your design • assert_always short_is_smaller_longer (clk, reset_n,(short_timer_v < long_timer_v)); • Can use `define to bypass synthesis of OVL • Can run OVL with both simulation and formal verification tools • Synthesizable subset (http://www.verificationlib.org/)

28. Assertion Languages • OVL is easy to use, but not flexible enough for general temporal properties • Lack of temporal constructs/keywords • Property specification language • To describe assertions in temporal logic • e.g. • PSL/Sugar (IBM origin, picked as IEEE standard by Accellera EDA Standards) • OpenVera/ForSpec (Synopsys/Intel)

29. PSL/Sugar Simple Examples • Boolean expression • ena || enb • Sequential expression • {req;ack;!cancel} • sequence BusArb (boolean br, bg; const n) = { br; (br && !bg)[0:n]; br && bg }; • endpoint ActiveLowReset (boolean rb, clk; const n) = { rb!=1'b1[*n:inf]; rb==1'b1 } @(posedge clk); • Assertion • assert always {req;ack;!cancel} (next[2] (ena || enb));

30. PSL/Sugar Availability • A very complete (yet, very complex) property specification language • Ref websites: • http://www.haifa.il.ibm.com/projects/verification/sugar/ • http://www.pslsugar.org/ • Many companies have announced to support PSL/Sugar for simulation or formal verification tools

31. OpenVera • Fully supported in Synopsys’ verification tool flow • VCS simulator • Formal verification tools • Originally: Vera • Bought from a startup company • Testbench authoring • Verilog-like language

32. OpenVera (cont’d) • Not just a property specification language, but a high-level verification language • Testbench authoring: • Specify input stimuli • Expected output response can be computed at high-level of abstraction (circuit model) • Test fixture for generating tests and checking results • Random or constrained testbench generation • Support coverage metrics • Interfaces to HDL and C • Able to specify various temporal properties • Object oriented: encapsulation and inheritance

33. a > always (a > b) b Property Added to a Circuit 0 1 0 1 1 0 1 1 0 0 1 Circuit 01100011 - 01100011 diff ? expected result

34. Formal Verification • No testbench required • Expected behavior  property  prove • Using logic and mathematic algorithms (formal verification engines) to “prove” that the property always holds w.r.t. circuit under test • If property passes, a complete verification • If property fails, generate a counter-example for debugging

35. For example • Proving “always (a > b + c)” • Simulation needs to enumerate all the possible combinations of a, b, and c • But, consider circuit is just a set of logic relations of input signals • Imagine in a math test, given a set of logic relations and asked to prove (a > b + c) • Try to use logic and math reasoning (e.g. induction)

36. Solving logic / temporal relations between circuit signals… A constraint satisfaction problem

37. Constraint Satisfaction Problems • Constraints • Logic: y = a && b; • Mux: y[31:0] = en? a[31:0] : b[63:32]; • Arithmetic: y = (a > b)? (c + d) : (c * d); • Relational: (x1 << 1) + x0 >= 256; • Constraint Satisfaction • Find an input assignment that satisfies all the constraints • Note: solutions in modular number systems

38. Constraint Satisfaction Solver • Solving techniques • Boolean: SAT, ATPG, BDD, etc. • General: arithmetic solvers • Examples of Applications • Testbench generation (Find a solution) • Assertion validation (Prove no solution) • Optimization problems (+ Cost functions)

39. INPUTS OUTPUTS Combinational Logic Sequential vs. Combinational Properties • In general, the counter-example for a property is a “sequence of input assignments” • One assignment for each clock cycle • Need to solve constraints multiple times • Iteratively, or • Recusively Property

40. To simplify discussion… Let’s focus on combinational property first (i.e. logic functions only, no temporal relationship)

41. How to solve the logic constraints? • Substitution / elimination method • Starting from constraints containing primary inputs (PIs)  substitute variables with input constraints • Continue the substitutions until get a conflict or result in a single constraint (i.e. only PIs) • Find an input assignment • The problem is: • Substitution is not always possible • Step 3 is still very difficult

42. Represent the combinational property (a logic function) using PIs…

43. Function Representation • In general… • f = (a && b || ((c + d) > e)) ^ !g && (a > b)?... • Not canonical • Enumeration (Truth table) • e.g. a1 a0 b1 b0 f ------------------- 0 0 0 0 0 0 0 0 1 1 ……… 1 1 1 0 1 1 1 1 1 0 • Exponential growth in size (like simulation) • But, once we have the table, finding an assignment is easy • Canonical

44. A better data structure to represent truth table?

45. target function a = 1 c c c c input variables a = 0 function = 1 function = 0 Binary Decision Tree f • Still exponential in size a b b 1 0 0 1 1 0 0 1

46. c c c c 0 1 1 0 Binary Decision Diagram f a b b 1 0 0 1

47. 1 0 Reduced Binary Decision Diagram f a b b c c

48. Binary Decision Diagram (BDD) • A graphical representation of truth table • f = func(a, b, c, d, …) is a logic function • Each level corresponds to an input variable  Set of inputs is called “support” • Functions with identical functions are merged together • Always canonical • Each node (and its sub-graph) represents a function • Each path represents a cube of the function

49. f Basic BDD Operations • Shannon expansion of f • f = x * fx + x * fx • f * g = (x * fx + x * fx) * (x * gx + x * gx) = x * (fx * gx) + x * (fx * gx) • f + g = x * (fx + gx) + x * (fx + gx) • Operation: perform on cofactors individually fx _ - x fx _ _ _ _ _ _ _ _ _ 0 1 _ _

50. c 1 0 b a a a 1 0 f = b b b b c c c c 0 0 1 1 1 1 0 0 1 0 f = a && b f = a && c Basic BDD Operations f = c OR OR f = a&& (b || c) f = (a && b) || (a && c) f = b || c