Design & Co-design of Embedded Systems Next Step: Transaction-Level Modeling Maziar Goudarzi

Design & Co-design of Embedded Systems

Next Step: Transaction-Level Modeling

Maziar Goudarzi

Today Program

The next step toward higher abstractions System-Level Modeling = Transaction-Level

ModelingWhat is TLMTaxonomy of TLMsSystem Design with TLMs

Slides from D. Gajski invited talk at ISSS’03:

D. Gajski, L. Cai, “Transaction-Level Modeling: An Overview,” Proc. of CODES+ISSS’03, California, 2003.

Copyright 2003 Dan Gajski and Lukai Cai 3

Transaction Level Modeling: An Overview

Daniel Gajski

Lukai Cai

Center for Embedded Computer Systems

University 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 Abdi

Rainer Doemer

Andreas Gerstlauer

Junyu Peng

Dongwan Shin

Haobo 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

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


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


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


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

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


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


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

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


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*c

Distributivity of multiplication over addition

B2 B3

B1 B1

B2 B3=

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 attri bute

l i braryEsti mati on

l i brary 2I Pl i brary

Test

DFT


SCE: SoC Environment


SCE: SoC Environment (cont’d)






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


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

Today Summary

The key enabling concept: channels

Next session: SystemC 2.0 facilities to define

channels (and hence, to support Transaction-Level Modeling)

Documents

Design & Co-design of Embedded Systems Next Step: Transaction-Level Modeling Maziar Goudarzi