Introduction to HW/SW Co-Design of Embedded Systems

Transcription

1 Introduction to HW/SW Co-Design of Embedded Systems Prof. Cristina SILVANO Politecnico di Milano Dipartimento di Elettronica e Informazione P.za L. Da Vinci 32, I Milano (Italy) Ph.: silvano@elet.polimi.it Web site: Outline Embedded Systems Overview Design Methodologies Hardware-Software Co-Design Flow Optimizing Design Metrics Design Technologies Design Productivity Gap - 2-1

2 Embedded Systems Overview Embedded Systems Overview Computing systems are everywhere Most of of us think of of desktop computers PC s Laptops Mainframes Servers But there s another type of of computing system Far more common

3 Embedded Systems Overview Embedded computing systems Computing systems embedded within electronic devices Hard to to define. Nearly any any computing system other than a desktop computer Billions of of units produced yearly, versus millions of of desktop units Perhaps per per household and and per per automobile Embedded systems are in here... and here... and even here Embedded Systems Embedded systems (ES) = information processing systems embedded into a larger product Examples: Main reason for buying is not information processing - 6-3

4 Application Areas (1) Automotive electronics Aircraft electronics Trains Telecommunication Application Areas (2) Medical systems Military applications Authentication - 8-4

5 Application Areas (3) Consumer electronics Fabrication equipment Smart buildings Application Areas (4) Robotics Robot Johnnie (Courtesy and : H.Ulbrich, F. Pfeiffer, TU München)

6 A short list of embedded systems Anti-lock brakes Modems Auto-focus cameras MPEG decoders Automatic teller Network cards machines Network switches/routers Automatic toll systems On-board navigation Automatic transmission Pagers Avionic systems Photocopiers Battery chargers Point-of-sale systems Camcorders Portable video games Cell phones Printers Cell-phone base stations Satellite phones Cordless phones Scanners Cruise control Smart ovens/dishwashers Curbside check-in Speech recognizers systems Stereo systems Digital cameras Teleconferencing systems Disk drives Televisions Electronic card readers Temperature controllers Electronic instruments Theft tracking systems Electronic toys/games TV set-top boxes Factory control VCR s, DVD players Fax machines Video game consoles Fingerprint identifiers Video phones Home security systems Washers and dryers Life-support systems Medical testing systems An embedded system example: Digital camera CCD Digital camera chip A2D CCD preprocessor Pixel coprocessor D2A lens JPEG codec Microcontroller Multiplier/Accum DMA controller Display ctrl Memory controller ISA bus interface UART LCD ctrl Single-functioned: Always a digital camera Tightly-constrained: Low cost, low power, small, fast Reactive and real-time: Only to a small extent

7 Some common characteristics of embedded systems Single-functioned Executes a single program, repeatedly Tightly-constrained Low cost, low power, small, fast, etc. Reactive and real-time Continually reacts to to changes in in the system s environment Must compute certain results in in real-time without delay Characteristics of Embedded Systems (1) Must be be dependable, Reliability R(t) = probability of of system working correctly provided that is is was working at at t=0 Maintainability M(d) = probability of of system working correctly d time units after error occurred. Availability: probability of of system working at at time tt Safety: no no harm to to be be caused Security: confidential and authentic communication Even perfectly designed systems can fail if if the assumptions about the workload and possible errors turn out to to be be wrong. Making the system dependable must not be be an an afterthought, it it must be be considered from the very beginning

8 Characteristics of Embedded Systems (2) Must be efficient Energy efficient Code-size efficient (especially for for systems on on a chip) Run-time efficient Weight efficient Cost efficient Dedicated towards a certain application Dedicated user interface (no mouse, keyboard and screen) Characteristics of Embedded Systems (3) Many ES must meet real-time constraints A real-time system must react to to stimuli from the controlled object (or the operator) within the time interval dictated by by the environment. For real-time systems, right answers arriving too late are wrong. A A real-time constraint is is called hard, if if not meeting that constraint could result in in a catastrophe [Kopetz, 1997]. All All other time-constraints are called soft

