Embedded System Concepts

Presented by
Dr.A.V.PRATHAP KUMAR
 INTRODUCTION
Embedded Systems :-
 An embedded system is a special-purpose computer system designed to
perform a dedicated function (OR)
 Application-specific systems which contain hardware and software tailored
for a particular task and are generally part of a larger system (e.g.,
industrial controllers)

A generic embedded
system
Characteristics
Are dedicated to a particular application
Include processors dedicated to specific functions
Represent a subset of reactive (responsive to external
inputs) systems
Contain real-time constraints
Include requirements that span:
Performance
Reliability
Form factor
 Why Embedded system ?
• Performance
• Technology Advances
• CMOS VLSI dominates older technologies (TTL, ECL)
• Computer architecture improvements
• RISC, superscalar, RAID, …
• Price
• Simpler development
• CMOS VLSI: smaller systems, fewer components
• Higher volumes
• CMOS VLSI : same device cost 10,000 vs. 10,000,000 units
 Structure
EMBEDDED SYSTEM

MICRO PROCESSOR MICRO

CONTROLLER

Micro controllers have built in peripherals and memory

which reduces the size of the system
 Application Areas
 Signal processing systems
Real-time video, DVD players, Medical equipment.
 Distributed control
Network routers, switches, firewalls,
 “Small” systems
Mobile phones, home appliances, toys, smartcards, MP3
players, PDAs, digital cameras, sensors, pc keyboard &
mouse
 Modern cars: Up to 100 or more processors
• Engine control unit
• ABS systems (Anti Lock Brake systems)
• Emissions control
• Diagnostics and Security systems
• Accessories (doors, windows etc)
Examples
 Apollo Guidance computer

The Apollo Guidance Computer, the first recognizable

modern embedded system developed by Charles Stark
Draper at the MIT Instrumentation Laboratory
 Other developments
First Microprocessor By mid 1980’s micro
Intel 4004 controllers came into
Required external existence
memory and support
chips
cost of a By the end of the 80s,
microcontroller fell embedded systems
below $1 were the norm rather
than the exception
 Characteristics of Embedded Systems
1. Interface
2. Complexity
3. Platform
4. Peripherals
5. Tools
6. Reliability
7. Volume
 1. Interface
Interface

No User Full User

Interface Interface

Dedicated to one Task Performing user defined

Missile guidance system PDA’s
 2. Complexity
Complexity

Simple systems Complex systems

•Use buttons, small character/ •Connected to a network

•Touch screen
digit-only displays
•simple menu system •Real time constraints
•Part of a critical operation
 3. CPU Platform
• Many different CPU architectures used in embedded designs
such as ARM, MIPS, x86, PIC, 8051 etc…
• Desktop computer market is limited to just a few architectures
• PC/104 is a typical base for small, low-volume embedded
system design.
• Uses an embedded real-time operating system such as
MicroC/OS-II, QNX or VxWorks
• Very-high-volume embedded systems use the system on a chip
(SoC), an application-specific integrated circuit (ASIC)
• CPU core was purchased and added as part of the chip design.
 4. Peripherals
• Serial Communication Interfaces
• Universal Serial Bus (USB)
• Networks: Ethernet, Controller Area Network
• Timers: PLL(s), Capture/Compare and Time Processing Units
• General Purpose Input/Output (GPIO)
• Analog to Digital/Digital to Analog (ADC/DAC)
 5. Tools
• Embedded system designers use compilers, assemblers,
and debuggers
• Utilities to add a checksum or CRC to a program
• Emulator replaces the microprocessor with a simulated
equivalent
 6. Reliability issues
• System cannot be shut down for repair
• Solutions involve subsystems with spares
• system must be kept running for safety and monetary
reasons
 7. Volume
Volume

High Volume Low Volume

Minimizing cost is Used when cost is not a

usually the primary major factor
design consideration
Performance and
reliability constraints
 Concepts of co-design
• Codesign
• The meeting of system-level objectives by exploiting the
trade-offs between hardware and software in a system
through their concurrent design

