Model-Based Design for Embedded Systems- P42 potx

Nicolescu/Model-Based Design for Embedded Systems 67842_C012 Finals Page 376 2009-10-1 376 Model-Based Design for Embedded Systems /{ #address−cells = <1>; #size−cells = <1>; compatible = "xlnx,virtex"; DDR2_SDRAM: memory@0 { device_type = "memory"; reg = < 0 10000000 >; }; cpus { #address−cells = <1>; #size−cells = <0>; #cpus = <1>; ppc405_0: cpu@0 { clock−frequency = <ee6b280>; compatible = "PowerPC,405", "ibm,ppc405"; d−cache−line−size = <20>; d−cache−size = <4000>; device_type = "cpu"; i−cache−line−size = <20>; i−cache−size = <4000>; model = "PowerPC,405"; reg = <0>; timebase−frequency = <ee6b280>; }; }; plb: plb@0 { #address−cells = <1>; #size−cells = <1>; compatible = "xlnx,plb−v46−1.00.a"; ranges ; TriMode_MAC_GMII: xps−ll−temac@81c00000 { #address−cells = <1>; #size−cells = <1>; compatible = "xlnx,compound"; ethernet@81c00000 { compatible = "xlnx,xps−ll−temac−1.01.a"; device_type = "network"; interrupt−parent = <&xps_intc_0>; interrupts = < 2 2 >; llink−connected = <&PIM2>; local−mac−address=[020000000000]; reg = < 81c00000 40 >; xlnx,phy−type = <1>; xlnx,temac−type = <1>; }; }; mpmc@0 { #address−cells = <1>; #size− cells = <1>; compatible = "xlnx,mpmc − 3.00.b"; PIM2: sdma@84600100 { compatible = "xlnx,ll−dma−1.00.a"; interrupt−parent = <&xps_intc_0>; interrupts=<1202>; reg = < 84600100 80 >; }; }; opb: opb@40000000 { #address−cells = <1>; #size−cells = <1>; compatible = "xlnx,opb−v20−1.10.c"; ranges = < 40000000 40000000 10000000 >; opb_hwicap_0: opb−hwicap@41300000 { compatible = "xlnx,opb−hwicap−1.00.b"; reg = < 41300000 10000 >; xlnx,family = "virtex4"; }; }; plbv46_dcr_bridge_0: plbv46−dcr−bridge@80700000 { compatible = "xlnx,plbv46−dcr−bridge−1.00.a"; dcr−access−method = "mmio"; dcr−controller ; dcr−mmio−range = < 80700000 1000 >; dcr−mmio−stride = <4>; }; rs232: serial@84000000 { clock−frequency = <4f790d5>; compatible = "xlnx,xps−uartlite−1.00.a"; current−speed = <2580>; device_type = "serial"; interrupt−parent = <&xps_intc_0>; interrupts = < 3 0 >; port−number = <0>; reg = < 84000000 10000 >; xlnx,baudrate = <2580>; xlnx,data−bits = <8>; xlnx,odd−parity = <0>; xlnx,use−parity = <0>; }; xps_bram_if_cntlr_1: xps−bram−if−cntlr@fffff000 { compatible = "xlnx,xps−bram−if−cntlr−1.00.a"; reg = < fffff000 1000 >; }; xps_intc_0: interrupt−controller@81800000 { #interrupt −cells = <2>; compatible = "xlnx,xps− intc−1.00.a"; interrupt−controller ; reg = < 81800000 10000 >; xlnx,num−intr−inputs = <5>; }; xps_socket_0: xps−socket@50000000 { compatible = "xlnx,xps−socket"; dcr−parent = <&plbv46_dcr_bridge_0>; dcr−reg = < c0 2 >; interrupt−parent = <&xps_intc_0>; interrupts = < 4 2 >; reg = < 50000000 10000000 >; }; }; }; FIGURE 12.13 Device tree. Nicolescu/Model-Based Design for Embedded Systems 67842_C012 Finals Page 377 2009-10-1 FPGA Platforms for Embedded Systems 377 References 1. B. Blodget, P.James-Roxby, E. Keller, S.McMillan, and P. Sundararajaran. A self-reconfiguring platform. In Proceedings of the International Field Pro- grammable Logic and Applications Conference (FPL), Lisbon, Portugal, 2003. Lecture Notes in Computer Science, Vol. 2778, Springer-Verlag, September 2003. 2. J. Castillo, P. Huerta, V. Lopez, and J. Martinez. A secure self- reconfiguring architecture based on open-source hardware. In Inter- national Conference on Reconfigurable Computing and FPGAs (ReConFig), Puebla City, Mexico, September 2005. 3. J. Corbett, A. Rubini, and G. Kroah-Hartman. Linux Device Drivers. O’Reilly, Sebastopol, CA, 3rd edition, 2005. 4. R. Fong, S. Harper, and P. Athanas. A versatile framework for FPGA field updates: An application of partial self-reconfiguration. In Proceedings of the IEEE International Workshop on Rapid System Prototyping, San Diego, CA, June 2003. 5. R. Freeman. Configurable electrical circuit having configurable logic ele- mentsandconfigurableinterconnects.USPatent4870302,September1989. 6. D. Gibson and B. Herrenschmidt. Device trees everywhere. In Proceed- ings of linux.conf.au, Dunedin, New Zealand, January 2006. Available at http://ozlabs.org/people/dgibson/home/papers/dtc-paper.pdf, accessed April 28, 2008. 7. IBM. Device control register bus architecture specifications version 3.5, January 2006. 8. IBM. 128-bit processor local bus architecture specifications version 4.7, May 2007. 9. I. Kuon and J. Rose. Measuring the gap between FPGAs and ASICs. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 26(2):203–215, February 2007. 10. E. A. Lee and S. Neuendorffer. Actor-oriented models for codesign: Bal- ancing re-use and performance. In S. Shukla and J P. Talpin (editors), Formal Methods and Models for System Design: A System Level Perspective, pp. 33–56, Kluwer, Norwell, MA, 2004. 11. M. Majer, J. Teich, A. Ahmadinia, and C. Bobda. The Erlangen slot machine: A dynamically reconfigurable FPGA-based computer. Journal of VLSI Signal Processing Systems, 47(1):15–31, March 2007. Nicolescu/Model-Based Design for Embedded Systems 67842_C012 Finals Page 378 2009-10-1 378 Model-Based Design for Embedded Systems 12. P. Murphy, A. Sabharwal, and B. Aazhang. Design of WARP: A flexi- ble wireless open-access research platform. In Proceedings of the European Signal Processing Conference (EUSIPCO), Florence, Italy, 2006. 13. A. Parsons et al. A scalable correlator architecture based on modular FPGA hardware and data packetization. In Asilomar Conference on Sig- nals, Systems, and Computers, Pacific Grove, CA, November 2006. 14. A. Parsons et al. A scalable correlator architecture based on modular FPGA hardware and data packetization. Submitted to IEEE Trans- actions on Signal Processing, available at http://casper.berkeley.edu/ papers/2008-02_parsons_et_al-correlator.pdf, February 2008. 15. Power.org. Power.org standard for embedded power architecture platform requirements (epapr), July 2008. Version 1.0. 16. A. Sangiovanni-Vincentelli. Defining platform-based design. EEDesign, February 2002. 17. P. Sedcole, B. Blodget, T. Becker, J. Anderson, and P. Lysaght. Modular dynamic reconfiguration in Virtex FPGAs. IEE Proceedings on Computers and Digital Techniques, 153(3):157–164, May 2006. 18. H. K H. So and R. W. Brodersen. Improving usability of FPGA-based reconfigurable computers through operating system support. In Proceed- ings of the International Field Programmable Logic and Applications Conference (FPL), Madrid, Spain, 2006. 19. Sun. Opensparc web page, available at http://www.opensparc. net, accessed on March 7, 2008. 20. Triscend. Triscend e5 configurable system-on-chip platform datsheet, July 2001, v1.06. 21. M. Uhm and J. Bezile. Meeting software defined radio cost and power targets: Making SDR feasible. in Military Embedded Systems, pp. 6–8, May 2005. 22. J. Williams and N. Bergmann. Embedded linux as a platform for dynamically self-reconfiguring systems-on-chip. In Proceedings of the International Multiconference in Computer Science and Computer Engineering (ERSA),Los Vegas, CA, June 2004. 23. Xilinx. PLBv46 to PLBv6 Bridge Data Sheet, ds618 edition. Ver- sion 1.00.a, available at http:/www.xilinx.com/bvdocs/ipcenter/data_ sheet/plbv46_plbv46_bridge.pdf, accessed on March 6, 2008. 24. Xilinx. Embedded System Tools Reference Manual, ug111 v9.2 edition, September 2007. Nicolescu/Model-Based Design for Embedded Systems 67842_C012 Finals Page 379 2009-10-1 FPGA Platforms for Embedded Systems 379 25. Xilinx. PLBV46 Interface Simplifications, sp026 edition, October 2007. 26. Xilinx. Virtex-4 FPGA Confituration User Guide, ug071 v1.10 edition, April 2008. 27. Xilinx. Virtex-4 FPGA Guide, ug070 v2.40 edition, April 2008. 28. K. Yaghmour. Building Embedded Linux System. O’Reilly, Sebastopol, CA, 2003. Nicolescu/Model-Based Design for Embedded Systems 67842_C012 Finals Page 380 2009-10-1 Nicolescu/Model-Based Design for Embedded Systems 67842_S003 Finals Page 381 2009-10-1 Part III Design Tools and Methodology for Multidomain Embedded Systems Nicolescu/Model-Based Design for Embedded Systems 67842_S003 Finals Page 382 2009-10-1 Nicolescu/Model-Based Design for Embedded Systems 67842_C013 Finals Page 383 2009-10-1 13 Modeling, Veriﬁcation, and Testing Using Timed and Hybrid Automata Stavros Tripakis and Thao Dang CONTENTS 13.1 Introduction 383 13.2 Modeling with Timed and Hybrid Automata 385 13.2.1 Timed Automata 386 13.2.2 Hybrid Automata 389 13.3 Exhaustive Verification 391 13.3.1 Model Checking for Timed Automata . 392 13.3.2 Verification of Hybrid Automata 396 13.3.2.1 Autonomous Linear Systems 398 13.3.2.2 Linear Systems with Uncertain Input 398 13.3.2.3 Nonlinear Systems 401 13.3.2.4 Abstraction 403 13.4 Partial Verification 404 13.4.1 Randomized Exploration and Resource-Aware Verification 406 13.4.2 RRTs for Hybrid Automata 408 13.4.2.1 Hybrid Distance 410 13.5 Testing 411 13.6 Test Generation for Timed Automata 412 13.7 Test Generation for Hybrid Automata 421 13.7.1 Conformance Relation 422 13.7.1.1 Continuous Inputs 422 13.7.1.2 Discrete Inputs 422 13.7.2 Test Cases and Test Executions 423 13.7.3 Test Coverage 424 13.7.4 Coverage Guided Test Generation 425 13.7.4.1 Coverage-Guided Sampling . . 425 13.8 Conclusions 427 Acknowledgments 427 References 427 13.1 Introduction Models have been used for a long time to build complex systems, in virtu- ally every engineering field. This is because they provide invaluable help 383 Nicolescu/Model-Based Design for Embedded Systems 67842_C013 Finals Page 384 2009-10-1 384 Model-Based Design for Embedded Systems in making important design decisions before the system is implemented. Recently, the term “model-based design” has been introduced to empha- size the use of models and place them in the center of the development process, especially for software-intensive systems. Traditionally, the fact that software is immaterial (contrary, say, to bridges or cars or hardware), has resulted in a software development process that largely blurs the line between design and implementation: a model of the software is the software itself, which is also the implementation. It is “cheap” to write software and test it, or so people used to believe. It is now becoming more and more clear that the costs for software development, testing and maintenance are non- negligible, in fact, they often outweigh the costs of the rest of the system. As a result of this and other factors, a more rigorous software development process based on formal, high-level models, is becoming widespread, especially in the “embedded software” domain. The term “embedded software” may generally include any type of software that runs on an embedded system. Embedded systems are computer-controlled systems that strongly interact with a physical environment, for example, “x-by-wire” systems for car control, cell phones, multimedia devices, medical devices, defense and aerospace, public transportation, energy and chemical plants, and so on. In all these systems, timing and other physical characteristics of the environment are essential for system correctness as well as for performance. For instance, in an engine-control system it is critical to ignite the engine at very precise moments in time (in the order of 1 ms). Moreover, the control logic depends on a number of continuously evolving variables that have to do with the combustion in the engine, exhaust, and so on. In order to cap- ture such timing and physical constraints, models of “timed automata” and “hybrid automata” have been developed in the early 1990s [5,9]. Since then, these models have been studied extensively and today there are a number of sophisticated analysis and synthesis methods and tools available for such models. We will discuss some of these methods in this chapter. Models, in general, play different roles and are used for different tasks, at different phases of the design process. For instance, sometimes a model captures a system that is already built to some extent, while at other times a model serves as a specification that the final system must conform to. In the rest of this chapter, we consider the following tasks in the context of timed or hybrid automata models: • Modeling: We discuss timed and hybrid automata in Section 13.2. Mod- eling is of course a task by itself, and probably the most crucial one, since it is a creative and to a large extent nonautomatable task. • Exhaustive verification: We use the term exhaustive verification to denote the task of proving that a given model of a system satisfies a given property (also expressed in some modeling language). This task is exhaustive in the sense that it is conclusive: either the proof succeeds or a counter-example is found that demonstrates that the system fails to satisfy the property. We focus on automatic (push-button) exhaustive Nicolescu/Model-Based Design for Embedded Systems 67842_C013 Finals Page 385 2009-10-1 Modeling, Veriﬁcation, and Testing Using Timed and Hybrid Automata 385 verification, also called model checking. We discuss exhaustive verification in Section 13.3. • Partial verification: Fundamental issues such as undecidability (in the case of hybrid automata) or state-explosion (in the case of both timed and hybrid automata) place limits on exhaustive verification. In Section 13.4 we discuss an alternative, namely, partial verification, which aims to check a given model as much as possible, given time and resource constraints. This is done using mainly simulation-based methods. • Testing: It is important to test the correctness of a system even after it is built. Testing mainly serves this purpose. Since designing good and correct test cases is itself a time-consuming and error-prone process, one of the main challenges in testing is automatic test generation from a formal specification. We discuss testing in general in Section 13.5, and test generation from timed and hybrid automata models in Sec- tions 13.6 and 13.7, respectively. Obviously, the topics covered in this chapter are wide and deep, and we can only offer an overview. We attempt an intuitive presentation and omit most of the technical details. Those can be found in the referenced papers. We also restrict ourselves to the topics mentioned earlier and omit many others. For example, we do not discuss discrete-time/state models, theorem proving, controller synthesis, implementability and code generation, as well as other interesting topics. Finally, excellent surveys exist for some of the topics covered in this chapter (e.g., see Alur’s survey on timed automata [3] and an overview of hybrid systems in the book [107]), thus we prefer to devote more of our discussion to topics that are more recent and perhaps have been less widely exposed such as testing and partial verification. 13.2 Modeling with Timed and Hybrid Automata Timed and hybrid automata models are extensions of finite automata with variables that evolve continuously in time. Timed automata are a subclass (i.e., special case) of hybrid automata. In timed automata all variables evolve with rate 1: that is, these variables measure time itself. Hybrid automata are more general, with variables that can in principle obey any type of continuous dynamics, usually expressed by some type of differential equations. These models were introduced in order to meet the desire to blend the “discrete” world of computers with the “continuous” physical world. Classi- cal models from computer science (e.g., finite-state automata) provide means for reasoning about discrete systems only. Classical models from engineering (e.g., differential equations) provide means for reasoning mostly about . III Design Tools and Methodology for Multidomain Embedded Systems Nicolescu /Model-Based Design for Embedded Systems 67842_S003 Finals Page 382 2009-10-1 Nicolescu /Model-Based Design for Embedded. Building Embedded Linux System. O’Reilly, Sebastopol, CA, 2003. Nicolescu /Model-Based Design for Embedded Systems 67842_C012 Finals Page 380 2009-10-1 Nicolescu /Model-Based Design for Embedded. 2007. Nicolescu /Model-Based Design for Embedded Systems 67842_C012 Finals Page 378 2009-10-1 378 Model-Based Design for Embedded Systems 12. P. Murphy, A. Sabharwal, and B. Aazhang. Design of WARP: