Protocol verification A good model is hard to find

1. Protocol verificationA good model is hard to find John O’Leary Murali Talupur Mark TuttleJin Yang with David James “Lookin’ for models in all the wrong places.Lookin’ for models in too many faces.Searching their eyes, looking for tracesof what I'm dreaming of.”(The tune sung by true Urban Cowboys everywhere)

2. How to do protocol verification • Protocol verification in “three easy steps” • Find an interesting protocol • Build a model of the protocol • Verify the protocol • Building the model can be the hardest step at Intel • See my last two talks at SCL for why [Leonard Tuttle 2006] • Our tools typically assume the existence of a model • Our work often ignores the problem of getting a model • We need to think hard about where models come from • “Who builds them, who owns them, who maintains them?” -Earlie • Wide-spread technology transfer won’t happen without an answer

3. The Superman approach • A single verification expert joins a group (late) • Learns the protocol • Builds the model • Maintains the model • Does the verification (finally) • This is the wrong approach • It doesn’t scale (very few supermen) • It burns out the supermen (leaving even fewer supermen) • It won’t get much past “technology demonstration”

4. We need a better approach • We need a cost-effective story for model building: • Write models our way • It doesn’t cost you any more (much more) than what you do now • And you get significant risk reduction from our analysis • Even better, accept their way as our way: • Make good use of design artifacts they produce now • MAS, state transition tables, block diagrams, pipeline diagrams, timing diagrams, message flows • Make it attractive for them to use what we produce • Elegant models of what is missing in the MAS

5. Protocol verification • Mission statement: • Delight engineering organizations by relentlessly reading their documentation and continuously asking questions about their intentions; • Build operational excellence by driving to increase clarity while ceaselessly pushing to decrease confusion; • Commit to deliver technology solutions that ensure Intel's leadership in model building, make model-buildingleadershiptechnology affordable, and fill the pipeline with pipeline models; • Intituitionalize the author of this mission statement.

6. Protocol verification • Project goals: • Verify an unusual cache coherence protocol at Intel • Learn to extract a formal model from a MAS typical of Intel • Talk outline: • The SIMPL cache coherence protocol and its MAS • A new tool for extracting a model from a MAS • An evaluation of this new tool vs other tools

7. S S S S S S S S SIMPL • A very unusual cache coherence protocol by David James: Cached copies maintained on a doubly-linked list • Shared/Invalid/Modifiable cache states on Pointer Lists • Scalable: constant directory size (flexible core tile layouts) • Efficient: optimized pairwise sharing, thread synchronization centralized directory distributed directory

8. - S S S I I Common flows straightforward Example: read exclusive invalidates shared copies ack M inval read data M

9. Efficient: pairwise sharing Supports producer-consumer without going to memory modified shared copy shared copy modified exclusive copy missing shared copy inval read Mh St Mp nSt Mh St pair data M M M producer writes consumer reads

10. S S S S S S S S S S - Tricky: deadlock avoidance Suppose cache at the head of list wants to flush its copy Suppose memory’s request queue is full head head doit ack head Piggyback doit request on ack response head Suppose new head’s request queue was also full? S ack’

11. SIMPL A big protocol: 37 cache states I F cS nS cSh nSh cSb nSb cSt nSt cM dM nM pM cMh dMh nMh cMp dMp nMp IH IS B R W cSMh cSMb nSMh nSMb cSM cSMt nSM nSMt dN dNb nNb dNt A big MAS: 300 pages

12. SIMPL MAS • A state transition table • What to do when a core issues a request • One of seven state transition tables

13. Preconditions Effects One state transition

14. What is this? A cache state Where does it come from? Another table! We should be able to use this!

15. Cache states We should be able to use this!

16. What is this? A function call Where does it come from? Another table!

17. What is this? Another function call Where does it come from? Another table! We should be able to use this!

18. What is this? Another function call Where does it come from? A table footnote! We should be able to use this!

19. MAS lessons learned • Observations • Tables depend on tables depend on tables depend on … • Every table likely to change, all must be first class objects • Every table is used in some context, need lexical scoping • Columns have a limited number of interpretations (almost) • Some hand coding required • Some state entirely missing or vaguely defined • Communication model, some data structures • If we model it, can it become part of the MAS? • Some clean up required • Typos, unusual notation, strange formatting artifacts • Many shorthands used: cPtr, tPtr • x = ECODE really means x = EXCL | x = MOD | x = …

20. Our solution • This is the dream: • A front end: extract formal models from design artifacts • A back end: extracts verification artifacts from the formal model • This is the current state: Murphi input from MAS tables MAS Transition tables Block diagrams Pipeline diagrams Timing diagrams MAS Transition tables FV tool input Murphi, MC/BMC SMT Theorem prover FV tool inputMurphi, MC/BMC Protocol state machine Protocol state machine DV reference models System Verilog SystemC Reference models Hand-coded modeling

