Embedded systems and software validation / Abhik Roychoudhury.
Material type:
TextSeries: Morgan Kaufmann series in systems on siliconPublication details: Amsterdam ; Boston : Morgan Kaufmann Publishers/Elsevier, c2009.Description: xii, 254 pages. : illustration ; 25 cmContent type: - text
- unmediated
- volume
- 9780123742308 (hardcover : alk. paper)
- 0123742307 (hardcover : alk. paper)
- 004.1 R.A.E 22
- TK7895.E42 R72 2009
| Item type | Current library | Collection | Call number | Copy number | Status | Date due | Barcode | |
|---|---|---|---|---|---|---|---|---|
Books
|
Main library A1 | Computers & Information Technology ( Computer Science ) | 004.1 R.A.E (Browse shelf(Opens below)) | 1 | Available | 00009630 |
Includes bibliographical references (p. 233-239) and index.
1 Introduction
2 Model Validation
2.1 Platform vs System Behavior
2.2 Criteria for Design Model
2.3 Informal Requirements: A Case Study
2.3.1 The Requirements Document
2.3.2 Simplication of the Informal Requirements
2.4 Common Modeling Notations
2.4.1 Finite State Machines (FSM)
2.4.2 Communicating FSMs
2.4.3 Message Sequence Chart based Models
2.5 Remarks about Modeling Notations
2.6 Model Simulations
2.6.1 FSM simulations
2.6.2 Simulating MSC-based System Models
2.7 Model-based Testing
2.8 Model Checking
2.8.1 Property Specifcation
2.8.2 Checking procedure
2.9 The SPIN Validation Tool
2.10 The SMV Validation Tool
2.11 Case Study: Air Traffic Controller
2.12 References
2.13 Exercises
3 Communication Validation
3.1 Common Incompatibilities
3.1.1 Sending/receiving signals in di erent order
3.1.2 Handling a diffrent signal alphabet
3.1.3 Mismatch in data format
3.1.4 Mismatch in data rates
3.2 Converter Synthesis
3.2.1 Representing Native Protocols and Converters
3.2.2 Basic ideas for Converter synthesis
3.2.3 Various strategies for protocol conversion
3.2.4 Avoiding no-progress cycles
3.2.5 Speculative transmission to avoid deadlocks
3.3 Changing a working design
3.4 References
3.5 Exercises
4 Performance Validation
4.1 The Conventional Abstraction of Time
4.2 Predicting Execution Time of a Program
4.2.1 WCET Calculation
4.2.2 Modeling of Micro-architecture
4.3 Interference within a Processing Element
4.3.1 Interrupts from Environment
4.3.2 Contention and Preemption
4.3.3 Sharing a Processor Cache
4.4 System level communication analysis
4.5 Designing Systems with Predictable Timing
4.5.1 Scratchpad Memories
4.5.2 Time-triggered Communication
4.6 Emerging applications
4.7 References
4.8 Exercises
5 Functionality Validation
5.1 Dynamic or Trace-based Checking
5.1.1 Dynamic Slicing
5.1.2 Fault Localization
5.1.3 Directed Testing Methods
5.2 Formal Verifcation
5.2.1 Predicate Abstraction
5.2.2 Software Checking via Predicate Abstraction
5.2.3 Combining Formal Verifcation with Testing
5.3 References
5.4 Exercises
Modern embedded systems require high performance, low cost and low power consumption. Such systems typically consist of a heterogeneous collection of processors, specialized memory subsystems, and partially programmable or fixed-function components. This heterogeneity, coupled with issues such as hardware/software partitioning, mapping, scheduling, etc., leads to a large number of design possibilities, making performance debugging and validation of such systems a difficult problem.
Embedded systems are used to control safety critical applications such as flight control, automotive electronics and healthcare monitoring. Clearly, developing reliable software/systems for such applications is of utmost importance. This book describes a host of debugging and verification methods which can help to achieve this goal.
• Covers the major abstraction levels of embedded systems design, starting from software analysis and micro-architectural modeling, to modeling of resource sharing and communication at the system level
• Integrates formal techniques of validation for hardware/software with debugging and validation of embedded system design flows
• Includes practical case studies to answer the questions: does a design meet its requirements, if not, then which parts of the system are responsible for the violation, and once they are identified, then how should the design be suitably modified?
There are no comments on this title.