You are on page 1of 8

HEINZ NIXDORF INSTITUTE

University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rückert

Outline

HEINZ NIXDORF INSTITUTE
University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rückert

HEINZ NIXDORF INSTITUTE
University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rückert

An introduction to embedded systems design
Matthias Grünewald

1. 2. 3. 4. 5. 6. 7.

Introduction to embedded systems Design metrics Embedded system technologies Design processes Computation models and languages Design technologies Summary

2

References

HEINZ NIXDORF INSTITUTE
University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rückert

Embedded systems overview

HEINZ NIXDORF INSTITUTE
University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rückert

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/122a_f99/

• 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.

Further references:
• J. Teich. Digitale Hardware/Software-Systeme Springer, 1997. ISBN 3-54062433-3 • Vorlesung „Eingebettete Systeme“, Bernd Kleinjohann und Lisa Kleinjohann, C-LAB, Fürstenallee 11, Raum FU.214, Tel. 606101 oder 606102, e-mail: bernd@c-lab.de lisa@c-lab.de • Embedded Systems Internet Resources: http://www.compapp.dcu.ie/~cdaly/embed/embedsys.html
3

4

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

HEINZ NIXDORF INSTITUTE
University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rückert

Some common characteristics of embedded systems

HEINZ NIXDORF INSTITUTE
University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rückert

• 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

Camera’s A and B process images in 0. fast Reactive and real-time -. safety. small.g.. e.-Ing.-Ing. Dr. Dr. low power.always a digital camera Tightly-constrained -. not clock speed or instructions per second • Latency (response time) • Time between task start and end • e. instructions per second – not good measures • Digital camera example – a user cares about how fast it processes images.a digital camera HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. excluding NRE cost • Common metrics (continued) • Time-to-prototype: the time needed to build a working version of the system • NRE cost (Non-Recurring Engineering cost): The one-time monetary cost of designing the system • Time-to-market: the time required to develop a system to the point that it can be released and sold to customers • • • • 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 • Maintainability: the ability to modify the system after its initial release • Correctness. 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 11 • Widely-used measure of system.g. widely-abused • Clock frequency.-Ing. Ulrich Rückert • Obvious design goal: Digital camera chip CCD CCD preprocessor A2D lens JPEG codec Microcontroller Multiplier/Accum Pixel coprocessor D2A • 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 DMA controller Display ctrl Memory controller ISA bus interface UART LCD ctrl • • • Single-functioned -. Ulrich Rückert Power Performance Size • Expertise with both software and hardware is needed to optimize design metrics • Not just a hardware or software expert.Low cost. Ulrich Rückert The performance design metric HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. CCD lens Digital camera chip A2D JPEG codec DMA controller CCD preprocessor Pixel coprocessor D2A • Speedup of B over S = B’s performance / A’s performance • Throughput speedup = 8/4 = 2 Microcontroller Multiplier/Accum Display ctrl Memory controller ISA bus interface UART LCD ctrl 12 . Dr. Dr. Camera A processes 4 images per second • Throughput can be more than latency seems to imply due to concurrency.-Ing. Camera B may process 8 images per second (by capturing a new image while previous image is being stored).-Ing. Ulrich Rückert Design challenge – optimizing design metrics HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. many more 9 10 Design metric competition -. Dr.only to a small extent 7 8 Design challenge – optimizing design metrics HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.g.-Ing. Ulrich Rückert • Common metrics • Unit cost: the monetary cost of manufacturing each copy of the system.improving one may worsen others HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Ulrich Rückert Design challenge – optimizing design metrics HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Dr. e.25 seconds NRE cost • Throughput • Tasks per second.An embedded system example -.

