630 likes | 838 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 • MoWe 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: Rose Weaver LaMountain, 6731 BH rose@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
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 hardware, software programming, 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, assumptions, 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 quick MS or are overloaded with courses
Course Logistics: Enrollment • If you are waiting to enroll • Sorry, no PTEs will be handed out • Wait for a couple of weeks as many students drop out • Auditors okay (seating space permitting) • If you decide to drop the course • Be considerate and drop by week 2 as after that your actions will cause significant trouble to your fellow project partners • Please drop the course officially on URSA as well • Unsubscribe from the class mailing list
Course Logistics: Grading • Homeworks: 24% total • Analysis, simulation, programming, library/web research, paper reviews • Some may be like take home exam (hard, short time), some may require oral presentation to me • One project: 20% quality of accomplishments normalized to difficulty of the project, 10% final report, 10% weekly reports and regular interactions, 20% presentation & demo = 60% total • Software/hardware design, tools, analysis, simulation • Implementation projects strongly encouraged • Literature surveys totally unacceptable, bogus hand-wavy stuff won’t get you far • Groups of 1-3 students • 30 min presentation (like a conference talk) + demo during the beginning of the finals week to me • Around 10-12 page report in the style of a technical conference paper • Must use ACM’s template at http://www.acm.org/sigs/pubs/proceed/template.html • Topic survey paper or in-class topic survey presentation : 15% total • I’ll hand out a set of topics, some of which will be marked for in-class presentation (by teams of 2-3) while others for a survey paper or report (teams of 2) • Topics will be handed out by mid-quarter, and assigned on a first-come-first served basis • Your team will need to thoroughly survey the specified topic using library and other resources • For topics marked for in-class presentation, a team of N will need to prepare and deliver an in-class presentation of roughly 12 min * N duration • These will be scheduled for the 9th and 10th week of classes • Slides must be prepared jointly, and every team member must participate roughly equally in the presentation • Grades will depend on quality of survey and the quality of oral presentation • Slides must include a bibliography, and will need to be submitted in powerpoint or keynote or pdf format • For topics marked for survey paper, a team will prepare an approximately 10 page paper following the format of the ACM template at http://www.acm.org/sigs/pubs/proceed/template.html • These will be due by the last class (Wed of 10th week) • Grades will depend on the quality survey and the quality of writing • Paper must include appropriate references and bibliography • End-of-class course and instructor survey on EEWEB: 1%
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, err on the side of risky ideas where the results ma turn to be negative • 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 • 20-min mid-course project presentation to me during week 6-7 • weekly progress reports thereafter, every Monday @ 5PM through week 10 • 30-min project presentations during finals week • reports due by Thu of exam week @ 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/2006f/ (redirects to EEWeb) • Or, use the alias http://nesl.ee.ucla.edu/courses/cs213a/2006f/ • 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/2006f/submissions • Or, http://nesl.ee.ucla.edu/courses/cs213a/2006f/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/2006f/papers • User = ee202a (or cs213a), Password=embedded!rocks • Class mailing list • ee202a+cs213a_2006f@nesl.ee.ucla.edu • I will use this for class announcements • You can use it to mail to the class for queries relevant to the course 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 did not receive the email, then either your name was not on the roster or the university has a wrong email for you. In either case, it is YOUR RESPONSBILITY to subscribe to the mailing list or fix the email address • 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_2006f • 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 athttp://nesl.ee.ucla.edu/mailman/listinfo.cgi/ee202a+cs213a_2006f
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 some student presentations • cover alternate ideas or related topics
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/18: Lecture by Ram Kumar and Simon Han • Wed 11/08: Make-up lecture or Substitute lecture TBD • Mon 12/04: No class - time off for projects! • Classes that I *may* miss due to travel • Wed 11/1: 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 for the beneficiary as well as the student providing the aid • 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 • In all other respects, University Integrity Policy applies • 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! • Bottom line: • Please don’t risk it - you will regret it! • If in doubt, check with me!
HW #0 - Due Tuesday October 3 @ 5PM • Goal: to make me familiar with your background, and to test-drive the homework submission system • Details: • Create a 1-page PDF document hw0.pdf which has • Your photograph, preferably in color • Background information about you • Your name • Education background (e.g. “B.S. in CSE from UCLA”) • Technical work background (e.g. “I worked at Company C writing embedded software”) • Which research group at UCLA are affiliated with, if any? What is your research on? • Have you ever (and briefly describe your yes/no answers): • Taken an of following courses at undergrad level: OS, architecture, VLSI design? • Written software for a bare-bones processor (i.e. no OS)? • Interfaced a decide to a microprocessor? • Written an interrupt handler? • Written a device driver? • Compiled linux kernel or some other OS? • Designed a PCB? FPGA? ASIC? • Written and debugged a large program in C/C++/Java? • Written shell scripts or scripts in TCL/Python/Perl/Ruby? • What is your interest in taking this course? • Submit the hw0.pdf file at http://nesl.ee.ucla.edu/courses/ee202a/2006f/submissionsor, http://nesl.ee.ucla.edu/courses/cs213a/2006f/submissions • Make sure to select the right tag for HW #0 from the drop-down menu
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 internet 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” • ARM sells 3x more CPUs than Intel cells Pentiums • 79% of all high-end processors are used in embedded systems • Tremendous growth in cell phones, DVR etc. Source: Nik Dutta, UCI & Tajana Simunic, UCSD
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! • Increasing share of s/w development in terms of cost Need careful co-design of h/w & s/w!
Worst of All: Embedded & Distributed Data Uncertainty System Uncertainty
“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 • Often integrated on a single SoC • Typical chip of near future: 50 sq. mm., 50M transistors, 1010GHz, 100-1000 MOP/sq. mm, 10-100 MIPS/mW • Cost is almost independent of functionality: 10K units/wafer, 20K wafer/mo.
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 Speed Power Cost • Microprocessors • Domain-specific processors • DSP • Network processors • Microcontrollers • ASIPs • Reconfigurable SoC • FPGA • Gatearray • ASIC 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