21. Our solution • Other features • An internal model of the protocol state machine • A small, expressive collection of table column semantics • A system of rewrites to deal with • Columns not mapping cleanly into our semantics • Tables requiring clean up before interpretation

22. State machine model • A modeling language of types, expressions, transitions • currently looks like murphi, soon to look like unity written in ocaml • Model fragments built with help of a parser • parse_type “array[1..4] of boolean” ArrayType (RangeType (IntExpr 1, IntExpr 4), IdType "boolean") • parse_stmt “x := y” AsgnStmt (IdLval "x", LvalExpr (IdLval "y")) • parse_expr “rec.field = table[index]” CallExpr ("=", [LvalExpr (FieldLval (IdLval "rec", "field")); LvalExpr (IndexLval (IdLval "table", LvalExpr (IdLval "index")))])

23. This table could define a state transition function enum or record type What is the meaning of “cell” in column “hdr”? Test: hdr = cell Cell defines a comparison Set: hdr := cell Cell defines an assignment Eval: cell Cell is a predicate function Cell is a side-effecting function Null: string Who knows? Code by hand. Enum, FieldName, FieldType, … With a small set of canonical semantics, we can give meaning to any table Column semantics

24. Example: the table • Consider a table of predicates: • Name column is a predicate name • Row column is a junk column • All other columns are tests

25. Example: the column semantics [ {(Mapping.bindcol ["Name"]) with semantics = Bind [("Q1DO",unit -> boolean); ("Q1GO",unit -> boolean); ("Q0", unit -> boolean); ("Q0AF",unit -> boolean); ("Q0AT",unit -> boolean)] }; Mapping.nullcol ["Row"]; Mapping.testcol ["cqReq"; "code"]; Mapping.testcol ["cPtr"; "level"]; Mapping.testcol ["cPtr"; "aged"]; Mapping.testcol ["tPtr"; "done"]; Mapping.testcol ["tPtr"; "sleep"]; Mapping.testcol ["tPtr"; "code0"]; Mapping.testcol ["tPtr"; "fCode"]; Mapping.testcol ["tPtr"; "tCode"]; Mapping.testcol ["tPtr"; "body"]; Mapping.testcol ["tPtr"; "head"]; Mapping.testcol ["tPtr"; "tail"]; Mapping.testcol ["QC"] ]

26. Rewrite rules • Rewrite rules enable “tweaking” of • Column semantics: our semantics may not be exactly right • Table input: tables may require cleaning up before interpretation • Rewrite rules have two forms: • String based: Rewrite.regexp • Model based: Rewrite.expr, Rewrite.stmt, Rewrite.type, … • Rewrite rules are the foundation of our generality • Rewrite rules and canonical semantics combine well • balance need for clean semantics and extensible semantics

27. String rewrites

28. String rewrites

29. String rewrites

30. Model rewrites via matching

31. Model rewrites via matching

32. Model rewrites via matching

33. Model rewrites via matching

34. Model rewrites via matching

35. Model rewrites via matching

36. Model rewrites via matching

37. Example: table cleanup • Clean up column headers: • cqReq. → cqReq, cPtr-> → cPtr, tPtr-> → tPtr

38. Example: table rewrites Table.changeHeaders[ Table.rewriteHeader[ Rewrite.regexp "cqReq \\." "cqReq"; Rewrite.regexp "cPtr ->" "cPtr"; Rewrite.regexp "tPtr ->" "tPtr" ]] table

39. Example: tweak column semantics • Test column semantics not quite right: • tPtr.code0 = N should really be isNull(tPtr.code0) • cqReq.code = NN should really be not(isNull(cqReq.code)) • T and F should really be true and false

40. Example: semantics tweaks Rewrite.expr "x_ = N" "isNull(x_)"; Rewrite.expr "x_ = NN" "not(isNull(x_))"; Rewrite.rhs (Rewrite.expr "T" "true"); Rewrite.rhs (Rewrite.expr "F" "false");

41. Semantic maps Semantic maps give meanings to tables map = { name = “action name”; params = [action parameters]; filename = “file containing table”; headers = number of header rows; cleanups = [table rewrites]; uses = [handcoded declarations]; dependson = [semantic maps for other tables]; rewrites = [model rewrite rules]; cols = [column semantic dfns]}

42. Configuration files Configuration files build models from tables let handcoded = "declarations" let cachestates = {map for an enumeration type} let setup = {map for a function} let effects = {map for many functions … dependson = [setup]} let requestaction = {map for state transitions … dependson = [effects]; uses = [handcoded]} let model = new Environment let model = State.doTable model cachestates let model = Action.doTable model requestaction let _ = ppMurphi model

