Transaction Assertions in an Interface Definition Language

Transaction Assertionsin an Interface Definition Language Dave Whipp – DesignCon 2008

Who Writes Assertions? • Designers • Bottom Up Assumptions • Verification Engineers • Top-down Intent • Verification Vs Validation

Who Writes Assertions? • Designers • Bottom Up Assumptions • Verification Engineers • Top-down Intent • Architects • The Specification • Top Down Assumptions • Bottom Up Intent

Where to Write Assertions • The RTL • Inline • Bound • The Testbench • Scoreboard • Environment • E.g. Post Process Log file

Where to Write Assertions • The RTL • Inline • Bound • The Testbench • Scoreboard • Environment • Post Process Log files • The Specification • C Models (?)

Where To Write Specification Assertions Functionality Model RTLDesign Performance Model

Where To Write Specification Assertions Functionality Model Structural Model RTLDesign Performance Model

What is a “Structural” model? • A Graph • Nodes • Arcs • Communicating Processes • Processors • Messages (Transactions) • A Netlist • Modules • Interfaces (Wires)

Birth of an IDL • Initially, a language just to define signals Interface a2b clock clk down U valid 1 up U busy 1 down U cmd 24 down U data 32

Evolution of an IDL • Quickly added flow-control protocol abstraction Interface a2b clock clk flow valid_busy down U cmd 24 down U data 32 • From this we can generate: • Testbench components (BFMs: producers, consumers) • Protocol Assertions • …

Multi-Unit Assemblies A B C D E F G a2b b2c c2d d2e e2f f2g A simple pipeline

Multi-Unit Assemblies a2b b2c c2d A B C D E F G d2e e2f f2g Simple rearrangement

Multi-Unit Assemblies a2b b2c c2d A B C D E F G d2e e2f f2g Identify units with similar behaviors

Multi-Unit Assemblies cf2d d2be BE CF D be2cf a2be A cf2g G Extract common behavior into unified components be2cf === b2c + e2f

Reusing Interface Definitions A B C D E F G BE CF D A G How to maximize reuse between these two architectures?

Continued Evolution of an IDL • Separation of packet structure from interface group SOP down U cmd 24 group MOP down U data 32 group EOP down U checksum 32 Interface a2b clock clk flow valid_busy packet SOP, MOP, EOP

Interfaces Vs State • Two approaches to comparing models: • Compare “Architectural State” • Registers/flops within the design whose existence is required by the specification • Compare externally visible behavior • Compare interface traffic • B. F. Skinner?

Comparing Interfaces • Simple “diff” • Normalization (masking, snapping) • Binning (collating, sorting) • Accumulating • In-memory FIFOs + scoreboard • File-based post-processing

Step 1: Capture transactions C-Model tid=A seq=1 tid=A seq=2 tid=A seq=3 tid=B seq=1 tid=B seq=2 tid=B seq=3 RTL 1010 01 1010 10 1011 01 1010 11 1011 10 1011 11 time

Step 2 : Normalize normal A1 A2 A3 B1 B2 B3 C-Model tid=A seq=1 tid=A seq=2 tid=A seq=3 tid=B seq=1 tid=B seq=2 tid=B seq=3 normal A1 A2 B1 A3 B2 B3 RTL 1010 01 1010 10 1011 01 1010 11 1011 10 1011 11 time

Step 3 : Binning normal A1 A2 A3 B1 B2 B3 C-Model tid=A seq=1 tid=A seq=2 tid=A seq=3 tid=B seq=1 tid=B seq=2 tid=B seq=3 bin A1 A2 A3 B1 B2 B3 normal A1 A2 B1 A3 B2 B3 bin A1 A2 B1 A3 B2 B3 RTL 1010 01 1010 10 1011 01 1010 11 1011 10 1011 11

Step 4: Accumulation • Binning may not be enough • Random Memory Access • don’t want to sort on every address • Different Algorithms • end result is same – checksum? • “Spaghetti” Perl scripts often evolve • We need to formalize the definition of interface traffic to compare two different models

Transaction Assertions in YACC valid_interface_traffic: | valid_interface_traffic packet; packet: begin middle end; begin: BEGIN; middle: | middle MIDDLE; end: END

Cycle Level Assertions in SVA clk cmd • sequence packet; (cmd==BEGIN) ##1 (cmd != BEGIN && cmd != END) [*0:$] ##1 cmd == END endsequence • a_well_formed_packet: assert @(posedge clk) cmd == BEGIN |-> sequence (packet) BEG END MID MID