9 Characteristics of Embedded Systems (4) Frequently connected to to physical environment through sensors and actuators, Hybrid systems (analog + digital parts). Typically, ES are reactive systems: A A reactive system is is one one which is is in in continual interaction with is is environment and and executes at at a pace determined by by that that environment [Bergé, 1995] Behavior depends on on input and current state. Automata model appropriate, model of of computable functions inappropriate Characteristics of Embedded Systems (5) Not every ES has all all of of the above characteristics. Def.: Information processing systems having most of of the above characteristics are called embedded systems. Methodologies for embedded systems design makes sense because of of the number of of common characteristics

10 IC Technology towards the System-On-Chip Approach IC Technology towards the System-On-Chip Approach Evolution of microelectronic technology, design methodology and EDA tool enables the System-On-Chip (SOC) approach. Satellite (DVB) Video Broadcasting Multimedia Game System Wireless GSM Pocket Communicator

11 System-On-Chip Approach The evolution of of SOC approach opens new perspectives to to HW/SW codesign. Specification languages and system-level modelling assume fundamental importance to to support mixed HW/SW descriptions. Based on integration of of off-the-shelf blocks as core processors and reuse of of IP (Intellectual Property) blocks and cells Embedded systems and ubiquitous computing Ubiquitous (or pervasive) computing: Information available anytime, anywhere. Embedded systems provide fundamental technology. Ist.gif UMTS,

12 Embedded Systems Market Growing economical importance of of embedded systems.... but but embedded chips form the the backbone of of the the electronics driven world in in which we we live live they are are part part of of almost everything that that runs on on electricity [Mary Ryan, EEDesign, 1995] 79% of of all all high-end processors are used in in embedded systems THE growing area, according to to all all forecasts Importance of Embedded Software and Embedded Processors... the New York Times has estimated that the average American comes into contact with about 60 micro-processors every day... [Camposano, 1996] Latest top-level BMWs contain over 100 micro-processors... it is now common knowledge that more than 70% of the development cost for complex systems such as automotive electronics and communication systems are due to software development [A. Sangiovanni-Vincentelli, 1999] Most of the functionality of embedded systems will be implemented in software!

