Embedded 120206023739-phpapp02

An introduction to

Embedded Systems
Michele Arcuri
Software Engineering 2
A.A. 2001-2002

Outline
 Introduction
 Embedded

System Design
 Formal System Specification
 Introduction to POLIS Design Methodology
As example that uses a formal system specification

 References
 Glossary

Introduction
 Fundamental
–
–

What is an embedded system?
Embedded System Applications

 Main
–
–
–

concepts and definitions

characteristics

Typical Embedded System Constraints
Distinctive Embedded System Attributes
Reactive Real-Time Embedded Systems

Embedded System =
Computer Inside a Product



An embedded system
–
–





uses a computer to perform some function, but
is not used (nor perceived) as a computer

Software is used for features and flexibility
Hardware is used for performance
Typical characteristics
–
–
–

it performs a single function
it is part of a larger (controlled) system
cost and reliability are often the most significant aspects

Typical Embedded System Organization

ADC
ASIC
DAC
FPGA

Embedded System Applications


Consumer electronics
(microwave oven, camera, ...)



Telecommunication switching and terminal
equipment
(cellular phone, ...)



Automotive, aero-spatial
(engine control, anti-lock brake, ...)



Plant control and production automation
(robot, plant monitor, ...)



Defense
(radar, intelligent weapon, ...)

Typical Embedded System Constraints


Small Size, Low Weight
–
–



Low Power
–
–



–
–

Power fluctuations, RF interference, lightning
Heat, vibration, shock
Water, corrosion, physical abuse

Safety-critical operation
–
–



Battery power for 8+hours (laptops often last only 2 hours)
Limited cooling may limit power even if AC power available

Harsh environment
–



Hand-held electronics
Transportation applications – weight costs money

Must function correctly
Must not function incorrectly

Extreme cost sensitivity

Small Size, Low Weight


Embedded computers are embedded in something
–

Form factor may be dictated by aesthetics
Electronics may be squeezed into whatever space is left over

–

Form factor may be carry-over from previous, less-capable systems

–



Weight may be critical
–
–



Fuel economy for transportation
Comfort for carried objects

Hardware design challenges
–
–

Non-rectangular, 3-D geometries
Integrating digital + analog + power on single chip for smaller
size/lighter weight

Power management


Power is often limited due to power storage capacity



"Low Power" desktop CPUs are not really suitable for many
embedded applications
–
–
–



3-7 Watt Low Power Pentium for laptop
Less than 1 Watt desired for PDA
Less than 1 mW needed for many embedded systems (may need to
run 30 days to 5 years on a battery)

–

Ultra-low power
Fast wake-up when needed

–

Low-cost perpetual power generation

–

Harsh Environment


Many embedded systems do not have a controlled
environment
–
–
–
–
–
–
–
–



Heat from combustion / limited cooling
Vibration / shock
Lightning / Electromagnetic Interference (EMI) / Electrostatic
Discharge (ESD)
"Dirty" power supplies
Water / corrosion
Fire
Shipping damage
Physical abuse ("drop test")

–
–

Accurate thermal modeling
Use of different components for each design, depending on operating
environment

Safe and Reliable


Systems must be safe to protect people and property
–

–



"Mission-critical" systems ~ if electronics fail, someone could die or
lose lots of money
Software and hardware must anticipate failure modes

Traditional fault-tolerant techniques work, but are expensive
–
–



Replicated hardware
Distributed consensus

Hw and Sw design challenges:
–
–

Realistic reliability predictions with commercial components
Use of validation techniques (simulation, formal verification,…) to
correct most errors before implementation

Distinctive Embedded System Attributes


Reactive: computation occur in response to external
events
–
–



Periodic events
Aperiodic events

Real Time: correctness is partially a function of time
–

Hard real time



–

Soft real time



–

Absolute deadline, beyond which answer is useless
(May include minimum and maximum time = deadline window)
Approximate deadline
Answer degrades with time difference from deadline

Firm real time


Result has no utility outside deadline window, but system can
withstand a few missed results

Reactive Real-Time Embedded Systems


Maintain a continuous and permanent interaction
with the environment
–





Must obey timing constraints dictated by the environment

Specified as a collection of concurrent modules
which talk to each other
Implemented using a mix of
–
–
–

