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

Medea DAC, November 2003, 2 Axel Jantsch, KTH, Stockholm Overview  Motivation  Models of Computation  Data Flow  Synchronous Models  Discrete Event Models  SDL - Matlab Integration  Summary

Medea DAC, November 2003, 3 Axel Jantsch, KTH, Stockholm System Model and Architecture Heterogeneous Task Graph Heterogeneous Architecture

Medea DAC, November 2003, 4 Axel Jantsch, KTH, Stockholm Rising Abstraction Levels Hardware  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, 5 Axel Jantsch, KTH, Stockholm Heterogeneity of Expertise Hardware Embedded Software RF/Mixed Signal Real-timeOperating System Communication Protocols Digital Signal Processing User InterfaceSpeech Processing System Design Communication Systems

Medea DAC, November 2003, 6 Axel 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:  Dataflow  Synchronous MoC  Timed MoC

Medea DAC, November 2003, 7 Axel Jantsch, KTH, Stockholm Dataflow Process Networks  Networks of actors connected with streams  Hierarchy of networks  Communication is buffered with unbounded FIFOs AB D C

Medea DAC, November 2003, 8 Axel 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 yf(x,y) g(x,y)

Medea DAC, November 2003, 9 Axel 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. ABC D ABC Schedule: AABAABCD D

Medea DAC, November 2003, 10 Axel Jantsch, KTH, Stockholm Perfect Synchrony  Perfect synchrony assumption:  Computation takes no time  Communication takes no time (synchronous broadcast) synchronized foreach period do end  Assumption: The system reacts rapidly enough to perceive all external events in suitable order.

Medea DAC, November 2003, 11 Axel Jantsch, KTH, Stockholm Features of Synchronous Languages  Deterministic  Amenable to formal analysis  Efficient synthesis  Substitution of equivalent blocks preserves behaviour

Medea DAC, November 2003, 12 Axel Jantsch, KTH, Stockholm Substitution of Equivalent Blocks P1P2P3 P1P2P3

Medea DAC, November 2003, 13 Axel Jantsch, KTH, Stockholm Clocked Synchronous Models  Computation takes 1 clock cycle  Communication takes no time  Substitution of blocks must consider timing behavour P1P2P3 P1P2P3 1 cycle ?

Medea DAC, November 2003, 14 Axel 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, 15 Axel Jantsch, KTH, Stockholm Simultaneous Events A B 0 delay C t t A B 0 delay C t t A B 0 delay C t t A B 0 delay C t+  t  delay model

Medea DAC, November 2003, 16 Axel Jantsch, KTH, Stockholm Delta Time time 0...tt+1... t+  t+2  t+3 ... A The model allows infinite feed back loops between t and t+1

Medea DAC, November 2003, 17 Axel 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 Combinatorial Block Register Combinatorial Block Register  DE Models are interpreted according to a different timing model: Clocked synchronous model

Medea DAC, November 2003, 18 Axel Jantsch, KTH, Stockholm Heterogeneous System Modelling  Heterogeneous Systems  Different Communities of Engineers  Established Languages with different profiles  Established design flows

Medea DAC, November 2003, 19 Axel Jantsch, KTH, Stockholm Mixing multiple MoCs A B C D E F I I MoC IMoC II Design Language (System C,...) A B C D E F I I Well defined mapping

Medea DAC, November 2003, 20 Axel 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, 21 Axel Jantsch, KTH, Stockholm Matlab - SDL Integration: Timing  Equip Matlab with a timing model with totally ordered events r = f(a) where a = and r = a n … a 1 a 0 r m … r 1 r 0 f Re-interpretation !

Medea DAC, November 2003, 22 Axel Jantsch, KTH, Stockholm Matlab - SDL: Synchronisation  Provide a synchronization mechanism which preserves Matlab’s vector oriented computation A SDL B f Matlab g Events Data streams

Medea DAC, November 2003, 23 Axel 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, 24 Axel Jantsch, KTH, Stockholm Signals  Signals  Signals are sets of events  An event is a (value, tag) pair (t 0, ) (t 1, ) (t 2, )(t 3, ) signal event  Sampled Signals  Values are only defined for tags t = t 0 +n  Vectorized Signals  Event values are vectors of constant length  Vectorized, sampled signals

Medea DAC, November 2003, 25 Axel Jantsch, KTH, Stockholm Vectorization  Head vectorization (t, v 0 ) (t+1, v 1 )(t+2, v 2 ) (t+3, v 3 ) Ψh4Ψ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Ψt4 (t-1, ) (t+3, <v 0, v 1, v 2, v 3 )  Tail vectorization

Medea DAC, November 2003, 26 Axel Jantsch, KTH, Stockholm De-Vectorization (t, v 0 ) (t+1, v 1 )(t+2, v 2 ) (t+3, v 3 ) Ωh4Ω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Ωt4 (t-1, ) (t+3, <v 0, v 1, v 2, v 3 )  Tail de-vectorization  Head de-vectorization

Medea DAC, November 2003, 27 Axel 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. P io i 1 = p 1 α p 2 o 1 = q 1 β q 2 i 2 = p 1 γ p 3 o 2 = q 1 δ q 3 P is causal if and only if tag(α)  tag(β)  Tail vectorization is causal not  Head vectorization is not causal not  Tail de-vectorization is not causal  Head de-vectorization is causal α  γ β  δ

Medea DAC, November 2003, 28 Axel 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Δn (t+n, v 0 ) (t+n+1, v 1 )(t+n+2, v 2 ) (t+n+3, v 3 )

Medea DAC, November 2003, 29 Axel Jantsch, KTH, Stockholm Constraints on Modelling  Modelling constraints must ensure that processes have data available when they need it. A s=n,n>0 C B Unsafe situation A s=n,n>0 C B Safe situation ΔnΔn

Medea DAC, November 2003, 30 Axel 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, 31 Axel 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, 32 Axel 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, 33 Axel Jantsch, KTH, Stockholm MoC Interface Refinement Step 1 – Add time interface P Q MoC I MoC II P Q MoC I MoC II Time relation: 3 : 1

Medea DAC, November 2003, 34 Axel Jantsch, KTH, Stockholm MoC Interface Refinement Step 2 – Refine Protocol P1 Q1 MoC I MoC II Time relation: 3 : 1 P2 Q2

Medea DAC, November 2003, 35 Axel Jantsch, KTH, Stockholm MoC Interface Refinement Step 3 – Model Channel Delay P1 Q1 MoC I MoC II Time relation: 3 : 1 P2 Q2 D[2,5]

Medea DAC, November 2003, 36 Axel 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