13 Importance of Embedded Software and Embedded Processors dramatic growth of of the number of of embedded applications and the size and the complexity of of the software used in in these applications. For many products in in the area of of consumer electronics the amount of of code is is doubling every two years. [Fritz Vaandrager in: Rozenberg, Vaandrager (eds.): Lectures on Embedded Systems, LNCS, Vol. 1494, 1998] Views on embedded software It It is is estimated that that each year embedded software is is written five five times as as much as as 'regular' software The The vast majority of of CPU-chips produced world-wide today are are used in in the the embedded market......; only a small portion of of CPU's is is applied in in PC's the the number of of software-constructors of of Embedded Systems will will rise rise from 2 million in in 1994 to to million in in 2010; the the number of of constructors employed by by softwareproducers 'merely' rises from million to to million. [Department of Trade and Industry/ IDC Benelux BV: Embedded software research in the Netherlands. Analysis and results, 1997 (according to:

14 Cost of Software in Embedded Systems What s the problem? If embedded systems will be implemented mostly in software, then why don t we just use what software engineers have come up with?

15 Some open problems How can we capture the required behavior of of complex systems? How do do we validate specifications? How do do we translate specifications efficiently into implementation? Do software engineers ever consider power dissipation? How can we check that we meet real-time constraints? Which programming language provides real-time features? How do do we validate embedded real-time software? (large volumes of of data, testing may be be safety-critical) The co-design ladder In In the the past: past: Hardware and and software design technologies were were very very different Recent maturation of of synthesis enables a unified view view of of hardware and and software Now: Now: Hardware/software codesign Compilers (1960's,1970's) Assembly instructions Assemblers, linkers (1950's, 1960's) Machine instructions Microprocessor plus program bits: software Sequential program code (e.g., C, VHDL) Implementation Behavioral synthesis (1990's) Register transfers RT synthesis (1980's, 1990's) Logic equations / FSM's Logic synthesis (1970's, 1980's) Logic gates VLSI, ASIC, or PLD implementation: hardware The choice of hardware versus software for a particular function is simply a tradeoff among various design metrics, like performance, power, size, NRE cost, and especially flexibility; there is no fundamental difference between what hardware or software can implement

16 Design Methodologies Design Methodologies A procedure for designing a system Many systems are complex and pose many design challenges: Large specifications, short time-to-market, high performance, multiple designers, interface to to manufacturing. Proper design methodology helps to to manage the design process and improves quality, performance and design costs

17 Design Flow A sequence of of design steps in in a design methodology The design flow can be partially or or fully automated A set or or tools can be used to to automate the methodology steps: Software engineering tools, Compilers, Computer-Aided Design tools, etc Design goals To provide the target functionality and user interface meeting the system level requirements in in terms of: Performance (latency and throughput) Power consumption Design and manufacturing costs Other requirements (physical size, weight, etc.)

18 A simplified design flow System-Level Requirements System-Level Specification Architecture Definition HW Design SW Design System Integration and Validation System-Level Requirements Plain language description of of what the user wants and expects to to gets May be developed in in several ways: talking directly to to customers, talking to to marketing representative, etc. Functional requirements: To describe outputs as a function of of inputs Non-functional requirements: Performance (latency and throughput), power consumption, reliability, sizes, weight, reliability, etc

19 System-Level Specification A more precise description of of the system behavior Should not yet imply a target architecture Provides inputs to to the architecture design process May include functional and non-functional requirements May be executable for simulation or or may be in in mathematical form for formal verification Architecture Design How HW and SW components can satisfy the specification? HW Components: Processor, Memory, Peripherals, etc. SW Components: Programs and their operations Some components are already available (design reuse), some can be modified from existing designs, some others must be designed from scratch

20 System Integration Put together the HW and SW components of of the system The components can be: Executable models Physical prototypes The system integration phase is is crucial to to validate the interaction among the different system components. Many system-level bugs can be discovered only at at this stage It It would be convenient to to validate system integration as early as possible! Levels of Abstraction Define the levels of detail in the description of the component and system models: System Level Behavioral Level Architectural or RT (Register Transfer) Level Logic Level Layout Level

21 Top-down Design Approach Top-down design approach: Start from the most abstract description down to to the most detailed low-level description Stepwise refinement process: At At each level of of abstraction, we must analyze the design to to determine the characteristics of of the current state of of the design To refine the design descriptions by adding details Bottom-up Design Approach Bottom-up design approach: Start from small component design to to system integration Based on the Reuse of of Intellectual Property (IP) components

22 HW/SW Co-design Flow What is HW/SW Co-design? HW/SW Co-design is is the field that emphasizes a unified view of of HW and SW and develops synthesis tools and simulators that enable the co-development of of systems by using both hardware and software. Main goal: To meet the design goals at at the system-level exploiting the synergy of of HW and SW parts through their concurrent design

23 HW/SW Co-design: Main Advantages To explore different design alternatives. To evaluate cost-performance trade-offs To reduce system design time Reduction of of product time-to-market and cost To improve product quality through design process optimization To support system-level specifications To facilitate the reuse of of hardware and software parts. To provide an integrated framework for the synthesis and validation of of hardware and software components HW/SW Co-design Flow

24 Main phases of HW/SW co-design process Requirements Analysis Functional Specification (System Modelling) Task Concurrency Management High-level Transformations Design Space Exploration HW/SW Partitioning Compilation and Scheduling Co-synthesis Co-simulation and co-verification Overview of co-design phases Functional Specification (System-Level Modelling): to to capture the system functionality in in a formal language. Task Concurrency Management: To identify and to to manage tasks in in the system; To define tasks granularity (size of of tasks) High-level Transformations: To apply some optimizing high-level transformations (that are outside the scope of of traditional compilers). For example: Loops can be interchanged so that accesses to to arrays in in memory can exploit more locality

25 Overview of co-design phases Design Space Exploration: To evaluate different design alternatives in in terms of of power-performance trade-offs HW/SW Partitioning: To map system functionalities to to either hardware or or software. Compilation and Scheduling: Hardwareaware compilation (for example energy-aware compilation) and scheduling (mapping of of operations to to control steps) Overview of co-design phases Co-synthesis: To automatically derive a system implementation Hardware synthesis of of dedicated units Software synthesis for processors (Specialized compiling techniques) Interface synthesis to to support HW/SW interface and synchronization Co-simulation and co-verification: To validate the design descriptions with respect to to system-level requirements

26 HW/SW Partitioning To map system functionalities to to either dedicated HW components or or SW (processors). One extreme: Fully HW solution High performance due to to parallelism High cost and long design time Other extreme: Fully SW solution High-performance low-cost processors Operations serialization Lack of of support for specific tasks Best solution: Mix of of HW and SW components based on cost-performance trade-offs HW/SW Partitioning Goals To speed-up software execution By migrating critical SW functions to to dedicated HW To reduce the cost of of hardware implementation By migrating non-critical hardware functions to to software running on processor core To achieve system prototypes By migrating functions to to the prototype medium

27 Open issues in HW/SW partitioning Object granularity in in partitioning Estimation of of performance and cost metrics from graph model of of the system Integrate the designer s experience in in biasing a partition Co-synthesis after partitioning To automatically derive a system implementation Hardware synthesis of of dedicated units Software synthesis for processors (Specialized compiling techniques) Interface synthesis to to support HW/SW interface and synchronization of of SW functions identified by program threads A single processor requires threads serialization or or interleaving Scheduling of of threads and instructions Satisfying performance constraints System-level run-time scheduler to to synchronize SW and HW functions

28 HW Synthesis After partitioning, HW behavior is is still described at at high-level of of abstraction (behavioral level) High-level synthesis alternatives: Manual translation to to RTL (Register Transfer Level) description Use behavioral synthesis tools SW Synthesis SW synthesis for processors is is based on specialized compiling techniques SW synthesis may be preceded by automatic SW generation steps Compilation characteristics in in embedded systems Code is is compiled once Compilation time is is not important, maximum optimization is is desired Performance constraints Code must be tight and fast Assembly code Energy-aware compilation for low-power portable embedded systems

29 Interface Synthesis Interfacing processors to to ASICs and peripheral devices Device drivers may be in in SW or or in in HW Define models for communication mechanisms Scheduling the processor communication HW/SW Co-design at System-Level HW Implementation Verification & Analysis SW Implementation System System Level IP System Level Design RTL Physical Soft IP Hard IP RTL to GDS II Synthesis Flow C Compiler Assembler Link Editor (IDE)

30 HW/SW Co-Design Architectural Design Functional Design C/C++ HW/SW Integration C/C++ + a.out System-Level Design Flow Based on a Common HW/SW Language Algorithm Architecture Application C/C++ Executable Specification C/C++ Hardware Synthesis Software Synthesis Application RTOS, Protocols Device Drivers

31 Optimizing Design Metrics Design goals: Optimizing design metrics Obvious design goal: Design an implementation with desired functionality Key design challenge: Simultaneously optimize several design metrics Design metric A measurable feature of of a system s implementation Optimizing design metrics is is a key challenge

32 Design goals: Optimizing design metrics Common metrics Unit cost: Monetary cost cost of of manufacturing each copy of of the the system, excluding NRE NRE cost cost NRE cost (Non-Recurring Engineering cost): One-time monetary cost cost of of designing the the system Size: Physical space required by by the the system Performance: Execution time or or throughput of of the the system Power: Amount of of power consumed by by the the system Flexibility: Ability to to change the the functionality of of the the system without incurring heavy NRE NRE cost cost Design goals: Optimizing design metrics Common metrics (continued) Time-to-prototype: Time Time needed to to build build a working version of of the the system Time-to-market: Time Time required to to develop a system to to the the point point that that it it can can be be released and and sold sold to to customers Maintainability: Ability Ability to to modify the the system after after its its initial initial release Correctness: Confidence to to have implemented the the system s functionality correctly Safety: Probability that that the the system will will no no cause harm Many more

33 Design metric competition: Improving one may worsen others Power Performance Size NRE cost Expertise with both software and hardware is is needed to to optimize design metrics Not just a hardware or or software expert, as as is is common The designer must be be able to to migrate from one technology to to another in in order to to find the best implementation for a given application and constraints Time-to-market: A demanding design metric Revenues ($) Time (months) Time required to to develop a product to to the the point it it can can be be sold to to customers Market window Period during which the the product would have highest sales Average time-to-market constraint is is about 8 months Delays can can be be costly

34 Losses due to delayed market entry Revenues ($) On-time Market rise Delayed D W On-time Delayed entry entry Peak revenue Peak revenue from delayed entry Market fall Time 2W Simplified revenue model Product life life = 2W, peak at at W Time of of market entry defines a triangle, representing market penetration Triangle area equals revenue Loss The difference between the the on-time and and delayed triangle areas Losses due to delayed market entry (cont.) Revenues ($) Market rise On-time Delayed Peak revenue Peak revenue from delayed entry Market fall Area = 1/2 * base * height On-time = 1/2 * 2W 2W * W = W 2 2 Delayed = 1/2 * (W-D+W)*(W-D) Percentage revenue loss = (D(3W-D)/2W 2 2 )*100% Try some examples On-time entry D Delayed entry W Time 2W Lifetime 2W=52 wks, delay D=4 wks (4*(3*26 4)/2*26^2) = 22% Lifetime 2W=52 wks, delay D=10 wks (10*(3*26 10)/2*26^2) = 50% Delays are costly!

35 NRE and unit cost metrics Costs: Unit cost: the the monetary cost of of manufacturing each copy of of the the system, excluding NRE cost NRE cost (Non-Recurring Engineering cost): The The onetime monetary cost of of designing the the system total cost = NRE cost + unit cost * # of of units per-product cost = total cost / # of of units = (NRE cost / # of of units) + unit cost Example NRE Cost = $2000, Unit Cost = $100 For 10 units total cost = $ *$100 = $3000 per-product cost = $2000/10 + $100 = $300 Amortizing NRE cost over the units results in an additional $200 per unit NRE and unit cost metrics Compare technologies by by costs -- --best depends on on quantity Technology A: A: NRE=$2,000, unit=$100 Technology B: B: NRE=$30,000, unit=$30 Technology C: C: NRE=$100,000, unit=$2 tota l c ost (x1000) $200,000 $160,000 $120,000 $80,000 A B C p er product cost $200 $160 $120 $80 A B C $40,000 $40 $0 $ Number of units (volume) Number of units (volume) But, must also consider time-to-market

36 NRE and unit cost metrics The best technology choice will depend on the number of of units we plan to to produce. Larger volumes allow us to to amortize NRE costs such that lower per-product costs result Larger volumes Lower per-product cost since NRE cost can be distributed over more products The performance design metric Widely-used measure of of system, widelyabused Clock frequency, instructions per per second not not good measures Digital camera example a user cares about how fast it it processes images, not not clock speed or or instructions per per second Latency (response time) Time between task start and and end end e.g., Camera s A and and B process images in in 0.25 seconds

37 The performance design metric Throughput (Number of of tasks that can be processed per unit time) Tasks per per second, e.g. Camera A processes 4 images per per second Throughput can can be be more than latency seems to to imply due due to to concurrency, e.g. e.g. Camera B may process 8 images per per second (by (by capturing a new image while previous image is is being stored). To compare the performance of of 2 systems: Speedup of of B over A = B s performance / A s performance Throughput speedup = 8/4 = Design Technologies

38 Three key technologies Technology A manner of of accomplishing a task, especially using technical processes, methods, or or knowledge Three key technologies for embedded systems Processor technology IC technology Design technology ) Processor technology The The architecture of of the the computation engine used to to implement a system s desired functionality Processor not notnecessarily equal to to general-purpose processor Controller Control logic and State register IR PC Datapath Register file General ALU Controller Control logic and State register IR PC Datapath Registers Custom ALU Controller Control logic State register Datapath index total + Program memory Assembly code for: Data memory Program memory Assembly code for: Data memory Data memory total = 0 for i =1 to General-purpose ( software ) total = 0 for i =1 to Application-specific Single-purpose ( hardware )

39 Processor technology Processors vary vary in in their their customization for for the the problem at at hand hand total = 0 for i = 1 to N loop total += M[i] end loop Desired functionality It represents the exact fit of the desired functionality General-purpose processor (SW) Application-specific processor (HW/SW) Single-purpose processor (HW) General-purpose processors (SW) Programmable device used in in a variety of of applications Also known as as microprocessor Features Program memory General data-path with large register file file and and general ALU User benefits Low time-to-market and and NRE costs High flexibility Pentium the the most well-known, but but there are are hundreds of of others Controller Control logic and State register IR PC Program memory Assembly code for: total = 0 for i =1 to Datapath Register file General ALU Data memory

40 Single-purpose processors (HW) Digital circuit designed to to execute exactly one one program a.k.a. coprocessor, accelerator or or peripheral Features Contains only the the components needed to to execute a single application program No No program memory Benefits Fast Low power Small size Controller Control logic State register Datapath index total + Data memory Application-specific processors (HW/SW) Programmable processor optimized for for a particular class of of applications having common characteristics Compromise between generalpurpose and and single-purpose processors Features Program memory Optimized data-path Special functional units Benefits Some flexibility, good performance, size and and power Controller Control logic and State register IR PC Program memory Assembly code for: total = 0 for i =1 to Datapath Registers Custom ALU Data memory

41 Application-specific processors ASIPS can require large NRE costs to to build the processor and the compiler Current research focuses on automatically generating ASIPs and their associated compile and debug environment ) IC technology The The manner in in which a digital (gate-level) implementation is is mapped onto an an IC IC IC: IC: Integrated circuit, or or chip IC IC technologies differ in in their customization to to a design IC s consist of of numerous layers (perhaps or or more) IC IC technologies differ with respect to to who builds each layer and and when IC package IC source gate oxide channel drain Silicon substrate

42 IC technology Three types of of IC technologies a) a) Full-custom/VLSI b) b) Semi-custom ASIC (gate array and standard cell) c) c) PLD (Programmable Logic Device) a) Full-custom/VLSI All layers are optimized for an embedded system s particular digital implementation Placing transistors Sizing transistors Routing wires Benefits Excellent performance, small size, low power Drawbacks High NRE cost (e.g., $300k), long time-tomarket