• Key concepts
• Concurrent: hardware and software developed at the same
time on parallel paths
• Integrated: interaction between hardware and software
developments to produce designs that meet performance
criteria and functional specifications
 Essential components and
considerations
• Essential components :-
- Microprocessor / DSP core
- Sensors
- Converter ( A-D and D-A )
- Actuators
- Memory (on-chip and off-chip )
- Communication path with interfacing environment

• Essential considerations :-
- Response time ;- ( Real time system )
- Area, Cost, Power, Portability, Fault-tolerance
Design-flow in ES Design
 A mix of Disciplines
• DSP, Communication, Control…..
• Software Engineering
• Programming Languages
• Compiler and OS
• Architecture, Processor and IO techniques
• Parallel and Distributed computing
• Real Time Systems
• VLSI CAD
 Models and Architecture

• Models :-
- Conceptual view of system’s functionality
- A set of functional objects and rules for composing these
objects.

• Architectures :-
- Abstract view of system’s functionality
- A set of implementation components and their connections
 Modeling : Introduction
• Modeling starts with System Specification

• System Specification : Main purpose : To provide clear and

unambiguous description of the system function, and to provide a
documentation of initial design process

• It supports diverse models of computation

• It allows the application of CAD tools for design space
exploration, partitioning, SW-HW synthesis, validation and
testing
• It should not constrain the implementation options
 Models and Modeling
• Models :- Conceptual views of system’s functionality ; A set of functional objects and rules for composing
these objects

• One of the keys to a GOOD hardware/software Codesign process is a unified representation the allows the
functionality of the system (at various levels of abstraction) to be specified in a manner that is “unbiased” towards
either a hardware or software implementation.

• Unified Representation –
• A representation of a system that can be used to describe its functionality independent of its
implementation in hardware or software
• Allows hardware/software partitioning to be delayed until trade-offs can be made
• Typically used at a high-level in the design process

• Provides a simulation environment after partitioning is done, for both hardware and software designers to use to
communicate

• Supports cross-fertilization between hardware and software domains

 Models And Modeling
• Models are used for design representation

• Design representation can be of three types

- Behavioral
- Physical
- Structural

• There are various methods of Designing ES namely

- Capture and Simulate : Schematic capture , simulation
- Describe and Synthesis : HDL , Behavioral and Logic synthesis
- Specify-Explore-Rene : Executable specification and other formal methods….
 Models
• State Oriented Models :-
- FSM : Melay and Moore models
- Petri Nets
- Hierarchical Concurrent FSM ( HCFSM )

• Activity Oriented Models :-

- Data Flow Graph ( DFG )
- Flow Chart / Control Flow Graph ( CFG )

• Structure Oriented Models :-

- Components Connectivity Diagrams
- RT net lists, Gate net lists
 Models
• Data Oriented Models :-
- Entry Relationship diagram
- Jackson’s Diagram

• Heterogeneous Models :-
- Control / Data Flow Graph
- Structure Chart
- Programming Languages : C, C++, Java, Verilog, VHDL, Esterel, SDL (Speciation and Description
Language), CSP (Communicating Sequential Process), SpecCharts, StateCharts etc...
- Object Oriented Paradigm
- Program state Machine
- Queuing model
- Process Networks : Kahn’s Process Network
- Communicating Sequential Processes ( CSP )
- Synchronous Data Flow model ( SDF )
 Models
• N numbers of Models for design representation !!! Now
question is which model to choose ???

• DSP apps uses Data flow Models

• Control Intensive apps FSM Models
• Similarly Event driven apps uses Reactive Models
• Finally the choice of models largely depends on
personal tastes, Application Domains, Availability of
software and tools etc....
 Architectures
• We must be clear about the architecture that we are going to use for design of ES
• It has also got a wide variety of choices, to be chosen according to the given application.
• The choices are as follows
• Application-specific Architecture :-
- Controller Architecture
- Datapath Architecture
- Finite state machine with datapath

• General Purpose Architecture :-