processors
complex peripherals
custom hardware and software

Embedded System Design






The Design Problem
System Architecture
Traditional Methodology
HW/SW Co-Design Methodology
Behavior/Architecture Co-Design Methodology

The Design Problem
 Deciding

the software and hardware
architecture for the system
–
–

which parts should be implemented in software
running on the programmable components
and which should be implemented in more
specialized hardware

System Architecture


Hardware
–
–



One micro-controller (to be extended later…)
ASICs

Software
–
–

Set of concurrent tasks
Customized operating system
(Real-Time scheduler)



Interfaces
–
–

Hardware modules
Software I/O drivers
(polling, interrupt handlers, ...)

Traditional Methodology

Hardware/Software
Partitioning and Allocation
HW Design
& Build

SW Design
& Code
Interface
Design
HW/SW
Integration

Problems with Past Design Method


Lack of unified system-level representation
–
–

Can not verify the entire HW-SW system
Hard to find incompatibilities across HW-SW boundary
(often found only when prototype is built)





Architecture is defined a priori, based on expert
evaluation of the functionality and constraints
Lack of well-defined design flow
–
–

Time-to-market problems
Specification revision becomes difficult

HW/SW Co-Design Methodology

Hardware/Software
Partitioning and Allocation
HW Design
& Build

SW Design
& Code
Interface
Design
HW/SW
Integration


Behavior/Architecture Co-Design Methodology
Architectural
Architectural
Architectural
Architectural
Specifications
Specifications
Specifications
Specifications

Behavioral
Specification

Mapping

High Level
Performance Simulation
System
Synthesis

C

HDL

Behavior/Architecture Co-Design
Goals


Clear separation between
–
–
–



behavior
architecture
communication

Same framework for
–
–
–

specification and behavioral simulation
performance simulation
refinement to implementation
HW, SW and interface synthesis
 rapid prototyping


Formal System Specification



Why a Formal System Specification?
–
–



Synthesis
–
–
–



Formal Model
Language
Mapping from Specification to Architecture
Partitioning
Hardware and software synthesis

System Validation
–
–

Simulation
Formal Verification

Why a Formal System Specification?


In the development of embedded reactive
systems the specification of the requirements is
most critical issue.



The reliability of embedded system depends on well-actuated
reactions according to the users’ expectations, even in
exceptional situations
Embedded systems – especially when running in risk critical
applications – demand a high degree of reliability
Statistics show that in typical application areas more than 50%
of the malfunctions that occur are not problems with
correctness of implementation but with misconceptions in
capturing the requirements (conceptual requirements errors)






Main purpose: provide clear and unambiguous
description of system function
–
–

documentation of initial design process
allow the application of Computer Aided Design
design space exploration and architecture selection
 HW/SW partitioning
 HW, SW, interface, RTOS synthesis
 validation
 testing


–

ideally should not constrain the implementation




Distinguish between models and languages
Model choice depends on
–

Application domain
E.g. data flow for digital signal processing, finite state machines
for control, Discrete Event for hardware, ...



Language choice depends on
–
–
–

Available tools
Personal taste and/or company policy
Underlying model
(the language must have a semantics in the chosen model)

Formal Model (based on L. Lavagno’s articles)


Consist of
–

–

–

–

A functional specification, given as a set of explicit or
implicit relations which involve inputs, outputs and possibly
internal (state) information
A set of properties that the design must satisfy, given as a
set of relations over inputs, outputs, and states, that can be
checked against the functional specification.
A set of performance indices that evaluate the quality of
the design in terms of cost, reliability, speed, size, etc.,
given as a set of equations involving, among other things,
inputs and outputs.
A set of constraints on performance indices, specified as
a set of inequalities.

Language
A
–
–
–

language is based on
a set of symbols
rules for combining them (its syntax)
rules for interpreting combinations of symbols (its
semantics).

Synthesis




The stage in the design refinement where a more
abstract specification is translated into a less
abstract specification
For embedded systems, synthesis is a combination
of manual and automatic processes, and is often
divided into three stages
–
–
–

mapping to architecture, in which the general structure of
an implementation is chosen
partitioning, in which the sections of a specification are
bound to the architectural units
hardware and software synthesis, in which the details of
the units are filled out