17 18 .01 0. to remain competitive by reducing power.001 1981 1983 1985 1987 1989 1991 1993 1995 1997 1999 2001 2003 2005 2007 2009 Logic transistors per chip (in millions) 100 10 1 0. Dr.-Ing. Ulrich Rückert • Describing embedded system’s processing behavior • Can be extremely difficult • Complexity increasing with increasing IC capacity Spiral design model Structural Behavioral • Original iteration experience helps in following iterations of 3 steps • Must come up with ways to obtain structure and physical implementations quickly • E. Ulrich Rückert • The most important trend in embedded systems • Predicted in 1965 by Intel co-founder Gordon Moore IC transistor capacity has doubled roughly every 18 months for the past several decades 10..g.01 0. etc.000 10.g. forgot to handle certain input condition • Waterfall model • Proceed to next step only after current step completed • Prototype often needed to know complete desired behavior • E.000 100.000 1... the rate of improvement has not kept pace with chip capacity 10. Cell phone.000 1000 Logic transistors per chip (in millions) Note: logarithmic scale 100 10 1 0../Staff-Mo.. productivity 0. Ulrich Rückert Modelling embedded systems HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.-Ing. etc. Dr. customer adds features after product demo Waterfall design model Behavioral Structural Physical Spiral design model Structural Behavioral • System specifications commonly change • E.001 1991 1993 1995 1997 1999 2001 2003 2005 1981 1983 1985 1987 1989 2007 2009 Gap IC capacity 100 10 1 Productivity (K) Trans. Dr.g.Moore’s law HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.-Ing.1 0.-Ing.01 13 14 Design process model HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Ulrich Rückert Design productivity gap HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.-Ing. though • End up with prototype • Use to test basic functions • Get idea of functions to add/remove HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. • Hundreds of thousands of lines of code • Desired behavior often not fully understood in beginning • Many implementation bugs due to description mistakes/omissions Physical • May have to use more tools • Extra effort/cost • Could require more time than waterfall method • If correct implementation first time with waterfall • English (or other natural language) common starting point • Precise description difficult to impossible • Example: Motor Vehicle Code – thousands of pages long.-Ing. Dr. Dr. FPGAs for prototype • silicon for final product • Past: washing machines.g.1 0.1 0. size • Certain features dropped • 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) • Unexpected iterations back through 3 steps cause missed deadlines Physical • Lost revenues • May never make it to market 15 16 Spiral method • First iteration of 3 steps incomplete • Much faster.000 1. Dr. Ulrich Rückert • Describes order that design steps are processed • Behavior description step • Behavior to structure conversion step • Mapping structure to physical implementation step Waterfall design model Behavioral Structural Physical • Not very realistic • Bugs often found in later steps that must be fixed in earlier step • E. Ulrich Rückert Waterfall method HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.000 • While designer productivity has grown at an impressive rate over the past decades. small games. • Hundreds of lines of code • Today: TV set-top boxes.

