E-Book, Englisch, 258 Seiten
ISBN: 978-0-387-29237-3
Verlag: Springer-Verlag
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)
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.
Autoren/Hrsg.
Weitere Infos & Material
1;Contents;7
2;Preface;13
3;Acknowledgments;17
4;1 INTRODUCTION;18
4.1;1.1 Terms and scope;18
4.2;1.2 Application areas;22
4.3;1.3 Growing importance of embedded systems;25
4.4;1.4 Structure of this book;26
5;2 SPECIFICATIONS;30
5.1;2.1 Requirements;30
5.2;2.2 Models of computation;33
5.3;2.3 StateCharts;35
5.3.1;2.3.1 Modeling of hierarchy;36
5.3.2;2.3.2 Timers;40
5.3.3;2.3.3 Edge labels and StateCharts semantics;41
5.3.4;2.3.4 Evaluation and extensions;43
5.4;2.4 General language characteristics;44
5.4.1;2.4.1 Synchronous and asynchronous languages;44
5.4.2;2.4.2 Process concepts;45
5.4.3;2.4.3 Synchronization and communication;45
5.4.4;2.4.4 Specifying timing;46
5.4.5;2.4.5 Using non-standard I/O devices;47
5.5;2.5 SDL;47
5.6;2.6 Petri nets;53
5.6.1;2.6.1 Introduction;53
5.6.2;2.6.2 Condition/event nets;57
5.6.3;2.6.3 Place/transition nets;57
5.6.4;2.6.4 Predicate/transition nets;59
5.6.5;2.6.5 Evaluation;61
5.7;2.7 Message Sequence Charts;61
5.8;2.8 UML;62
5.9;2.9 Process networks;67
5.9.1;2.9.1 Task graphs;67
5.9.2;2.9.2 Asynchronous message passing;70
5.9.3;2.9.3 Synchronous message passing;72
5.10;2.10 Java;75
5.11;2.11 VHDL;76
5.11.1;2.11.1 Introduction;76
5.11.2;2.11.2 Entities and architectures;77
5.11.3;2.11.3 Multi-valued logic and IEEE 1164;79
5.11.4;2.11.4 VHDL processes and simulation semantics;86
5.12;2.12 SystemC;90
5.13;2.13 Verilog and SystemVerilog;92
5.14;2.14 SpecC;93
5.15;2.15 Additional languages;94
5.16;2.16 Levels of hardware modeling;96
5.17;2.17 Language comparison;99
5.18;2.18 Dependability requirements;100
6;3 EMBEDDED SYSTEM HARDWARE;104
6.1;3.1 Introduction;104
6.2;3.2 Input;105
6.2.1;3.2.1 Sensors;105
6.2.2;3.2.2 Sample-and-hold circuits;107
6.2.3;3.2.3 A/D-converters;108
6.3;3.3 Communication;110
6.3.1;3.3.1 Requirements;111
6.3.2;3.3.2 Electrical robustness;112
6.3.3;3.3.3 Guaranteeing real-time behavior;113
6.3.4;3.3.4 Examples;114
6.4;3.4 Processing Units;115
6.4.1;3.4.1 Overview;115
6.4.2;3.4.2 Application-Speci.c Circuits (ASICs);117
6.4.3;3.4.3 Processors;117
6.4.4;3.4.4 Reconfigurable Logic;132
6.5;3.5 Memories;135
6.6;3.6 Output;137
6.6.1;3.6.1 D/A-converters;138
6.6.2;3.6.2 Actuators;139
7;4 STANDARD SOFTWARE: EMBEDDED OPERATING SYSTEMS, MIDDLEWARE, AND SCHEDULING;142
7.1;4.1 Prediction of execution times;143
7.2;4.2 Scheduling in real-time systems;144
7.2.1;4.2.1 Classification of scheduling algorithms;145
7.2.2;4.2.2 Aperiodic scheduling;148
7.2.3;4.2.3 Periodic scheduling;152
7.2.4;4.2.4 Resource access protocols;157
7.3;4.3 Embedded operating systems;160
7.3.1;4.3.1 General requirements;160
7.3.2;4.3.2 Real-time operating systems;161
7.4;4.4 Middleware;165
7.4.1;4.4.1 Real-time data bases;165
7.4.2;4.4.2 Access to remote objects;166
8;5 IMPLEMENTING EMBEDDED SYSTEMS: HARDWARE/SOFTWARE CODESIGN;168
8.1;5.1 Task level concurrency management;170
8.2;5.2 High-level optimizations;174
8.2.1;5.2.1 Floating-point to fixed-point conversion;174
8.2.2;5.2.2 Simple loop transformations;176
8.2.3;5.2.3 Loop tiling/blocking;177
8.2.4;5.2.4 Loop splitting;180
8.2.5;5.2.5 Array folding;182
8.3;5.3 Hardware/software partitioning;184
8.3.1;5.3.1 Introduction;184
8.3.2;5.3.2 COOL;185
8.4;5.4 Compilers for embedded systems;194
8.4.1;5.4.1 Introduction;194
8.4.2;5.4.2 Energy-aware compilation;195
8.4.3;5.4.3 Compilation for digital signal processors;198
8.4.4;5.4.4 Compilation for multimedia processors;201
8.4.5;5.4.5 Compilation for VLIW processors;201
8.4.6;5.4.6 Compilation for network processors;202
8.4.7;5.4.7 Compiler generation, retargetable compilers and design space exploration;202
8.5;5.5 Voltage Scaling and Power Management;203
8.5.1;5.5.1 Dynamic Voltage Scaling;203
8.5.2;5.5.2 Dynamic power management (DPM);206
8.6;5.6 Actual design flows and tools;207
8.6.1;5.6.1 SpecC methodology;207
8.6.2;5.6.2 IMEC tool flow;208
8.6.3;5.6.3 The COSYMA design flow;211
8.6.4;5.6.4 Ptolemy II;212
8.6.5;5.6.5 The OCTOPUS design flow;213
9;6 VALIDATION;216
9.1;6.1 Introduction;216
9.2;6.2 Simulation;217
9.3;6.3 Rapid Prototyping and Emulation;218
9.4;6.4 Test;218
9.4.1;6.4.1 Scope;218
9.4.2;6.4.2 Design for testability;219
9.4.3;6.4.3 Self-test programs;222
9.5;6.5 Fault simulation;223
9.6;6.6 Fault injection;224
9.7;6.7 Risk- and dependability analysis;224
9.8;6.8 Formal Veri.cation;226
10;References;229
11;About the Author;244
12;List of Figures;246
13;Index;254
14;More eBooks at www.ciando.com;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.
