Download as pdf or txt
Download as pdf or txt
You are on page 1of 8

HEINZ NIXDORF INSTITUTE

University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Outline

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

An introduction to embedded systems design


Matthias Grnewald

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

References

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Embedded systems overview

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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, Frstenallee 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

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 VCRs, DVD players Video game consoles Video phones Washers and dryers

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Some common characteristics of embedded systems

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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 systems environment Must compute certain results in real-time without delay

An embedded system example -- a digital camera

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Design challenge optimizing design metrics

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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 systems implementation Optimizing design metrics is a key challenge

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 8

Design challenge optimizing design metrics

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Design challenge optimizing design metrics

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Common metrics
Unit cost: the monetary cost of manufacturing each copy of the system,
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, safety, many more

10

Design metric competition -- improving one may worsen others

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

The performance design metric

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Power

Performance

Size

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
11

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., Cameras A and B process images in 0.25 seconds

NRE cost

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

CCD lens

Digital camera chip A2D JPEG codec DMA controller CCD preprocessor Pixel coprocessor D2A

Speedup of B over S = Bs performance / As performance


Throughput speedup = 8/4 = 2

Microcontroller

Multiplier/Accum Display ctrl

Memory controller

ISA bus interface

UART

LCD ctrl

12

Moores law

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Design productivity gap

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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,000 1,000

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,000 10,000 1000

Logic transistors per chip (in millions) Note: logarithmic scale

100 10 1 0.1 0.01 0.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.1 0.01 0.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./Staff-Mo.

productivity

0.1 0.01

13

14

Design process model

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Waterfall method

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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.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.g, customer adds features after product demo

Waterfall design model Behavioral Structural Physical

Spiral design model Structural Behavioral

System specifications commonly change


E.g., to remain competitive by reducing power, 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, 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. Dr.-Ing. Ulrich Rckert

Modelling embedded systems

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Describing embedded systems 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.g., FPGAs for prototype
silicon for final product

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

17

18

Models and languages How can we (precisely) capture behavior?

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Models vs. languages

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

We may think of languages (C, C++), but computation model is the key

Poetry

Recipe

Story

Models

State machine

Sequent. program

Dataflow

Common computation models:


Sequential program model
Statements, rules for composing statements, semantics for executing them
Languages
English Spanish Japanese C C++ Java

Recipes vs. English

Sequential programs vs. C

Communicating process model


Multiple sequential programs running concurrently

Computation models describe system behavior


Conceptual notion, e.g., recipe, sequential program Concrete form, e.g., English, C E.g., sequential program model C,C++, Java E.g., C++ ? sequential program model, object-oriented model, state machine model

State machine model


For control dominated systems, monitors control inputs, 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, transforms input data streams into output streams

Object-oriented model
For breaking complex software into simpler, 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. Dr.-Ing. Ulrich Rckert

Concurrent process model

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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." delay(x); } } PrintHowAreYou(x) { while( 1 ) { print "How are you?" delay(y); } }

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

u,d,o, t = 1,0,0,0

GoingUp req > floor

!(req > floor) timer < 10 !(timer < 10)

u,d,o,t = 0,0,1,0 Idle req == floor req < floor

DoorOpen u,d,o,t = 0,0,1,1

More effort would be required with sequential program or state machine model
Enter X: 1 Enter Y: 2 Hello world. Hello world. How are you? Hello world. How are you? Hello world. ...

u,d,o,t = 0,1,0,0

!(req<floor) GoingDn u is up, d is down, 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. Dr.-Ing. Ulrich Rckert

