Stop Writing Assertions! Efficient Verification Methodology

1. Stop Writing Assertions!Efficient Verification Methodology Dave Whipp – DVClub SV, August 2008

2. Todays Talk • An Overview of Methodology Creation • Methodology as User Interface • Making ESL work as a Hardware Design Flow • Evolution of a Interface Definition Language • Transaction Level Assertions • Transaction Level Debug

3. A HW Development Flow Big Paper Spec ISS Model Verification Coverage Debug Design Checkers Testbench Tests RTL Synthesis Clocks, Resets Directed C Model Assertions BFMs, Assertions Random TLMs Scoreboard Formal

4. User Model for Running Tests Run Predictor Build Testbench * Generate Test Compare Behaviors Run DUT

5. Part 1 Methodology Design

6. Purpose of a Flow • Conceptual Framework • Where do things live? • How do things work? • Keep out of the way • Don’t make life difficult for people • Define Metaphors • Subtly influence future directions • Anchor for Variation • Give people something to complain about

7. Two Philosophies • Conformity • Emphasize Standardization • Diversity • Emphasize Innovation • Synergy or Conflict?

8. Understanding Variation • To understand what to standardize: • you need to understand what not to standardize • Personal Preferences • Technical Aspects of the Designs • Supporting Legacy • Seeking the Next Big Thing

9. Personal Preferences Emacs! vi

10. Personal Preferences • Choice of editor doesn’t affect others • At least, not much • Choice of scripting language has greater impact • But is encapsulated • A script’s users don’t see the implementation language • Choice of HVL affects whole team • Can’t write “E” tests for a “Vera” testbench! • But a unit testbench isn’t seen by other units • A good flow will allow encapsulation of preferences • I can go to any unit and build & run its tests • Enables rapid localization of infrastructure issues

11. Technological Differences

12. Technical Characteristics PCIE Graphics Pipe Frame Buffer Video Off-chip Memory

13. Reuse Vs Stagnation • Reuse considered Good • Avoid reinventing the wheel • Build on the shoulders of giants • Reuse invites Inertia • Reuse can propagate dependencies • Dependencies make things harder to change • Resistance to change is known as inertia • Inertia can lead to Stagnation • Improper reuse accumulates dependencies • Reused code that is not understood will bit-rot • To avoid stagnation, inject agitation

14. Are Single Paradigm Projects Possible? Paradigm 1 Unit A Unit B Unit B Unit B Paradigm 2 Unit C Unit C Paradigm 3 Unit D time Project 1 Project 2 Project 3

15. Watch some Real Users Image courtesy of DAZ Productions

16. How to “Watch” Users • Meetings and Discussions • Coffee-Break Grousing • Bug Reports • Keep Track of Support Requests • create FAQs • VNC (Remote Desktop) • Instrumentation

17. Build Time Distribution: 10,000 per sample

18. Build Time Distribution: 1000 per sample

19. Part 2 ESL for Transaction Design

20. A HW Development Flow (BAD) Big Paper Spec ISS Model Verification Coverage Debug Design Checkers Testbench Tests RTL Synthesis Clocks, Resets C Model Directed Assertions BFMs, Assertions Randoms TLMs Scoreboard

21. A HW Development Flow (BAD) Big Paper Spec ISS Model Verification Coverage Debug Design Checkers Testbench Tests RTL Synthesis Clocks, Resets C Model Directed Assertions BFMs, Assertions Randoms TLMs Scoreboard

22. A HW Development Flow (Better) Small Paper Spec Coverage Triage ISS Model ESL Verification C Model Debug Testbench Randoms Interfaces Validation Design Assertions Scoreboards TLMs RTL BFMs Assertions Directed Tests Clocks, Resets Synthesis

23. Who Writes Assertions? • Designers • Bottom Up Assumptions • Verification Engineers • Top-down Intent

24. Who Writes Assertions? • Designers • Bottom Up Assumptions • Verification Engineers • Top-down Intent • Architects • The Specification • Top Down Assumptions • Bottom Up Intent

25. Where to Write Assertions • The RTL • Inline • Bound • The Testbench • Scoreboard • Environment • E.g. Post Process Log file

26. Where to Write Assertions • The RTL • Inline • Bound • The Testbench • Scoreboard • Environment • Post Process Log files • The Specification • C Models (?)

27. Where To Write Specification Assertions Functionality Model RTLDesign Performance Model

