A Graduate Embedded System Education Program

Transcription

1 A Graduate Embedded System Education Program Alberto Sangiovanni-Vincentelli Department of EECS, University of California at Berkeley EE249:Fall03

2 The Killer Applications for the Future? 2 Energy Conservation Emergency Response and Homeland Defense Transportation Efficiency Monitoring Health Care Land and Environment Education

3 Needs for Electronics Industry of the Future MEMS, Analog and RF devices Scalable computing architectures Networked-oriented operating systems Distributed file systems Data management systems Security/privacy User interfaces Collaboration applications Intelligent learning systems Program verification Methodologies for HW/SW design/evaluation 3 The single most serious problem in the Valley today is to find PEOPLE with the right expertise!

4 Design Practice 4

5 Design Science 5

6 Innovators with solid scientific foundations Innovation in such a complex world must come from deep understanding of basic issues Do not mistake techniques for principles! Ad hoc engineering solutions should be avoided at all costs Balance of foundations and experience 6

7 Dr. Right 7

8 A set of Graduate Courses EE249: Design of Embedded Systems EE290O: Embedded Software Design EE290N: Concurrent Models of Computation CS298-4: Formal Methods for Software Reliability CS290A: Ubiquitous Systems CS290D: Oceanic Systems EECS290F: Dependable Computing and National Security 8

9 Electronic Design: A Vision Platform-Based Design Embedded Software will be increasingly critical in Application Space the Electronic Industry Embedded Software Design must not be seen as a Platform problem Mapping in isolation, it is an, albeit essential, aspect of EMBEDDED SYSTEM DESIGN System (Software + Hardware) The vision is to change radically P Platform the way in which ESW Platform is developed today by linking it: Design-Space Export Application Instance Upwards in the abstraction layers to system functionality Downwards in the programmable platforms that support it thus providing Platform the means Instance to verify whether the constraints posed on Embedded Architectural Systems are met. Space 9

10 Platforms: Evolution In general, a platform is an abstraction layer that covers a number of possible refinements (platform instances) into a lower level. The platform representation is a library of components including interconnects from which the lower level refinement can choose (as such is a set of designs). Platform stack { Platform Mapping Tools Platform 10

11 Principles of Platform methodology: Meet-in-the-Middle Top-Down: Define a set of abstraction layers From specifications at a given level, select a solution (controls, components) in terms of components (Platforms) of the following layer and propagate constraints Bottom-Up: Platform components (e.g., micro-controller, RTOS, communication primitives) at a given level are abstracted to a higher level by their functionality and a set of parameters that help guiding the solution selection process. The selection process is equivalent to a covering problem if a common semantic domain is used. 11

12 Platform-Based Implementation Platforms eliminate large loop iterations for affordable design Restrict design space via new forms of regularity and structure that surrender some design potential for lower cost and first-pass success The number and location of intermediate platforms is the essence of platform-based design Application Application 12 Silicon Implementation Silicon Implementation

13 A Hierarchical Application of the Paradigm: The Fractal Nature of Design! Network Level Functional & Performance Requirements Performance analysis Network Architecture Constraints Radio Node Level Functional & Performance Requirements Performance analysis Node Architecture Constraints Module Level Functional & Performance Requirements Performance analysis Network Architecture 13 Source: Jan Rabaey

14 Sensor Network Applications Environment S S S C C C A A Application - collection of sensors, controllers and actuators cooperating to achieve a common goal (environment control or monitoring) Sensor - measures the state of the environment 14 Parameters: phy. quantity, range, accuracy, ID, location... Actuator - sets the state of the environment Controller - gets the state of sensors and decides whether and how to set the state of actuators

15 Network Platforms Platform Specification Application Space Application Instance Network Platform API Communication Services: -CS1: Lossy Broadcast Error rate: 33% Max Delay: 30 ms -CS2: Platform Design- Space Parameters System Platform Performance Estimates Constraints Budgeting NP components: node Platform Instance Architectural Space Network Platform Instance link port NPI I/O port 15

16 Sensor Network Platform S S C A A N1 N2 N3 N4 16 Node computation and communication platform (memory, processors ) sensor/actuator devices Parameters: memory available, energy level, computation/communication cost Sensors, Controllers and Actuators mapped onto nodes

17 EE249 A graduate 4 unit system design course: Emphasis on understanding of system design The basic mathematical models representing system behavior independent of implementation, TSM, Abstract Algebraic Approach Implementation as choice of architecture Architecture as platform Mapping of behavior into architecture as an exercise in design exploration Software and hardware seen uniformly Hands-on experience on industrial and University tools (Ptolemy, Giotto, Mescal, Matlab, Cadence VCC, WindRiver, Xilinx, Cypress, Polis, Metropolis) 17 Final Projects: Design. Methodology and Tools (most published in Conferences and Journals)

18 Behavior Vs. Architecture Models of Computation 1 System Behavior System Architecture Comm. and comp. resources 2 Quantity estimation Synthesis: HW and SW Mapping Refinement Flow To Implementation 4 3 Assign functionality to arch elements HW/SW partitioning, Scheduling 18

19 Behavior Vs. Communication Clear separation between functionality and interaction model Maximize reuse in different environments, change only interaction model 19

20 Outline of the course Part 1. Introduction: Future of Information Technology, System Design, IP-based Design, System-on-Chip and Industrial Trends Part 2. Design Methodology: Platform-based Design Part 3. Functional Design: Models of Computation Part 4. Architecture Design: Capture and Modeling Part 5. Exploration and Mapping Part 6. Implementation Verification and Synthesis, Hardware and Software 20

21 Discussion sections Lab section (Th. 4-6): tool presentations Discussion Session (Tu. 5-6) students presentation of selected papers Each student is required to fill in a questionnaire in class for each discussion session Each student (in groups of 2-3 people) has to make an oral presentation once during the class Week Lab Sections Homeworks Tool presentation HW1 3 Discussion 4 Tool presentation HW2 5 Discussion 6 Tool presentation HW3 7 Discussion 8 Tool presentation HW4 9 Discussion 10 Tool presentation HW5 11 Discussion 12 Tool presentation HW6 13 Discussion 14 HW

22 Reaching a Consensus on a Curriculum? Determine partition between undergraduate and graduate program Determine the partition between foundations and application areas Should a graduate program be established on the foundations of embedded system and should coordinated programs be instituted in the application domains (e.g., mechanical engineering, civil engineering)? How to establish a continuing education program for professionals What is the best mechanism to coordinate across the Ocean? 22