Royal Institute of Technolog y 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
Medea DAC, November 2003, 3Axel Jantsch, KTH, Stockholm
System Model and Architecture
Heterogeneous Task Graph
Heterogeneous Architecture
Medea DAC, November 2003, 4Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 5Axel Jantsch, KTH, Stockholm
Heterogeneity of Expertise
Hardware Embedded Software RF/Mixed Signal
Real-time Operating SystemCommunication
Protocols
Digital Signal ProcessingUser Interface Speech Processing
SystemDesign
CommunicationSystems
Medea DAC, November 2003, 6Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 7Axel Jantsch, KTH, Stockholm
Dataflow Process Networks
Networks of actors connected with streams Hierarchy of networks Communication is buffered with unbounded FIFOs
A B
D
C
Medea DAC, November 2003, 8Axel Jantsch, KTH, Stockholm
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)
Medea DAC, November 2003, 9Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 10Axel Jantsch, KTH, Stockholm
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.
Medea DAC, November 2003, 11Axel Jantsch, KTH, Stockholm
Features of Synchronous Languages
Deterministic
Amenable to formal analysis
Efficient synthesis
Substitution of equivalent blocks preserves behaviour
Medea DAC, November 2003, 12Axel Jantsch, KTH, Stockholm
Substitution of Equivalent Blocks
P1 P2 P3
P1 P2 P3
Medea DAC, November 2003, 13Axel Jantsch, KTH, Stockholm
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?
Medea DAC, November 2003, 14Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 15Axel Jantsch, KTH, Stockholm
Simultaneous Events
A B0 delay
Ct
t
A B0 delay
Ct
t
A B0 delay
Ct
t
A B0 delay
Ct+
t
delay model
Medea DAC, November 2003, 16Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 17Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 18Axel Jantsch, KTH, Stockholm
Heterogeneous System Modelling
Heterogeneous Systems
Different Communities of Engineers
Established Languages with different profiles
Established design flows
Medea DAC, November 2003, 19Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 20Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 21Axel Jantsch, KTH, Stockholm
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 !
Medea DAC, November 2003, 22Axel Jantsch, KTH, Stockholm
Matlab - SDL: Synchronisation Provide a synchronization mechanism which preserves
Matlab’s vector oriented computation
A
SDL
B
SDL
fMatlab
gMatlab
Events
Data streams
Medea DAC, November 2003, 23Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 24Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 25Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 26Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 27Axel Jantsch, KTH, Stockholm
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
α γ β δ
Medea DAC, November 2003, 28Axel Jantsch, KTH, Stockholm
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 )
Medea DAC, November 2003, 29Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 30Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 31Axel Jantsch, KTH, Stockholm
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
Medea DAC, November 2003, 32Axel Jantsch, KTH, Stockholm
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.
Medea DAC, November 2003, 33Axel Jantsch, KTH, Stockholm
MoC Interface RefinementStep 1 – Add time interface
P Q
MoC I MoC II
P Q
MoC I MoC II
Time relation:3 : 1
Medea DAC, November 2003, 34Axel Jantsch, KTH, Stockholm
MoC Interface RefinementStep 2 – Refine Protocol
P1 Q1
MoC I MoC II
Time relation:3 : 1P2 Q2
Medea DAC, November 2003, 35Axel Jantsch, KTH, Stockholm
MoC Interface RefinementStep 3 – Model Channel Delay
P1 Q1
MoC I MoC II
Time relation:3 : 1P2 Q2
D[2,5]
D[2,5]
Medea DAC, November 2003, 36Axel Jantsch, KTH, Stockholm
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