Embedded System Design
Description
Until the late eighties, information processing was associated with large mainframe computers and huge tape drives. During the nineties, this trend shifted towards information processing with personal computers, or PCs. The trend towards miniaturization continues. In the future, most of the information processing systems will be quite small and embedded into larger products such as transportation and fabrication equipment. Hence, these kinds of systems are called embedded systems. It is expected that the total market volume of embedded systems will be significantly larger than that of traditional information processing systems such as PCs and mainframes. Embedded systems share a number of common characteristics. For example, they must be dependable, efficient, meet real-time constraints and require customized user interfaces (instead of generic keyboard and mouse interfaces). Therefore, it makes sense to consider common principles of embedded system design.
EmbeddedSystem Design starts with an introduction into the area and a survey of specification languages for embedded systems. A brief overview is provided of hardware devices used for embedded systems and also presents the essentials of software design for embedded systems. Real-time operating systems and real-time scheduling are covered briefly. Techniques for implementing embedded systems are also discussed, using hardware/software codesign. It closes with a survey on validation techniques.
Embedded System Design can be used as a text book for courses on embedded systems and as a source which provides pointers to relevant material in the area for PhD students and teachers. The book assumes a basic knowledge of information processing hardware and software.
More details
Other editions
Additional editions
Person
Dr. Peter Marwedel received his PhD in Physics from the University of Kiel in 1974. He is one of the early researchers in high level synthesis, working on the MIMOLA system for a number of years. Dr. Marwedel is a professor at the University of Dortmund since 1989. He has served as the chairman of the computer science department, has played a leading role in establishing the Design, Automation and Test in Europe (DATE) conference and is the chairman of the Informatik Centrum Dortmund (ICD), a technology transfer centre.
Content
Chapter 2
SPECIFICATIONS (p. 13-14)
2.1 Requirements
Consistent with the simplified design flow (see .g. 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 speci.cation 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 features: 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 ef.cient, no obstacles prohibiting the generation of ef.cient 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 veri.cation 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 .g. 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.
