610 likes | 1.27k Views
Lecture #1: Embedded Computing Systems - An Overview. Welcome to EEM202A/CSM213A!. Course logistics and administrivia Overview what are embedded computing systems? why are they important? what are their characteristics & requirements? what are the interesting trends?
E N D
Welcome to EEM202A/CSM213A! • Course logistics and administrivia • Overview • what are embedded computing systems? • why are they important? • what are their characteristics & requirements? • what are the interesting trends? • what will the course cover?
Course Logistics: Instructor Info • Email: mbs@ucla.edu • Phone: 310-267-2098 • Office: 6731-H BH • Office hours • Mon 10:30-11:30 AM, We 2:00-3:00 PM • or by appointment • I’m very responsive with email • Please put “EE202A” or “CS213A” in mail subject line • Do not send emails from hotmail, yahoo etc. as my spam filter will likely discard them unless you put EE202A or CS213A in the subject field • Assistant: Marilyn Saunders, 6731 BH marilyn@ea.ucla.edu
About This Course • Part of embedded systems course suite in EE and CS • Potkonjak/Srivastava’s EEM202A/CS213A (Fall): Core • Kaiser/Pottie’s EE180D (Fall): Undergrad Design • Estrin’s CS113 (Winter): Undergrad • Kaiser’s EE209S (Winter): Design • Estrin/Srivastava’s EEM202B/CSM213B (Spring): Distributed • Required course for EE’s ECS Major Field Students as well as those with ECS minor • Plus, question in M.S. comprehensive exam / PhD prelims
Course Logistics: Prerequisites • No official prerequisite graduate courses as the course covers a wide range of topics, but I’ll assume that you have • Background equivalent to UCLA’s BS in CSE or EE/CE option • Requirement #1: knowledge • Digital systems, Operating systems • Requirement #2: skills • Using simulation and analysis tools • Advanced ability to program & use simulation/analysis tools • Strong ability to communicate your ideas (talks, reports) • Requirement #3: initiative • Definitely not a spoon-fed undergrad or basic grad course • Open-ended problems with no single answer, requiring thinking and research • Requirement #4: interest • Have strong interest in research in embedded systems or related fields • Don’t take this course if you’re here for a quickie MS and are overloaded with courses
Course Logistics: Enrollment • If you want to enroll • Limit of 39 across the two courses • I’ll hand out some PTEs if needed, based on my discretion • wait till end of week 2 as many students drop out • Priority order for PTEs • ECS students who have been at UCLA for > 1 year • Students of one of my close research collaborators • ECS students in their first year • Auditors okay (space permitting) • If you decide to drop the course • Be considerate and drop by week 2 or 3 as after that you only hurt your fellow project partners • Please drop the course officially on URSA as well • Unsubscribe from the class mailing list
Course Logistics: Grading • Homeworks: 20% total • Analysis, simulation, programming, library/web research, paper reviews • Topic presentations : 15% total • Teams of 2-4 for each presentation as a function of topic (decided by me) • Survey a set of papers or an area (topic & resources specified by me on a continual basis) • Prepare slides and do a (12*TeamSize)-minute presentation • slides prepared jointly, all students share the presentation • slides must include a bibliography • One project: 25% quality of accomplishments normalized to difficulty of the project, 10% final report, 5% weekly reports and regular interactions, 15% presentation & demo = 55% total • Software/hardware design, tools, analysis, simulation • Implementation projects strongly encouraged • Literature surveys unacceptable, bogus hand-wavy stuff won’t get you far • Groups of 1-3 students • Up to 30 minute presentation during the finals week to me, like a conference talk with a demo • Up to 12 page report in the style of a technical conference paper • use ACM’s template at http://www.acm.org/sigs/pubs/proceed/template.html • Class participation and interaction: 10% • E.g. questions that you ask during lectures and student presentations • E.g. how much you interact with me regarding the project
Course Logistics: Project • Dig deep into a focus area on your own • lectures would provide a “broad” coverage • Should have some new idea/result, even if minor • one or more of simulation, analysis, implementation • no paper reviews and surveys • Project topics • some suggested project topics on class web page by early Week 2 • I encourage you to think of your own topic • may relate to your own research • but you may not “reuse” work already done or being done for some other purpose • come and discuss possible project ideas with me! • What should be your goal? • something useful • similar style/quality as a conference paper and talk • key is to keep the project simple, and focused • aim for high quality! • Timeline • project topics and groups finalized by Monday of Week 3 @ 5PM • detailed proposal, timeline, and work till date by Monday of Week 4 @ 5PM • weekly progress reports thereafter, every Monday @ 5PM through week 10 • Project presentations during finals week, reports due by last day of exams @ 5PM
More Project Guidelines • The project should reflect a serious effort to go beyond the course material • Obtain additional sources from the net, journals, or books. • All prior work, published or not, public domain or proprietary, should be fully credited • "my officemate, Joe Schmo, says ...", "This section of code is modified from XXX gotten from YYY” etc. • Do not build software or hardware from scratch • Your project will not be evaluated on the basis of how much effort you put into it, but rather on how effective your work is. Go to the net or commercial software and find something to build on. • Learn to use the relevant tools and languages • at least to the level of proficiency required to make your point - Get the compiler, simulator, design environment, and install it • If you are already engaged in relevant work, leverage it. • You may work in groups of up to 3 • I will expect the ambitious-ness of the project to be proportional to the group size • I think optimal group size is 2 • Be careful in who you choose as your partner as you will be graded equally, no matter what the work breakdown and irrespective of any inter-personal issues, partners dropping the course etc. Source: Prof. Lee @ Berkeley, Prof. Kastner @ UCSB
Course Logistics: On the Web • Course web site • URL http://nesl.ee.ucla.edu/courses/ee202a/2005f/ (redirects to EEWeb) • Or, use the alias http://nesl.ee.ucla.edu/courses/cs213a/2005f/ • If enrolled: your student id is your user name and password • If auditing or wait listed: use “guest” as user name and password • On-line submissions • Home works, reports, slides etc. need to be submitted on-line as a single file (.tgz, .zip etc.) • URL: http://nesl.ee.ucla.edu/courses/ee202a/2005f/submissions • Or, http://nesl.ee.ucla.edu/courses/cs213a/2005f/submissions • Select appropriate submission tag from menu • Submissions are time stamped and would be ignored if submitted after deadline • On-line material • lecture viewgraphs (.ppt and/or .pdf) and audio recordings (.mp3 an/or .wav) • copies of handouts, home works, exams etc. • list of prescribed papers • Copies of paper at password protected URL: http://nesl.ee.ucla.edu/courses/ee202a/2005f/papers • User = ee202a (or cs213a), Password=embedded!rocks • Class mailing list • ee202a+cs213a_2005f@nesl.ee.ucla.edu • I have added all students on the roster(enrolled and on waiting list) to the mailing list using the email address in registrar’s record • You should have received a welcome email • If you wish to subscribe, unsubscribe, or change mailing list options (e.g. change email address), please visit http://nesl.ee.ucla.edu/mailman/listinfo.cgi/ee202a+cs213a_2005f • I will use this for class announcements • You can use it to mail to the class for queries relevant to the course • It is YOUR RESPONSIBILITY to subscribe to the class mailing list or fix the email address. Do this by this evening. I shall not be responsible for any emails that you miss! • Please use a reliable email account - yahoo and hotmail seem to deliver emails quite late, and I will not be responsible for delayed delivery of emails. You can always browse the archive at http://nesl.ee.ucla.edu/mailman/listinfo.cgi/ee202a+cs213a_2005f
Course Logistics: Reader & Textbooks • No books required • Unfortunately no single adequate book exists • Some books on embedded systems • Embedded System Design by Peter Marwedel • Real-Time Systems by Jane W. S. Liu • Real Time Systems and Their Programming Languages by Alan Burns, Andy Wellings • Embedded System Design: A Unified Hardware/Software Introduction by Frank Vahid, Tony D. Givargis • Computers as Components: Principles of Embedded Computer Systems Design by Wayne Wolf • Synthesis and Optimization of Digital Circuits by Giovanni De Micheli • A set of papers will be required reading • average of 2-3 papers per class • will relate to the core topic of that class • you are expected to read the papers before the class • listed on web site and in lecture notes • locating papers is your responsibility: Google, CiteSeer, ACM Digital Library, IEEE Xplore, UCLA Library etc. • In addition, there are student presentations • cover alternate ideas or related topics • lead discussion but every one is supposed to participate • selected from a set of topics of my choosing • I will give pointers to papers and web resources
Course Logistics: Some More Books (for your interest only…) • “Embedded, Everywhere: A Research Agenda for Networked Systems of Embedded Computers,” National Research Council. http://www.nap.edu/books/0309075688/html/ • R. Barnett, S. Cox, and L O’Cull, “Embedded C Programmign and the Atmel AVR,” Delmar Learning, 2002. • Albert M. K. Cheng, “Real-Time Systems : Scheduling, Analysis, and Verification,” Wiley-Interscience, 2002. • John A. Stankovic and Kirthi Ramamritham, "Hard Real-Time Systems," IEEE Computer Society Press. • G.D. Micheli, W. Wolf, R. Ernst, “Readings in Hardware/Software Co-Design,” Morgan Kaufman. • S.A. Edwards, “Languages for Digital Embedded Systems,” Kluwer, 2000. • R. Melhem and R. Graybill, “Power Aware Computing,” Plenum, 2002. • M. Pedram and J. Rabaey, “Power Aware Design Methodologies,” Kluwer, 2002. • Bruce Douglass, "Real-Time UML - Developing Efficient Objects for Embedded Systems," Addison-Wesley, 1998. • Hermann Kopetz, "Real-Time Systems : Design Principles for Distributed Embedded Applications," Kluwer, 1997. • Jean J. Labrosse, "Embedded Systems Building Blocks : Complete And Ready To Use Modules In C ," R&D Publishing, 1995. • Jean J. Labrosse, "uC / OS : The Real Time Kernel," R&D Publishing, 1992.
Embedded Systems on the Web • Berkeley Design technology, Inc.: http://www.bdti.com • EE Times Magazine: http://www.eet.com/ • Linux Devices: http://www.linuxdevices.com • Embedded Linux Journal: http://embedded.linuxjournal.com • Embedded.com: http://www.embedded.com/ • Embedded Systems Programming magazine • Circuit Cellar: http://www.circuitcellar.com/ • The Ganssle Group: http://www.ganssle.com/ • Electronic Design Magazine: http://www.planetee.com/ed/ • Electronic Engineering Magazine: http://www2.computeroemonline.com/magazine.html • Integrated System Design Magazine: http://www.isdmag.com/ • Sensors Magazine: http://www.sensorsmag.com • Embedded Systems Tutorial: http://www.learn-c.com/ • Collections of embedded systems resources • http://www.ece.utexas.edu/~bevans/courses/ee382c/resources/ • http://www.ece.utexas.edu/~bevans/courses/realtime/resources.html • Newsgroups • comp.arch.embedded, comp.cad.cadence, comp.cad.synthesis, comp.dsp, comp.realtime, comp.software-eng, comp.speech, and sci.electronics.cad
Embedded Systems Courses on the Web • Andreas Savvides @ Yale • EE460A: Networked Embedded Systems and Sensor Networks • http://www.eng.yale.edu/enalab/courses/eeng460a/ • Brian Evans @ U.T. Austin • EE382C-9 Embedded Software Systems • http://www.ece.utexas.edu/~bevans/courses/ee382c/index.html • Ryan Kastner @ UCSB • ECE594 Reconfigurable System Synthesis • http://www.ece.ucsb.edu/~kastner/ece594/ • Edward Lee @ Berkeley • EE290N: Concurrent Models of Computation for Embedded Software • http://embedded.eecs.berkeley.edu/concurrency/ • Rajesh Gupta @ UCSD • CSE237B: Software for Embedded Systems • http://mesl.ucsd.edu/gupta/cse237b.html • Nikil Dutt, UCI • ICS212: Introduction to Embedded and Ubiquitous Systems • http://www.ics.uci.edu/~dutt/ics212.html
Course Logistics: Some Conferences and Journals • Conferences & Workshops • ACM EmSoft • ACM SenSys • ACM/IEEE IPSN/SPOTS • ACM/IEEE DAC • IEEE ICCAD • IEEE RTSS • ACM ISLPED • IEEE VLSI SP Workshop • CASES • Many others… • Journals & Magazines • ACM Transactions on Design Automation of Electronic Systems • ACM Transactions on Embedded Computing Systems • ACM Transactions on Sensor Networks • IEEE Transactions on Computer-Aided Design • IEEE Transactions on VLSI Design • IEEE Design and Test of Computers • IEEE Transactions on Computers • Journal of Computer and Software Engineering • Journal on Embedded Systems • Many others…
Course Logistics: Impact of Travel on Class Schedule • Classes that I will definitely miss due to travel • Mon 10/17: Substitute lecture by Saurabh Ganeriwal • Classes that I *may* miss due to travel • Wed 10/26: Make-up lecture or Substitute lecture TBD • Wed 11/2: Make-up lecture or Substitute lecture TBD • Will schedule make up classes if needed
Cheating & Plagiarism • What is cheating & plagiarism? • Acting dishonestly, practicing fraud • Stealing or using (without permission) other people’s writings or ideas • E.g. from other students, other sources such as web sites, solutions from previous offerings of this course etc. • Note that it doesn’t have to be literal copying – stealing ideas but presenting in a different style is still cheating and plagiarism. • You are also guilty if you aid in cheating & plagiarism • My policy: zero tolerance • HWs, presentations: 0 score + one letter level (e.g. A to B) reduction in course grade • Exam, project: “F” grade for the course + report to Dean • More than 1 incident: : “F” grade for the course + report to Dean • Moreover, remember that you may have to face me in other exams (e.g. M.S. comprehensive, Ph.D. prelims, Ph.D. qualifiers) and professionally! • Bottomline: • Please don’t risk it - you will regret it! • If in doubt, check with me!
Reading List for This Lecture • MANDATORY READING • John Stankovic, et. al. Strategic directions in real-time and embedded systems. ACM Computing Surveys, vol. 28, no. 4, December 1996. p.751-763.http://citeseer.ist.psu.edu/stankovic96strategic.html • David Tennenhouse. Proactive computing. Communications of the ACM, vol. 43, no. 5, ACM, May 2000. p.43-50. http://www.acm.org/pubs/citations/journals/cacm/2000-43-5/p43-tennenhouse/ • OTHER READING • Roy Want, Trevor Perring, and David Tennenhouse. Comparing Autonomic and Proactive Computing. IBM Systems Journal, vol. 42, no. 1, 2003.http://www.research.ibm.com/journal/sj/421/want.pdf Also see Intel brochure:http://www.intel.com/research/documents/proactivepdf.pdf
Course Goals • Explain fundamental concepts underlying the design of embedded and real-time systems • building hardware, software, and mixed h/w-s/w embedded systems • Techniques for optimizing design of embedded systems • algorithms for systematic design • Research issues, industry trends, and interesting applications Prepare for the Shift from General-purpose toEmbedded Computing
Secondary Goals • How to communicate effectively • both written and orally • How to do research
More Examples... • Signal processing systems • radar, sonar, real-time video, set-top boxes, DVD players, medical equipment, residential gateways • Mission critical systems • avionics, space-craft control, nuclear plant control • Distributed control • network routers & switches, mass transit systems, elevators in large buildings • “Small” systems • cellular phones, pagers, home appliances, toys, smart cards, MP3 players, PDAs, digital cameras and camcorders, sensors, smart badges • Large dynamic range of attributes and capabilities
Why do we care?Some Market Tidbits... • Specialized devices and information appliances are replacing the generalist PC • variety of forms: set-top boxes, fixed-screen phones, smart mobile phones, iPods, PDAs, NCs, etc. • Vast majority of inter access devices are appliances and not PCs • In 1997, 96% of internet access devices sold in the US were PCs • Now, unit shipments of just internet-enabled cells phones exceed PCs • Traditional systems becoming dependent on computation systems • Modern cars: up to ~100 processors running complex software • engine & emissions control, stability & traction control, diagnostics, gearless automatic transmission • http://www.howstuffworks.com/car-computer.htm • An indicator: where are the CPUs being used?
Where Are the Processors? Where Has CS Focused? Direct2% InteractiveComputers Robots6% Vehicles12% 200Mper Year 8.5B Parts per Year Servers,etc. Embedded Computers 80% In Vehicles In Robots Embedded Look for the CPUs…the Opportunities Will Follow! Source: DARPA/Intel (Tennenhouse) Where are the CPUs? Estimated 98% of 8 Billion CPUs produced in 2000 used for embedded apps
Profusion of Embedded Systems • Gartner Group estimates 70 Billion μP used in embedded systems in 2001 • Other estimates say 50 to 120 Billion μP • Average embedded system has 4 μP • Of all μP sold, 90% go into “non-computers”, 10% in “computers” Source: Nik Dutta, UCI
Example: BMW 745i • 2, 000, 000 LOC • Windows CE OS • 53 8-bit μP • 11 32-bit μP • 7 16-bit μP • Multiple Networks • Buggy! Source: Nik Dutta, UCI
History of Computing Technology discontinuities drive new computing paradigms and applications 1960 1970 1980 1990 1995 1998 2000 Mainframe Mini Workstation PC Routers Cell phones, PDAs Networked Embedded Systems IBM DEC Sun, HP Intel, Dell Cisco Nokia, Palm ??? Increasing # of computers / person Increasing connectivity
Typical Characteristics of Embedded Systems • Part of a larger system • not a “computer with keyboard, display, etc.” • Physically coupled • Interact (sense, manipulate, communicate) with the external world • Hybrid • Mix of continuous-state and discrete-state dynamics • HW & SW do application-specific function – not G.P. • application is known a priori • but definition and development concurrent • Some degree of re-programmability is essential • flexibility in upgrading, bug fixing, product differentiation, product customization • Never terminate (ideally) • Operation is time constrained: latency, throughput • Passage of time is important • Correctness of results depends on time at which it is produced • Other constraints: power, size, weight, heat, reliability etc. • Inherently concurrent • Increasingly high-performance (DSP) & networked • Security, safety, reliability, maintainability… • What else?
Key Recent Trends • Increasing computation demands • e.g. multimedia processing in set-top boxes, HDTV • Increasingly networked • to eliminate host, and remotely monitor/debug • embedded Web servers • e.g. Axis camera http://neteye.nesl.ucla.edu • e.g. Mercedes car with web server • embedded Java virtual machines • e.g. Java ring, smart cards, printers • cameras, disks etc. that sit directly on networks • Increasing need for flexibility • time-to-market under ever changing standards! Need careful co-design of h/w & s/w!
“Traditional” Hardware Embedded Systems = ASIC • A direct sequence spread spectrum (DSSS) receiver ASIC (UCLA) ASIC Features Area: 4.6 mm x 5.1 mm Speed: 20 MHz @ 10 Mcps Technology: HP 0.5 mm Power: 16 mW - 120 mW (mode dependent) @ 20 MHz, 3.3 V Avg. Acquisition Time: 10 ms to 300 ms
Application Specific Gates Analog I/O DSP Code Processor Cores Memory Modern Embedded Systems? • Embedded systems employ a combination of • application-specific h/w (boards, ASICs, FPGAs etc.) • performance, low power • s/w on prog. processors: DSPs, controllers etc. • flexibility, complexity • mechanical transducers and actuators
Complexity and Heterogeneity • Heterogeneity within H/W & S/W parts as well • S/W: control oriented, DSP oriented • H/W: ASICs, COTS ICs controller processes control panel Real-time OS ASIC UI processes controller DSP Assembly Code Programmable DSP Programmable DSP DSP Assembly Code CODEC Dual-ported RAM
Handling Heterogeneity From Lee (Berkeley)
Increasingly on the Same ChipSystem-on-Chip (SoC) • SC3001 DIRAC chip (Sirius Communications)
More SoCs Camera-on-chip (Bell Labs) Solar-power Wireless Sensor (Berkeley)
Tied to Trends in Microelectronics • 2001 • 0.13 micron • 1.7GHz on chip clock • 7 wiring levels • 480-1700 pins • Vdd=1.1-1.2V • 2.4W / 61W / 130W • DRAM:0.54 Gb/chip, 127 mm^2, 0.42 Gb/cm^2 • MPU97 Mtrans/chip, 140 mm^2, 69 Mtrans/cm^2 • 2007 • 0.065 micron • 6.7 GHz on chip clock • 9 wiring levels • 600-3000 pins • Vdd=0.7-1.1V • 3.5W / 104W / 190W • DRAM:4.29 Gb/chip, 183 mm^2, 2.35 Gb/cm^2 • MPU386 Mtrans/chip, 140 mm^2, 276.1 Mtrans/cm^2 • 2016 • 0.022 micron • 28.8 GHz on chip clock • 10 wiring levels • 1320-7100 pins • Vdd=0.4-0.9V • 3.0W / 158W / 288W • DRAM:68.72 Gb/chip, 238 mm^2, 28.85 Gb/cm^2 • MPU3092 Mtrans/chip, 140 mm^2, 2209 Mtrans/cm^2 Sematech’s International Technology Roadmap for Semiconductors (ITRS)(http://public.itrs.net/)
Many Implementation Choices • Microprocessors • Domain-specific processors • DSP • Network processors • Microcontrollers • ASIPs • Reconfigurable SoC • FPGA • Gatearray • ASIC Speed Power Cost High Low Volume
Hardware vs. Software Modules • Hardware = functionality implemented via a custom architecture (e.g. datapath + FSM) • Software = functionality implemented in software on a programmable processor • Key differences: • Multiplexing • software modules multiplexed with others on a processor • e.g. using an OS • hardware modules are typically mapped individually on dedicated hardware • Concurrency • processors usually have one “thread of control” • dedicated hardware often has concurrent datapaths
Multiplexing Software Modules A B A B A B Call B Return Resume B Resume B Resume A Resume A SUBROUTINES COROUTINES PROCESSES Hierarchical Symmetric Symmetric Sequential Sequential Concurrent Modularity Complexity
Many Types of Programmable Processors • Past • Microprocessor • Microcontroller • DSP • Graphics Processor • Now / Future • Network Processor • Sensor Processor • Cryptoprocessor • Game Processor • Wearable Processor • Mobile Processor
Example: Network Processor mC I$ D$ DMA System Management I/O System Pipeline ASPP ASPP Network ASPP ASPP ASPP Network ASPP ASPP ASPP
Application-Specific Instruction Processors (ASIPs) • Processors with instruction-sets tailored to specific applications or application domains • instruction-set generation as part of synthesis • e.g. Tensilica • Pluses: • customization yields lower area, power etc. while r • Minuses: • higher h/w & s/w development overhead • design, compilers, debuggers • higher time to market
Reconfigurable SoC Triscend’s A7 CSoC Other Examples Atmel’s FPSLIC(AVR + FPGA) Altera’s Nios(configurable RISC on a PLD)
H/W-S/W Architecture • A significant part of the problem is deciding which parts should be in s/w on programmable processors, and which in specialized h/w • Today: • Ad hoc approaches based on earlier experience with similar products, & on manual design • H/W-S/W partitioning decided at the beginning, and then designs proceed separately
Embedded System Design • CAD tools take care of h/w fairly well • Although a productivity gap emerging • But, S/W is a different story… • HLLs such as C help, but can’t cope with complexity and performance constraints Holy Grail for Tools People: H/W-like synthesis & verification from a behavior description of the whole system at a high level of abstraction using formal computation models
Productivity Gap in Hardware Design Source: sematech97 A growing gap between design complexity and design productivity