Embedded System Design
Description
Embedded systems can be defined as information processing systems embedded into enclosing products such as cars, telecommunication or fabrication equipment. Such systems come with a large number of common characteristics, including real-time constraints, and dependability as well as efficiency requirements. Following the success of information technology (IT) for office and workflow applications, embedded systems are considered to be the most important application area of IT during the coming years. This importance of embedded systems is so far not well reflected in many of the current curricula.
Embedded System Design is intended as an aid for changing this situation. It provides the material for a first course on embedded systems, but can also be used by PhD students and professors.
A key goal of this book is to provide an overview of embedded system design and to relate the most important topics in embedded system design to each other. It should help to motivate students as well as professors to put more emphasis on education in embedded systems. In order to facilitate teaching from this book, slides, exercises and other related material can be downloaded via the author's web page.
More details
Content
2 - Preface [Seite 13]
3 - Acknowledgments [Seite 17]
4 - 1 INTRODUCTION [Seite 18]
4.1 - 1.1 Terms and scope [Seite 18]
4.2 - 1.2 Application areas [Seite 22]
4.3 - 1.3 Growing importance of embedded systems [Seite 25]
4.4 - 1.4 Structure of this book [Seite 26]
5 - 2 SPECIFICATIONS [Seite 30]
5.1 - 2.1 Requirements [Seite 30]
5.2 - 2.2 Models of computation [Seite 33]
5.3 - 2.3 StateCharts [Seite 35]
5.3.1 - 2.3.1 Modeling of hierarchy [Seite 36]
5.3.2 - 2.3.2 Timers [Seite 40]
5.3.3 - 2.3.3 Edge labels and StateCharts semantics [Seite 41]
5.3.4 - 2.3.4 Evaluation and extensions [Seite 43]
5.4 - 2.4 General language characteristics [Seite 44]
5.4.1 - 2.4.1 Synchronous and asynchronous languages [Seite 44]
5.4.2 - 2.4.2 Process concepts [Seite 45]
5.4.3 - 2.4.3 Synchronization and communication [Seite 45]
5.4.4 - 2.4.4 Specifying timing [Seite 46]
5.4.5 - 2.4.5 Using non-standard I/O devices [Seite 47]
5.5 - 2.5 SDL [Seite 47]
5.6 - 2.6 Petri nets [Seite 53]
5.6.1 - 2.6.1 Introduction [Seite 53]
5.6.2 - 2.6.2 Condition/event nets [Seite 57]
5.6.3 - 2.6.3 Place/transition nets [Seite 57]
5.6.4 - 2.6.4 Predicate/transition nets [Seite 59]
5.6.5 - 2.6.5 Evaluation [Seite 61]
5.7 - 2.7 Message Sequence Charts [Seite 61]
5.8 - 2.8 UML [Seite 62]
5.9 - 2.9 Process networks [Seite 67]
5.9.1 - 2.9.1 Task graphs [Seite 67]
5.9.2 - 2.9.2 Asynchronous message passing [Seite 70]
5.9.3 - 2.9.3 Synchronous message passing [Seite 72]
5.10 - 2.10 Java [Seite 75]
5.11 - 2.11 VHDL [Seite 76]
5.11.1 - 2.11.1 Introduction [Seite 76]
5.11.2 - 2.11.2 Entities and architectures [Seite 77]
5.11.3 - 2.11.3 Multi-valued logic and IEEE 1164 [Seite 79]
5.11.4 - 2.11.4 VHDL processes and simulation semantics [Seite 86]
5.12 - 2.12 SystemC [Seite 90]
5.13 - 2.13 Verilog and SystemVerilog [Seite 92]
5.14 - 2.14 SpecC [Seite 93]
5.15 - 2.15 Additional languages [Seite 94]
5.16 - 2.16 Levels of hardware modeling [Seite 96]
5.17 - 2.17 Language comparison [Seite 99]
5.18 - 2.18 Dependability requirements [Seite 100]
6 - 3 EMBEDDED SYSTEM HARDWARE [Seite 104]
6.1 - 3.1 Introduction [Seite 104]
6.2 - 3.2 Input [Seite 105]
6.2.1 - 3.2.1 Sensors [Seite 105]
6.2.2 - 3.2.2 Sample-and-hold circuits [Seite 107]
6.2.3 - 3.2.3 A/D-converters [Seite 108]
6.3 - 3.3 Communication [Seite 110]
6.3.1 - 3.3.1 Requirements [Seite 111]
6.3.2 - 3.3.2 Electrical robustness [Seite 112]
6.3.3 - 3.3.3 Guaranteeing real-time behavior [Seite 113]
6.3.4 - 3.3.4 Examples [Seite 114]
6.4 - 3.4 Processing Units [Seite 115]
6.4.1 - 3.4.1 Overview [Seite 115]
6.4.2 - 3.4.2 Application-Speci.c Circuits (ASICs) [Seite 117]
6.4.3 - 3.4.3 Processors [Seite 117]
6.4.4 - 3.4.4 Reconfigurable Logic [Seite 132]
6.5 - 3.5 Memories [Seite 135]
6.6 - 3.6 Output [Seite 137]
6.6.1 - 3.6.1 D/A-converters [Seite 138]
6.6.2 - 3.6.2 Actuators [Seite 139]
7 - 4 STANDARD SOFTWARE: EMBEDDED OPERATING SYSTEMS, MIDDLEWARE, AND SCHEDULING [Seite 142]
7.1 - 4.1 Prediction of execution times [Seite 143]
7.2 - 4.2 Scheduling in real-time systems [Seite 144]
7.2.1 - 4.2.1 Classification of scheduling algorithms [Seite 145]
7.2.2 - 4.2.2 Aperiodic scheduling [Seite 148]
7.2.3 - 4.2.3 Periodic scheduling [Seite 152]
7.2.4 - 4.2.4 Resource access protocols [Seite 157]
7.3 - 4.3 Embedded operating systems [Seite 160]
7.3.1 - 4.3.1 General requirements [Seite 160]
7.3.2 - 4.3.2 Real-time operating systems [Seite 161]
7.4 - 4.4 Middleware [Seite 165]
7.4.1 - 4.4.1 Real-time data bases [Seite 165]
7.4.2 - 4.4.2 Access to remote objects [Seite 166]
8 - 5 IMPLEMENTING EMBEDDED SYSTEMS: HARDWARE/SOFTWARE CODESIGN [Seite 168]
8.1 - 5.1 Task level concurrency management [Seite 170]
8.2 - 5.2 High-level optimizations [Seite 174]
8.2.1 - 5.2.1 Floating-point to fixed-point conversion [Seite 174]
8.2.2 - 5.2.2 Simple loop transformations [Seite 176]
8.2.3 - 5.2.3 Loop tiling/blocking [Seite 177]
8.2.4 - 5.2.4 Loop splitting [Seite 180]
8.2.5 - 5.2.5 Array folding [Seite 182]
8.3 - 5.3 Hardware/software partitioning [Seite 184]
8.3.1 - 5.3.1 Introduction [Seite 184]
8.3.2 - 5.3.2 COOL [Seite 185]
8.4 - 5.4 Compilers for embedded systems [Seite 194]
8.4.1 - 5.4.1 Introduction [Seite 194]
8.4.2 - 5.4.2 Energy-aware compilation [Seite 195]
8.4.3 - 5.4.3 Compilation for digital signal processors [Seite 198]
8.4.4 - 5.4.4 Compilation for multimedia processors [Seite 201]
8.4.5 - 5.4.5 Compilation for VLIW processors [Seite 201]
8.4.6 - 5.4.6 Compilation for network processors [Seite 202]
8.4.7 - 5.4.7 Compiler generation, retargetable compilers and design space exploration [Seite 202]
8.5 - 5.5 Voltage Scaling and Power Management [Seite 203]
8.5.1 - 5.5.1 Dynamic Voltage Scaling [Seite 203]
8.5.2 - 5.5.2 Dynamic power management (DPM) [Seite 206]
8.6 - 5.6 Actual design flows and tools [Seite 207]
8.6.1 - 5.6.1 SpecC methodology [Seite 207]
8.6.2 - 5.6.2 IMEC tool flow [Seite 208]
8.6.3 - 5.6.3 The COSYMA design flow [Seite 211]
8.6.4 - 5.6.4 Ptolemy II [Seite 212]
8.6.5 - 5.6.5 The OCTOPUS design flow [Seite 213]
9 - 6 VALIDATION [Seite 216]
9.1 - 6.1 Introduction [Seite 216]
9.2 - 6.2 Simulation [Seite 217]
9.3 - 6.3 Rapid Prototyping and Emulation [Seite 218]
9.4 - 6.4 Test [Seite 218]
9.4.1 - 6.4.1 Scope [Seite 218]
9.4.2 - 6.4.2 Design for testability [Seite 219]
9.4.3 - 6.4.3 Self-test programs [Seite 222]
9.5 - 6.5 Fault simulation [Seite 223]
9.6 - 6.6 Fault injection [Seite 224]
9.7 - 6.7 Risk- and dependability analysis [Seite 224]
9.8 - 6.8 Formal Veri.cation [Seite 226]
10 - References [Seite 229]
11 - About the Author [Seite 244]
12 - List of Figures [Seite 246]
13 - Index [Seite 254]
14 - More eBooks at www.ciando.com [Seite 0]
Chapter 2
SPECIFICATIONS (p. 13-14)
2.1 Requirements
Consistent with the simplified design flow (see fig. 1.5), we will now describe requirements and approaches for specifying embedded systems.
There may still be cases in which the specification of embedded systems is captured in a natural language, such as English. However, this approach is absolutely inappropriate since it lacks key requirements for specification techniques: it is necessary to check specifications for completeness, absence of contradictions and it should be possible to derive implementations from the specification in a systematic way. Therefore, specifications should be captured in machine readable, formal languages. Specification languages for embedded systems should be capable of representing the following features1:
* Hierarchy: Human beings are generally not capable of comprehending systems that contain many objects (states, components) having complex relations with each other. The description of all real-life systems needs more objects than human beings can understand. Hierarchy is the only mechanism that helps to solve this dilemma. Hierarchies can be introduced such that humans need to handle only a small number of objects at any time.
There are two kinds of hierarchies:
– Behavioral hierarchies: Behavioral hierarchies are hierarchies containing objects necessary to describe the system behavior. States, events and output signals are examples of such objects.
– Structural hierarchies: Structural hierarchies describe how systems are composed of physical components. For example, embedded systems can be comprised of processors, memories, actors and sensors. Processors, in turn, include registers, multiplexers and adders. Multiplexers are composed of gates.
* Timing-behavior: Since explicit timing requirements are one of the characteristics of embedded systems, timing requirements must be captured in the specification.
* State-oriented behavior: It was already mentioned in chapter 1 that automata provide a good mechanism for modeling reactive systems. Therefore, the state-oriented behavior provided by automata should be easy to describe. However, classical automata models are insufficient, since they cannot model timing and since hierarchy is not supported.
* Event-handling: Due to the reactive nature of embedded systems, mechanisms for describing events must exist. Such events may be external events (caused by the environment) or internal events (caused by components of the system).
* No obstacles to the generation of efficient implementations: Since embedded systems have to be efficient, no obstacles prohibiting the generation of efficient realizations should be present in the specification. Support for the design of dependable systems: Specification techniques should provide support for designing dependable systems. For example, specification languages should have unambiguous semantics, facilitate formal verification and be capable of describing security and safety requirements.
* Exception-oriented behavior: In many practical, systems exceptions do occur. In order to design dependable systems, it must be possible to describe actions to handle exceptions easily. It is not acceptable that exceptions have to be indicated for each and every state (like in the case of classical state diagrams). Example: In fig. 2.1, input k might correspond to an exception.
Specifying this exception at each state makes the diagram very complex. The situation would get worse for larger state diagrams with many transitions. We will later show, how all the transitions can be replaced by a single one.
