Design and Architectures for Embedded Systems (ESII) Prof. Dr. J. - - PowerPoint PPT Presentation

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 1 ESII: Specification & Modeling

Design and Architectures for Embedded Systems (ESII)

• Prof. Dr. J. Henkel, M. Shafique
• Prof. Dr. J. Henkel, M. Shafique

CES CES - Chair for Embedded Systems Chair for Embedded Systems Karlsruhe Institute of Technology, Germany Karlsruhe Institute of Technology, Germany

Today: Specification and Modeling I Today: Specification and Modeling I

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 2 ESII: Specification & Modeling

Embedded Processor Design & Architectures

Where are we?

• models of computation
• Spec languages

embedded IP:

• PEs
• Memories
• Communication
• Peripherals
• …

IC technology

Optimization

• low power, performance,

area, reliability, peak temp. …

Design Space Exploration Design Space Exploration

• low power, performance, area, reliability,…
• 8. ASIPs, Extensible
• 8. ASIPs, Extensible

Processors Embedded Embedded Software Optimize for

• Optimize for
• Low Power
• Performance
• Area
• Reliability
• 7. ISA extensions 
• 7. ISA extensions 

Special Instructions

• 6. Code
• 6. Code

Generation for Embedded Systems Middleware, Middleware, RTOS 13 & 14. 13 & 14. Scheduling

• 9. DSPs, VLIW
• 9. DSPs, VLIW

10 & 11. Reconfigurable 10 & 11. Reconfigurable Processors SYSTEM PARTITIONING SYSTEM PARTITIONING Hardware Hardware Design

• Synthesis

2, 3, 4, 5 SYSTEM SPECIFICATION 2, 3, 4, 5 SYSTEM SPECIFICATION

refine

• Integration
• Integration
• Prototyping
• Tape out

Estimation&Simulation

• low power, performance,

area, reliability, peak temp. …

• 12. Multi-Corefuture
• 12. Multi-Corefuture

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 3 ESII: Specification & Modeling

Outline

 Categorization of systems Categorization of systems  Models vs. Languages Models vs. Languages  State Machine Model State Machine Model

 FSM/FSMD FSM/FSMD  HCFSM and HCFSM and Statecharts Statecharts Language Language  Program Program-State Machine (PSM) Model State Machine (PSM) Model

 Concurrent Process Model Concurrent Process Model  Dataflow Model Dataflow Model  Concurrent Processes Concurrent Processes  System and Model Properties System and Model Properties

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 4 ESII: Specification & Modeling

Categorization of Systems

 Transformational Transformational

 Operate on inputs; produce outputs and stop Operate on inputs; produce outputs and stop

 Interactive Interactive

 Do not typically terminate Do not typically terminate  Continuous interaction with environment Continuous interaction with environment  Interactive system act at their own speed Interactive system act at their own speed  Example: OS Example: OS

 Reactive Reactive

 Like interactive systems Like interactive systems  But: the pace is imposed by the environment But: the pace is imposed by the environment Embedded Systems belong to this group Embedded Systems belong to this group

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 5 ESII: Specification & Modeling

What are models for?

 => => perform various tasks of a design process: perform various tasks of a design process:  Performance modeling  Functional modeling and specification  Design and synthesis  Validation and verification  Test vector generation  Test coverage analysis  Architecture evaluation and mapping  Technology mapping  Placement and routing

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 6 ESII: Specification & Modeling

Why Models?

 Describing embedded system’s processing behavior Describing embedded system’s processing behavior

 Difficulty Difficulty  Due to High Due to High Complexity Complexity  radically growing radically growing

 Complexity of Current/Next Complexity of Current/Next-Generation Embedded Systems Generation Embedded Systems

 Software complexity ~ Increasing IC Software complexity ~ Increasing IC capactiy capactiy  Software Complexity Software Complexity  thousands to millions of LOC thousands to millions of LOC  >10 >109 LOC LOC Think about Digital Washing Machines or Ovens Think about Digital Washing Machines or Ovens Now think Now think

Digital Camera Digital Camera Multimedia TV, Multimedia TV, Mobile Phones (Video Coding, Audio Coding, GPS, 4G Mobile Phones (Video Coding, Audio Coding, GPS, 4G communication, …) communication, …)

 Desired behavior often not fully understood in beginning Desired behavior often not fully understood in beginning

