ee382v: embedded system design and...
TRANSCRIPT
EE382V:
Embedded System Design and Modeling
Andreas GerstlauerElectrical and Computer Engineering
University of Texas at [email protected]
Lecture 2 – Models of Computation, Languages
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 2
Lecture 2: Outline
• Overview
• Modeling, computational models, languages
• Models of Computation (MoCs)
• Process models• State machine models
• System-Level Design Languages (SLDLs)
• Goals, requirements• Communication and computation
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 3
Modeling
• Design models as an abstraction of a design instance
• Representation (model) of some aspect of reality– Virtual prototyping of what has been decided
• Specification for further implementation/synthesis– Describe desired functionality of what still to build
� Usually a combination of both� Different parts of the model or different use cases for the same model
• Needed in every step of the design process
� Documentation and specification of outputs and inputs� Capability to capture complex systems� Precise, complete and unambiguous
� Observability and predictability to reason about properties� Validation through simulation� Analysis through formal methods
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 4
Models of Computation (MoCs)
• Define a class of models
• Formal, abstract description of a system– Decomposition into pieces and their relationship– Well-defined objects and composition rules
• Various degrees of– supported features– complexity– expressive power
• Examples
• Sequential, imperative program models– Sequence of statements that manipulate program state
• Process models: networks, dataflow, calculi– Concurrency, data dependencies/causality
• State machine models: evolution from FSM to PSM– Control flow and state enumeration
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 5
Models vs. Languages
• Computation models describe system behavior
• Conceptual notion, e.g., recipe, sequential program• Languages capture models
• Concrete form, e.g., English, C• Variety of languages can capture one model
• E.g., sequential program model � C,C++, Java • One language can capture variety of models
• E.g., C++ → sequential program model, object-oriented model, state machine model
• Certain languages better at capturing certain models
Models
Languages
Recipe
SpanishEnglish Japanese
Poetry Story Sequent.program
C++C Java
Statemachine
Data-flow
Recipes vs. English Sequential programs vs. C
Source: T. Givargis, F. Vahid. “Embedded System Design”, Wiley 2002.
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 6
Text vs. Graphics
• Models versus languages not to be confused with text
versus graphics
• Text and graphics are just two types of languages– Text: letters, numbers– Graphics: circles, arrows (plus some letters, numbers)
Source: T. Givargis, F. Vahid. “Embedded System Design”, Wiley 2002.
…
X = 1;
if (N)
Y = X + 1;
…
N?
X =1
Y = X + 1
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 7
Lecture 2: Outline
� Overview
• Models of Computation (MoCs)
• Process models– Process networks– Dataflow– Process calculi
• State machine models: evolution from FSM to PSM– Finite State Machine (FSM)– FSM with Data (FSMD)– Super-state FSMD– ...– Program State Machine (PSM)
• System-Level Design Languages (SLDLs)
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 8
Process Models
• Set of processes
• Processes execute in parallel– Concurrent composition
• Each process is internally sequential– Imperative program
• Inter-process communication?
• Shared variables– Synchronization: critical section/mutex, monitor, …
• Message passing– Synchronous, rendezvous (blocking send)– Asynchronous, queues (non-blocking send)
� Examples: MPI, Java
� Implementation: OS processes or threads
� Single or multiple processors/cores
Producer
Consumer
Process1 Process2
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 9
Deadlocks
• Circular chain of 2 or more processes which each hold a
shared resource that the next one is waiting for
• Circular dependency through shared resources
� Prevent chain by using the same precedence� Use timeouts (and retry), but: livelock
� Dependency can be created when resources are shared
� Side effects, e.g. when blocking on filled queues/buffers
m2.lock();
m1.lock();
…
m1.unlock();
m2.unlock();
m1.lock();
m2.lock();
…
m2.unlock();
m1.unlock();
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 10
Non-determinism
• Deterministic: same inputs always produce same outputs
• Random: probability of certain behavior
• Non-deterministic: undefined behavior (for some inputs)
• Undefined execution order – Statement evaluation in imperative languages: f(a++, a++)
– Concurrent process race conditions:
� Can be desired or undesired
� How to ensure correctness?� Simulator must typically pick one behavior
� But: over-specification?� Leave freedom of implementation choice
x = a;
y = b;
a = 1;
b = 2;
x = ?, y = ?
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 11
Kahn Process Network (KPN) [Kahn74]
• C-like process description (Algol)
• Unbounded (infinite), uni-directional, point-to-point FIFO queues (channels) for communication
• Sender (send()) never blocks• Receiver (wait()) blocks until data available
� Deterministic
• Process can’t peek into channels and can only wait on one channel at a time
• Output data produced by a process does not depend on the order of its inputs
� Terminates on global deadlock: all process blocked on wait()
� Formal mathematical representation
• Process = continuous function mapping input to output streams
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 12
Kahn Process Networks (KPN) (2)
• Turing-complete, undecidable (in finite time)
• Terminates?• Can run in bounded buffers (memory)?
• Scheduling [Parks95]
• Start with smallest bounded buffers• Schedule with blocking send() until (artificial) deadlock• Increase size of smallest blocked buffer and continue
� Behavior does not depend on scheduling strategy
� Focus on causality, not order (implementation issue)� Difficult to schedule (Park’s algorithm)
� Dynamic memory allocation�Memory usage depends on scheduling strategy
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 13
Dataflow Networks
• Breaking processes down into network of actors
• Atomic blocks of computation, executed when firing
• Fire when required number of input tokens are available– Consume required number of tokens on input(s)– Produce number of tokens on output(s)
� Separate computation & communication/synchronization� Actors (indivisible units of computation) may fire simultaneously, any order� Tokens (units of communication) can carry arbitrary pieces of data
• Unbounded FIFOs on arcs between actors
� Signal-processing applications
f1() f3()f2()
f4()
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 14
Synchronous Dataflow (SDF) [Lee86]
• Fixed number of tokens per firing
• Consume fixed number of inputs• Produce fixed number of outputs
� Can be scheduled statically
� Solve system of linear equations for relative rates� Periodically schedule actors in proportion to their rates
� Find a sequence of firings in each period
� Trade-off code size and buffer sizes– Single-appearance vs. memory-minimal schedule
a cb
d
1 2 12
2
2 1 8
1
2Initialization� Delay� Prevent deadlock
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 15
Process Calculi
• Rendezvous-style, synchronous communication
• Communicating Sequential Processes (CSP) [Hoare78]• Calculus of Communicating Systems (CCS) [Milner80]
• Formal, mathematical framework: process algebra
• Algebra = <objects, operations, axioms>– Objects: processes (P, Q), events (a, b)– Composition operators: parallel (P║Q), prefix/input (a→P), choice (P|Q)– Axioms: indemnity (Ø║P = P), reduction (a→P║ a→Q = P║Q)
• Manipulate processes by manipulating expressions
� Examples: LOTOS, Occam (Transputer), HandleC (Celoxica)
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 16
Lecture 2: Outline
� Overview
• Models of Computation (MoCs)
�Process models� Process networks�Dataflow� Process calculi
• State machine models: evolution from FSM to PSM– Finite State Machine (FSM)– FSM with Data (FSMD)– Super-state FSMD– ...– Program State Machine (PSM)
• System-Level Design Languages (SLDLs)
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 17
State Machine Models
• Finite State Machine (FSM)
• Basic model for describing control• States and state transitions
– FSM = <S, I, O, f, h>
• Two types:– Mealy-type FSM (input-based)– Moore-type FSM (state-based)
S1 S2
S3
FSM model
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 18
State Machine Models
• Finite State Machine (FSM)
• Data Flow Graph (DFG)
• Basic model for describing computation (variant of SDF)• Directed graph
– Nodes: operations– Arcs: dependency of operations
Op2 Op3
Op4
Op6
Op1
Op5DFG model
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 19
State Machine Models
• Finite State Machine (FSM)
• Data Flow Graph (DFG)
• Finite State Machine with Data (FSMD)
• Combined model for control and computation– FSMD = FSM + DFG
� Implementation: controller plus datapath
FSMD model
S1 S2
S3
Op2 Op3
Op4
Op6
Op1
Op5Op1 Op2
Op3
Op1 Op2
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 20
State Machine Models
• Finite State Machine (FSM)
• Data Flow Graph (DFG)
• Finite State Machine with Data (FSMD)
• Super-State FSM with Data (SFSMD)
• FSMD with complex, multi-cycle states– States described by procedures in a programming language
SFSMD model
a = a + b;
c = c + d;
PS3
PS1 PS2PS2
PS3
PS1
a = 42;
while (a<100)
{ b = b + a;
if (b > 50)
c = c + d;
a = a + c;
}
a = 42;
b = a * 2;
for(c=0; c<100; c++)
{ b = c + a;
if (b < 0)
b = -b;
else
b = b + 1;
a = b * 10;
}
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 21
State Machine Models
• Finite State Machine (FSM)
• Data Flow Graph (DFG)
• Finite State Machine with Data (FSMD)
• Super-State FSM with Data (SFSMD)
• Hierarchical Concurrent FSM (HCFSM)
• FSM extended with hierarchy and concurrency– Multiple FSMs composed hierarchically (OR) and in parallel (AND)
� Example: StateCharts (graphical), Esterel/Lustre (textual)� Synchronous (lock-step) composition of concurrent FSMs
S4
S5
S3
S2
S1
HCFSM model
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 22
State Machine Models
• Finite State Machine (FSM)
• Data Flow Graph (DFG)
• Finite State Machine with Data (FSMD)
• Super-State FSM with Data (SFSMD)
• Hierarchical Concurrent FSM (HCFSM)
• Program State Machine (PSM)
• HCFSMD plus programming language– States described by proceduresin a programming language
� Example: SpecC!
PSM model
Source: R. Doemer, UC Irvine
PS4
PS5
PS3
PS2
PS1
...
a = 42;
while (a<100)
{ b = b + a;
if (b > 50)
c = c + d;
else
c = c + e;
a = c;
}
...
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 23
Lecture 2: Outline
� Overview
� Models of Computation (MoCs)
�Process models�State machine models
• System-Level Design Languages (SLDLs)
• Goals, requirements• Communication and computation
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 24
Design Languages
� Represent a model in machine-readable form
� Apply algorithms and tools
• Syntax provides the handle
• Grammar defines possible strings over an alphabet• Semantics connects/maps strings to a model
• Operational semantics– Defined through execution of an abstract state machine
• Denotational semantics– Define through mapping into a mathematical domain (e.g. functions)
� General underlying model of computation
• Discrete-event semantics as common denominator– Event = (value, tag) tuples– Signal = sequence of events– Ordering of tags (time) defines order of events
� Able to represent different MoCs� Defines interpretation of language into other MoCs
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 25
Simulation vs. Synthesis
• Ambiguous semantics of languages
� Simulatable but not synthesizable or verifiable
� Impossible to automatically discern implicit meaning� Need explicit set of constructs
case X iswhen X1=>...when X2=>
Finite state machine
Controller
3.415
2.715
--
--
Look-up table
Memory
Source: D. Gajski, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 26
System-Level Design Languages (SLDLs)
• Goals
• Executability– Validation through simulation
• Synthesizability– Implementation in HW and/or SW– Support for IP reuse
• Modularity– Hierarchical composition– Separation of concepts
• Completeness– Support for all concepts found in embedded systems
• Orthogonality– Orthogonal constructs for orthogonal concepts– Minimality
• Simplicity
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 27
System-Level Design Languages (SLDLs)
Behavioral
hierarchyStructural
hierarchy
Concurrency
Synchronization
Exception
handling
Timing
State
transitionsComposite
data types
SpecC
harts
Statecharts
Hardw
areC
Verilog
VHDL
Java
C++
C
SpecC
not supported partially supported supported
• Requirements
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 28
System-Level Design Languages (SLDLs)
• Examples in use today
• C/C++– ANSI standard programming languages, software design– traditionally used for system design because of practicality, availability
• SystemC– C++ API and library– initially developed at UCI, supported by Open SystemC Initiative
• SpecC– C extension– developed at UCI, supported by SpecC Technology Open Consortium
• SystemVerilog– Verilog with C extensions
• Matlab– specification and simulation in engineering, algorithm design
• UML– unified modeling language, software specification, graphical
• SDL– telecommunication area, standard by ITU, used in COSMOS
• SLDL– formal specification of requirements, not executable
• etc.Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 29
Separation of Concerns
• Fundamental principle in modeling of systems
• Clear separation of concerns
• address separate issues independently• System-Level Description Language (SLDL)
• orthogonal concepts• orthogonal constructs
• System-level Modeling
• Computation– encapsulated in modules / behaviors
• Communication– encapsulated in channels
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 30
Computation vs. Communication
• Traditional model
• Processes and signals• Mixture of computation and communication• Automatic replacement impossible
s2
s1
s3
P1 P2
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 31
Computation vs. Communication
• Traditional model
• Processes and signals• Mixture of computation and communication• Automatic replacement impossible
• SpecC model
• Behaviors and channels• Separation of computation and communication• Plug-and-play
s2
s1
s3
P1 P2
B2
v2
v1
v3
B1C1
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 32
Computation vs. Communication
• Protocol Inlining
• Specification model• Exploration model
– Computation in behaviors– Communication in channels
B2
v2
v1
v3
B1C1
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 33
Computation vs. Communication
• Protocol Inlining
• Specification model• Exploration model
– Computation in behaviors– Communication in channels
• Implementation model
– Channel disappears– Communication inlined into behaviors– Wires exposed
B2
v2
v1
v3
B1C1
B2B1
v2
v1
v3
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 34
v2
v1
IP in wrapper
Intellectual Property (IP)
• Computation IP: Wrapper model
B
Synthesizable
behavior
IP
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 35
Intellectual Property (IP)
• Computation IP: Wrapper model
B T
v2
v1IP
replacable
at any time
Synthesizable
behaviorTransducer IP in wrapper
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 36
Intellectual Property (IP)
• Computation IP: Wrapper model
B T
v2
v1IP
replacable
at any time
Synthesizable
behaviorTransducer IP in wrapper
• Protocol inlining with wrapper
B1
v2
v1IP
before after
v2
v1IP
B1
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 37
Intellectual Property (IP)
• Computation IP: Adapter model
B
replacable
at any time
Synthesizable
behavior
T
Transducer
v2
v1A
Adapter
IP
IP
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 38
Intellectual Property (IP)
• Computation IP: Adapter model
T
v2
v1
IPA
B
replacable
at any time
Synthesizable
behaviorTransducer Adapter IP
• Protocol inlining with adapter
B1
v2
v1
IPA
before
B1
v2
v1
IP
afterSource: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 39
IP protocol channel in wrapper
C2
Intellectual Property (IP)
• Communication IP: Channel with wrapper
replacable
at any time
Virtual channel
v2
v1
v3
C1
IP
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 40
Intellectual Property (IP)
• Communication IP: Channel with wrapper
replacable
at any time
Virtual channel IP protocol channel in wrapper
v2
v1
v3
IP
• Protocol inlining with hierarchical channel
B1 B2
v2
v1
before
v2
v1
B1 B2
after
C1 C2
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 41
Intellectual Property (IP)
• Incompatible busses: Transducer insertion
T
v2
v1
v3
B1
v5
v4
IPA
Transducer Adapter IPIP busSystem busSynthesizable
behavior
Source: R. Doemer, UC Irvine
EE382V: Embedded Sys Dsgn and Modeling, Lecture 2 © 2008 A. Gerstlauer 42
Intellectual Property (IP)
• Incompatible busses: Transducer insertion
• Protocol inlining with transducer
T
v2
v1
v3
B1
v5
v4
IPA
TB1
v5
v4
IP
v2
v1
v3
Transducer Adapter IPIP busSystem busSynthesizable
behavior
afterSource: R. Doemer, UC Irvine