150 likes | 216 Views
The Temporal Logic Sugar. Cindy Eisner joint work with: Ilan Beer, Shoham Ben-David, Dana Fisman, Anna Gringauze, Yoav Rodeh. IBM Research Laboratory in Haifa. Outline. History Current status The Sugar language Examples. History.
E N D
The Temporal Logic Sugar Cindy Eisner joint work with: Ilan Beer, Shoham Ben-David, Dana Fisman, Anna Gringauze, Yoav Rodeh IBM Research Laboratory in Haifa
Outline • History • Current status • The Sugar language • Examples
History • Sugar was developed at IBM Haifa Research Lab as the specification language of RuleBase • 1994: syntactic sugaring of CTL • 1995: a linear part was added • 1996-2000: evolved gradually according to needs of users • This is the first complete description of the language
Current Status • Specification language of IBM FV toolset • Used for: • formal verification (RuleBase) • automatically generated simulation checkers (FoCs) • Extensive user base both within and outside of IBM
The Sugar Language - Overview • Contains both branching and linear constructs. • CTL • SERE: Sugar Extended Regular Expression • Extensive syntactic sugaring
The Sugar Language – SEREs • Sugar Extended Regular Expressions • Why extended? • more operators than regular expressions • built from boolean expressions over the atomic propositions • {p & q, r | s[*], t & u | v} • Engineers find SEREs to be a natural way of expressing specifications shown as timing diagrams
The Sugar Language – SEREs (cont.) • Sugar Extended Regular Expressions • Built from boolean expressions: • If r, r1, and r2 are SEREs, then so are: • r1, r2 concatenation • r1 || r2 union • r[*] closure • r1 ~ r2 overlapping concatenation • r1 && r2 intersection • Note: a single SERE is not a formula
The Sugar Language • CTL • Extensions: • {r1} | {r2}! r1 must be followed by r2 (r2 must “reach its end”) • {r1} | {r2} r1 must be followed by r2 (r2 may not “reach its end”) • {r}(f) f must hold on final state of r • Everything else is syntactic sugar
Example 1 • Every request which is acknowledged must be followed at some point in the future with a valid grant (a grant which is not aborted the following cycle) AG {req,ack} {true[*],grant,abort}!
Example 2 • A sequence beginning with the assertion of go, containing eight not necessarily consecutive assertions of signal get, during which kill is not asserted, must be followed by a sequence of eight assertions of signal put before signal end can be asserted. Sugared: AG ({go, {get[=8]} && {kill[=0]}} {{put[=8]} && {end[=0]}}) Unsugared: {true[*], go, (get kill)[*], get kill, …
Example 3 • Every transaction must complete, and within every transaction, a full data transfer must occur. Sugared: AG within!(tr_strt, tr_end) {true[*],dat_strt,true[*],dat_end} Unsugared: {true[*],tr_strt} | {tr_end[*], dat_start tr_end, tr_end[*], dat_end tr_end, tr_end}
Example 4 • Whenever hi_pri_req is asserted, one of the next two assertions of signal gnt must have dst equal to hi_pri. Sugared: AG (hi_pri_req next_event_f(gnt)[1..2](dst=hi_pri)) Unsugared: AG (hi_pri_req A[gnt W ((gnt dst=hi_pri) (gnt AX A[gnt W (gnt dst=hi_pri)]))])
Example 5 • If within eight cycles from the beginning of the transaction, signals p_start_reg and discard_rx are both asserted, then the valid signal should be deasserted in the next cycle. AG {start_pack, {true[8]} && {p_start_reg[>0]} && {discard_rx[>0]}}(AX valid)
Example 6 • A transaction sequence with two data transfers, during which an error occurs, should be retried. AG { {trans_start,data[=2],trans_end} && {error[>0]}} | {[..4],retry}
Experience • Mature language • used since 1994 by tens of design groups • Multiple uses: • formal verification • specification language for simulation checkers • Intuitive semantic sugar makes it easy to use • most users are self-taught through a tutorial