Mapping from Specification to
Architecture


The problem of architecture selection and/or design is one of
the key aspects of the design of embedded systems



The mapping problem takes as input a
functional specification and produces as output
an architecture and an assignment of functions
to architectural units

Partitioning


Partitioning is a problem in embedded systems because of the
heterogeneous hardware/software mixture



Partitioning determines which parts of the
specification will be implemented on architecture
components

Hardware and Software Synthesis


After partitioning (and sometimes before partitioning, in order to
provide cost estimates) the hardware and software components
of the embedded system must be implemented



Hardware and Software Synthesis realize this.



The inputs to the problem are a specification, a set of
resources and possibly a mapping onto an architecture
The objective is to realize the specification with the minimum
cost



System Validation
 Validation

refers to the process of
determining that a design is correct



Simulation remains the main tool to validate a model,
but the importance of formal verification is growing,
especially for safety-critical embedded systems.

System Validation


Safety-critical real-time systems must be validated
–
–



Explicit exhaustive simulation is infeasible
Formal verification can achieve the same level of safeness

How to use verification and simulation together ?
–

Simulation can be used initially for



–
–

Quick functional debugging
Ruling out obvious cases (can be expensive to verify)

Then formal verification takes over for exhaustive checking, but...
Simulation is used again as user interface to provide the designer
with error traces

Simulation


Simulation is the operation of a real-world
process or system over time



Simulation involves the generation of an artificial
history of the system, and the observation of that
artificial history to draw inferences concerning the
operating characteristics of the real system that is
represented

Simulation


Simulating embedded system is challenging because they
are heterogeneous
–
–
–



Both software and hardware components must be simulated at the
same time (the co-simulation problem)
To test software as fast as possible are used machine that may be
faster the final embedded CPU, and is very different from it
Necessary to keep the hardware and software simulation
synchronized, so that they interact just as they will in the target
system

A solution is to use a general-purpose software simulator
to simulate a model of target CPU
–

Example: simulator based on VHDL or Verilog

Formal Verification
 Formal

verification is the process of
mathematically checking that the behavior of
a system, described using a formal model,
satisfies a given property, also described
using a formal model

Formal Verification


Two distinct types of verification
–

Specification Verification: checking an abstract property
of a high-level model


–

example: checking whether a protocol modeled as a network of
communicating FSMs can ever deadlock

Implementation Verification: checking if a relatively lowlevel model correctly implements a higher-level model or
satisfies some implementation-dependent property


example: checking whether a piece of hardware correctly
implements a given FSM, or whether a given dataflow network
implementation on a given DSP completely processes an input
sample before the next one arrives.

Introduction to POLIS Design
Methodology
 POLIS
–

POLIS Co-design Methodology

 Polis
–
–
–
–

Co-design

Design Flow

The ESTEREL language
The ECL language
CFSM (Codesign Finite State Machines)
Why hardware prototypes ?

POLIS Co-design


Polis is a methodology developed by Cadence Berkeley Labs
and Politecnico di Torino from 1993



Is also a CAD tool to design complex and heterogeneous
embedded systems
–

The POLIS system is freely available on the WEB:
http://www-cad.eecs.berkeley.edu/~polis

<More…>

POLIS Co-design Methodology
Formal
Verification

Graphical FSM

ESTEREL

................

Compilers
Partitioning

CFSMs

Sw Synthesis

Simulation

Intfc + RTOS
Synthesis

Sw Code +
RTOS

Hw Synthesis

Logic Netlist
Rapid prototyping

Polis Design Flow


System specification:
–
–
–




SW synthesis and estimation
High-level co-simulation
–
–





ESTEREL
ECL
graphical CFSM net editor

functional debugging
architecture selection and evaluation

Formal verification
SW, HW, RTOS synthesis
Low-level co-simulation and prototyping

The ESTEREL language
 Designed

at INRIA
 Textual imperative language with sequential
an concurrent statements that describe
hierarchically-arranged processes
 High-level reactive control (signals,
concurrency, pre-emption)
 Rigorous mathematical semantics (FSM)
 Strong analysis and optimization tools
<Example>

The ECL language
 ECL

is a research project that began at
Cadence Berkeley Labs
 Language based on a combination of Esterel