- CISC
- RISC
- Vector machine
- VLIW ( Very Long Instruction Word Computer )
 System Specification
• For every design there exists an conceptual view
• Conceptual view depends on application
- Computation : Conceptualize as a Program
- Controller : Conceptualize as a FSM
• Goal of specification language : To capture conceptual view with minimum designer’s effort
• Ideal language : 1-to-1 mapping between conceptual model and language construct
• Characteristics of commonly used conceptual models
- Concurrency
- Hierarchy
- Synchronization
 Specification Language
Requirements I
• A good ES specification Language should have a bunch of feature supported such as :-

• Concurrency :-
- Can exists at difference levels such as :-
# Job Level
# Task Level
# Statement Level
# Operation Level
# Bit Level
- Two types of concurrency within a behavior :-
# Data driven
# Control driven
 Specification Language
Requirements II
• State Transitions :-
- System are often modeled as state-based, e.g. Controller
- difficult to capture using programming construct

• Hierarchy :-
- Required for managing system complexity
- Allows system modeler to focus on one sub-system at a time
- Two types of hierarchy :-
# Structural Hierarchy
# Behavioral Hierarchy
# Concurrent Decomposition :- fork-join , process
# Sequential Decomposition :- procedure, state machine
 Specification Language
Requirements III
• Behavioral Completion :-
- Behavior completes when all computation performed
- Advantages : Behavior can be viewed with inter-level transitions and
allows natural decomposition into sequential behavior

• Communication :-
- Concurrent behavior exchange data
- Are of two types
# Shared memory model
# Message passing model
 Specification Language
Requirements IV
• Synchronization :-
- Needed when concurrent behavior executes at different speeds
- Required when :-
# Data exchange between behavior
# Different activities must be performed simultaneously
- Types
# Control dependent :- by reset , fork-join etc...
# Data dependent :- synchronization by :-
# Common event
# Status detection
# Common variable
 Specification Language
Requirements V
• Exception handling :-
- Occurrence of event terminates current computation
- Control transferred to appropriate next mode
- Ex :- Reset, Interrupt

• Timing :-
- Required to implement / represent real time situation
- Ex :-
Wait for 100 ns
A <= A+1 after 200ns etc..
 Specification Languages Examples
• A good ES specification Language should support all the above characteristics of ES

• Essential Characteristics :-
# State Transition
# Exceptions
# Behavioral Hierarchy
# Concurrency
# Programming Construct
# Behavioral Completion

• Some commonly used languages for ES specification :-

VHDL, Verilog, Esterel, SDL, CSP, SpecChart, StateChart
Specification Languages Examples : A
comparison
Hardware/Software Partitioning
• Definition
• The process of deciding, for each subsystem, whether the required
functionality is more advantageously implemented in hardware or
software

• Goal
• To achieve a partition that will give us the required performance
within the overall system requirements (in size, weight, power,
cost, etc.)

• This is a multivariate optimization problem that when

automated, is an NP-hard problem
 HW/SW Partitioning Issues

• Partitioning into hardware and software affects overall system cost

and performance

• Hardware implementation
• Provides higher performance via hardware speeds and parallel execution of
operations
• Incurs additional expense of fabricating ASICs

• Software implementation
• May run on high-performance processors at low cost (due to high-volume
production)
• Incurs high cost of developing and maintaining (complex) software
 Partitioning Approaches

• Start with all functionality in software and move

portions into hardware which are time-critical and
can not be allocated to software (software-
oriented partitioning)

• Start with all functionality in hardware and move

portions into software implementation
(hardware-oriented partitioning)
 System Partitioning
• Structural :-
# Implement structure and then partition ...

• Functional :-
# System partitioning in the context of HW-SW partitioning is known as functional partitioning
# Approach:- System’s functionality is described as collection of indivisible functional objects
# Each system’s functionality is either implemented in either hardware or software
# Advantages:- Enables better size/performance tradeoff
# Uses fewer objects
# Better for Algorithms / Humans
# Permits HW-SW solutions
# But is harder than graph partitioning
 Partitioning Metrics
