Transaction Level Modeling:
An Overview
Daniel Gajski
Lukai Cai
Center for Embedded Computer Systems
University of California, Irvine
www.cecs.uci.edu/~{gajski, lcai}
Copyright 2003 Dan Gajski and Lukai Cai
1
Acknowledgement
We would like to thank transaction level team at CECS that
has contributed many ideas through numerous lunch
discussions:
Samar Abdi
Rainer Doemer
Andreas Gerstlauer
Junyu Peng
Dongwan Shin
Haobo Yu
Copyright 2003 Dan Gajski and Lukai Cai
2
Overview
•
Motivation for TLM
•
TLM definition
•
TLMs at different abstraction levels
•
TLMs for different design domains
•
SL methodology = model algebra
•
Conclusion
Copyright 2003 Dan Gajski and Lukai Cai
3
Motivation
•
SoC problems
•
•
•
SoC solutions
•
•
•
•
Higher level of abstraction – transaction level modeling (TLM)
IP reuse
System standards
TLM questions
•
•
•
Increasing complexity of systems-on-chip
Shorter times-to-market
What is TLM ?
How to use TLM ?
This paper
•
•
TLM taxonomy
TLM usage
Copyright 2003 Dan Gajski and Lukai Cai
4
TLM Definition
•
TLM = < {objects}, {compositions} >
•
Objects
•
•
Composition
•
•
Computation objects + communication objects
Computation objects read/write abstract (above pin-accurate) data types
through communication objects
Advantages
•
•
Object independence
– Each object can be modeled independently
Abstraction independence
– Different objects can be modeled at different abstraction levels
Copyright 2003 Dan Gajski and Lukai Cai
5
Abstraction Models
•
•
Time granularity for communication/computation objects can be
classified into 3 basic categories.
Models B, C, D and E could be classified as TLMs.
A. "Specification model"
"Untimed functioal models"
Communication
Cycletimed
D
C. "Bus-arbitration model"
"Transaction model"
Approximatetimed
Untimed
B. "Component-assembly model"
"Architecture model"
"Timed functonal model"
F
C
E
D. "Bus-functional model"
"Communicatin model"
"Behavior level model"
A
B
Untimed
Approximatetimed
Cycletimed
Computation
E. "Cycle-accurate computation
model"
F. "Implementation model"
"Register transfer model"
Copyright 2003 Dan Gajski and Lukai Cai
6
A: “Specification Model”
Objects
- Computation
-Behaviors
- Communication
-Variables
Composition
B1
-
v1 = a*a;
-
-Parallel
-Piped
B3
B2
v3= v1- b*b;
v2 = v1 + b*b;
-States
-
v2
v3
B4
F
Approximatetimed
C
E
Untimed
A
B
Untimed
Approximatetimed
Cycletimed
v4 = v2 + v3;
c = sequ(v4);
Transitions
-TI, TOC
-
Communication
D
Order
-Sequential
v1
B2B3
Cycletimed
Hierarchy
Synchronization
-Notify/Wait
Computation
Copyright 2003 Dan Gajski and Lukai Cai
7
B: “Component-Assembly Model”
Composition
PE1
B1
cv11
-
Hierarchy
-
Order
v1 = a*a;
PE3
-Sequential
B3
cv12
Objects
- Computation
- Proc
- IPs
- Memories
- Communication
-Variable channels
-Piped
v3
PE2
B2
-Parallel
v3= v1- b*b;
-States
B4
cv2
v4 = v2 + v3;
c = sequ(v4);
v2 = v1 + b*b;
-
Transitions
-TI, TOC
-
Synchronization
Communication
A
Cycletimed
D
B1
-Notify/Wait
v1 = a*a;
F
v1
B2B3
B3
B2
Approximatetimed
Untimed
C
A
B
Untimed
Approximatetimed
E
v2 = v1 + b*b;
v3= v1- b*b;
v2
v3
B4
Cycletimed
Computation
v4 = v2 + v3;
c = sequ(v4);
Copyright 2003 Dan Gajski and Lukai Cai
8
C: “Bus-Arbitration Model”
Objects
- Computation
- Proc
- IPs (Arbiters)
- Memories
- Communication
- Abstract bus
channels
Composition
PE4
(Arbiter)
PE1
PE3
3
B1
-
Order
1
cv2
-Sequential
v3= v1- b*b;
cv12
-Parallel
2
v3
cv11
-Piped
B4
B2
v2 = v1 + b*b;
Hierarchy
B3
v1 = a*a;
PE2
-
v4 = v2 + v3;
c = sequ(v4);
1. Master interface
2. Slave interface
3. Arbiter interface
-States
-
Transitions
-TI, TOC
-
Communication
PE1
Cycletimed
D
B1
F
Synchronization
-Notify/Wait
cv11
v1 = a*a;
PE3
C
cv12
Approximatetimed
E
B
B3
v3= v1- b*b;
v3
PE2
B2
v2 = v1 + b*b;
Untimed
A
B
Untimed
Approximatetimed
Cycletimed
cv2
B4
v4 = v2 + v3;
c = sequ(v4);
Computation
Copyright 2003 Dan Gajski and Lukai Cai
9
D: “Bus-Functional Model”
Composition
PE4
(Arbiter)
PE1
3
B1
B3
v1 = a*a;
address[15:0]
address[15:0]
data[31:0]
data[31:0]
ready
ack ready
ack
-
Order
-Sequential
2
-Parallel
v3
B4
B2
v2 = v1 + b*b;
Hierarchy
v3= v1- b*b;
1
PE2
PE3
IProtocolSlav
e
Objects
- Computation
- Proc
- IPs (Arbiters)
- Memories
- Communication
- Protocol bus
channels
-Piped
v4 = v2 + v3;
c = sequ(v4);
1: master interface
2: slave interface
3: arbitor interface
-States
-
Transitions
-TI, TOC
-
Communication
Cycletimed
D
C
PE4
(Arbiter)
F
PE1
C
PE3
B3
v1 = a*a;
E
1
Untimed
cv2
B
Untimed
Approximatetimed
v2 = v1 + b*b;
Cycletimed
Computation
2
v3
cv11
B4
B2
A
v3= v1- b*b;
cv12
PE2
-Notify/Wait
3
B1
Approximatetimed
Synchronization
1. Master interface
2. Slave interface
3. Arbiter interface
v4 = v2 + v3;
c = sequ(v4);
Copyright 2003 Dan Gajski and Lukai Cai
10
E: “Cycle-Accurate Computation Model”
Objects
- Computation
- Proc
- IPs (Arbiters)
- Memories
- Wrappers
- Communication
- Abstract bus
channels
Composition
PE4
S0
-
Hierarchy
-
Order
S1
S2
S3
-Sequential
-Parallel
4
PE1
PE3
MOV r1, 10
MUL r1, r1, r1
....
4
S0
cv12
1
...
r1, r2, r2, r1
....
cv2
-States
S1
2
4
S2
cv11
PE2
MLA
-Piped
3
-
Transitions
S3
-TI, TOC
S4
4
1. Master interface
2. Slave interface
3. Arbiter interface
4. Wrapper
-
Synchronization
Communication
-Notify/Wait
Cycletimed
D
F
C
PE4
(Arbiter)
PE1
Approximatetimed
C
PE3
3
B1
E
B3
v1 = a*a;
v3= v1- b*b;
cv12
1
PE2
Untimed
A
Untimed
Cycletimed
Computation
v2 = v1 + b*b;
2
v3
cv11
B4
B2
B
Approximatetimed
cv2
1. Master interface
2. Slave interface
3. Arbiter interface
v4 = v2 + v3;
c = sequ(v4);
Copyright 2003 Dan Gajski and Lukai Cai
11
F: “Implementation Model”
Objects
- Computation
- Proc
- IPs (Arbiters)
- Memories
- Communication
-Buses (wires)
PE1
Composition
PE2
interrupt
interrupt
MOV r1, 10
MUL r1, r1, r1
....
req
...
r1, r2, r2, r1
....
MLA
req
-
Hierarchy
-
Order
-Sequential
MCNTR
MADDR
MDATA
-Parallel
PE4
PE3
-Piped
S0
-States
S0
S1
interrupt
S1
S2
-
S2
Transitions
S3
S3
-TI, TOC
S4
-
-Notify/Wait
Communication
Cycletimed
D
F
D
E
v1 = a*a;
Untimed
A
B
Untimed
Approximatetimed
address[15:0]
address[15:0]
data[31:0]
data[31:0]
ready
ack ready
ack
Cycletimed
Computation
S0
1: master interface
2: slave interface
3: arbitor interface
cv12
1
2
v3
B4
B2
v2 = v1 + b*b;
v1 = a*a;
v3= v1- b*b;
1
PE2
PE3
3
B1
B3
IProtocolSlav
e
C
PE1
PE3
3
B1
PE4
(Arbiter)
E
PE4
(Arbiter)
PE1
Approximatetimed
Synchronization
v4 = v2 + v3;
c = sequ(v4);
PE2
cv2
cv11
4
S2
S3
S4
B2
v2 = v1 + b*b;
S1
2
1. Master interface
2. Slave interface
3. Arbiter interface
4. Wrapper
Copyright 2003 Dan Gajski and Lukai Cai
12
Characteristics of Different Abstraction Models
Models
Specification
model
Componentassembly model
Bus-arbitration
model
Bus-functional
model
Cycle-accurate
computation
model
Implementation
model
Communication
time
no
Computation
time
no
Communication
scheme
variable
PE interface
no
approximate
variable channel
abstract
approximate
approximate
abstract
time/cycle
accurate
approximate
approximate
cycle-accurate
abstract bus
channel
protocol bus
channel
abstract bus
channel
cycle-accurate
cycle-accurate
bus (wire)
(no PE)
abstract
pin-accurate
pin-accurate
Copyright 2003 Dan Gajski and Lukai Cai
13
Model Algebra
•
Algebra = < {objects}, {operations} >
[ex: a * (b + c)]
•
Model = < {objects}, {compositions} >
[ex:
•
Transformation t(model) is a change in objects or compositions.
•
Model refinement is an ordered set of transformations, < tm, … ,
t2, t1 >, such that model B = tm( … ( t2( t1( model A ) ) ) … )
•
Model algebra = < {models}, {refinements} >
•
Methodology is a sequence of models and corresponding
refinements
]
Copyright 2003 Dan Gajski and Lukai Cai
14
Model Definition
•
•
Model = < {objects}, {composition rules} >
Objects
•
•
•
Composition rules
•
•
•
•
Behaviors (representing tasks / computation / functions)
Channels (representing communication between behaviors)
Sequential, parallel, pipelined, FSM
Behavior composition creates hierarchy
Behavior composition creates execution order
– Relationship between behaviors in the context of the formalism
Relations amongst behaviors and channels
•
•
Verify 2003
Data transfer between channels
Interface between behaviors and channels
Copyright
2003
Dan
Gajski
and
LukaiAbdi
Cai
Copyright
2003
Dan
Gajski
and
Samar
15
Model Transformations (Rearrange and Replace)
•
Rearrange object composition
•
•
analogous to……
To correctly transform a sequential
composition to parallel and vice-versa
Decompose abstract data
structures
•
•
•
•
Import library components
Add / Remove synchronization
•
•
Distributivity of multiplication
over addition
Replace objects
•
•
a*(b+c) = a*b + a*c
To distribute computation over
components
B1
To implement data transaction over a
bus
Other transformations
B2
B1
B3
=
B3
B2
PE1
PE2
.
.
Verify 2003
Distribution of behaviors (tasks)
over components
Copyright
2003
Dan
Gajski
and
LukaiAbdi
Cai
Copyright
2003
Dan
Gajski
and
Samar
16
Model Refinement
•
Definition
•
•
Derives a more detailed model from an abstract one
•
•
•
Each transformation maintains functional equivalence
The refinement is thus correct by construction
Refinement based system level methodology
•
Verify 2003
Specific sequence for each model refinement
Not all sequences are relevant
Equivalence verification
•
•
•
Ordered set of transformations < tm, … , t2, t1 > is a refinement
– model B = tm( … ( t2( t1( model A ) ) ) … )
Methodology is a sequence of models and refinements
Copyright
2003
Dan
Gajski
and
LukaiAbdi
Cai
Copyright
2003
Dan
Gajski
and
Samar
17
Verification
•
Transformations preserve
equivalence
•
•
•
•
•
Model A
Same partial order of tasks
Same input/output data for each
task
Same partial order of data
transactions
Same functionality in replacements
All refined models will be
“equivalent” to input model
•
•
Still need to verify first model using
traditional techniques
Still need to verify equivalence of
replacements
Verify 2003
Designer
Decisions
Library of
objects
Refinement
Tool
t1
t2
…
tm
Model B
Copyright
2003
Dan
Gajski
and
LukaiAbdi
Cai
Copyright
2003
Dan
Gajski
and
Samar
18
Synthesis
•
•
Set of models
Sets of design tasks
•
•
•
•
•
•
•
•
•
•
•
Profile
Explore
Select components / connections
Map behaviors / channels
Schedule behaviors/channels
.
Each design decision => model transformation
Detailing is a sequence of design decisions
Refinement is a sequence of transformations
Synthesis = detailing + refinement
Challenge: define the sequence of design decisions and
transformations
Copyright 2003 Dan Gajski and Lukai Cai
19
Design Domains
Synthesis
domain
Component attribute
2
library
Synthesis
Exploration
domain
Refinement
domain
Modeling
domain
Estimation
2
library
IP
2
library
Estimation
Model A
Design
decisions
DFT
Validation
domain
Simulation
Verification
Refinement
Model B
Test
Copyright 2003 Dan Gajski and Lukai Cai
20
SCE Experiment is Very Positive
Source: http://www.cecs.uci.edu/~cad/sce.html
Copyright 2003 Dan Gajski and Lukai Cai
21
Conclusion
•
Computation and communication objects of TLM are connected
through abstract data types
•
TLM enables modeling each component independently at
different abstraction levels
•
The major challenge is to define necessary and sufficient set of
models for a design flow
•
The next major challenge is to define model algebra and
corresponding methodology for each application such that
algorithms and tools for modeling, verification, exploration,
synthesis and test can be easily developed
•
Opportunities are bigger than anything seen before
Copyright 2003 Dan Gajski and Lukai Cai
22