An introduction to embedded systems design

Outline An introduction to embedded systems design Matthias Grünewald. Introduction to embedded systems 2. Design metrics 3. Embedded system technologies 4. Design processes 5. Computation models and languages 6. Design technologies 7. Summary 2 References Embedded systems overview Embedded System Design: A Unified Hardware/Software Introduction Frank Vahid and Tony Givargis, John Wiley & Sons, 2002 Slides are mainly based on the lecture slides available at the book homepage (http://www.cs.ucr.edu/content/esd/) Draft version online available at: http://www.cs.ucr.edu/~vahid/courses/22a_f99/ Further references: J. Teich. Digitale Hardware/Software-Systeme Springer, 997. ISBN 3-540- 62433-3 Vorlesung Eingebettete Systeme, Bernd Kleinjohann und Lisa Kleinjohann, C-LAB, Fürstenallee, Raum FU.24, Tel. 6060 oder 60602, e-mail: bernd@c-lab.de lisa@c-lab.de Embedded Systems Internet Resources: http://www.compapp.dcu.ie/~cdaly/embed/embedsys.html Embedded computing systems Computing systems embedded Computers are in here... within electronic devices and here... Hard to define. Nearly any computing system other than a desktop and even here... computer Billions of units produced yearly, versus millions of desktop units Perhaps 50 per household and per automobile Lots more of these, though they cost a lot less each. 3 4 A short list of embedded systems Some common characteristics of embedded systems And the list goes on and on Anti-lock brakes Modems Auto-focus cameras MPEG decoders Automatic teller machines Network cards Automatic toll systems Network switches/routers Automatic transmission On-board navigation Avionic systems Pagers Battery chargers Photocopiers Camcorders Point-of-sale systems Cell phones Portable video games Cell-phone base stations Printers Cordless phones Satellite phones Cruise control Scanners Curbside check-in systems Smart ovens/dishwashers Digital cameras Speech recognizers Disk drives Stereo systems Electronic card readers Teleconferencing systems Electronic instruments Televisions Electronic toys/games Temperature controllers Factory control Theft tracking systems Fax machines TV set-top boxes Fingerprint identifiers VCR s, DVD players Home security systems Video game consoles Life -support systems Video phones Medical testing systems Washers and dryers 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 5 6

7 An embedded system example -- a digital camera Design challenge optimizing design metrics lens CCD Digital camera chip CCD preprocessor Pixel coprocessor D2A A2D JPEG codec Microcontroller Multiplier/Accum DMA controller Display ctrl Memory controller ISA bus interface UART LCD ctrl 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 Single-functioned -- always a digital camera Tightly-constrained -- Low cost, low power, small, fast Reactive and real-time -- only to a small extent 8 Design challenge optimizing design metrics Design challenge optimizing design metrics 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 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 9 0 Design metric competition -- improving one may worsen others lens CCD Performance Digital camera chip A2D JPEG codec DMA controller CCD preprocessor Power NRE cost Microcontroller Pixel coprocessor Size D2A Multiplier/Accum Display ctrl Memory controller ISA bus interface UART LCD ctrl 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 in order to choose the best for a given application and constraints Hardware Software 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 2

3 Moore s law Design productivity gap The most important trend in embedded systems Predicted in 965 by Intel co-founder Gordon Moore IC transistor capacity has doubled roughly every 8 months for the past several decades Logic transistors per chip (in millions) 0,000,000 00 0 0. Note: 0.0 logarithmic scale 0.00 While designer productivity has grown at an impressive rate over the past decades, the rate of improvement has not kept pace with chip capacity Logic transistors per chip (in millions) 0,000,000 00 0 0. 0.0 0.00 98 983 985 987 IC capacity 989 99 993 995 productivity 997 999 200 2003 2005 Gap 2007 2009 00,000 0,000 000 00 Productivity (K) Trans./Staff-Mo. 0 0. 0.0 98 983 985 987 989 99 993 995 997 999 200 2003 2005 2007 2009 4 Design process model Waterfall method Describes order that design steps are processed Behavior description step Behavior to structure conversion step Mapping structure to physical implementation step Waterfall model Proceed to next step only after current step completed Spiral model Proceed through 3 steps in order but with less detail Repeat 3 steps gradually increasing detail Keep repeating until desired system obtained Becoming extremely popular (hardware & software development) Waterfall design model Spiral design model Not very realistic Bugs often found in later steps that must be fixed in earlier step E.g., forgot to handle certain input condition Prototype often needed to know complete desired behavior E.g, customer adds features after product demo System specifications commonly change E.g., to remain competitive by reducing power, size Certain features dropped Unexpected iterations back through 3 steps cause missed deadlines Lost revenues May never make it to market Waterfall design model 5 6 Spiral method First iteration of 3 steps incomplete Much faster, though End up with prototype Use to test basic functions Get idea of functions to add/remove Original iteration experience helps in following iterations of 3 steps Must come up with ways to obtain structure and physical implementations quickly E.g., FPGAs for prototype silicon for final product May have to use more tools Extra effort/cost Could require more time than waterfall method If correct implementation first time with waterfall Spiral design model Modelling embedded systems Describing embedded system s processing behavior Can be extremely difficult Complexity increasing with increasing IC capacity Past: washing machines, small games, etc. Hundreds of lines of code Today: TV set-top boxes, Cell phone, etc. Hundreds of thousands of lines of code Desired behavior often not fully understood in beginning Many implementation bugs due to description mistakes/omissions English (or other natural language) common starting point Precise description difficult to impossible Example: Motor Vehicle Code thousands of pages long... 7 8

9 Models and languages How can we (precisely) capture behavior? We may think of languages (C, C++), but computation model is the key Common computation models: Sequential program model Statements, rules for composing statements, semantics for executing them Communicating process model Multiple sequential programs running concurrently State machine model For control dominated systems, monitors control inputs, sets control outputs Dataflow model For data dominated systems, transforms input data streams into output streams Object-oriented model For breaking complex software into simpler, well-defined pieces Models vs. languages Models Languages Poetry Recipe Story State Sequent. machine program English Spanish Japanese Recipes vs. English Computation models describe system behavior Conceptual notion, e.g., recipe, sequential program Languages capture models Concrete form, e.g., English, C Variety of languages can capture one model E.g., sequential program model C,C++, Java One language can capture variety of models E.g., C++? sequential program model, object-oriented model, state machine model Certain languages better at capturing certain computation models C C++ Dataflow Java Sequential programs vs. C 20 Finite-state machine (FSM) model Concurrent process model u,d,o, t =,0,0,0 u,d,o,t = 0,0,,0 req == floor u,d,o,t = 0,,0,0 UnitControl process using a state machine req > floor GoingUp!(req > floor) req > floor timer < 0!(timer < 0) Idle DoorOpen u,d,o,t = 0,0,, req < floor!(req<floor) GoingDn u is up, d is down, o is open req < floor t is timer_start ConcurrentProcessExample() { x = ReadX() y = ReadY() Call concurrently: PrintHelloWorld(x) and PrintHowAreYou(y) PrintHelloWorld(x) { while( ) { print "Hello world." delay(x); PrintHowAreYou(x) { while( ) { print "How are you?" delay(y); Simple concurrent process example Describes functionality of system in terms of two or more concurrently executing subtasks Many systems easier to describe with concurrent process model because inherently multitasking E.g., simple example: Read two numbers X and Y Display Hello world. every X seconds Display How are you? every Y seconds More effort would be required with sequential program or state machine model ReadX ReadY PrintHelloWorld PrintHowAreYou time Enter X: Enter Y: 2 Hello world. (Time = s) Hello world. (Time = 2 s) How are you? (Time = 2 s) Hello world. (Time = 3 s) How are you? (Time = 4 s) Hello world. (Time = 4 s)... Subroutine execution over time Sample input and output 2 22 Dataflow model Role of appropriate model and language Derivative of concurrent process model Nodes represent transformations May execute concurrently Edges represent flow of tokens (data) from one node to another May or may not have token at any given time When all of node s input edges have at least one token, node may fire When node fires, it consumes input tokens processes transformation and generates output token Nodes may fire simultaneously Several commercial tools support graphical languages for capture of dataflow model Can automatically translate to concurrent process model for implementation Each node becomes a process Z = (A + B) * (C - D) A B C D + t t2 * Z Nodes with arithmetic transformations A B C D modulate convolve t t2 transform Z Nodes with more complex transformations Finding appropriate model to capture embedded system is an important step Model shapes the way we think of the system Originally thought of sequence of actions, wrote sequential program First wait for requested floor to differ from target floor Then, we close the door Then, we move up or down to the desired floor Then, we open the door Then, we repeat this sequence To create state machine, we thought in terms of states and transitions among states When system must react to changing inputs, state machine might be best model Language should capture model easily Ideally should have features that directly capture constructs of model Other factors may force choice of different model Structured techniques can be used instead E.g., Template for state machine capture in sequential program language 23 24

25 Concurrent processes Mapping of system s functionality onto hardware processors: captured using computational model(s) written in some language(s) choice independent from language(s) choice choice based on power, size, performance, timing and cost requirements Final implementation tested for feasibility Also serves as blueprint/prototype for mass manufacturing of final product State machine Sequent. program Dataflow Concurrent processes Pascal C/C++ Java VHDL A B C The choice of computational model(s) is based on whether it allows the designer to describe the system. The choice of language(s) is based on whether it captures the computational model(s) used by the designer. The choice of implementation is based on whether it meets power, size, performance and cost requirements. Consider two examples having separate tasks running independently but sharing data Difficult to write system using sequential program model Concurrent process model easier Separate sequential programs (processes) for each task Programs communicate with each other B[..4] Heart-beat pulse Input Signal Heartbeat Monitoring System Task : Task 2: Read pulse If B/B2 pressed then If pulse < Lo then Lo = Lo +/ Activate Siren If B3/B4 pressed then If pulse > Hi then Hi = Hi +/ Activate Siren Sleep 500 ms Sleep second Repeat Repeat Set-top Box Task : Task 2: Read Signal Wait on Task Separate Audio/Video Decode/output Audio Send Audio to Task 2 Repeat Send Video to Task 3 Repeat Task 3: Wait on Task Decode/output Video Repeat Video Audio 26 Communication among processes Concurrent process model: implementation Processes need to communicate data and signals to solve their computation problem Processes that don t communicate are just independent programs solving separate problems Basic example: producer/consumer Process A produces data items, Process B consumes them E.g., A decodes video packets, B display decoded packets on a screen How do we achieve this communication? Two basic methods Shared memory Message passing Important mechanisms: Mutual exclusion, Synchronization => Deadlocks! processa() { // Decode packet // Communicate packet to B Encoded video packets Decoded video packets void processb() { // Get packet from A // Display packet To display Can use single and/or general-purpose processors (a) Multiple processors, each executing one process True multitasking (parallel processing) General-purpose processors Use programming language like C and compile to instructions of processor Expensive and in most cases not necessary Custom single-purpose processors More common (b) One general-purpose processor running all processes Most processes don t use 00% of processor time Can share processor time and still achieve necessary execution rates (c) Combination of (a) and (b) Multiple processes run on one general-purpose processor while one or more processes run on own single_purpose processor (a) (b) (c) Process Process2 Process3 Process4 Process Process2 Process3 Process4 Process Process2 Process3 Process4 Processor A Processor B Processor C Processor D General Purpose Processor Processor A General Purpose Processor Communication Bus Communication Bus 27 28 Three key embedded system technologies Technology A manner of accomplishing a task, especially using technical processes, methods, or knowledge Three key technologies for embedded systems Processor technology IC technology Design technology 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 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 + Data memory Data memory Program memory Assembly code for: Data memory Program memory Assembly code for: total = 0 for i = to General-purpose ( software ) total = 0 for i = to Application-specific Single-purpose ( hardware ) 29 30

3 IC technology The manner in which a digital (gate-level) implementation is mapped onto an IC IC: Integrated circuit, or chip IC technologies differ in their customization to a design IC s consist of numerous layers (perhaps 0 or more) IC technologies differ with respect to who builds each layer and when Types: Full-custom/VLSI, Semi-custom ASIC (gate array and standard cell), PLD (Programmable Logic Device) IC package IC source gate oxide channel drain Silicon substrate Design Technology The manner in which we convert our concept of desired system functionality into an implementation Compilation/Synthesis: Automates exploration and insertion of implementation details for lower level. Libraries/IP: Incorporates predesigned implementation from lower abstraction level into higher level. Test/Verification: Ensures correct functionality at each level, thus reducing costly iterations between levels. System specification specification RT specification Logic specification Compilation/ Synthesis System synthesis Behavior synthesis RT synthesis Logic synthesis To final implementation Libraries/ IP Hw/Sw/ OS Cores RT components Gates/ Cells Test/ Verification Model simulat./ checkers Hw-Sw cosimulators HDL simulators Gate simulators 32 The co-design ladder Independence of processor and IC technologies In the past: Hardware and software design technologies were very different Recent maturation of synthesis enables a unified view of hardware and software Hardware/software codesign Sequential program code (e.g., C, VHDL) Compilers (960's,970's) Assembly instructions Assemblers, linkers (950's, 960's) Machine instructions synthesis (990's) Register transfers RT synthesis (980's, 990's) Logic equations / FSM's Logic synthesis (970's, 980's) Logic gates Microprocessor plus VLSI, ASIC, or PLD program bits: software 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. Basic tradeoff General vs. custom With respect to processor technology or IC technology The two technologies are independent General, providing improved: Flexibility Maintainability NRE cost Time- to-prototype Time-to-market Cost (low volume) Generalpurpose processor PLD ASIP Semi-custom Singlepurpose processor Full-custom Customized, providing improved: Power efficiency Performance Size Cost (high volume) 33 34 Design technology Improving productivity Design task Define system functionality Convert functionality to physical implementation while Satisfying constrained metrics Optimizing other design metrics Designing embedded systems is hard Complex functionality Millions of possible environment scenarios Competing, tightly constrained metrics Productivity gap As low as 0 lines of code or 00 transistors produced per day Design technologies developed to improve productivity We focus on technologies advancing hardware/software unified view Automation Specification Automation Program replaces manual design Synthesis Reuse Verification Predesigned components Cores General-purpose and single-purpose processors on single IC Verification Ensuring correctness/completeness of each design step Hardware/software co-simulation Reuse 35 36

37 Automation: synthesis Gajski s Y-chart Early design mostly hardware Software complexity increased with advent of general-purpose processor Different techniques for software design and hardware design Caused division of the two fields Design tools evolve for higher levels of abstraction Different rate in each field Hardware/software design fields rejoining Both can start from behavioral description in sequential program model 30 years longer for hardware design to reach this step in the ladder Many more design dimensions Optimization critical The codesign ladder Sequential program code (e.g., C, VHDL) synthesis (990s) Compilers (960s,970s) Register transfers RT synthesis Assembly instructions (980s, 990s) Logic equations / FSM's Assemblers, linkers (950s, 960s) Logic synthesis (970s, 980s) Machine instructions Logic gates Microprocessor plus VLSI, ASIC, or PLD program bits implementation Each axis represents type of description Defines outputs as function of inputs Algorithms but no implementation Processors, memories Registers, FUs, MUXs Implements behavior by connecting components with known behavior Gates, flip-flops Transistors Gives size/locations of components and wires on chip/board Synthesis converts behavior at given level to structure at same level or lower E.g., FSM? gates, flip-flops (same level) FSM? transistors (lower level) FSM X registers, FUs (higher level) FSM X processors, memories (higher level) Behavior Sequential programs Register transfers Logic equations/fsm Transfer functions Cell Layout Modules Chips Boards 38 Verification Advantages over physical implementation Ensuring design is correct and complete Correct Implements specification accurately Complete Describes appropriate output to all relevant input Formal verification Hard For small designs or verifying certain key properties only Simulation Most common verification method Controllability Control time Stop/start simulation at any time Control data values Inputs or internal values Observability Examine system/environment values at any time Debugging Can stop simulation at any point and: Observe internal values Modify system/environment values before restarting Can step through small intervals (i.e., 500 nanoseconds) 39 40 Disadvantages Simulation speed Simulation setup time Often has complex external environments Could spend more time modeling environment than system Models likely incomplete Some environment behavior undocumented if complex environment May not model behavior correctly Simulation speed much slower than actual execution Sequentializing parallel design IC: gates operate in parallel Simulation: analyze inputs, generate outputs for each gate at time Several programs added between simulated system and real hardware simulated operation: = 0 to 00 simulator operations = 00 to 0,000 operating system operations =,000 to 00,000 hardware operations Relative speeds of different types of simulation/emulation hour actual execution of SOC =.2 years instruction-set simulation = 0,000,000 hours gate-level simulation 000 0000 00,000,000,000 00 0 FPGA hardware emulation throughput model hour instruction-set simulation cycle-accurate simulation register-transfer-level HDL simulation 0,000,000 gate-level HDL simulation IC day 4 days.4 months.2 years 2 years > lifetime millennium 4 42

43 Emulators General physical device system mapped to Microprocessor emulator Microprocessor IC with some monitoring, control circuitry SPP emulator FPGAs (0s to 00s) Usually supports debugging tasks Created to help solve simulation disadvantages Mapped relatively quickly Hours, days Can be placed in real environment No environment setup time No incomplete environment Typically faster than simulation Hardware implementation www.raptor2000.de Reuse: intellectual property cores Commercial off-the-shelf (COTS) components Predesigned, prepackaged ICs Implements GPP or SPP Reduces design/debug time Have always been available System-on-a-chip (SOC) All components of system implemented on single chip Made possible by increasing IC capacities Changing the way COTS components sold As intellectual property (IP) rather than actual IC, structural, or physical descriptions Processor-level components known as cores SOC built by integrating multiple descriptions 44 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 Three key technologies Processor: general-purpose, application-specific, single-purpose IC: Full-custom, semi-custom, PLD Design: Compilation/synthesis, libraries/ip, test/verification Computation models are distinct from languages Sequential program model is popular Most common languages like C support it directly Summary State machine models good for control Concurrent process model for multi-task systems Communication and synchronization methods exist Scheduling is critical Dataflow model good for signal processing Design technology seeks to reduce gap between IC capacity growth and designer productivity growth Synthesis has changed digital design Increased IC capacity means sw/hw components coexist on one chip Design paradigm shift to core-based design Simulation essential but hard Spiral design process is popular 45 46