and C to create an integrated specification
environment
 The goal is to model concurrent processes
that may be communicating synchronously or
asynchronously
<Example>

ECL compilation
ECL
Specification

Esterel Code

C - code
Simulation
Model
Implementation
HW / SW

CFSM


Codesign Finite State Machines
–
–
–
–

A Finite State Machine (FSM)
Input events, output events and state events
Initial values (for state events)
A transition function
Transitions may involve complex, memory-less, instantaneous
arithmetic and/or Boolean functions
 All the state of the system is under form of events


–

Globally Asynchronous Locally Synchronous (GALS) model
for heterogeneous implementation
<Example>

Finite State Machines (FSM)


FSMs are an attractive model for embedded systems
because:
–
–
–



A FSM consists of:
–
–
–
–
–




The amount of memory required is always decidable
Halting and performance questions are always decidable
In theory, each state can be examined in finite time
A set of input symbols
A set of output signals
A finite set of states with an initial state
An output function mapping inputs and states to outputs
A next-state function mapping inputs and states to (next) states

Good for modeling sequential behavior
Impractical for modeling concurrency without mechanisms
that reduce the complexity (e.g. non-determinism)

Event



One-way data communication
Need efficient implementation
(interrupts, buffers...)



No mutual synchronization requirement, but...




Building block for higher-level synchronization primitives

Examples:
–
–

valued event : temperature sample
pure event : excessive temperature alarm

Why hardware prototypes ?


High-level co-simulation cannot be used to validate the
final implementation
–

need a much more detailed model of HW and SW architecture



Low-level co-simulation (using HW simulator) is too slow
Need to validate the design in the real environment



Example: engine control



–

–

specification can not be formalized
(“must run well”)
must be loaded on a vehicle for test drives

References


Philip Koopman
“Embedded System Foundations”
An introductory seminar of course “Distributed Embedded Systems” of
Carnegie Mellon University (2001)
http://www.ece.cmu.edu/~ece549/index.html



Philip Koopman

“Embedded System Design Issue (the Rest of the Story)”
Proceedings of the 1996 International Conference on Computer Design,
Austin, October 7-9 1996
http://www-2.cs.cmu.edu/~koopman/personal.html#publication


S. Edwards, L. Lavagno, E. A. Lee, A. Sangiovanni-Vincentelli
“Design of Embedded System: Formal Models, Validation and Synthesis”
In Proceedings of the IEEE, vol. 85, (no.3), March 1997. p.366-90

References


L. Lavagno
“Behavior/architecture Co-Design of Embedded Systems”
A seminar to introduce Co-Design and Polis methodology showed at
University of Udine
http://web.diegm.uniud.it/Utenti/lavagno/public_html/hwsw.html



POLIS Co-design Methodology Homepage
http://www-cad.eecs.berkeley.edu/~polis
Where it is possible to download the tool and the manual of Polis



Michael Barr’s Embedded Systems Glossary
http://www.netrino.com/Publications/Glossary/
An updated web version of glossary written in the book “Programming
Embedded Systems in C and C++” of same author

Glossary


ADC (analog-to-digital converter)
–



A hardware device that reads an analog signal--typically a
voltage--compares it to a reference signal and converts the
resulting percentage to a digital value that can be read by a
processor.

ASIC
–

Application-Specific Integrated Circuit. A piece of customdesigned hardware in a chip.

Glossary


DSP (digital signal processor)
–

A device that is similar to a microprocessor, except that the
internal CPU has been optimized for use in applications
involving discrete-time signal processing. In addition to
standard microprocessor instructions, DSPs usually support
a set of specialized instructions, like multiply-andaccumulate, to perform common signal-processing
computations quickly. A Harvard architecture, featuring
separate code and data memory spaces, is commonly used
to speed data throughput. Common DSP families are TI's
320Cxx and Motorola's 5600x series.

Glossary


DAC (digital-to-analog converter)
–



A hardware device that takes a digital value as its input
(from a processor) and converts that to an analog output
signal--typically a voltage.

FPGA
–

Field Programmable Gate Array. A type of logic chip, with
thousands of internal gates, that can be programmed.
FPGAs are especially popular for prototyping integrated
circuit designs. However, once the design is finalized, hardwired chips called ASICs are often used instead for their
faster performance and lower cost.

