1 IP-Based System-on-Chip Design 2002

IP Reuse Hardening viaEmbedded 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 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 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} |-> {!reset@c1 [*3]; reset@c2};

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 2002

1 2 3 4 5 6

HCLK

BUSYHTRANS

OKAYHRESP

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

1 2 3 4 5 6

HCLK

OKAYHRESP

HREADY

previous transaction Transaction

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