Transaction Level Modeling: An OvervieSW assembly Alg. selection Lang. Translators RTL/RTOS...

Copyright ©2003 Dan Gajski and Lukai Cai 1

Transaction Level Modeling: An Overview

Daniel GajskiLukai Cai

Center for Embedded Computer SystemsUniversity of California, Irvine

www.cecs.uci.edu/~{gajski, lcai}


Acknowledgement

We would like to thank transaction level team at CECS that has contributed many ideas through numerous lunch discussions:

Samar AbdiRainer DoemerAndreas GerstlauerJunyu PengDongwan ShinHaobo Yu


Overview

• Motivation for TLM

• TLM definition

• TLMs at different abstraction levels

• TLMs for different design domains

• SL methodology = model algebra

• Conclusion


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


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


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.


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


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

cv12

cv11

Computation

Communication

A B

C

D F

Un-timed

Approximate-timed

Cycle-timed

Un-timed

Approximate-timed E

Cycle-timed


- Proc- IPs- Memories

- Communication-Variable channels

Composition

- Hierarchy

- Order

-Sequential

-Parallel

-Piped

-States

- Transitions

-TI, TOC

- Synchronization

-Notify/Wait


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

cv12

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


- Proc- IPs (Arbiters)- Memories

- Communication- Abstract bus

channels

Composition

- Hierarchy

- Order

-Sequential

-Parallel

-Piped

-States

- Transitions

-TI, TOC

- Synchronization

-Notify/Wait


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


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: mast er i nt er f ace2: sl ave i nt er f ace3: ar bi t or i nt er f ace

readyack

address[15:0]data[31:0]

IPro

toco

lSla

ve

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



- Communication- Protocol bus

channels

Composition

- Hierarchy

- Order

-Sequential

-Parallel

-Piped

-States

- Transitions

-TI, TOC

- Synchronization

-Notify/Wait


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


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

PE4S0

S1

S2

S3

4

4

PE2

PE1MOV r1, 10MUL r1, r1, r1

....

...MLA r1, r2, r2, r1

....

4

4


- Proc- IPs (Arbiters)- Memories- Wrappers

- Communication- Abstract bus

channels

Composition

- Hierarchy

- Order

-Sequential

-Parallel

-Piped

-States

- Transitions

-TI, TOC

- Synchronization

-Notify/Wait


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

PE1 PE3

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: mast er i nt er f ace2: sl ave i nt er f ace3: ar bi t or i nt er f ace

readyack

address[15:0]data[31:0]

IPro

toco

lSla

ve

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



- Communication-Buses (wires)

Composition

- Hierarchy

- Order

-Sequential

-Parallel

-Piped

-States

- Transitions

-TI, TOC

- Synchronization

-Notify/Wait


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


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


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


• 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*cDistributivity of multiplication

over addition

B2 B3

B1 B1

B2B3=

Distribution of behaviors (tasks)over components

analogous to……

PE1 PE2



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



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



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


Design Domains

2

Model A

Simulation

Model B

Refinement

Estimation

Synthesis VerificationDesigndecisions

Synthesisdomain

Explorationdomain

Refinementdomain

Modelingdomain

Validationdomain

2Component at t r i but el i br ar y

Est i mat i onl i br ar y 2I P

l i br ar y

Test

DFT


SCE Experiment is Very Positive

Source: http://www.cecs.uci.edu/~cad/sce.html

Specification

Architecture modelEstimation

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

Estimation

Impl. synthesis

Estimation results

Design decisions Impl. refinement

Implementation model

Capture

RTL/RTOS attributes

Protocol models

Comp. / IPattributes

Protocol attributes

Comp. / IPmodels

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/RTOSmodels

Estimation results

ValidationUser Interface (VUI)

Verify

Synthesize

Synthesize

Synthesize

Verify

Verify

Verify

Compile

Estimate

Simulate

Simulate

Estimate

Simulate

Profile

Simulate


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 ofmodels 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

Transaction Level Modeling: An OvervieSW assembly Alg. selection Lang. Translators RTL/RTOS...

Documents

Transcript of Transaction Level Modeling: An OvervieSW assembly Alg. selection Lang. Translators RTL/RTOS...