Role of appropriate model and language

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Z = (A + B) * (C - 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, 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

Edges represent flow of tokens (data) from one node to another


May or may not have token at any given time

B C

+ t1 t2 *

When all of nodes 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

Nodes with arithmetic transformations


A B C D

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

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.g., Template for state machine capture in sequential program language

transform

Nodes with more complex transformations

23

24

Implementation

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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.-Ing. Ulrich Rckert

Mapping of systems functionality onto hardware processors:


captured using computational model(s) written in some language(s)
State machine Sequent. program Dataflow Concurrent processes

The choice of computational model(s) is based on whether it allows the designer to describe the system.

Heartbeat Monitoring System


B[1..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, size, performance, 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.

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, size, performance and cost requirements.

Video

Input Signal

Audio

25

26

Communication among processes Processes need to communicate data and signals to solve their computation problem
Processes that dont communicate are just independent programs solving separate problems

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Concurrent process model: implementation

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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

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 dont 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, 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, each executing one process

Processor A

28

Three key embedded system technologies

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Processor technology

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Technology
A manner of accomplishing a task, especially using technical processes, methods, or knowledge

The architecture of the computation engine used to implement a systems 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

IC technology

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Design Technology

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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 ICs 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. System specification System synthesis Libraries/ IP Hw/Sw/ OS Test/ Verification Model simulat./ checkers

Types: Full-custom/VLSI, Semi-custom ASIC (gate array and standard cell), PLD (Programmable Logic Device)

Behavioral specification Libraries/IP: Incorporates predesigned implementation from lower abstraction level into higher level.

Behavior synthesis

Cores

Hw-Sw cosimulators

RT specification

RT synthesis

RT components

HDL simulators

Test/Verification: Ensures correct functionality at each level, thus reducing costly iterations between levels. 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. Dr.-Ing. Ulrich Rckert

Independence of processor and IC technologies Basic tradeoff

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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.g., C, VHDL) Compilers (1960's,1970's) Assembly instructions Assemblers, linkers (1950's, 1960's) Machine instructions Behavioral synthesis (1990's) Register transfers RT synthesis (1980's, 1990's) Logic equations / FSM's Logic synthesis (1970's, 1980's) Logic gates

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

ASIP

Singlepurpose processor

Customized, providing improved: Power efficiency Performance Size Cost (high volume)

Hardware/software codesign

Microprocessor plus program bits: software

Implementation

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.

PLD

Semi-custom

Full-custom

33

34

Design technology Design task

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Improving productivity

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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, 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

Automation: synthesis

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Gajskis Y-chart

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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.g., C, VHDL) Behavioral synthesis (1990s) Register transfers Assembly instructions RT synthesis (1980s, 1990s) Logic equations / FSM's Assemblers, linkers (1950s, 1960s) Logic synthesis (1970s, 1980s) Logic gates Implementation VLSI, ASIC, 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, memories Registers, FUs, MUXs Gates, flip-flops Transistors

Structural

Design tools evolve for higher levels of abstraction


Different rate in each field

Compilers (1960s,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.g.,
FSM ? gates, flip-flops (same level) FSM ? transistors (lower level) FSM X registers, FUs (higher level) FSM X processors, 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. Dr.-Ing. Ulrich Rckert

Advantages over physical implementation Controllability


Control time
Stop/start simulation at any time

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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.e., 500 nanoseconds)

39

40

Disadvantages

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Simulation speed

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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.2 years instruction-set simulation = 10,000,000 hours gate-level simulation
1 10 100 1000 IC FPGA 1 hour 1 day 4 days 1.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, 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,000 to 100,000 hardware operations

hardware emulation throughput model

instruction-set simulation 1.2 years 10000 cycle-accurate simulation 12 years 100,000 register-transfer- level HDL simulation >1 lifetime 1,000,000 gate- level HDL simulation 1 10,000,000 millennium

41

42

Emulators
General physical device system mapped to
Microprocessor emulator
Microprocessor IC with some monitoring, control circuitry

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Reuse: intellectual property cores

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Commercial off-the-shelf (COTS) components


Predesigned, 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, 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, structural, 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.raptor2000.de

SOC built by integrating multiple descriptions

43

44

Summary

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

Summary

HEINZ NIXDORF INSTITUTE


University of Paderborn System and Circuit Technology Prof. Dr.-Ing. Ulrich Rckert

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, 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

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

You might also like