EMBEDDED by yaofenjin


									  An introduction to
Embedded Systems

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

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

   Glossary

   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

Embedded System Applications

   Consumer electronics
    (microwave oven, camera, ...)
   Telecommunication switching and terminal
    (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
    –   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
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
    –   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 Design
Traditional Methodology

               Partitioning and Allocation

   HW Design                                 SW Design
    & Build                                   & Code

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 Design
HW/SW Co-Design Methodology

               Partitioning and Allocation

   HW Design                                 SW Design
    & Build                                   & Code

Embedded System Design
Behavior/Architecture Co-Design Methodology

   Behavioral                                    Architectural
  Specification                                  Specifications


                        High Level
                  Performance Simulation

                         System            C    HDL
Behavior/Architecture Co-Design

   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 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.

   A language is based on
    –   a set of symbols
    –   rules for combining them (its syntax)
    –   rules for interpreting combinations of symbols (its

   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

   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 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
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
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 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

   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
   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

   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:

POLIS Co-design Methodology

                Graphical FSM         ESTEREL          ................

 Partitioning                         CFSMs

                   Sw Synthesis     Intfc + RTOS      Hw Synthesis

 Simulation        Sw Code +                          Logic Netlist

                                  Rapid 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
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
   The goal is to model concurrent processes
    that may be communicating synchronously or
ECL compilation


  Esterel Code                    C - code


                    HW / SW

   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

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)

   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

   Philip Koopman
    “Embedded System Foundations”
    An introductory seminar of course “Distributed Embedded Systems” of
    Carnegie Mellon University (2001)

   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
   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
   L. Lavagno
    “Behavior/architecture Co-Design of Embedded Systems”
    A seminar to introduce Co-Design and Polis methodology showed at
    University of Udine
   POLIS Co-design Methodology Homepage
    Where it is possible to download the tool and the manual of Polis

   Michael Barr’s Embedded Systems Glossary
    An updated web version of glossary written in the book “Programming
    Embedded Systems in C and C++” of same author

   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

   ASIC
    –   Application-Specific Integrated Circuit. A piece of custom-
        designed hardware in a chip.

   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.

   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.

   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.

   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.

   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 in
loop do                                      req and not go
    t:=0;                                       => ack(t)
    every go do
                                          s1                   s0
         await req; emit ack(t)                go => t:=t+1
watching reset                                          reset => t:=0
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

                             KEY_OFF or       END_TIMER_5 =>
                             BELT _ON =>      ALARM_ON

            END_TIMER_10 or
            BELT_ON or
            KEY_OFF => ALARM_OFF

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

To top