An introduction to Embedded Systems

1. An introduction toEmbedded Systems Michele Arcuri Software Engineering 2 A.A. 2001-2002

2. Outline • Introduction • Embedded System Design • Formal System Specification • Introduction to POLIS Design Methodology As example that uses a formal system specification • References • Glossary

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

4. What is an embedded system? Embedded System = Computer Inside a Product

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

6. Typical Embedded System Organization ADC ASIC DAC FPGA

7. 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, ...)

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

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

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

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

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

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

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

15. Embedded System Design • The Design Problem • System Architecture • Traditional Methodology • HW/SW Co-Design Methodology • Behavior/Architecture Co-Design Methodology

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

17. 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, ...)

18. Embedded System DesignTraditional Methodology Hardware/Software Partitioning and Allocation HW Design & Build SW Design & Code Interface Design HW/SW Integration

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

20. Embedded System DesignHW/SW Co-Design Methodology Hardware/Software Partitioning and Allocation HW Design & Build SW Design & Code Interface Design HW/SW Integration

21. Architectural Specifications Architectural Specifications Architectural Specifications Architectural Specifications C HDL Embedded System DesignBehavior/Architecture Co-Design Methodology Behavioral Specification Mapping High Level Performance Simulation System Synthesis

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

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

24. 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)

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

26. Formal System Specification • Distinguish between modelsand 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)

27. 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 propertiesthat 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 indicesthat 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 constraintson performance indices, specified as a set of inequalities.

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

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

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

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

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

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

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

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

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

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

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

39. 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 ?

40. 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 isfreely available on the WEB: http://www-cad.eecs.berkeley.edu/~polis <More…>

41. Formal Verification Compilers Partitioning Simulation POLIS Co-design Methodology ................ ESTEREL Graphical FSM CFSMs Sw Synthesis Hw Synthesis Intfc + RTOS Synthesis Sw Code + RTOS Logic Netlist Rapid prototyping

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

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

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

45. ECL Specification EsterelCode C - code Simulation Model Implementation HW / SW ECL compilation

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

47. 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)

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

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

50. References • Philip Koopman “Embedded System Foundations” An introductoryseminar 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