Royal Institute of Technology System Specification Fundamentals Axel Jantsch, Royal Institute of Technology Stockholm, Sweden

Royal Institute of Technology

System Specification Fundamentals

Axel Jantsch, Royal Institute of Technology

Stockholm, Sweden

Medea DAC, November 2003, 2Axel Jantsch, KTH, Stockholm

Overview

Motivation Models of Computation

Data FlowSynchronous ModelsDiscrete Event Models

SDL - Matlab Integration Summary


System Model and Architecture

Heterogeneous Task Graph

Heterogeneous Architecture


Rising Abstraction LevelsHardware Polygons Gates Blocks (ALUs, Multipliers,

FSMs, etc) Functional blocks (Filters,

MPEG codecs, Protocols, etc.)

System Functional blocks (Filters, MPEG codecs, Protocols,

etc.) Features (GSM connection, GPS Modules, Speech

recognision, etc.)

Software Machine code Assembler code Subroutines, libraries


Heterogeneity of Expertise

Hardware Embedded Software RF/Mixed Signal

Real-time Operating SystemCommunication

Protocols

Digital Signal ProcessingUser Interface Speech Processing

SystemDesign

CommunicationSystems


Models of Computation (MoC)

Raise timing abstraction Raise communication abstraction Different MoCs serve different needs Different MoCs can be integrated into the

system MoCs to be discussed:

DataflowSynchronous MoCTimed MoC


Dataflow Process Networks

Networks of actors connected with streams Hierarchy of networks Communication is buffered with unbounded FIFOs

A B

D

C


Functional Actors

No side effects For the same input values produce the same output

values Functional for each firing cycle Functional over the entire streams

A

x

y

f(x,y)

g(x,y)


Static Data Flow The number of tokens consumed and produced by each

process is constant. A static schedule can always be found, if it exists, and The maximum buffer requirements can be computed

statically.

A B C

D

2 2 4 1 2 2

2

1

22

2

1

A B C

Schedule: AABAABCD

D

8 0

4

0 0

00


Perfect Synchrony Perfect synchrony assumption:

Computation takes no time Communication takes no

time (synchronous broadcast) synchronized

<Initialize memory>foreach period do

<Read inputs><Compute outputs><Update memory>

end

Assumption: The system reacts rapidly enough to perceive all external events in suitable order.


Features of Synchronous Languages

Deterministic

Amenable to formal analysis

Efficient synthesis

Substitution of equivalent blocks preserves behaviour


Substitution of Equivalent Blocks

P1 P2 P3

P1 P2 P3


Clocked Synchronous Models Computation takes 1 clock cycle Communication takes no time Substitution of blocks must consider timing behavour

P1 P2 P3

P1 P2 P3

1 cycle 1 cycle 1 cycle?


Discrete Event Models Event driven dynamics Events:

Primary input stimuli Internally generated

events Events have totally ordered

time stamps Components have arbitrary

delays Discrete or continuous time Most general timing model Primarily targeted to

simulation


Simultaneous Events

A B0 delay

Ct

t

A B0 delay

Ct

t

A B0 delay

Ct

t

A B0 delay

Ct+

t

delay model


Delta Time

time

0 ... t t+1 ...t+ t+2 t+3 ...

A The model allows infinite feed back loops between t and t+1


Discrete Event Models Global event queue is a bottleneck Timing model is close to physical time

Good to simulate timing behaviour of existing components;

Difficult to synthesize Difficult to formally verify

CombinatorialBlock

Register

CombinatorialBlock

Register

DE Models are interpreted according to a different timing model: Clocked synchronous model


Heterogeneous System Modelling

Heterogeneous Systems

Different Communities of Engineers

Established Languages with different profiles

Established design flows


Mixing multiple MoCs

AB

C

DE

F

I

I

MoC I MoC II

Design Language(System C, ...)

AB

C

DE

F

I

I

Well defined mapping


SDL and Matlab SDL

Communicating State Machines Communication is buffered with infinite FIFOs Non-deterministic elements Partially or totally ordered global time Discrete events govern the execution

Matlab Data flow model Demand driven execution Deterministic Partially ordered events; no global time Vector oriented computation


Matlab - SDL Integration: Timing Equip Matlab with a timing model with totally ordered

events

r = f(a) where a = <a0, a1, …, an> and r = <r0, r1, …, rm>

an … a1 a0rm … r1 r0

f

Re-interpretation !


