1 IP-Based System-on-Chip Design 2002 IP Reuse Hardening via Embedded Sugar Assertions Erich Marschner 1, Bernard Deadman 2, Grant Martin 1 1 Cadence Design Systems 2 Structured Design Verification

2 IP-Based System-on-Chip Design 2002 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 IP-Based System-on-Chip Design 2002 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 IP-Based System-on-Chip Design 2002 Sugar 2.0 Overview Booleans control conditions: (OPC=`JSR) && (Addr != 0) clocking clka) Sequences multi-cycle behavior: {a; b[*2]; c[+]}[*] Properties always, never, next, eventually until, before, within, abort {a;b} |=> {c;d;e} Clocking always Declarations sequence, property,... parameterizable Directives assert, assume, restrict, cover,... Embedding // pragma sugar // always ph1 -> next ph2;

5 IP-Based System-on-Chip Design 2002 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} |-> [*3];

6 IP-Based System-on-Chip Design 2002 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 IP-Based System-on-Chip Design HCLK BUSY HTRANS OKAY HRESP HREADY Address phase Data phase AHB - Correct Busy Response assert always (HREADY && HTRANS==`BUSY) -> next (HREADY && HRESP==`OKAY); Pass

8 IP-Based System-on-Chip Design 2002 AHB - Incorrect Error Response HCLK OKAY HRESP HREADY previous transactionTransaction ERROR 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) } } }; Fail

9 IP-Based System-on-Chip Design 2002 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 IP-Based System-on-Chip Design 2002 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 IP-Based System-on-Chip Design 2002 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 IP-Based System-on-Chip Design 2002 Transaction Modeling (4) Model all transactions as compound sequences Require a series of valid transactions assert {HREADY} |=> { BurstModeRead | BurstModeWrite | SingleRead | SingleWrite | Inactive | Reset };

13 IP-Based System-on-Chip Design 2002 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 IP-Based System-on-Chip Design 2002 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