-Ing.-Ing.-Ing. e. t = 1.-Ing. English. } } • • 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.t = 0.0.g. we thought in terms of states and transitions among states • When system must react to changing inputs.d. we open the door Then. Dr.0.0." delay(x). recipe. Dr. we repeat this sequence Edges represent flow of tokens (data) from one node to another • May or may not have token at any given time A B C D + t1 t2 * – • • • • When all of node’s input edges have at least one token.-Ing.. C E.o. semantics for executing them • • • • Languages English Spanish Japanese C C++ Java Recipes vs. How are you? Hello world. state machine model • State machine model • For control dominated systems.. Dr.1 • More effort would be required with sequential program or state machine model Enter X: 1 Enter Y: 2 Hello world. Java E. sets control outputs Languages capture models Variety of languages can capture one model One language can capture variety of models • Dataflow model • For data dominated systems.. Hello world.” every X seconds Display “How are you?” every Y seconds u.Models and languages • How can we (precisely) capture behavior? HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Ulrich Rückert Concurrent process model HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. sequential program model à C. node may fire When node fires. o is open req < floor t is timer_start PrintHelloWorld Simple concurrent process example ReadX ReadY PrintHowAreYou time (Time (Time (Time (Time (Time (Time = = = = = = 1 2 2 3 4 4 s) s) s) s) s) s) Subroutine execution over time Sample input and output 21 22 Dataflow model • • • Derivative of concurrent process model Nodes represent transformations • May execute concurrently HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. C++). well-defined pieces 19 • Certain languages better at capturing certain computation models 20 Finite-state machine (FSM) model HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. we close the door Then. Ulrich Rückert Role of appropriate model and language HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. English Sequential programs vs. monitors control inputs. d is down.C++..g.0 GoingUp req > floor !(req > floor) timer < 10 !(timer < 10) u. simple example: • • • Read two numbers X and Y Display “Hello world.t = 0. languages HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.1.g.d.0. .t = 0. Ulrich Rückert • UnitControl process using a state machine req > floor ConcurrentProcessExample() { x = ReadX() y = ReadY() Call concurrently: PrintHelloWorld(x) and PrintHowAreYou(y) } PrintHelloWorld(x) { while( 1 ) { print "Hello world. but computation model is the key Poetry Recipe Story Models State machine Sequent. state machine might be best model modulate t1 t2 convolve • 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..o.o.. program Dataflow • Common computation models: • Sequential program model • Statements. Template for state machine capture in sequential program language transform Z Nodes with more complex transformations 23 24 . wrote sequential program • • • • • First wait for requested floor to differ from target floor Then. transforms input data streams into output streams • Object-oriented model • For breaking complex software into simpler.0.g. Ulrich Rückert • We may think of languages (C.d.g. C • Communicating process model • Multiple sequential programs running concurrently Computation models describe system behavior • • • • Conceptual notion. sequential program Concrete form. Dr. object-oriented model. 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 Nodes with arithmetic transformations A B C D • To create state machine. How are you? Hello world. Ulrich Rückert Z = (A + B) * (C . C++ ? sequential program model.-Ing. } } PrintHowAreYou(x) { while( 1 ) { print "How are you?" delay(y).1.0 !(req<floor) GoingDn u is up. rules for composing statements.. Dr. e. Dr.. we move up or down to the desired floor Then.d.1. u.D) • 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.g.0 Idle req == floor req < floor DoorOpen u.o. Ulrich Rückert Models vs.

Ulrich Rückert Concurrent process model: implementation HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. B display decoded packets on a screen processA() { // Decode packet // Communicate packet to B } } • Process1 Process2 (a) Process3 Process4 Processor B Processor C Processor D • • 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 (b) Process1 Decoded video packets void processB() { // Get packet from A // Display packet } • Process2 Process3 Process4 General Purpose Processor • Custom single-purpose processors • More common Processor A Process1 Process2 (c) Process3 Process4 General Purpose Processor • Two basic methods • Shared memory • Message passing To display • • Most processes don’t use 100% of processor time Can share processor time and still achieve necessary execution rates Multiple processes run on one general-purpose processor while one or more processes run on own single_purpose processor • (c) Combination of (a) and (b) • • Important mechanisms: Mutual exclusion. program Dataflow Concurrent processes The choice of computational model(s) is based on whether it allows the designer to describe the system. Dr. especially using technical processes. performance. Ulrich Rückert • Basic example: producer/consumer • Process A produces data items. Ulrich Rückert • Mapping of system’s functionality onto hardware processors: • • captured using computational model(s) written in some language(s) State machine Sequent. Video Input Signal Audio 25 26 Communication among processes • Processes need to communicate data and signals to solve their computation problem • Processes that don’t communicate are just independent programs solving separate problems HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. methods.-Ing. Ulrich Rückert Processor technology HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.g. timing and cost requirements Final implementation tested for feasibility • Also serves as blueprint/prototype for mass manufacturing of final product Pascal C/C++ Java VHDL The choice of language(s) is based on whether it captures the computational model(s) used by the designer. Process B consumes them • E. Dr.-Ing.. or knowledge • 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 Datapath Register file General ALU Controller Control logic and State register Datapath Registers Custom ALU Controller Control logic State register Datapath index total + • Three key technologies for embedded systems • Processor technology • IC technology • Design technology IR PC IR PC Data memory Data memory Program memory Assembly code for: Data memory Program memory Assembly code for: total = 0 for i =1 to … Application-specific Single-purpose (“hardware”) total = 0 for i =1 to … General-purpose (“software”) 29 30 . A decodes video packets. Dr. size. Synchronization => Deadlocks! 27 Communication Bus • How do we achieve this communication? • (b) One general-purpose processor running all processes Communication Bus Encoded video packets • Can use single and/or general-purpose processors (a) Multiple processors.Implementation HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Ulrich Rückert Concurrent processes • 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 HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Dr. Set-top Box Task 1: Read Signal Separate Audio/Video Send Audio to Task 2 Send Video to Task 3 Repeat Task 2: Wait on Task 1 Decode/output Audio Repeat Task 3: Wait on Task 1 Decode/output Video Repeat Implementation A Implementation B Implementation C The choice of implementation is based on whether it meets power.-Ing.-Ing. Dr. Ulrich Rückert • Technology • A manner of accomplishing a task. each executing one process Processor A 28 Three key embedded system technologies HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. performance and cost requirements..-Ing.4] Task 1: Read pulse If pulse < Lo then Activate Siren If pulse > Hi then Activate Siren Sleep 1 second Repeat Task 2: If B1/B2 pressed then Lo = Lo +/– 1 If B3/B4 pressed then Hi = Hi +/– 1 Sleep 500 ms Repeat Heart-beat pulse • • • Implementation choice independent from language(s) choice Implementation choice based on power. Dr.-Ing. size. Heartbeat Monitoring System B[1.

-Ing. PLD (Programmable Logic Device) Behavioral specification Libraries/IP: Incorporates predesigned implementation from lower abstraction level into higher level. Semi-custom ASIC (gate array and standard cell). VHDL) Compilers (1960's. Ulrich Rückert • Define system functionality • Convert functionality to physical implementation while • Satisfying constrained metrics • Optimizing other design metrics • Design technologies developed to improve productivity • We focus on technologies advancing hardware/software unified view • Automation • Program replaces manual design • Synthesis Automation Specification • Designing embedded systems is hard • Complex functionality • Millions of possible environment scenarios • Competing.g. IC package IC source gate oxide channel Logic specification Logic synthesis Gates/ Cells Gate simulators drain Silicon substrate To final implementation 31 32 The co-design ladder HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Ulrich Rückert Independence of processor and IC technologies • Basic tradeoff HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.-Ing.. PLD Semi-custom Full-custom 33 34 Design technology • Design task HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Dr. Ulrich Rückert • The manner in which a digital (gate-level) implementation is mapped onto an IC • IC: Integrated circuit. power. Ulrich Rückert • In the past: • Hardware and software design technologies were very different • Recent maturation of synthesis enables a unified view of hardware and software Sequential program code (e. Dr.IC technology HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. tightly constrained metrics • Reuse Verification Implementation Reuse • Productivity gap • As low as 10 lines of code or 100 transistors produced per day • Predesigned components • Cores • General-purpose and single-purpose processors on single IC • Verification • Ensuring correctness/completeness of each design step • Hardware/software co-simulation 35 36 . System specification System synthesis Libraries/ IP Hw/Sw/ OS Test/ Verification Model simulat.-Ing. NRE cost. 1960's) Machine instructions Behavioral synthesis (1990's) Register transfers RT synthesis (1980's. Behavior synthesis Cores Hw-Sw cosimulators RT specification RT synthesis RT components HDL simulators Test/Verification: Ensures correct functionality at each level. C. size./ checkers • Types: Full-custom/VLSI. providing improved: Power efficiency Performance Size Cost (high volume) • Hardware/software “codesign” Microprocessor plus program bits: “software” Implementation VLSI. providing improved: Flexibility Maintainability NRE cost Time. Ulrich Rückert Design Technology HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. linkers (1950's. Ulrich Rückert Improving productivity HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Dr. Dr. 1980's) Logic gates • General vs. or “chip” • IC technologies differ in their customization to a design • IC’s consist of numerous layers (perhaps 10 or more) • IC technologies differ with respect to who builds each layer and when • The manner in which we convert our concept of desired system functionality into an implementation Compilation/ Synthesis Compilation/Synthesis: Automates exploration and insertion of implementation details for lower level. Dr. custom • With respect to processor technology or IC technology • The two technologies are independent General.1970's) Assembly instructions Assemblers.-Ing.to-prototype Time-to-market Cost (low volume) Generalpurpose processor ASIP Singlepurpose processor Customized. thus reducing costly iterations between levels. 1990's) Logic equations / FSM's Logic synthesis (1970's. like performance. Dr. ASIC. and especially flexibility. there is no fundamental difference between what hardware or software can implement.-Ing.-Ing. or PLD implementation: “hardware” The choice of hardware versus software for a particular function is simply a tradeoff among various design metrics.

. C.e. 1960s) Logic synthesis (1970s. ASIC. Dr.-Ing.000 millennium 41 42 .g. generate outputs for each gate 1 at time • Several programs added between simulated system and real hardware • 1 simulated operation: • = 10 to 100 simulator operations • = 100 to 10.000 operating system operations • = 1. Ulrich Rückert Advantages over physical implementation • Controllability • Control time • Stop/start simulation at any time HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.000. Ulrich Rückert • Simulation setup time • Often has complex external environments • Could spend more time modeling environment than system • Relative speeds of different types of simulation/emulation • 1 hour actual execution of SOC • = 1. 500 nanoseconds) 39 40 Disadvantages HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. linkers (1950s.-Ing. 1990s) Logic equations / FSM's Assemblers. MUXs Gates.-Ing... Dr.-Ing. Ulrich Rückert • • • 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 • The codesign ladder Sequential program code (e. Dr. or PLD implementation Each axis represents type of description • Behavioral • Defines outputs as function of inputs • Algorithms but no implementation Structural Behavior Sequential programs Register transfers Logic equations/FSM Transfer functions Cell Layout Modules Chips Boards Physical Processors.Automation: synthesis HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.g.000 hours gate-level simulation 1 ×10 ×100 ×1000 IC FPGA 1 hour 1 day 4 days 1.1970s) • Implements behavior by connecting components with known behavior • Physical • Gives size/locations of components and wires on chip/board • 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 • Synthesis converts behavior at given level to structure at same level or lower • E.000 gate. FUs. • • • • FSM ? gates. flip-flops Transistors • Structural • Design tools evolve for higher levels of abstraction • Different rate in each field Compilers (1960s. Ulrich Rückert • Complete • Describes appropriate output to all relevant input • Control data values • Inputs or internal values • Formal verification • Hard • For small designs or verifying certain key properties only • 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 • Simulation • Most common verification method • Can step through small intervals (i.000. Ulrich Rückert Simulation speed HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.2 years ×10000 cycle-accurate simulation 12 years ×100. VHDL) Behavioral synthesis (1990s) Register transfers Assembly instructions RT synthesis (1980s. Dr.4 months • 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.level HDL simulation 1 ×10.-Ing.000 register-transfer. 1980s) Logic gates Implementation VLSI. memories (higher level) Machine instructions Microprocessor plus program bits 37 38 Verification • Ensuring design is correct and complete • Correct • Implements specification accurately HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. memories Registers.-Ing. flip-flops (same level) FSM ? transistors (lower level) FSM X registers. Dr.000 to 100.000.000 hardware operations hardware emulation throughput model instruction-set simulation 1. Ulrich Rückert Gajski’s Y-chart HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. FUs (higher level) FSM X processors. Dr.level HDL simulation >1 lifetime ×1.2 years instruction-set simulation • = 10.