Many implementation bugs due to description mistakes/omissions Many implementation bugs due to description mistakes/omissions

 English (or other natural language) common starting point English (or other natural language) common starting point Precision Precision  hard to describe clearly hard to describe clearly  difficult to impossible difficult to impossible

Level of Ambiguity Level of Ambiguity

(src: Vahid02)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 7 ESII: Specification & Modeling

5

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

Models and languages

• How can we (precisely) capture behavior?

– We may think of languages (C, C++), but computation model is the key

• Common computation models:

– Sequential program model

• Statements, rules for composing statements, semantics for executing them

– Communicating process model

• Multiple sequential programs running concurrently

– State machine model

• For control dominated systems, monitors control inputs, sets control outputs

– Dataflow model

• For data dominated systems, transforms input data streams into output streams

– Object-oriented model

• For breaking complex software into simpler, well-defined pieces

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 8 ESII: Specification & Modeling

6

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

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 computation models

Models Languages

Recipe Spanish English Japanese Poetry Story Sequent. program C++ C Java State machine Data- flow

Recipes vs. English Sequential programs vs. C

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 9 ESII: Specification & Modeling

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

12

Finite State Machine (FSM) Model

• An FSM is a 6-tuple F<S, I, O, F, H, s0>

– S is a set of all states {s0, s1, …, sl} – I is a set of inputs {i0, i1, …, im} – O is a set of outputs {o0, o1, …, on} – F is a next-state function (S x I → S) – H is an output function (S → O) – s0 is an initial state

• Moore-type

– Associates outputs with states (as given above, H maps S → O)

• Mealy-type

– Associates outputs with transitions (H maps S x I → O)

• Shorthand notations to simplify descriptions

– Implicitly assign 0 to all unassigned outputs in a state – Implicitly AND every transition condition with clock edge (FSM is synchronous)

→ → → →

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 10 ESII: Specification & Modeling

15

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

State machine vs. sequential program model

• Different thought process used with each model
• State machine:

– Encourages designer to think of all possible states and transitions among states based on all possible input conditions

• Sequential program model:

– Designed to transform data through series of instructions that may be iterated and conditionally executed

• State machine description excels in many cases

– More natural means of computing in those cases – Not due to graphical representation (state diagram)

• Would still have same benefits if textual language used (i.e., state table)
• Besides, sequential program model could use graphical representation (i.e., flowchart)

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 11 ESII: Specification & Modeling

17

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

Capturing state machines in sequential programming language

• Despite benefits of state machine model, most popular development tools use

sequential programming language

– C, C++, Java, Ada, VHDL, Verilog, etc. – Development tools are complex and expensive, therefore not easy to adapt or replace

• Must protect investment
• Two approaches to capturing state machine model with sequential programming

language

– Front-end tool approach

• Additional tool installed to support state machine language

– Graphical and/or textual state machine languages – May support graphical simulation – Automatically generate code in sequential programming language that is input to main development tool

• Drawback: must support additional tool (licensing costs, upgrades, training, etc.)

– Language subset approach

• Most common approach...

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 12 ESII: Specification & Modeling

20

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

HCFSM and the Statecharts language

• Hierarchical/concurrent state machine model

(HCFSM)

– Extension to state machine model to support hierarchy and concurrency – States can be decomposed into another state machine

• With hierarchy has identical functionality as Without

hierarchy, but has one less transition (z)

• Known as OR-decomposition

– States can execute concurrently

• Known as AND-decomposition
• Statecharts

– Graphical language to capture HCFSM – timeout: transition with time limit as condition – history: remember last substate OR-decomposed state A was in before transitioning to another state B

• Return to saved substate of A when returning from B

instead of initial state

A1

z

B A2 z x

y w Without hierarchy

A1

z

B A2 x y A

w With hierarchy

C1 C2 x y C B D1 D2 u v D

Concurrency

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 13 ESII: Specification & Modeling

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

22

Program-state machine model (PSM): HCFSM plus sequential program model

• Program-state’s actions can be FSM or sequential program

– Designer can choose most appropriate

• Stricter hierarchy than HCFSM used in Statecharts

– transition between sibling states only, single entry – Program-state may “complete”

• Reaches end of sequential program code, OR
• FSM transition to special complete substate
• PSM has 2 types of transitions

– Transition-immediately (TI): taken regardless of source program-state – Transition-on-completion (TOC): taken only if condition is true AND source program-state is complete

– SpecCharts: extension of VHDL to capture PSM model – SpecC: extension of C to capture PSM model

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 14 ESII: Specification & Modeling