Transaction Level Assertions in SVA clk valid cmd • sequence packet; (cmd==BEGIN) ##1 (cmd != BEGIN && cmd != END) [*0:$] ##1 cmd == END endsequence MID MID BEG END

Transaction Level Assertions in SVA clk valid busy cmd • event sample; • always @(posedge clk) if (valid && ! busy) -> sample • assert @(sample) cmd == BEGIN |-> sequence (packet) MIDDLE MID BEG END

The Structural Model • An Interface Definition Language • Define transactions/messages • Associate them with specific physical interfaces • Define connectivity of Modules • Use the definitions • RTL code generators • C-model code generators • Reuse the Definitions • Topology Changes • Implementation Protocols

Towards an ESL Language • During its early years, evolved • from 500 line Perl script • to 6000 line monster • Decision time: • Throw it away (replace with SV?), or • Revamp it • Clean up language definition • Add first-class ESL features • Assertions • Testpoints

Example Renderer Memory

The Traffic group mem_write down U address 16 down U data 1 group sync down U shape 2 enum SQUARE, CIRCLE, TRIANGE, BLANK down U radius 3

Accumulate Memory State group mem_write down U address 16 down U data 1 assign mem[ x = 0 .. 15 ][ y = 0 .. 15 ] = past( data :sample( address == {x,y} ))

Add Predicates group_more mem_write assign is_circle[ r = 0..7 ] = “&&”( [ x = -8 .. 7 ] [ y = -8 .. 7 ] mem[ x+8 ][ y+8 ] == ( x**2 + y**2 <= r**2 ) )

Define the interface interface render2memory clock mem_clk flow valid_busy packet sync, mem_write assert “correct sync shape” sync => sync.shape == CIRCLE => mem_write.is_circle[ sync.radius ] …

Important concepts • Assertion Scoping • Assertion in group checked only when that group valid • “valid” signal • Packet id • Temporal Scoping • “past” function sampled only when its group is valid • Further qualified by “sample” property • Assertions must be true in All models • RTL • C Model • …

Transaction Linkage across Interfaces Request Client Memory Response

A link Assertion module memory equiv client_id 2 in mem_req map client_id = mem_req.src_id out mem_ack[ N=4 ] map client_id = N assert “every req has an ack” [ id = 0 .. 3 ] :enable( client_id == N ) link mem_req -> mem_ack[ id ]

Equivalence Classes • How to identify transaction pairings • Need identifier that it common to each • Equivalence Classes module memory equiv client_id 2 in mem_req map client_id = mem_req.src_id out mem_ack[ N=4 ] map client_id = N

More Interaction Concepts • a2b -> b2c // propagate • (a2x | b2x) -> x2y // merge • a2b -> (b2x | b2y) // branch • (a2x & b2x) -> x2y // join • a2b -> (b2x & b2y) // fork • :in_order( id ) • :thread( id )

Summary • Architects should write assertions • Validated assertions are input to Verification • Assertions must be directly reusable across models • Manual recoding invites errors • Explicitly model the structure that is common to architectural models and to design • Tie assertions to these common points

BACKUP

Summary • Bridging abstractions requires defined traceability • ESL  RTL • ESL  C-Model • Use Transaction Abstraction for ESL • RTL and C-Model share a common shape • Transaction flow defines the equivalence class • Designer Freedoms are defined by ESL • This is a design activity • Verification “trusts” the ESL

Multi-Cycle Interface : RTL traffic Module A Module B 34 1 1 1 0 0 0 key value key value - - 1 1 1 1 1 0 data data data data data - time

Multi-Cycle Interface: structural view Module A Module B 34 struct a2b_iface { struct command { union { struct key { bit valid, bit [7:0] key }, struct value { bit more, bit [7:0] value } } struct datum { bit valid, bit [7:0] data } };

Multi-Cycle Interface : grammar Module A Module B 34 seq command = <key> <value> where $1.valid attr more = $2.more seq commands = <command> ** [0,64] where all( $1[ 0..$-1 ].more ) && ! $1[$].more seq data = <datum> ** [0,128] where all( $1[*].valid ) seq a2b_info = <commands> & <data>

Multi-Cycle Interface: C-model struct Module A Module B 34 struct A2B_info { map<int8,int8> commands; vector<int24> data; };

Equivalence classes for transactions • Every implementation is a deformation of the ESL • RTL • C-Model • We want to know up front how we’ll compare them • Implementation-independent comprehension • “Races” in the transaction graph • are like “holes” in a topology • may be non-deterministic

Transaction Assertions in an Interface Definition Language