43. Tables aren’t everything • We are focused on tables because they are easy • Designers don’t do everything with tables • Block diagrams, timing diagrams, pipeline diagrams, message flows • We would like to use these artifacts, too, eventually • Our goal is to use all these sources to build a single model

44. Other table approaches • Table-based specification is not new • Parnas tables • Heitmeyer tables • Ptables by Chou, Mannava, and Park for CSI • Parnas and Heitmeyer focused on controls systems • Flight control system, nuclear reactor control, auto pilots • You have a set of inputs you can use to control a system • You have a set of sensors that monitor a system • For each input, how should you set it based on sensor readings? • Not a natural way to think about cache coherence protocols • Ptables are the closest to our work • And inspired our work!!

45. Ptable approach • Ptables are about • Extracting a textual state transition table from a design document • Assigning meaning to the table • Ptables take a table as written and do something with it • No language or GUI for building the table • No rigid philosophy about how protocols should be described • We buy this approach completely

46. Ptable approach • Semantic maps require writing a transformation“cell value” => “murphi fragment”for every cell value in the ptable • Ptables assemble these fragments into a murphi model • This approach is universal: there is a map for every table • It could be a lot to write (every test or assignment in the model) • It could be a lot to maintain for a protocol described like SIMPL • So much is in the supporting functions and not the table • And what if you don’t want to generate murphi any more?

47. Our approach • We interpret several kinds of tables • We build a real model • Potential for static analysis of the model • Potential for generating SystemC, Verilog, SMT questions,… • We have a set of canonical semantics for columns • Potential for static analysis of the maps themselves • We have a system of rewrite rules • Bridges the gap between • canonical semantics and arbitrary tables • our modeling language in tables and arbitrary tables • Provides a smooth trade-off between our way and their way

48. Our maps are expressive • A ptable semantic map might say mapping = [ (“cell value1” => “murphi fragment1”); (“cell value2” => “murphi fragment2”); (“cell value3” => “murphi fragment3”)] • Our semantic map would say Mapping.evalcol with semantics = Null [ Rewrite.regexp “cell value1” “murphi fragment1”; Rewrite.regexp “cell value2” “murphi fragment2”; Rewrite.regexp “cell value3” “murphi fragment3”]

49. Ptable map for one SIMPL column: mapping = [ ("B" => (cState = "B")); ("F" => (cState = "F")); ("I" => (cState = "I")); ("I, cS, nS, cSt, nSt cSb, nSb cSh, nSh cM, dM, nM cMp, dMp, nMp cMh, dMh, nMh" => (cState = "I") | (cState = "cS") | (cState = "nS") | (cState = "cSt") | (cState = "nSt") | (cState = "cSb") | (cState = "nSb") | (cState = "cSh") | (cState = "nSh") | (cState = "cM") | (cState = "dM") | (cState = "nM") | (cState = "cMp") | (cState = "dMp") | (cState = "nMp") | (cState = "cMh") | (cState = "dMh") | (cState = "nMh")]); ("R" => (cState = "R")); ("W" => (cState = "W")); ("cM, nM" => (cState = "cM") | (cState = "nM")); ("cMh, dMh" => (cState = "cMh") | (cState = "dMh")); ("cMp" => (cState = "cMp")); ("cMp, dMp" => (cState = "cMp") | (cState = "dMp")); ("cMp, nMp cMh, nMh" => (cState = "cMp") | (cState = "nMp") | (cState = "cMh") | (cState = "nMh")); ("cS" => (cState = "cS")); ("cS, cSt cSb, cSh cM, dM cMp, dMp cMh, dMh" => (cState = "cS") | (cState = "cSt") | (cState = "cSb") | (cState = "cSh") | (cState = "cM") | (cState = "dM") | (cState = "cMp") | (cState = "dMp") | (cState = "cMh") | (cState = "dMh")); ("cS, nS" => (cState = "cS") | (cState = "nS")); ("cSb" => (cState = "cSb")); ("cSb, nSb" => (cState = "cSb") | (cState = "nSb")); ("cSh" => (cState = "cSh")); ("cSh, nSh" => (cState = "cSh") | (cState = "nSh")); ("cSt" => (cState = "cSt")); ("cSt, nSt" => (cState = "cSt") | (cState = "nSt")); ("dM" => (cState = "dM")); ("dMp" => (cState = "dMp")); ("dMp, dMh" => (cState = "dMp") | (cState = "dMh")); ("nM" => (cState = "nM")); ("nMp, nMh" => (cState = "nMp") | (cState = "nMh")); ("nNb" => (cState = "nNb")); ("nS" => (cState = "nS")); ("nSb" => (cState = "nSb")); ("nSh" => (cState = "nSh")); ("nSt" => (cState = "nSt"))] Our maps can be simple

50. Our map for the same SIMPL column: Mapping.testcol Our maps can be simple