The Temporal Logic Sugar

1. 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

2. Outline • History • Current status • The Sugar language • Examples

3. 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

4. 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

5. The Sugar Language - Overview • Contains both branching and linear constructs. • CTL • SERE: Sugar Extended Regular Expression • Extensive syntactic sugaring

6. 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

7. 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

8. 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

9. 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}!

10. 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, …

11. 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}

12. 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)]))])

13. 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)

14. 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}

15. 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