copyright 2003 dan gajski and lukai cai 1 transaction level modeling: an overview daniel gajski...
TRANSCRIPT
Copyright 2003 Dan Gajski and Lukai Cai 1
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 2
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 3
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 4
Motivation
• SoC problems• Increasing complexity of systems-on-chip
• Shorter times-to-market
• SoC solutions• Higher level of abstraction – transaction level modeling (TLM)
• IP reuse
• System standards
• TLM questions• What is TLM ?
• How to use TLM ?
• This paper• TLM taxonomy
• TLM usage
Copyright 2003 Dan Gajski and Lukai Cai 5
TLM Definition
• TLM = < {objects}, {compositions} >
• Objects• Computation objects + communication objects
• Composition• 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 6
Abstraction Models
A. "Specification model" "Untimed functioal models"
B. "Component-assembly model" "Architecture model" "Timed functonal model"
C. "Bus-arbitration model" "Transaction model"
D. "Bus-functional model" "Communicatin model" "Behavior level model"
E. "Cycle-accurate computationmodel"
F. "Implementation model" "Register transfer model"
Computation
Communication
A B
C
D F
Un-timed
Approximate-timed
Cycle-timed
Un-timed
Approximate-timed E
Cycle-timed
• Time granularity for communication/computation objects can be classified into 3 basic categories.
• Models B, C, D and E could be classified as TLMs.
Copyright 2003 Dan Gajski and Lukai Cai 7
v2 = v1 + b*b; v3= v1- b*b;
v1
v1 = a*a;
v2
v4 = v2 + v3;c = sequ(v4);
B1
B2
v3
B3
B4
B2B3
Computation
Communication
A B
C
D F
Un-timed
Approximate-timed
Cycle-timed
Un-timed
Approximate-timed E
Cycle-timed
A: “Specification Model”
Objects
- Computation
-Behaviors
- Communication
-Variables
Composition
- Hierarchy
- Order
-Sequential
-Parallel
-Piped
-States
- Transitions
-TI, TOC
- Synchronization
-Notify/Wait
Copyright 2003 Dan Gajski and Lukai Cai 8
B: “Component-Assembly Model”
v2 = v1 + b*b; v3= v1- b*b;
v1
v1 = a*a;
v2
v4 = v2 + v3;c = sequ(v4);
B1
B2
v3
B3
B4
B2B3
A
v3
v3= v1- b*b;
B3
v4 = v2 + v3;c = sequ(v4);
B4
PE3
v2 = v1 + b*b;
B2
PE2
v1 = a*a;
B1
PE1
cv2
cv
12
cv11
Computation
Communication
A B
C
D F
Un-timed
Approximate-timed
Cycle-timed
Un-timed
Approximate-timed E
Cycle-timed
Objects
- Computation
- Proc
- IPs
- Memories
- Communication
-Variable channels
Composition
- Hierarchy
- Order
-Sequential
-Parallel
-Piped
-States
- Transitions
-TI, TOC
- Synchronization
-Notify/Wait
Copyright 2003 Dan Gajski and Lukai Cai 9
C: “Bus-Arbitration Model”
v3
v3= v1- b*b;B3
v4 = v2 + v3;c = sequ(v4);
B4
PE3
v2 = v1 + b*b;
B2
PE2
v1 = a*a;
B1
PE1
cv2
cv
12
cv11
B
Computation
Communication
A B
C
D F
Un-timed
Approximate-timed
Cycle-timed
Un-timed
Approximate-timed E
Cycle-timed
v2 = v1 + b*b;
B2
PE2
v1 = a*a;
B1
PE1
v3
v3= v1- b*b;
B3
v4 = v2 + v3;c = sequ(v4);
B4
PE3
cv12
cv11
cv2
PE4(Arbiter)
3
1 2
1. Master interface2. Slave interface3. Arbiter interface
Objects
- Computation
- Proc
- IPs (Arbiters)
- Memories
- Communication
- Abstract bus channels
Composition
- Hierarchy
- Order
-Sequential
-Parallel
-Piped
-States
- Transitions
-TI, TOC
- Synchronization
-Notify/Wait
Copyright 2003 Dan Gajski and Lukai Cai 10
v2 = v1 + b*b;
B2
PE2
v1 = a*a;
B1
PE1
v3
v3= v1- b*b;
B3
v4 = v2 + v3;c = sequ(v4);
B4
PE3
cv12
cv11
cv2
PE4(Arbiter)
3
1 2
1. Master interface2. Slave interface3. Arbiter interface
C
v2 = v1 + b*b;
B2
PE2
v1 = a*a;
B1
PE1
v3
v3= v1- b*b;
B3
v4 = v2 + v3;c = sequ(v4);
B4
PE3
PE4(Arbiter)
3
1 2
1: master i nterf ace2: sl ave i nterf ace3: arbi tor i nterf ace
ready
ack
address[15:0]
data[31:0]
IPro
toc
olS
lav
e
ready
ack
address[15:0]
data[31:0]
D: “Bus-Functional Model”
Computation
Communication
A B
C
D F
Un-timed
Approximate-timed
Cycle-timed
Un-timed
Approximate-timed E
Cycle-timed
Objects
- Computation
- Proc
- IPs (Arbiters)
- Memories
- Communication
- Protocol bus channels
Composition
- Hierarchy
- Order
-Sequential
-Parallel
-Piped
-States
- Transitions
-TI, TOC
- Synchronization
-Notify/Wait
Copyright 2003 Dan Gajski and Lukai Cai 11
v2 = v1 + b*b;
B2
PE2
v1 = a*a;
B1
PE1
v3
v3= v1- b*b;
B3
v4 = v2 + v3;c = sequ(v4);
B4
PE3
cv12
cv11
cv2
PE4(Arbiter)
3
1 2
1. Master interface2. Slave interface3. Arbiter interface
C
Computation
Communication
A B
C
D F
Un-timed
Approximate-timed
Cycle-timed
Un-timed
Approximate-timed E
Cycle-timed
E: “Cycle-Accurate Computation Model”
PE3
cv12
cv11
cv2
3
1 2
1. Master interface2. Slave interface3. Arbiter interface4. Wrapper
S0
S1
S2
S3
S4
PE4
S0
S1
S2
S3
4
4
PE2
PE1
MOV r1, 10MUL r1, r1, r1
....
...MLA r1, r2, r2, r1
....
4
4
Objects
- Computation
- Proc
- IPs (Arbiters)
- Memories
- Wrappers
- Communication
- Abstract bus channels
Composition
- Hierarchy
- Order
-Sequential
-Parallel
-Piped
-States
- Transitions
-TI, TOC
- Synchronization
-Notify/Wait
Copyright 2003 Dan Gajski and Lukai Cai 12
PE2PE1
PE3PE4
S0
S1
S2
S3
S4
MOV r1, 10MUL r1, r1, r1
....
...MLA r1, r2, r2, r1
....
S0
S1
S2
S3
MCNTRMADDRMDATA
interrupt
interrupt
interrupt
req req
v2 = v1 + b*b;
B2
PE2
v1 = a*a;
B1
PE1PE3
cv12
cv11
cv2
PE4(Arbiter)
3
1 2
1. Master interface2. Slave interface3. Arbiter interface4. Wrapper
S0
S1
S2
S3
S4
4
E
F: “Implementation Model”
v2 = v1 + b*b;
B2
PE2
v1 = a*a;
B1
PE1
v3
v3= v1- b*b;
B3
v4 = v2 + v3;c = sequ(v4);
B4
PE3
PE4(Arbiter)
3
1 2
1: master i nter f ace2: sl ave i nter f ace3: arbi tor i nter f ace
ready
ack
address[15:0]
data[31:0]
IPro
toc
olS
lav
e
ready
ack
address[15:0]
data[31:0]
D
Computation
Communication
A B
C
D F
Un-timed
Approximate-timed
Cycle-timed
Un-timed
Approximate-timed E
Cycle-timed
Objects
- Computation
- Proc
- IPs (Arbiters)
- Memories
- Communication
-Buses (wires)
Composition
- Hierarchy
- Order
-Sequential
-Parallel
-Piped
-States
- Transitions
-TI, TOC
- Synchronization
-Notify/Wait
Copyright 2003 Dan Gajski and Lukai Cai 13
Characteristics of Different Abstraction Models
Models Communication time
Computation time
Communication scheme
PE interface
Specification model
no no variable (no PE)
Component-assembly model
no approximate variable channel abstract
Bus-arbitration model
approximate approximate abstract bus channel
abstract
Bus-functional model
time/cycle accurate
approximate protocol bus channel
abstract
Cycle-accurate computation
model
approximate cycle-accurate abstract bus channel
pin-accurate
Implementation model
cycle-accurate cycle-accurate bus (wire) pin-accurate
Copyright 2003 Dan Gajski and Lukai Cai 14
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 15
Model Definition
• Model = < {objects}, {composition rules} >
• Objects• Behaviors (representing tasks / computation / functions)
• Channels (representing communication between behaviors)
• Composition rules• 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• Data transfer between channels
• Interface between behaviors and channels
Copyright 2003 Dan Gajski and Samar AbdiVerify 2003
Copyright 2003 Dan Gajski and Lukai Cai 16
• Rearrange object composition• To distribute computation over
components
• Replace objects• Import library components
• Add / Remove synchronization• To correctly transform a sequential
composition to parallel and vice-versa
• Decompose abstract data structures
• To implement data transaction over a bus
• Other transformations• .
• .
Model Transformations (Rearrange and Replace)
a*(b+c) = a*b + a*c
Distributivity of multiplication over addition
B2 B3
B1 B1
B2 B3=
Distribution of behaviors (tasks)over components
analogous to……
PE1 PE2
Copyright 2003 Dan Gajski and Samar AbdiVerify 2003
Copyright 2003 Dan Gajski and Lukai Cai 17
Model Refinement
• Definition• Ordered set of transformations < tm, … , t2, t1 > is a refinement
– model B = tm( … ( t2( t1( model A ) ) ) … )
• Derives a more detailed model from an abstract one• Specific sequence for each model refinement
• Not all sequences are relevant
• Equivalence verification• Each transformation maintains functional equivalence
• The refinement is thus correct by construction
• Refinement based system level methodology• Methodology is a sequence of models and refinements
Copyright 2003 Dan Gajski and Samar AbdiVerify 2003
Copyright 2003 Dan Gajski and Lukai Cai 18
Verification
• Transformations preserve equivalence
• 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
RefinementTool
t1t2…tm
Model A
Model B
DesignerDecisions
Library ofobjects
Copyright 2003 Dan Gajski and Samar AbdiVerify 2003
Copyright 2003 Dan Gajski and Lukai Cai 19
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 20
Design Domains
2
Model A
Simulation
Model B
Refinement
Estimation
Synthesis VerificationDesigndecisions
Synthesisdomain
Explorationdomain
Refinementdomain
Modelingdomain
Validationdomain
2Component attri bute
l i braryEsti mati on
l i brary 2I Pl i brary
Test
DFT
Copyright 2003 Dan Gajski and Lukai Cai 21
SCE Experiment is Very Positive
Source: http://www.cecs.uci.edu/~cad/sce.html
Specification model
Architecture model Estimation
Profiling
Profiling data
Design decisions
Communication model
Profiling weights
Arch. synthesis
Arch. refinement
Comm. synthesis
Comm. refinement
Refinement User Interface (RUI)
Estimation results
Design decisions ecisions
Estimation
Impl. synthesis
Estimation results
Design decisions Impl. refinement
Implementation model
Capture
RTL/RTOS attributes
Protocol models
Comp. / IP attributes
Protocol attributes
Comp. / IP models
Allocation
Beh. partitioning
Scheduling / RTOS
Protocol selection
Channel partitioning
Spec. optimization
Cycle scheduling
Protocol scheduling
Browsing
Arbitration
SW assembly
Alg. selection
Lang. Translators
Estimation RTL/RTOS models
Estimation results
Validation User Interface (VUI)
Verify
Synthesize
Synthesize
Synthesize
Verify
Verify
Verify
Compile
Estimate
Simulate
Simulate
Estimate
Simulate
Profile
Simulate
Copyright 2003 Dan Gajski and Lukai Cai 22
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