43 b) Semi-custom Lower layers are fully or or partially built Designers are left with routing of of wires and maybe placing some blocks Benefits Good performance, good size, less NRE cost than a full-custom implementation (perhaps $10k to to $100k) Drawbacks Still require weeks to to months to to develop c) PLD (Programmable Logic Device) All All layers already exist Designers can can purchase an an IC IC Connections on on the the IC IC are are either created or or destroyed to to implement desired functionality Field-Programmable Gate Array (FPGA) very popular Benefits Low NRE costs, almost instant IC IC availability Drawbacks Bigger, expensive (perhaps $30 per per unit), power hungry, slower

44 Independence of processor and IC technologies Basic Basic tradeoff General vs. vs. custom With With respect to to processor technology or or IC IC technology The The two two technologies are are independent General, providing improved: Generalpurpose processor ASIP Singlepurpose processor Customized, providing improved: Flexibility Maintainability NRE cost Time- to-prototype Time-to-market Cost (low volume) Power efficiency Performance Size Cost (high volume) PLD Semi-custom Full-custom Embedded Hardware: Moore s law The The most important trend in in embedded systems [Predicted in in 1965 by by Intel co-founder Gordon Moore] IC IC transistor capacity has has doubled roughly every months for for the the past several decades Logic transistors per chip (in millions) Note: logarithmic scale 10,000 1,

45 Embedded Hardware: Moore s law This trend is is mainly caused by improvements in in IC manufacturing Minimum feature size for CMOS IC technology in in 2002 is is approximately 130 nm Graphical illustration of Moore s law ,000 transistors 150,000,000 transistors Leading edge chip in 1981 Leading edge chip in 2002 Something that doubles frequently grows more quickly than most people realize! A 2002 chip can hold about 15, chips inside itself