![Lect-01.26
CprE 588 – Embedded Computer Systems
Jan 13-15, 2009
Processor Technology (cont.)
• Processors vary in their customization for the
problem at hand
total = 0
for i = 1 to N loop
total += M[i]
end loop
General-purpose
processor
Single-purpose
processor
Application-specific
processor
Desired
functionality](https://image.slidesharecdn.com/lect-01-230925174757-2242e5aa/85/Electronic-control-unit-26-320.jpg)
Electronic control unit
- 1. CprE 588 Embedded Computer Systems Prof. Joseph Zambreno Department of Electrical and Computer Engineering Iowa State University Lecture #1 – Introduction and Overview
- 2. Lect-01.2 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Digital System v. Embedded System • Digital System: may provide service • as a self-contained unit (e.g., desktop PC) • as part of a larger system (e.g., digital control system for manufacturing plant) • Embedded System: • part of a larger unit • provides dedicated service to that unit G. De Micheli and R. Gupta, “Hardware/Software Co-Design,” Proceedings of the IEEE, 85(3), March 1997, pp. 349-365
- 3. Lect-01.3 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Embedded Systems Overview • Computing systems are everywhere • Most of us think of “desktop” computers • PC’s • Laptops • Mainframes • Servers • But there’s another type of computing system • Far more common... F. Vahid and T. Givargis, Embedded System Design: A Unified Hardware/Software Introduction, John Wiley & Sons, 2002.
- 4. Lect-01.4 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Embedded Systems Overview (cont.) • Embedded computing systems • Computing systems embedded within electronic devices • Hard to define. Nearly any computing system other than a desktop computer • Billions of units produced yearly, versus millions of desktop units • Perhaps 100s per household and per automobile Computers are in here... and here... and even here... Lots more of these, though they cost a lot less each.
- 5. Lect-01.5 CprE 588 – Embedded Computer Systems Jan 13-15, 2009
- 6. Lect-01.6 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 A “Short List” of Embedded Systems And the list goes on and on Anti-lock brakes Auto-focus cameras Automatic teller machines Automatic toll systems Automatic transmission Avionic systems Battery chargers Camcorders Cell phones Cell-phone base stations Cordless phones Cruise control Curbside check-in systems Digital cameras Disk drives Electronic card readers Electronic instruments Electronic toys/games Factory control Fax machines Fingerprint identifiers Home security systems Life-support systems Medical testing systems Modems MPEG decoders Network cards Network switches/routers On-board navigation Pagers Photocopiers Point-of-sale systems Portable video games Printers Satellite phones Scanners Smart ovens/dishwashers Speech recognizers Stereo systems Teleconferencing systems Televisions Temperature controllers Theft tracking systems TV set-top boxes VCR’s, DVD players Video game consoles Video phones Washers and dryers
- 7. Lect-01.7 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Examples of Embedded Systems • PC having dedicated software programs and appropriate interfaces to a manufacturing assembly line • Microprocessor dedicated to a control function in a computer, e.g., keyboard/mouse input control
- 8. Lect-01.8 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Outline • Embedded systems overview • Design challenge – optimizing design metrics • Technologies • Processor technologies • Design technologies • Generic codesign methodology
- 9. Lect-01.9 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Some Application Domains • CONSUMER PRODUCTS • Appliances, Games, A/V, Intelligent home devices • TRANSPORTATION • Autos, Trains, Ships, Aircrafts • PLANT CONTROL • Manufacturing, Chemical, Power Generation • NETWORKS • Telecommunication, Defense • Local • e.g., appliance • Locally distributed • e.g., aircraft control over a LAN • Geographically distributed • e.g., telephone network
- 10. Lect-01.10 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Parts of an Embedded System HARDWIRED UNIT • Application-specific logic • Timers • A/D and D/A conversion MEMORY PROCESSOR EMBEDDED SYSTEM ENVIRONMENT USER I/O
- 11. Lect-01.11 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Parts of an Embedded System (cont.) • Actuators - mechanical components (e.g., valve) • Sensors - input data (e.g., accelerometer for airbag control) • Data conversion, storage, processing • Decision-making • Range of implementation options • Single-chip implementation: system on a chip
- 12. Lect-01.12 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Functions and Design Criteria • Monitoring and control functions for the overall system (e.g., vehicle control) • Information-processing functions (e.g., telecommunication system -- data compression, routing, etc.) • Criteria: performance, reliability, availability, safety, usability, etc.
- 13. Lect-01.13 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Some Common Characteristics • Single-functioned • Executes a single program, repeatedly • Tightly-constrained • Low cost, low power, small, fast, etc. • Reactive and real-time • Continually reacts to changes in the system’s environment • Must compute certain results in real-time without delay
- 14. Lect-01.14 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 An Embedded System Example Microcontroller CCD preprocessor Pixel coprocessor A2D D2A JPEG codec DMA controller Memory controller ISA bus interface UART LCD ctrl Display ctrl Multiplier/Accum Digital camera chip lens CCD • Single-functioned -- always a digital camera • Tightly-constrained -- Low cost, low power, small, fast • Reactive and real-time -- only to a small extent • Digital Camera
- 15. Lect-01.15 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Design Challenge – Optimization • Obvious design goal: • Construct an implementation with desired functionality • Key design challenge: • Simultaneously optimize numerous design metrics • Design metric • A measurable feature of a system’s implementation • Optimizing design metrics is a key challenge
- 16. Lect-01.16 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Design Challenge – Optimization (cont.) • Common metrics • Unit cost: the monetary cost of manufacturing each copy of the system, excluding NRE cost • NRE cost (Non-Recurring Engineering cost): The one-time monetary cost of designing the system • Size: the physical space required by the system • Performance: the execution time or throughput of the system • Power: the amount of power consumed by the system • Flexibility: the ability to change the functionality of the system without incurring heavy NRE cost
- 17. Lect-01.17 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Design Challenge – Optimization (cont.) • Common metrics (continued) • Time-to-prototype: the time needed to build a working version of the system • Time-to-market: the time required to develop a system to the point that it can be released and sold to customers • Maintainability: the ability to modify the system after its initial release • Correctness, safety, many more
- 18. Lect-01.18 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Design Metric Competition • Expertise with both software and hardware is needed to optimize design metrics • Not just a hardware or software expert, as is common • A designer must be comfortable with various technologies Size Performance Power NRE cost Microcontroller CCD preprocessor Pixel coprocessor A2D D2A JPEG codec DMA controller Memory controller ISA bus interface UART LCD ctrl Display ctrl Multiplier/Accum Digital camera chip lens CCD Hardware Software
- 19. Lect-01.19 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Time-to Market • Time required to develop a product to the point it can be sold to customers • Market window • Period during which the product would have highest sales • Average time-to-market constraint is about 8 months • Delays can be costly Revenues ($) Time (months)
- 20. Lect-01.20 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Delayed Market Entry • Simplified revenue model • Product life = 2W, peak at W • Time of market entry defines a triangle, representing market penetration • Triangle area equals revenue • Loss • The difference between the on-time and delayed triangle areas On-time Delayed entry entry Peak revenue Peak revenue from delayed entry Market rise Market fall W 2W Time D On-time Delayed Revenues ($)
- 21. Lect-01.21 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 NRE and Unit Cost Metrics • Costs: • Unit cost: the monetary cost of manufacturing each copy of the system, excluding NRE cost • NRE cost (Non-Recurring Engineering cost): the one-time monetary cost of designing the system • total cost = NRE cost + unit cost * # of units • per-product cost = total cost / # of units = (NRE cost / # of units) + unit cost • Example – NRE=$2000, unit=$100 – For 10 units – total cost = $2000 + 10*$100 = $3000 – per-product cost = $2000/10 + $100 = $300 Amortizing NRE cost over the units results in an additional $200 per unit
- 22. Lect-01.22 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 NRE and unit cost metrics $0 $40,000 $80,000 $120,000 $160,000 $200,000 0 800 1600 2400 A B C $0 $40 $80 $120 $160 $200 0 800 1600 2400 Number of units (volume) A B C Number of units (volume) tota l c ost (x1000) p er p rod uc t c ost • Compare technologies by costs -- best depends on quantity • Technology A: NRE=$2,000, unit=$100 • Technology B: NRE=$30,000, unit=$30 • Technology C: NRE=$100,000, unit=$2 • But, must also consider time-to-market
- 23. Lect-01.23 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 The Performance Design Metric • Widely-used measure of system, widely-abused • Clock frequency, instructions per second – not good measures • Digital camera example – a user cares about how fast it processes images, not clock speed or instructions per second • Latency (response time) • Time between task start and end • e.g., Camera’s A and B process images in 0.25 seconds • Throughput • Tasks per second, e.g. Camera A processes 4 images per second • Throughput can be more than latency seems to imply due to concurrency, e.g. Camera B may process 8 images per second (by capturing a new image while previous image is being stored). • Speedup of B over S = B’s performance / A’s performance • Throughput speedup = 8/4 = 2
- 24. Lect-01.24 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Three Key Technologies • Technology • A manner of accomplishing a task, especially using technical processes, methods, or knowledge • Three key technologies for embedded systems • Processor technology (CprE 581, 583, 681) • IC technology (EE 501, 507, 511) • Design technology (CprE 588)
- 25. Lect-01.25 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Processor Technology • The architecture of the computation engine used to implement a system’s desired functionality • Processor does not have to be programmable • “Processor” not equal to general-purpose processor Application-specific Registers Custom ALU Datapath Controller Program memory Assembly code for: total = 0 for i =1 to … Control logic and State register Data memory IR PC Single-purpose (“hardware”) Datapath Controller Control logic State register Data memory index total + IR PC Register file General ALU Datapath Controller Program memory Assembly code for: total = 0 for i =1 to … Control logic and State register Data memory General-purpose (“software”)
- 26. Lect-01.26 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Processor Technology (cont.) • Processors vary in their customization for the problem at hand total = 0 for i = 1 to N loop total += M[i] end loop General-purpose processor Single-purpose processor Application-specific processor Desired functionality
- 27. Lect-01.27 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 General-Purpose Processors • Programmable device used in a variety of applications • Also known as “microprocessor” • Features • Program memory • General datapath with large register file and general ALU • User benefits • Low time-to-market and NRE costs • High flexibility • “Intel/AMD” the most well-known, but there are hundreds of others IR PC Register file General ALU Datapath Controller Program memory Assembly code for: total = 0 for i =1 to … Control logic and State register Data memory
- 28. Lect-01.28 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Application-Specific Processors • Programmable processor optimized for a particular class of applications having common characteristics • Compromise between general- purpose and single-purpose processors • Features • Program memory • Optimized datapath • Special functional units • Benefits • Some flexibility, good performance, size and power IR PC Registers Custom ALU Datapath Controller Program memory Assembly code for: total = 0 for i =1 to … Control logic and State register Data memory
- 29. Lect-01.29 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Independence of Processor Technologies • Basic tradeoff • General vs. custom • With respect to processor technology or IC technology • The two technologies are independent General- purpose processor ASIP Single- purpose processor Semi-custom PLD Full-custom General, providing improved: Customized, providing improved: Power efficiency Performance Size Cost (high volume) Flexibility Maintainability NRE cost Time- to-prototype Time-to-market Cost (low volume)
- 30. Lect-01.30 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Design Technology • The manner in which we convert our concept of desired system functionality into an implementation Libraries/IP: Incorporates pre- designed implementation from lower abstraction level into higher level. System specification Behavioral specification RT specification Logic specification To final implementation Compilation/Synthesis: Automates exploration and insertion of implementation details for lower level. Test/Verification: Ensures correct functionality at each level, thus reducing costly iterations between levels. Compilation/ Synthesis Libraries/ IP Test/ Verification System synthesis Behavior synthesis RT synthesis Logic synthesis Hw/Sw/ OS Cores RT components Gates/ Cells Model simulat./ checkers Hw-Sw cosimulators HDL simulators Gate simulators
- 31. Lect-01.31 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Design Productivity Exponential Increase • Exponential increase over the past few decades 100,000 10,000 1,000 100 10 1 0.1 0.01 1983 1987 1989 1991 1993 1985 1995 1997 1999 2001 2003 2005 2007 2009 Productivity (K) Trans./Staff – Mo.
- 32. Lect-01.32 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Design Productivity Gap • While designer productivity has grown at an impressive rate over the past decades, the rate of improvement has not kept pace with chip capacity 10,000 1,000 100 10 1 0.1 0.01 0.001 Logic transistors per chip (in millions) 100,000 10,000 1000 100 10 1 0.1 0.01 Productivity (K) Trans./Staff-Mo. IC capacity productivity Gap
- 33. Lect-01.33 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Design Productivity Gap (cont.) • 1981 leading edge chip required 100 designer months • 10,000 transistors / 100 transistors/month • 2002 leading edge chip requires 30,000 designer months • 150,000,000 / 5000 transistors/month • Designer cost increase from $1M to $300M 10,000 1,000 100 10 1 0.1 0.01 0.001 Logic transistors per chip (in millions) 100,000 10,000 1000 100 10 1 0.1 0.01 Productivity (K) Trans./Staff-Mo. IC capacity productivity Gap
- 34. Lect-01.34 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 The Mythical Man-Month • The situation is even worse than the productivity gap indicates • In theory, adding designers to team reduces project completion time • In reality, productivity per designer decreases due to complexities of team management and communication • In the software community, known as “the mythical man-month” (Brooks 1975) • At some point, can actually lengthen project completion time! (“Too many cooks”) 10 20 30 40 0 10000 20000 30000 40000 50000 60000 43 24 19 16 15 16 18 23 Team Individual Months until completion Number of designers • 1M transistors, 1 designer=5000 trans/month • Each additional designer reduces for 100 trans/month • So 2 designers produce 4900 trans/month each
- 35. Lect-01.35 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Co-Design Methodology • Co-design • Design of systems involving both hardware and software components • Starts with formal, abstract specification; series of refinements maps to target architecture: allocation, partitioning, scheduling, communication synthesis • Means to manage large-scale, complex systems R. Domer, D. Gajski, J. Zhu, “Specification and Design of Embedded Systems,” it+ti magazine, Oldenbourg Verlag (Germany), No. 3, June 1998.
- 36. Lect-01.36 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Complex Systems • SOC (System-On-a-Chip) • Millions of gates on a chip • Decreasing processing technologies (deep sub- micron, 0.25 µm and below): decreasing geometry size, increasing chip density • Problems • Electronic design automation (EDA) tools • Time-to-market
- 37. Lect-01.37 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Complex Systems (cont.) • Abstraction • Reduce the number of objects managed by a design task, e.g., by grouping objects using hierarchy • Computer-aided design (CAD) example • Logic level: transistors grouped into gates • Register transfer level (RTL): gates grouped into registers, ALUs, and other RTL components
- 38. Lect-01.38 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Complex Systems (cont.) • Abstraction • Co-design example • System level: processors (off-the-shelf or application- specific), memories, application-specific integrated circuits (ASICs), I/O interfaces, etc. • Integration of intellectual property (IP) - representations of products of the mind • Reuse of formerly designed circuits as core cells
- 39. Lect-01.39 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Generic Co-Design Methodology Synthesis • Specification • Allocation • Partitioning • Scheduling • Communication synthesis Implementation • Software synthesis • Hardware synthesis • Interface synthesis model task Analysis & Validation Note: design models may be captured in the same language
- 40. Lect-01.40 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 System Specification • Describes the functionality of the system without specifying the implementation • Describes non-functional properties such as performance, power, cost, and other quality metrics or design constraints • May be executable to allow dynamic verification
- 41. Lect-01.41 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 System Specification Example shared sync read write sync B0: top behavior • integer variable • boolean variable child behavior Graphical representation: • Hierarchy • Concurrency • Transitions between behaviors Behaviors • Sequential: B1, B2, B3 • Concurrent: B4, B5 • Atomic: B1 • Composite: B2
- 42. Lect-01.42 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 System Specification Example (cont.) shared sync read write sync Producer- consumer functionality • B6 computes a value • B4 consumes the value • Synchronization is needed: B4 waits until B6 produces the value
- 43. Lect-01.43 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 System Specification Example • Atomic behaviors B1( ) { stmt; ... } B3( ) { stmt; ... } B7( ) { stmt; ... } B6( ) { int local; … shared = local + 1; signal(sync); } B4( ) { int local; wait(sync); local = shared - 1; ... }
- 44. Lect-01.44 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Allocation • Selects the type and number of components from a library and determines their interconnection • Implements functionality so as to • Satisfy constraints • Minimize objective cost function • Result may be customization of a generic target architecture
- 45. Lect-01.45 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Allocation Example Proc1 LMem1 LMem2 ASIC1 GMem1 IF1 IF2 IF3 system bus Arbiter1 bus1 bus2 bus3 PE1 PE2 PE: Processing Element LMem: Local Memory GMem: Global Memory IF: Interface Target Architecture Model
- 46. Lect-01.46 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Partitioning • Defines the mapping between the set of behaviors in the specification and the set of allocated components in the architecture • Satisfy constraints • Minimize costs • Not yet near implementation • Multiple behaviors in a single PE (scheduling) • Interactions between PEs (communication) • Design model • additional level of hierarchy • functional equivalence with specification
- 47. Lect-01.47 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Partitioning Example System model after partitioning shared sync B1_start B1_done B4_start B4_done B1_start B1_done B4_start B4_done PE0 PE1 Top B1_ctrl B4_ctrl controlling behavior Child (B1) assigned to different PE than parent (B0) synchronization variables
- 48. Lect-01.48 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Partitioning Example (cont.) • Atomic behaviors B1( ) { wait(B1_start); … signal(B1_done); } B3( ) { stmt; ... } B7( ) { stmt; ... } B6( ) { int local; … shared = local + 1; signal(sync); } B4( ) { int local; wait(B4_start); wait(sync); local = shared - 1; … signal(B4_done); } B1_ctrl( ) { signal(B1_start); wait(B1_done); } B4_ctrl( ) { signal(B4_start); wait(B4_done); }
- 49. Lect-01.49 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Scheduling • Given a set of behaviors and optionally a set of performance constraints, determines a total order in time for invoking behaviors running on the same PE • Maintains the partial order imposed by dependencies in the functionality • Minimizes synchronization overhead between PEs and context-switching overhead within each PE
- 50. Lect-01.50 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Scheduling • Ordering information • Known at compile time • Static scheduling • Higher inter-PE synchronization overhead if inaccurate performance estimation, i.e., longer wait times and lower CPU utilization • Unknown until runtime (e.g., data-, event- dependent) • Dynamic scheduling • Higher context-switching overhead (running task blocked, new task scheduled)
- 51. Lect-01.51 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Scheduling Example shared sync B6_start B3_start B6_start sync B3_start System model after static scheduling Scheduling decision: • Sequential ordering of behaviors on PE0, PE1 • Synchronization to maintain partial order across Pes • Optimization - no control behaviors
- 52. Lect-01.52 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Scheduling Example (cont.) • Atomic behaviors B1( ) { … signal(B6_start); } B3( ) { wait(B3_start); ... } B7( ) { stmt; ... } B6( ) { int local; wait(B6_start); … shared = local + 1; signal(sync); } B4( ) { int local; wait(sync); local = shared - 1; … signal(B3_start); }
- 53. Lect-01.53 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Communication Synthesis • Implements the shared-variable accesses between concurrent behaviors using an inter- PE communication scheme • Shared memory: read or write to a shared- memory address • Local PE memory: send or receive message- passing calls • Inserts interfaces to communication channels (local or system buses)
- 54. Lect-01.54 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Communication example lbus0 lbus1 lbus2 sbus IF0 IF1 IF2 B6 B7 B3 B1 B4 PE0 PE1 Shared_mem Arbiter System model after communication synthesis Synthesis decision: • Put all global variables into Shared_mem • New global variables in Top
- 55. Lect-01.55 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Communication Example (cont.) • Atomic behaviors B1( ) { … signal (*B6_start_addr); } B3( ) { wait(*B3_start_addr); ... } B7( ) { stmt; ... } B6( ) { int local; wait (*B6_start_addr); … *shared_addr = local + 1; signal(*sync_addr); } B4( ) { int local; wait (*sync_addr); local = *shared_addr - 1; … signal (*B3_start_addr); }
- 56. Lect-01.56 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Communication Example (cont.) • Atomic behaviors IF0( ) { stmt; ... } Shared_mem( ) { int shared; bool sync; bool B3_start; bool B6_start; } Arbiter( ) { stmt; ... } IF1( ) { stmt; ... } IF2( ) { stmt; ... }
- 57. Lect-01.57 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Analysis and Validation • Functional validation of design models at each step using simulation or formal verification • Analysis to estimate quality metrics and make design decisions • Tools • Static analyzer - program, ASIC metrics • Simulator - functional, cycle-based, discrete- event • Debugger - access to state of behaviors • Profiler - dynamic execution information • Visualizer - graphical displays of state, data
- 58. Lect-01.58 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Backend • Implementations • Processor: compiler translates model into machine code • ASIC: high-level synthesis tool translates model into netlist of RTL components • Interface • Special type of ASIC that links a PE with other components • Implements the behavior of a communication channel
- 59. Lect-01.59 CprE 588 – Embedded Computer Systems Jan 13-15, 2009 Summary • Embedded systems are everywhere • Key challenge: optimization of design metrics • Design metrics compete with one another • A unified view of hardware and software is necessary to improve productivity • Key technologies • Processor: general-purpose, application-specific, single- purpose • Design: compilation/synthesis, libraries/IP, test/verification