Glossary


Firmware
–



Embedded software that is stored as object code within a
ROM. This name is more common among the users of
digital signal processors.

Microcontroller
–

A microcontroller is very similar to a microprocessor. The
main difference is that a microcontroller is designed
specifically for use in embedded systems. Microcontrollers
typically include a CPU, memory (a small amount of RAM
and/or ROM), and other peripherals on the same chip.
Common examples are the PIC and 8051, Intel's 80196,
and Motorola's 68HCxx series.

Glossary


MAC (multiply-and-accumulate)
–



A special CPU instruction, common on digital signal
processors, that performs both a multiplication and an
addition in a single instruction cycle. The result of the
multiplication is typically added to a sum kept in a register.
A multiply-and-accumulate (MAC) instruction is helpful for
speeding up the execution of the digital filters and
transforms required in signal processing applications.

PWM (pulse width modulation)
–

A technique for controlling analog circuits with a processor's
digital outputs. PWM is employed in a wide range of
applications, from measurement and communications to
power control and conversion.

Glossary


RTOS (real-time operating system)
–



An operating system designed specifically for use in realtime systems.

Real-time system
–

Any computer system, embedded or otherwise, that has
deadlines. The following question can be used to
distinguish real-time systems from the rest: "Is a late
answer as bad, or even worse, than a wrong answer?" In
other words, what happens if the computation doesn't finish
in time? If nothing bad happens, it's not a real-time system.
If someone dies or the mission fails, it's generally
considered "hard" real-time, which is meant to imply that the
system has "hard" deadlines. Everything in between is "soft"
real-time.

Key aspects of the methodology




un-biased specification, using extended Finite
State Machines that can be (almost) indifferently
implemented in HW or SW
support of multiple specification languages
(Esterel, graphical state machines, VHDL, Verilog, ...)



design aids for quick evaluation and optimized
synthesis, to guide the (manual) architecture
selection and partitioning step.

Key aspects of the methodology






automated generation of interface circuitry and
software (device drivers) for the chosen microcontroller configuration.
accurate estimation of software cost and
performance (memory and cycles) on a range of
micro-controllers, without the need to compile and
profile it.
emphasis on the verifiability (both with simulation
and formal techniques) of each design level, from
specification to implementation.

Example: readable counter
module counter:
input go, reset, req; output ack(integer);
var t:integer in
req and not go
loop do
t:=0;
=> ack(t)
every go do
s1
s0
t:=t+1;
await req; emit ack(t)
go => t:=t+1
end
reset => t:=0
watching reset
end end.

Example : complete ECL module
typedef { byte hdr[HSIZE]; byte data[DSIZE]; int crc; } frame_t;
module frame_proc (input byte in, output frame_t out)
{
signal frame_t frame; signal bad_crc;
byte buf[SIZE]; frame_t f; int crc;
while (1) { /* get bytes into frame */
for (i = 0; i < SIZE; i++) {await (in); buf[i] = in;}
create_frame_from_buffer(&f, buf);
emit (frame, f);
} PAR
while (1) { /* check CRC */
await (frame);
for (i = 0; i < HSIZE; i++) crc ^= frame.hdr[i];
if (crc != frame.crc) emit (bad_crc);
} PAR
while (1) { /* process address (if correct) */
await (frame);
do { /* … */; emit (out, frame) } abort (bad_crc);
}}

CFSM Example
 Informal

specification:

If the driver
turns on the key, and
does not fasten the seat belt within 5 seconds

then an alarm beeps
for 5 seconds, or
until the driver fastens the seat belt, or
until the driver turns off the key

CFSM Example
KEY_ON => START_TIMER

OFF

WAIT

KEY_OFF or
BELT _ON =>

END_TIMER_10 or
BELT_ON or
KEY_OFF => ALARM_OFF

END_TIMER_5 =>
ALARM_ON

ALARM

If no condition is satisfied, self-loop and no output ( empty execution)

Embedded 120206023739-phpapp02

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (16)

Similaire à Embedded 120206023739-phpapp02

Similaire à Embedded 120206023739-phpapp02 (20)

Dernier

Dernier (20)

Embedded 120206023739-phpapp02