control circuitry HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Ulrich Rückert Reuse: intellectual property cores HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. Dr. libraries/IP. single-purpose • IC: Full-custom. Dr. application-specific. prepackaged ICs Implements GPP or SPP Reduces design/debug time Have always been available • • SPP emulator • FPGAs (10s to 100s) Usually supports debugging tasks • Created to help solve simulation disadvantages • • Mapped relatively quickly • Hours. semi-custom.-Ing. Ulrich Rückert • Commercial off-the-shelf (COTS) components • • • • Predesigned.de • SOC built by integrating multiple descriptions 43 44 Summary HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof. PLD • Design: Compilation/synthesis.-Ing.Emulators • General physical device system mapped to • Microprocessor emulator • Microprocessor IC with some monitoring.-Ing. Ulrich Rückert • Embedded systems are everywhere • Key challenge: optimization of design metrics • Design metrics compete with one another • State machine models good for control • Concurrent process model for multi-task systems • Communication and synchronization methods exist • Scheduling is critical • A unified view of hardware and software is necessary to improve productivity • Three key technologies • Processor: general-purpose. test/verification • Computation models are distinct from languages • Sequential program model is popular • Most common languages like C support it directly • 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 . structural. Ulrich Rückert Summary HEINZ NIXDORF INSTITUTE University of Paderborn System and Circuit Technology Prof.raptor2000.-Ing. Dr. Dr. or physical descriptions • Processor-level components known as cores Can be placed in real environment • No environment setup time • No incomplete environment • Typically faster than simulation • Hardware implementation www. days • 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 • Behavioral.