Matlab - SDL: Synchronisation Provide a synchronization mechanism which preserves

Matlab’s vector oriented computation

A

SDL

B

SDL

fMatlab

gMatlab

Events

Data streams


Composite Signal Flow

Execution Model Data flow process Processes may have state

Signals Signals are sets of events An event is a (value, tag) pair

Process

signal


Signals Signals

Signals are sets of events An event is a (value, tag) pair

(t0,

<v 0,

v 1, …

, vn>

)

(t1,

< …

>)

(t2,

< …

>)

(t3,

< …

>)

signal

event

Sampled Signals Values are only defined for tags t = t0+n

Vectorized Signals Event values are vectors of constant length

Vectorized, sampled signals


Vectorization

Head vectorization

(t, v

0)

(t+

1, v

1)

(t+

2, v

2)

(t+

3, v

3 )

Ψh4

(t, <

v 0, v

1, v

2, v

3)

(t+

4, <

v 4, v

5, v

6, v

7)

(t, v

0)

(t+

1, v

1)

(t+

2, v

2)

(t+

3, v

3 )

Ψt4

(t-1

, <…

>)

(t+

3, <

v 0, v

1, v

2, v

3)

Tail vectorization


De-Vectorization

(t, v

0)

(t+

1, v

1)

(t+

2, v

2)

(t+

3, v

3 )

Ωh4

(t, <

v 0, v

1, v

2, v

3)

(t+

4, <

v 4, v

5, v

6, v

7)

(t, v

0)

(t+

1, v

1)

(t+

2, v

2)

(t+

3, v

3 )Ωt

4

(t-1

, <…

>)

(t+

3, <

v 0, v

1, v

2, v

3) Tail de-vectorization

Head de-vectorization


Causality A process is causal if for all possible input and output

streams two output streams never differ earlier than the corresponding two input streams.

Pi o

i1 = p1 α p2 o1 = q1 β q2

i2 = p1 γ p3 o2 = q1 δ q3

P is causal if and only if tag(α) tag(β)

Tail vectorization is causal

Head vectorization is notnot causal

Tail de-vectorization is notnot causal

Head de-vectorization is causal

α γ β δ


Causality and Delay Processes By combining a non-causal process with a delay

process, the resulting compound process can be causal A delay process outputs every input event delayed by a

specific time.

(t, v

0)

(t+

1, v

1)

(t+

2, v

2)

(t+

3, v

3 )

Δn

(t+

n, v

0)

(t+

n+1,

v1)

(t+

n+2,

v2)

(t+

n+3,

v3 )


Constraints on Modelling Modelling constraints must ensure that processes have

data available when they need it.

As=n,n>0

C

B

Unsafe situation

As=n,n>0

C

B

Safe situation

Δn


Applications Co-Modelling of Matlab and SDL

Causality constraints imply modelling constraints to safely mix Matlab and SDL processes

Timing analysis Causality constraints can be interpreted as timing

constraints derived from the timing of streams Parallel Simulation

A partition must be a causal process Only periodic signals may cross partition

boundaries


Connecting MoC Domains Connecting MoC Domains relates time structures When you connect an U-MoC with a T-MoC or a S-MoC,

the U-MoC imports the time structure. Interfaces can model the time relation Interface delays can be modeled stochastically or

nondeterministically Channel behaviour becomes more realistic Time structure relation can be complex


MoC Interface Refinement

1) Add time interface to precisely define the time structure relation. The relation can be constant, cyclic, deterministic or stochastic.

2) Refine the protocol to allow reliable communication across the domain boundary with the given time relation.

3) Model the channel delay if desirable.


MoC Interface RefinementStep 1 – Add time interface

P Q

MoC I MoC II

P Q

MoC I MoC II

Time relation:3 : 1


MoC Interface RefinementStep 2 – Refine Protocol

P1 Q1

MoC I MoC II

Time relation:3 : 1P2 Q2


MoC Interface RefinementStep 3 – Model Channel Delay

P1 Q1

MoC I MoC II

Time relation:3 : 1P2 Q2

D[2,5]

D[2,5]


Summary

Heterogeneous system modeling is a necessity

Different models of computation continue to coexist

Designers should use MoCs as abstract as possible that still contain the properties of interest.

A thorough understanding of different MoCs and their relation will address many current problems

Different MoCs can be represented in the same or different design languages

Documents

Royal Institute of Technology System Specification Fundamentals Axel Jantsch, Royal Institute of Technology Stockholm, Sweden