IP Reuse Hardening via Embedded Sugar Assertions

1. IP Reuse Hardening viaEmbedded Sugar Assertions Erich Marschner 1, Bernard Deadman 2, Grant Martin 1 1 Cadence Design Systems 2 Structured Design Verification

2. Agenda • Motivation • Sugar 2.0 Overview • Simple Use of Assertions • Clock and Reset • More Complex Use of Assertions • Protocol Requirements • Transaction Modeling • Arbitration Requirements • Summary

3. Motivation • Rapid design of complex chips requires reuse • acquisition and integration of reusable IP blocks • Effective reuse requires good documentation • to capture designer's understanding of the block, • interface requirements • assumptions about internal operation • Embedded Assertions can capture this knowledge • to catch errors in the configuration or use of the IP • Sugar 2.0 provides this capability • Accellera standard property specification language • developed by Accellera FVTC based on IBM donation • supports both simulation and formal verification

4. Sugar 2.0 Overview • Booleans • control conditions:(OPC=`JSR) && (Addr != 0) • clocking conditions:@(posedge clka) • Sequences • multi-cycle behavior: {a; b[*2]; c[+]}[*] • Properties • always, never, next, eventually • until, before, within, abort • {a;b} |=> {c;d;e} • Clocking • b@clk, {a;b;c}@clk, always f@clk • Declarations • sequence, property, ... • parameterizable • Directives • assert, assume, restrict, cover, ... • Embedding • // pragma sugar// always ph1 -> next ph2;

5. Clock and Reset Requirements • Exclude disallowed cases: • assert never (c1 && c2); • Describe required clocking behavior: • assert always {c1} |-> {(c1 && !c2)[+]; (!c1 && !c2)[*]; (!c1 && c2)[+]; (!c1 && !c2)[*]; (c1)}; • Describe legal reset behavior: • assert always {reset; !reset} |-> {!reset@c1 [*3]; reset@c2};

6. Protocol Requirements • Define Default Clock • default clock = rose(HCLK); • Define Protocol Requirements • assert always (HREADY && HTRANS==`BUSY) -> next (HREADY && HRESP==`OKAY); • assert always { HREADY } |=> { ( !HREADY && (HRESP==`OKAY) )[*]; { { HREADY && (HRESP==`OKAY)} | { {!HREADY;HREADY} && {(HRESP==`ERROR)[*2]} } | { {!HREADY;HREADY} && {(HRESP==`SPLIT)[*2]} } | { {!HREADY;HREADY} && {(HRESP==`RETRY)[*2]} } } };

7. AHB - Correct ‘Busy’ Response 1 2 3 4 5 6 HCLK Address phase HTRANS BUSY Data phase HRESP OKAY HREADY Pass assert always (HREADY && HTRANS==`BUSY) -> next (HREADY && HRESP==`OKAY);

8. 1 2 3 4 5 6 HCLK previous transaction Transaction HRESP OKAY ERROR HREADY AHB - Incorrect ‘Error’ Response Fail assert always { HREADY } |=> { ( !HREADY && (HRESP==`OKAY) )[*]; { { HREADY && (HRESP==`OKAY)} | { !HREADY && (HRESP==`ERROR); HREADY && (HRESP==`ERROR) } | { !HREADY && (HRESP==`SPLIT); HREADY && (HRESP==`SPLIT) } | { !HREADY && (HRESP==`RETRY); HREADY && (HRESP==`RETRY) } } };

9. Transaction Modeling • Define alternative behaviors as sequences: • sequence NotReady = {!HREADY && (HRESP==`OKAY)}; • sequence Ready = {HREADY && `OKAY}; • sequence Error = { !HREADY && (HRESP==`ERROR); HREADY && (HRESP==`ERROR) } • sequence Split = { !HREADY && (HRESP==`SPLIT); HREADY && (HRESP==`SPLIT) } • sequence Retry = { !HREADY && (HRESP==`RETRY); HREADY && (HRESP==`RETRY) }

10. Transaction Modeling (2) • Define master control conditions as Boolean expressions: • `define FirstTransfer ( HTRANS == `NONSEQ ) • `define NextTransfer ( HTRANS == `SEQ ) • `define MasterBusy ( HTRANS == `BUSY ) • `define ReadIncr ( !HWRITE && ( HBURST == `INCR ) )

11. Transaction Modeling (3) • Build compound sequences with && and |, [*] • sequence SlaveResponse = { NotReady[*]; { Ready | Error | Split | Retry } }; • sequence ReadFirst = { {SlaveResponse} && {(`FirstTransfer && `ReadIncr)[*]}}; • sequence ReadNext ={ {SlaveResponse} && { {(`NextTransfer && `ReadIncr)[*]} | {`MasterBusy[*]} }}; • sequence BurstModeRead = { {ReadFirst} ; {ReadNext}[*]};

12. Transaction Modeling (4) • Model all transactions as compound sequences • Require a series of valid transactions • assert {HREADY} |=> { BurstModeRead | BurstModeWrite | SingleRead | SingleWrite | Inactive | Reset };

13. Arbitration Requirements • Require Arbiter to properly restrict master access • assert forall m in {0:15} :always (HREADY && (HMASTER == m) && (HRESP==`SPLIT)) -> next (HMASTER != m) until! (HSPLIT[m]); • Require Arbiter to eventually complete splits • assert forall m in {0:15} :always (HSPLIT[m]) -> eventually ((HMASTER == m) && HREADY && HSEL);

14. Summary • Embedded Sugar assertions enable “reuse hardening” of design IP • to exclude illegal operating conditions • to define (and require) legal behavior • Assertions capture the original designer's knowledge • interface requirements, design assumptions, etc. • executable documentation of design/environment functionality • Embedded assertions record knowledge directly within the IP • can be developed in parallel with the design, by the designer • knowledge is guaranteed to be available to for later verification • Embedded assertions facilitate design and verification • can be checked during simulation • can be used in formal verification • Result: more reliable IP reuse in the design of large, complex chips • and less time spent by designers helping users debug problems later