24

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

Concurrent process model

• Describes functionality of system in terms of two or more

concurrently executing subtasks

• Many systems easier to describe with concurrent process model

because inherently multitasking

• E.g., simple example:

– Read two numbers X and Y – Display “Hello world.” every X seconds – Display “How are you?” every Y seconds

• More effort would be required with sequential program or state

machine model

Subroutine execution over time

time ReadX ReadY PrintHelloWorld PrintHowAreYou

Simple concurrent process example

ConcurrentProcessExample() { x = ReadX() y = ReadY() Call concurrently: PrintHelloWorld(x) and PrintHowAreYou(y) } PrintHelloWorld(x) { while( 1 ) { print "Hello world." delay(x); } } PrintHowAreYou(x) { while( 1 ) { print "How are you?" delay(y); } }

Sample input and output

Enter X: 1 Enter Y: 2 Hello world. (Time = 1 s) Hello world. (Time = 2 s) How are you? (Time = 2 s) Hello world. (Time = 3 s) How are you? (Time = 4 s) Hello world. (Time = 4 s) ...

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 15 ESII: Specification & Modeling

25

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

Dataflow model

• Derivative of concurrent process model
• Nodes represent transformations

– May execute concurrently

• Edges represent flow of tokens (data) from one node to another

– May or may not have token at any given time

• When all of node’s input edges have at least one token, node may

fire

• When node fires, it consumes input tokens processes

transformation and generates output token

• Nodes may fire simultaneously
• Several commercial tools support graphical languages for capture
• f dataflow model

– Can automatically translate to concurrent process model for implementation – Each node becomes a process

modulate convolve transform A B C D Z

Nodes with more complex transformations

t1 t2 + – * A B C D Z

Nodes with arithmetic transformations

t1 t2

Z = (A + B) * (C - D)

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 16 ESII: Specification & Modeling

26

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

Synchronous dataflow

• With digital signal-processors (DSPs), data flows at fixed rate
• Multiple tokens consumed and produced per firing
• Synchronous dataflow model takes advantage of this

– Each edge labeled with number of tokens consumed/produced each firing – Can statically schedule nodes, so can easily use sequential program model

• Don’t need real-time operating system and its overhead
• How would you map this model to a sequential programming

language? Try it...

• Algorithms developed for scheduling nodes into “single-

appearance” schedules

– Only one statement needed to call each node’s associated procedure

• Allows procedure inlining without code explosion, thus reducing
• verhead even more

modulate convolve transform A B C D Z

Synchronous dataflow

mt1 ct2 mA mB mC mD tZ tt1 tt2 t1 t2

ESII: Spec & Modeling

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 17 ESII: Specification & Modeling

What is a model?

 Model: A model is a simplification of another entity, which can be a physical thing or another model. The model contains exactly those characteristics and properties of the modeled entity which are relevant for a given task. A model is minimal with respect to a task, if it does not contain any

• ther characteristics than those relevant for the task.

 A model relates to an entity  A model is a simplification of that entity  A model is related to a task and an objective  A model may relate to a not yet existing entity

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 18 ESII: Specification & Modeling

Property of models

 Inherent property: The property is inherent in every model. E.g. the finite state space of a finite state machine model.  Static property: The property can be statically evaluated. E.g. the required memory of a finite state machine model.  Dynamic property: The property can only be dynamically

• evaluated. E.g. the required memory of a C program.

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 19 ESII: Specification & Modeling

Need for heterogeneous modeling

 A system consists of different parts. E.g. data flow and control flow dominated parts.  Different objectives apply for different parts. E.g. the system and its environment.  Different parts are developed by different people and tools. E.g. HW and SW.

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 20 ESII: Specification & Modeling

So, what is a system?

Some definitions:  “an aggregation or assemblage of things so combined by nature or man as to form an integral or complex whole” [Encyclopedia America]  “a regularly interacting or independent group of items forming a unified whole” [Webster’s Dictionary]  “a combination of components that act together to perform a function not possible with any of the individual parts” [IEEE Standard Dictionary of Electrical and Electronic Terms]

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 21 ESII: Specification & Modeling

Input-Output modeling process

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 22 ESII: Specification & Modeling

Mathematical models of real systems

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 23 ESII: Specification & Modeling

Example: temperature controller

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 24 ESII: Specification & Modeling

Static and dynamic systems

Definition: A static system is one where the

• utput y(t) is independent of past values of

