Transaction Assertions in an Interface Definition Language

1
Transaction Assertionsin an Interface Definition
Language

• Dave Whipp DesignCon 2008

2
Who Writes Assertions?

• Designers
• Bottom Up Assumptions
• Verification Engineers
• Top-down Intent
• Verification Vs Validation

3
Who Writes Assertions?

• Designers
• Bottom Up Assumptions
• Verification Engineers
• Top-down Intent
• Architects
• The Specification
• Top Down Assumptions
• Bottom Up Intent

4
Where to Write Assertions

• The RTL
• Inline
• Bound
• The Testbench
• Scoreboard
• Environment
• E.g. Post Process Log file

5
Where to Write Assertions

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

6
Where To Write Specification Assertions
Functionality Model
RTLDesign
Performance Model
7
Where To Write Specification Assertions
Functionality Model
Structural Model
RTLDesign
Performance Model
8
What is a Structural model?

• A Graph
• Nodes
• Arcs
• Communicating Processes
• Processors
• Messages (Transactions)
• A Netlist
• Modules
• Interfaces (Wires)

9
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

10
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

11
Multi-Unit Assemblies
A
E
B
C
D
F
G
a2b
b2c
c2d
d2e
e2f
f2g
A simple pipeline
12
Multi-Unit Assemblies
a2b
b2c
c2d
A
B
C
D
E
F
G
d2e
e2f
f2g
Simple rearrangement
13
Multi-Unit Assemblies
a2b
b2c
c2d
A
B
C
D
E
F
G
d2e
e2f
f2g
Identify units with similar behaviors
14
Multi-Unit Assemblies
cf2d
d2be
BE
CF
D
be2cf
a2be
A
cf2g
G
Extract common behavior into unified
components be2cf b2c e2f
15
Reusing Interface Definitions
A
E
B
C
D
F
G
BE
CF
D
A
G
How to maximize reuse between these two
architectures?
16
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

17
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?

18
Comparing Interfaces

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

19
Step 1 Capture transactions
C-Model tidA seq1 tidA seq2 tidA
seq3 tidB seq1 tidB seq2 tidB seq3
RTL 1010 01 1010 10 1011 01 1010 11 1011 10 1011
11
time
20
Step 2 Normalize
normal A1 A2 A3 B1 B2 B3
C-Model tidA seq1 tidA seq2 tidA
seq3 tidB seq1 tidB seq2 tidB seq3
RTL 1010 01 1010 10 1011 01 1010 11 1011 10 1011
11
normal A1 A2 B1 A3 B2 B3
time
21
Step 3 Binning
normal A1 A2 A3 B1 B2 B3
C-Model tidA seq1 tidA seq2 tidA
seq3 tidB seq1 tidB seq2 tidB seq3
bin A1 A2 A3 B1 B2 B3
RTL 1010 01 1010 10 1011 01 1010 11 1011 10 1011
11
normal A1 A2 B1 A3 B2 B3
bin A1 A2 B1 A3 B2 B3
22
Step 4 Accumulation

• Binning may not be enough
• Random Memory Access
• dont 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

23
Transaction Assertions in YACC

• valid_interface_traffic
• valid_interface_traffic packet
• packet begin middle end
• begin BEGIN
• middle
• middle MIDDLE
• end END

24
Cycle Level Assertions in SVA
clk cmd
BEG
END
MID
MID

• sequence packet
• (cmdBEGIN)
• 1 (cmd ! BEGIN cmd ! END) 0
• 1 cmd END
• endsequence
• a_well_formed_packet assert _at_(posedge clk)
• cmd BEGIN -gt sequence (packet)

25
Transaction Level Assertions in SVA
clk valid cmd
MID
MID
BEG
END

• sequence packet
• (cmdBEGIN)
• 1 (cmd ! BEGIN cmd ! END) 0
• 1 cmd END
• endsequence

26
Transaction Level Assertions in SVA
clk valid busy cmd
MIDDLE
MID
BEG
END

• event sample
• always _at_(posedge clk)
• if (valid ! busy) -gt sample
• assert _at_(sample)
• cmd BEGIN -gt sequence (packet)

27
Transaction Level Assertions in SVA
clk valid busy cmd
MIDDLE
MID
BEG
END

• event sample
• always _at_(posedge clk)
• if (valid ! busy) -gt sample
• assert _at_(sample)
• cmd BEGIN -gt sequence (packet)

28
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

29
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

30
Example
Renderer
Memory
31
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

32
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 ))

33
Add Predicates

• group_more mem_write
• assign is_circle r 0..7 (
• x -8 .. 7
• y -8 .. 7
• mem x8 y8 ( x2 y2 lt r2 )
• )

34
Define the interface

• interface render2memory
• clock mem_clk
• flow valid_busy
• packet sync, mem_write
• assert correct sync shape
• sync gt
• sync.shape CIRCLE gt
• mem_write.is_circle sync.radius

35
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

36
Transaction Linkage across Interfaces
Request
Client
Memory
Response
37
A link Assertion

• module memory
• equiv client_id 2
• in mem_req
• map client_id mem_req.src_id
• out mem_ack N4
• map client_id N
• assert every req has an ack
• id 0 .. 3
• enable( client_id N )
• link mem_req -gt mem_ack id

38
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 N4
• map client_id N

39
More Interaction Concepts

• a2b -gt b2c // propagate
• (a2x b2x) -gt x2y // merge
• a2b -gt (b2x b2y) // branch
• (a2x b2x) -gt x2y // join
• a2b -gt (b2x b2y) // fork
• in_order( id )
• thread( id )

40
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

41
BACKUP
42
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

43
Multi-Cycle Interface RTL traffic
Module A
Module B
34
1 1 1 0 0 0
data data data data data -
key value key value - -
1 1 1 1 1 0
time
44
Multi-Cycle Interface structural view
Module A
Module B
34
struct a2b_iface struct command union
struct key bit valid, bit 70 key
, struct value bit more, bit 70 value
struct datum bit valid, bit 70 data

45
Multi-Cycle Interface grammar
Module A
Module B
34
seq command ltkeygt ltvaluegt where 1.valid attr
more 2.more seq commands ltcommandgt
0,64 where all( 1 0..-1 .more ) !
1.more seq data ltdatumgt 0,128 where
all( 1.valid ) seq a2b_info ltcommandsgt
ltdatagt
46
Multi-Cycle Interface C-model struct
Module A
Module B
34
struct A2B_info mapltint8,int8gt commands
vectorltint24gt data
47
Equivalence classes for transactions

• Every implementation is a deformation of the ESL
• RTL
• C-Model
• We want to know up front how well compare them
• Implementation-independent comprehension
• Races in the transaction graph
• are like holes in a topology
• may be non-deterministic