28. Where To Write Specification Assertions ISS Model Transaction Model Correlation Model RTLDesign Performance Model Debug/Triage Model

29. Where To Write Specification Assertions Transaction Model Structural Model RTLDesign Performance Model

30. Interfaces Vs State • Two approaches to comparing models: • Compare “Architectural State” • Registers/flops within the design whose existence is required by the specification • Compare externally visible behavior • Compare interface traffic • B. F. Skinner?

31. Birth of an IDL • Interface Description Language • Initially, a language just to define signals Interface a2b clock clk down U valid 1 up U busy 1 down U cmd 24 down U data 32

32. Evolution of an IDL • Quickly added flow-control protocol abstraction Interface a2b clock clk flow valid_busy down U cmd 24 down U data 32 • From this we can generate: • Testbench components (BFMs: producers, consumers) • Protocol Assertions • …

33. Continued Evolution of an IDL • Separation of packet structure from interface group SOP down U cmd 24 group MOP down U data 32 group EOP down U checksum 32 Interface a2b clock clk flow valid_busy packet SOP, MOP, EOP

34. Transaction Assertions in YACC valid_interface_traffic: | valid_interface_traffic transaction; transaction: begin middle end; begin: SOP; middle: | middle MOP; end: EOP

35. Cycle Level Assertions in SVA clk cmd • sequence valid_trans; (cmd==SOP) (##1 cmd != SOP && cmd != EOP) [*0:$] ##1 cmd == EOP endsequence • a_well_formed_transaction: assert @(posedge clk) cmd == SOP |-> sequence (valid_trans) SOP EOP MOP MOP

36. Transaction Level Assertions in SVA clk valid cmd • sequence valid_transaction; (cmd==SOP) (##1 cmd != SOP && cmd != EOP) [*0:$] ##1 cmd == EOP endsequence MOP MOP SOP EOP

37. Transaction Level Assertions in SVA clk valid busy cmd • event sample; • always @(posedge clk) if (valid && ! busy) -> sample • assert @(sample) cmd == SOP |-> sequence (valid_transaction) MOP MOP SOP EOP

38. Transaction Level Assertions in SVA clk valid busy cmd • event sample; • always @(posedge clk) if (valid && ! busy) -> sample • assert @(sample) cmd == BEGIN |-> sequence (valid_transaction) MOP MOP SOP EOP

39. Grammer using IDL assert “temporal representation” data SOP => past( EOP ) data MOP => past( SOP | MOP ) data EOP => past( SOP | MOP ) assert “bnf representation” bnf SOP -> MOP ** past( SOP.length-1 :sample( SOP ) ) -> EOP

40. Multi-Unit Assemblies A B C D E F G a2b b2c c2d d2e e2f f2g A simple pipeline

41. Multi-Unit Assemblies a2b b2c c2d A B C D E F G d2e e2f f2g Simple rearrangement

42. Multi-Unit Assemblies a2b b2c c2d A B C D E F G d2e e2f f2g Identify units with similar behaviors

43. Multi-Unit Assemblies cf2d d2be BE CF D be2cf a2be A cf2g G Extract common behavior into unified components be2cf === b2c + e2f

44. Reusing Interface Definitions A B C D E F G BE CF D A G How to maximize reuse between these two architectures?

45. Packets as Traffic Streams group b2c down U data 32 group e2f down U data 32 Interface be2cf clock clk flow valid_credit packet b2c, e2f

46. Time Units of Temporal Expressions Group b2c down U value 4 assert value != past( value ) Group e2f down U value 4 assert ( value == 0 ) => ( past( value ) != 0 ) Interface be2cf packet b2c, e2f assert b2c => ( b2c.value != past( b2c.value :sample(b2c) ) ) assert past( e2f && e2f.value == 0 ) => (b2c && b2c.value != 0)

47. Example Renderer Memory

48. The Traffic group mem_write down U address 16 down U data 1 group sync down U shape 2 enum SQUARE, CIRCLE, TRIANGE, BLANK down U radius 3

49. Accumulate Memory State group mem_write down U address 16 down U data 1 assign mem[ x = 0 .. 15 ][ y = 0 .. 15 ] = past( data :sample( address == {x,y} ))

50. Add Predicates group_more mem_write assign is_circle[ r = 0..7 ] = “&&”( [ x = -8 .. 7 ] [ y = -8 .. 7 ] mem[ x+8 ][ y+8 ] == ( x**2 + y**2 <= r**2 ) )