the input u(t0), t0 < t for all t Definition: A dynamic system is one where the output y(t) depends on the current input value u(t) and on at least another input value u(t0) with t0 < t, y(t) = f(u(t), u(t0)).

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 25 ESII: Specification & Modeling

Time-varying and time-invariant systems

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 26 ESII: Specification & Modeling

Example: time-invariant system

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 27 ESII: Specification & Modeling

The concept of state

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 28 ESII: Specification & Modeling

State space

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 29 ESII: Specification & Modeling

State space model for continuous time, continuous state systems

(src: A. Jantsch)

(i.e. differential equation; g - state function)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 30 ESII: Specification & Modeling

State space model for discrete time systems

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 31 ESII: Specification & Modeling

State space model time-invariant discrete time

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 32 ESII: Specification & Modeling

Linear and non-linear systems

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 33 ESII: Specification & Modeling

Deterministic, stochastic and non-deterministic systems

Definition: A system model is deterministic if the

• utput function f and the state function g are

functions in the sense that they evaluate a given argument always and unambiguously to the same result. A system model is stochastic if at least one of their

• utput variables is a random variable.

A system model is nondeterministic if a given input may result in different outputs.

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 34 ESII: Specification & Modeling

Events

Events are associated with a time instance and have no duration.  Arrival of a message;  Change of a signal value;  Change of a state;  A counter exceeding a given threshold value;  An elapsed time period;  etc.

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 35 ESII: Specification & Modeling

Time-driven and event-driven systems

In time-driven systems the advance of time causes the system to become active. In event-driven systems the occurrence of an event causes the system to become active.

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 36 ESII: Specification & Modeling

Systems classification summary

(src: A. Jantsch)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 37 ESII: Specification & Modeling

References and Sources

 [Vahid02] F. Vahid, T. Givargis, Embedded System Design, John Wiley&Sons, 2002.  [BLee00] B. Lee, Specification and Design of Reactive Systems, PhD Dissertation, UC Berkeley, Spring 2000.  [A. Jantsch] A. Jantsch, “Modeling Embedded Systems and SoCs”, Morgan Kaufmann Publishers, 2004.

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 38 ESII: Specification & Modeling

Extra Slides

• Prof. Dr. J. Henkel, M. Shafique
• Prof. Dr. J. Henkel, M. Shafique

CES CES - Chair for Embedded Systems Chair for Embedded Systems Karlsruhe Institute of Technology, Germany Karlsruhe Institute of Technology, Germany

Today: Specification and Modeling I Today: Specification and Modeling I

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 39 ESII: Specification & Modeling

Are these System Linear???

 y(n) = A*x(n)+B y(n) = A*x(n)+B  y(n) = x(n y(n) = x(n2)  y(n) = x y(n) = x2(n) (n)

• J. Henkel, M. Shafique, KIT, WS1011

http://ces.itec.kit.edu 40 ESII: Specification & Modeling

18

Embedded Systems Design: A Unified Hardware/Software Introduction, (c) 2000 Vahid/Givargis

Language subset approach

• Follow rules (template) for capturing

state machine constructs in equivalent sequential language constructs

• Used with software (e.g.,C) and

hardware languages (e.g.,VHDL)

• Capturing UnitControl state machine

in C

– Enumerate all states (#define) – Declare state variable initialized to initial state (IDLE) – Single switch statement branches to current state’s case – Each case has actions

• up, down, open, timer_start

– Each case checks transition conditions to determine next state

• if(…) {state = …;}

#define IDLE0 #define GOINGUP1 #define GOINGDN2 #define DOOROPEN3 void UnitControl() { int state = IDLE; while (1) { switch (state) { IDLE: up=0; down=0; open=1; timer_start=0; if (req==floor) {state = IDLE;} if (req > floor) {state = GOINGUP;} if (req < floor) {state = GOINGDN;} break; GOINGUP: up=1; down=0; open=0; timer_start=0; if (req > floor) {state = GOINGUP;} if (!(req>floor)) {state = DOOROPEN;} break; GOINGDN: up=1; down=0; open=0; timer_start=0; if (req < floor) {state = GOINGDN;} if (!(req<floor)) {state = DOOROPEN;} break; DOOROPEN: up=0; down=0; open=1; timer_start=1; if (timer < 10) {state = DOOROPEN;} if (!(timer<10)){state = IDLE;} break; } } }

UnitControl state machine in sequential programming language

ESII: Spec & Modeling