An introduction toEmbedded 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 concepts and definitions– What is an embedded system?– Embedded System Applications

Main characteristics– Typical Embedded System Constraints– Distinctive Embedded System Attributes– Reactive Real-Time Embedded Systems

What is an embedded system?

Embedded System =

Computer Inside a Product

What is an embedded system?

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– Hand-held electronics– Transportation applications – weight costs money

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

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

Safety-critical operation– 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) Hardware design challenges

– 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")

Hardware design challenges– 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

Absolute deadline, beyond which answer is useless (May include minimum and maximum time = deadline window)

– Soft real time 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, ...)

Embedded System DesignTraditional Methodology

HW Design& Build

Hardware/SoftwarePartitioning and Allocation

SW Design& Code

InterfaceDesign

HW/SWIntegration

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

Embedded System DesignHW/SW Co-Design Methodology

HW Design& Build

Hardware/SoftwarePartitioning and Allocation

SW Design& Code

InterfaceDesign

HW/SWIntegration

Embedded System DesignBehavior/Architecture Co-Design Methodology

Mapping

BehavioralSpecification

ArchitecturalSpecifications

ArchitecturalSpecifications

ArchitecturalSpecifications

ArchitecturalSpecifications

High Level Performance Simulation

SystemSynthesis

C HDL

Behavior/Architecture Co-DesignGoals

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? Formal System Specification

– Formal Model– Language

Synthesis– 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)

Formal System Specification

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

Formal System Specification

Distinguish between models and languages Model choice depends on

– Application domainE.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 low-

level 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 Co-design– POLIS Co-design Methodology

Polis 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

Graphical FSMGraphical FSM ESTERELESTEREL ................................

CompilersCompilers

PartitioningPartitioning

Sw SynthesisSw Synthesis

FormalFormal

VerificationVerification

Sw Code + Sw Code +

RTOSRTOSLogic NetlistLogic NetlistSimulationSimulation

Hw SynthesisHw SynthesisIntfc + RTOSIntfc + RTOS

SynthesisSynthesis

CFSMsCFSMs

Rapid prototypingRapid prototyping

Polis Design Flow

System specification:– ESTEREL– ECL– graphical CFSM net editor

SW synthesis and estimation High-level co-simulation

– 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

ImplementationHW / SW

ECLSpecification

Esterel Code C - code

SimulationModel

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:

– 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 FSM consists of:– 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 1996http://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 Udinehttp://web.diegm.uniud.it/Utenti/lavagno/public_html/hwsw.html

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

Michael Barr’s Embedded Systems Glossaryhttp://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 custom-

designed 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-and-accumulate, 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, hard-wired 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 real-time

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 micro-controller 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 inloop do

t:=0; every go do

t:=t+1;await req; emit ack(t)

end watching resetend end.

go =>=> t:=t+1

reset =>=> t:=0

s1 s0

req and not go

=> => ack(t)

Example : complete ECL module

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); } }

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;

CFSM Example

Informal specification:If the driver

turns on the key, and

does not fasten the seat belt within 5 seconds

then an alarm beepsfor 5 seconds, or

until the driver fastens the seat belt, or

until the driver turns off the key

CFSM Example

KEY_ON => START_TIMERKEY_ON => START_TIMER

END_TIMER_5 => END_TIMER_5 =>

ALARM_ONALARM_ONKEY_OFF orKEY_OFF or

BELT _ON =>BELT _ON =>

END_TIMER_10 orEND_TIMER_10 or

BELT_ON orBELT_ON or

KEY_OFF => ALARM_OFFKEY_OFF => ALARM_OFF

WAITWAIT

ALARMALARM

OFFOFF

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