• Deterministic estimation techniques
• Can be used only with a fully specified model with all data
dependencies removed and all component costs known
• Result in very good partitions
• Statistical estimation techniques
• Used when the model is not fully specified
• Based on the analysis of similar systems and certain design
parameters
• Profiling techniques
• Examine control flow and data flow within an architecture to
determine computationally expensive parts which are better
realized in hardware
 Binding Software
to Hardware
• Binding: assigning software to hardware
components
• After parallel implementation of assigned modules,
all design threads are joined for system integration
• Early binding commits a design process to a certain
course
• Late binding, on the other hand, provides greater
flexibility for last minute changes
 Issues in Partitioning
• Specification abstraction level
• Granularity
• System-component allocation
• Metrics and estimations
• Partitioning algorithms
• Objective and closeness functions
• Partitioning algorithms
• Output
• Flow of control and designer interaction
 Specification Abstraction
Levels
• Task-level dataflow graph
• -A Dataflow graph where each operation represents a task
• Task
– Each task is described as a sequential program
• Arithmetic-level dataflow graph
– A Dataflow graph of arithmetic operations along with some
control operations
– The most common model used in the partitioning techniques
• Finite state machine (FSM) with datapath
– A finite state machine, with possibly complex expressions
being computed in a state or during a transition
 Specification Abstraction Levels
(Cont.)
• Register transfers
• The transfers between registers for each machine state
are described
• Structure
• A structural interconnection of physical components
• Often called a netlist
 Granularity Issues in Partitioning

• The granularity of the decomposition is a measure of the size

of the specification in each object
• The specification is first decomposed into functional objects,
which are then partitioned among system components
• Coarse granularity means that each object contains a large amount
of the specification.
• Fine granularity means that each object contains only a small
amount of the specification
• Many more objects
• More possible partitions
• Better optimizations can be achieved
 System Component
Allocation
• The process of choosing system component types from
among those allowed, and selecting a number of each to
use in a given design
• The set of selected components is called an allocation
• Various allocations can be used to implement a specification,
each differing primarily in monetary cost and performance
• Allocation is typically done manually or in conjunction with
a partitioning algorithm
• A partitioning technique must designate the types of
system components to which functional objects can be
mapped
• ASICs, memories, etc
 Metrics and Estimations Issues

• A technique must define the attributes of a partition that determine its quality
• Such attributes are called metrics
• Examples include monetary cost, execution time, communication bit-rates, power
consumption, area, pins, testability, reliability, program size, data size, and memory
size
• Closeness metrics are used to predict the benefit of grouping any two objects
• Need to compute a metric’s value
• Because all metrics are defined in terms of the structure (or software) that implements the
functional objects, it is difficult to compute costs as no such implementation exists during
partitioning Two key metrics are used in hardware/software partitioning

• Performance: Generally improved by moving objects to hardware

• Hardware size: Hardware size is generally improved by moving objects out of hardware
 Partitioning Approaches
• Traditional Approaches
• Take Objective function as a weighted sum along with
constrains considerations
• Aim:- To minimize Power, Delay, cost, Area etc...
• Here is the objective function values which is obviously
multimodal with multiple maxima and minima.

B
A, B - Local minima
A
C - Global minimum
C
 Basic partitioning algorithms
• Clustering and multi-stage clustering [Joh67, LT91]

• Group migration (a.k.a. min-cut or Kernighan/Lin) [KL70, FM82]

• Ratio cut [KC91]

• Simulated annealing [KGV83]

• Genetic evolution

• Integer linear programming

 Functional Partitioning Algorithms

• For Hardware :-
# BUD
# Aparty

• For Systems :-
# Vulcan I
# Vulcan II
# Cosyma
# SpecSyn
 Summary
• Partitioning heavily influence design quality
• Functional partitioning is necessary
• Executable specification enables
# Automation
# Exploration
# Documentation
• Variety of algorithm exist
• Variety of techniques exist for different applications