1. Embedded System, A Brief Introduction
Presented by
Subash Chandra Nayak
01EC3010, IIT Kharagpur

2. Part - 1
Introduction

3. Introduction Embedded Systems :-
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)
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

4. Examples

5. Characteristics

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

7. Essential components and considerations
- 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

8. Design-flow in ES Design

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

10. Specification and Modelling methods in Embedded System
Part - 2
Specification and Modelling methods in Embedded System

11. Models and Architecture
- 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

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

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

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

15. Models State Oriented Models :- Activity 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

16. Models Data Oriented Models :- Heterogeneous 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 )

17. Models DSP apps uses Data flow 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....

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

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

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

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

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

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

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

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

26. Specification Languages Examples : A comparison

27. HW-SW Partitioning

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

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

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

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

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

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

34. Issues in Partitioning
Specification abstraction level
Granularity
System-component allocation
Metrics and estimations
Partitioning algorithms
Objective and closeness functions
Output
Flow of control and designer interaction

35. Issues in Partitioning (cont.)
High Level Abstraction
Decomposition of functional objects
Metrics and estimations
Partitioning algorithms
Objective and closeness functions
Component allocation
Output

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

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

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

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

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

41. 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. A B C
A, B - Local minima
C - Global minimum

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

43. Functional Partitioning Algorithms
For Hardware :-
# BUD
# Aparty
For Systems :-
# Vulcan I
# Vulcan II
# Cosyma
# SpecSyn

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

45. Thank You