9 - ES - Hardware Software Co-Design

Hardware Software Co-Design and Program
Modelling
(Embedded System)
l
ita
Dr. Basudeba Behera
ig
Assistant Professor
-D
BB
Department of Electronics and Communication Engineering
National Institute of Technology Jamshedpur, Jharkhand, India
INTRODUCTION
• In the traditional embedded system development approach,
 the hardware software partitioning is done at an early stage
 and engineers from the software group take care of the software architecture
development and implementation,
l
ita
 whereas engineers from the hardware group are responsible for building the hardware
required for the product.
ig
• There is less interaction between the two teams and the development happens either serially
-D
or in parallel.
• Once the hardware and software are ready, the integration is performed.
•
BB
The increasing competition in the commercial market and need for reduced ‘time-to-market’
the product calls for a novel approach for embedded system design in which the hardware and
software are co-developed instead of independently developing both.
• During the co-design process, the product requirements captured from the customer are
converted into system level needs or processing requirements.
2
INTRODUCTION
• At this point of time it is not segregated as either hardware requirement or software
requirement, instead it is specified as functional requirement.
• The system level processing requirements are then transferred into functions which can be
simulated and verified against performance and functionality.
l
• The Architecture design follows the system design.
ita
• The partition of system level processing requirements into hardware and software takes place
ig
during the architecture design phase.
-D
• Each system level processing requirement is mapped as either hardware and/or software
requirement.
•
• BB
The partitioning is performed based on the hardware-software trade-offs.
The architectural design results in the detailed behavioral description of the hardware
requirement and the definition of the software required for the hardware.
• The processing requirement behavior is usually captured using computational models and
ultimately the models representing the software processing requirements are translated into
firmware implementation using programming languages. 3
FUNDAMENTAL ISSUES IN HARDWARE SOFTWARE CO-DESIGN
• Selecting the model
• Selecting the Architecture
 controller architecture
 datapath architecture
l
ita
 Finite State Machine Datapath (FSMD)
ig
 Complex Instruction Set Computing (CISC)
-D
 Very Long Instruction Word (VLIW)
• Parallel processing architecture
• Selecting the language
BB
• Partitioning System Requirements into hardware and software
4
Selecting the model
• In hardware software co-design, models are used for capturing and describing the system
characteristics.
• A model is a formal system consisting of objects and composition rules.
l
ita
• It is hard to make a decision on which model should be followed in a particular system design.
• Most often designers switch between a variety of models from the requirements specification
ig
to the implementation aspect of the system design.
-D
• The reason being, the objective varies with each phase; for example at the specification stage,
only the functionality of the system is in focus and not the implementation information.
•
BB
When the design moves to the implementation aspect, the information about the system
components is revealed and the designer has to switch to a model capable of capturing the
system’s structure.
5
Selecting the Architecture
• A model only captures the system characteristics and does not provide information on ‘how
the system can be manufactured?’'.
• The architecture specifies how a system is going to implement in terms of the number and
l
types of different components and the interconnection among them.
ita
• Controller architecture, Datapath Architecture, Complex Instruction Set Computing (CISC),
ig
Reduced Instruction Set Computing (RISC), Very Long Instruction Word Computing (VLIW),
Single Instruction Multiple Data (SIMD), Multiple Instruction Multiple Data (MIMD), etc. are
-D
the commonly used architectures in system design.
BB
• Some of them fall into Application Specific Architecture Class (like controller architecture),
while others fall into either general purpose architecture class (CISC, RISC, etc.) or Parallel
processing class (like VLIW, SIMD, MIMD, etc.).
6
• The controller architecture implements the finite state machine model using a state register
and two combinational circuits.
• The state register holds the present state and the combinational circuits implement the logic
for next state and output.
l
• The datapath architecture is best suited for implementing the data flow graph model where
ita
the output is generated as a result of a set of predefined computations on the input data.
ig
• A datapath represents a channel between the input and output and in datapath architecture
the datapath may contain registers, counters, register files, memories and ports along with
-D
high speed arithmetic units.
BB
• Ports connect the datapath to multjple buses.
• Most of the time the arithmetic units are connected in parallel with pipelining support for
bringing high performance
7
• The Finite State Machine Datapath (FSMD) architecture combines the controller
architecture with datapath architecture. It implements a controller with datapath.
• The controller generates the control input whereas the datapath processes the data.
• The datapath contains two types of I/O ports, out of which one acts as the control port for
l
receiving/sending the control signals from/to the controller unit and the second I/O port
ita
interfaces the datapath with' external world for data input and data output.
ig
• Normally the datapath is implemented in a chip and the I/O pins of the chip acts as the data
input output ports for the chip resident data path.
-D
BB
8
• The Complex Instruction Set Computing (CISC) architecture uses an instruction set
representing complex operations.
• It is possible for a CISC instruction set to perform a large complex operation (e.g. Reading a
register value and comparing it with a given value and then transfer the program execution to
a new address location (The CJNE instruction for 8051 ISA)) with a single instruction.
l
ita
• The use of a single complex instruction in place of multiple simple instructions greatly
reduces the program memory access and program memory size requirement.
ig
• However it requires additional silicon for implementing microcode decoder for decoding the
-D
CISC instruction.
BB
• The datapath for the CISC processor is complex. On the other hand, Reduced Instruction Set
Computing (RISC) architecture uses instruction set representing simple operations and it
requires the execution of multiple RISC instructions to perform a complex operation.
• The data path of RISC architecture contains a large register file for storing the operands and
output. RISC instruction set is designed to operate on registers. RISC architecture supports
extensive pipelining.
9
• The Very Long Instruction Word (VLIW) architecture implements multiple functional units
(ALUs, multipliers, etc.) in the datapath.
• The VLIW instruction packages one standard instruction per functional unit of the datapath.
• Parallel processing architecture implements multiple concurrent Processing Elements
l
(PEs) and each processing element may associate a datapath containing register and local
ita
memory.
ig
• Single Instruction Multiple Data (SIMD) and Multiple Instruction Multiple Data (MIMD)
architectures are examples for parallel processing architecture.
-D
• In SIMD architecture, a single instruction is executed in parallel with the help of the
BB
Processing Elements.
10
• The scheduling of the instruction execution and controlling of each PE is performed through a
single controller.
• The SIMD architecture forms the basis of re-configurable processor.
• On the other hand, the processing elements of the MIMD architecture execute different
l
instructions at a given point of time.
ita
• The MIMD architecture forms the basis of multiprocessor systems.
ig
• The PEs in a multiprocessor system communicates through mechanisms like shared memory
-D
and message passing.
BB
11
• Selecting the language A programming language captures a ‘Computational Model’ and
maps it into architecture.
• There is no hard and fast rule to specify this language should be used for capturing this model.
• A model can be captured using multiple programming languages like C, C++, C#, Java, etc. for
l
software implementations and languages like VHDL, System C, Verilog, etc. for hardware
ita
implementations.
ig
• On the other hand, a single language can be used for capturing a variety of models. Certain
languages are good in capturing certain computational model.
-D
• For example, C++ is a good candidate for capturing an object oriented model.
•
BB
The only pre-requisite in selecting a programming language for capturing a model is that the
language should capture the model easily.
12
• Partitioning System Requirements into hardware and software So far discussed about the
models for capturing the system requirements and the architecture for implementing the
system.
• From an implementation perspective, it may be possible to implement the system
requirements in either hardware or software (firmware).
l
ita
• It is a tough decision making task to figure out which one to opt.
ig
• Various hardware software trade-offs are used for making a decision on the hardware-
software partitioning.
-D
BB
13
COMPUTATIONAL MODELS IN EMBEDDED DESIGN
The commonly used computational models in embedded system design are as
follow.
 Data Flow Graph (DFG) model,
l
ita
 State Machine model,
 Concurrent Process model,
ig
 Sequential Program model,
-D
 Object Oriented model, etc.
BB
14
Data Flow Graph/Diagram (DFG) Model
• The Data Flow Graph (DFG) model translates the data processing requirements into a data
flow graph.
• The Data Flow Graph (DFG) model is a data driven model in which the program execution is
l
determined by data.
ita
• This model emphasizes on the data and operations on the data which transforms the input
ig
data to output data.
-D
• Indeed Data Flow Graph (DFG) is a visual model in which the operation on the data (process)
is represented using a block (circle) and data flow is represented using arrows.
•
BB
An inward arrow to the process (circle) represents input data and an outward arrow from the
process (circle) represents output data in DFG notation.
15
Data Flow Graph/Diagram (DFG) Model
• Embedded applications which are computational
intensive and data driven are modeled using the
DFG model.
l
• DSP applications are typical examples for it.
ita
• Now let’s have a look at the implementation of a
DFG.
ig
• Suppose one of the functions in our application
-D
contains the computational requirement x = a + b;
and y = x - c.
•
•
BB
Figure shows the implementation of a DFG model for implementing these requirements.
In a DFG model, a data path is the data flow path from input to output.
• A DFG model is said to be acyclic DFG (ADFG) if it doesn’t contain multiple values for the input
variable and multiple output values for a given set of input(s).
• Feedback inputs (Output is fed back to Input), events, etc. are examples for non-acyclic inputs.
A DFG model translates the program as a single sequential process execution. 16
Control Data Flow Graph/Diagram (CDFG)
• We have seen that the DFG model is a data driven model in
which the execution is controlled by data and it doesn’t
involve any control operations (conditionals).
l
• The Control DFG (CDFG) model is used for modelling
ita
applications involving conditional program execution.
ig
• CDFG models contains both data operations and control
operations.
-D
• The CDFG uses Data Flow Graph (DFG) as element and
BB
conditional (constructs) as decision makers.
• CDFG contains both data flow nodes and decision nodes,
whereas DFG contains only data flow nodes.
• Let us have a look at the implementation of the CDFG for the following requirement.
• If flag = 1 ,x = a + b\ els ey = a-b;
• This requirement contains a decision making process. 17
Control Data Flow Graph/Diagram (CDFG)
• The control node is represented by a ‘Diamond’ block which is the decision making element
in a normal flow chart based design.
• CDFG translates the requirement, which is modeled to a concurrent process model.
l
• The decision on which process is to be executed is determined by the control node.
ita
• A real world example for modeling the embedded application using CDFG is
ig
 the capturing and saving of the image to a format set by the user in a digital still camera
-D
where everything is data driven starting from the Analog Front End which converts the
CCD sensor generated analog signal to Digital Signal and the task which stores the data
BB
from ADC to a frame buffer for the use of a media processor which performs various
operations like, auto correction, white balance adjusting, etc.
• The decision on, in which format the image is stored (formats like JPEG, TIFF, BMP, etc.) is
controlled by the camera settings, configured by the user.
18
State Machine Model
• The State Machine model is used for modeling reactive or event-driven embedded systems
whose processing behavior are dependent on state transitions.
• Embedded systems used in the control and industrial applications are typical examples for
l
event driven systems.
ita
• The State Machine model describes the system behavior with ‘States’, ‘Events’, ‘Actions’ and
ig
‘Transitions’.
-D
• State is a representation of a current situation.
• An event is an input to the state.
•
•
BB
The event acts as stimuli for state transition.
Transition is the movement from one state to another.
• Action is an activity to be performed by the state machine.
• A Finite State Machine (FSM) model is one in which the number of states are finite.
• In other words the system is described using a finite number of possible states. 19
State Machine Model
• As an example let us consider the design of an
embedded system for driver/ passenger ‘Seat Belt
Warning’ in an automotive using the FSM model.
l
• The system requirements are captured as.
ita
 When the vehicle ignition is turned on and
ig
the seat belt is not fastened within 10
seconds of ignition ON, the system generates
-D
an alarm signal for 5 seconds.
BB
 The Alarm is turned off when the alarm time (5 seconds) expires or if the driver/
passenger fastens the belt or if the ignition switch is turned off, whichever happens
first.
• Here the states are ‘Alarm Off’, ‘Waiting’ and ‘Alarm On’ and the events are ‘Ignition Key ON’,
‘Ignition Key OFF’, ‘Timer Expire’, ‘Alarm Time Expire’ and ‘Seat Belt ON’.
• Using the FSM, the system requirements can be modeled as given in Fig. 7.3. 20
State Machine Model
• The ‘Ignition Key ON’ event triggers the 10 second timer and transitions the state to ‘Waiting’.
If a ‘Seat Belt ON’ or ‘Ignition Key OFF’ event occurs during the wait state, the state
transitions into ‘Alarm Off’.
l
• When the wait timer expires in the waiting state, the event ‘Timer Expire’ is generated and it
ita
transitions the state to ‘Alarm On’ from the ‘Waiting’ state.
ig
-D
BB
21
State Machine Model
• The ‘Alarm On’ state continues until a ‘Seat Belt ON’ or ‘Ignition Key OFF’ event or ‘Alarm
Time Expire’ event, whichever occurs first.
• The occurrence of any of these events transitions the state to ‘Alarm Off’. The wait state is
implemented using a timer.
l
ita
• The timer also has certain set of states and events for state transitions.
• As seen from the FSM, the timer state can be either ‘IDLE’ or ‘READY’ or ‘RUNNING’.
ig
• During the normal condition when the timer is not running, it is said to be in the ‘IDLE’ state.
-D
• The timer is said to be in the ‘READY’ state when the timer is loaded with the count
BB
corresponding to the required time delay.
• The timer remains in the ‘READY’ state until a ‘Start Timer’ event occurs.
• The timer changes its state to ‘RUNNING’ from the ‘READY’ state on receiving a ‘Start Timer’
event and remains in the ‘RUNNING’ state until the timer count expires or a ‘Stop Timer’ even
occurs.
• The timer state changes to ‘IDLE’ from ‘RUNNING’ on receiving a ‘Stop Timer’ or ‘Timer
22
Expire’ event.
Example 1
Design an automatic tea/coffee
vending machine based on
FSM model for the following
l
requirement.
ita
• The tea/coffee vending is
initiated by user inserting a
ig
5 rupee coin.
-D
• After inserting the coin, the
BB
user can either select
‘Coffee’ or ‘Tea’ or press
‘Cancel’ to cancel the order
and take back the coin.
23
• In its simplest representation, it contains four states namely; ‘Wait for coin’ ‘Wait for User
Input’, ‘Dispense Tea’ and ‘Dispense Coffee’.
• The event ‘Insert Coin’ (5 rupee coin insertion), transitions the state to ‘Wait for User Input’.
• The system stays in this state until a user input is received from the buttons ‘Cancel’, ‘Tea’ or
l
‘Coffee’ (Tea and Coffee are the drink select button).
ita
• If the event triggered in ‘Wait State’ is ‘Cancel’ button press, the coin is pushed out and the
ig
state transitions to ‘Wait for Coin’.
-D
• If the event received in the ‘Wait State’ is either ‘Tea’ button press, or ‘Coffee’ button press,
the state changes to ‘Dispense Tea’ and ‘Dispense Coffee’ respectively.
•
BB
Once the coffee/tea vending is over, the respective states transitions back to the ‘Wait for
Coin’ state.
24
• A few modifications like adding a timeout for the ‘Wait State’ (Currently the ‘Wait State’ is
infinite; it can be re-designed to a timeout based ‘Wait State’.
• If no user input is received within the timeout period, the coin is returned back and the state
automatically transitions to ‘Wait for Coin’ on the timeout event) and capturing another
events like, ‘Water not available’, ‘Tea/Coffee Mix not available’ and changing the state to an
l
ita
‘Error State’ can be added to enhance this design.
ig
-D
BB
25
Example 2
Design a coin operated public telephone unit based on FSM model for the following
requirements.
1. The calling process is initiated by lifting the receiver (off-hook) of the telephone unit
l
ita
2. After lifting the phone the user needs to insert a 1 rupee coin to make the call.
3. If the line is busy, the coin is returned on placing the receiver back on the hook (on-hook)
ig
4. If the line is through, the user is allowed to talk till 60 seconds and at the end of 45th second,
-D
prompt for inserting another 1 rupee coin for continuing the call is initiated
5. If the user doesn’t insert another 1 rupee coin, the call is terminated on completing the 60
seconds time slot.
BB
6. The system is ready to accept new call request when the receiver is placed back on the hook
(on-hook)
7. The system goes to the ‘Out of Order’ state when there is a line fault.
26
BB
-D
ig
ita
l
27
• The FSM model is a simple representation and it doesn’t take care of scenarios like, user
doesn’t insert a coin within the specified time after lifting the receiver, user inserts coins
other than a one rupee etc.
• Handling these scenarios is left to the readers as exercise.
l
• Most of the time state machine model translates the requirements into sequence driven
ita
program and it is difficult to implement concurrent processing with FSM.
ig
• This limitation is addressed by the Hierarchical/ Concurrent Finite State Machine model
(HCFSM).
-D
• The HCFSM is an extension of the FSM for supporting concurrency and hierarchy.
•
BB
HCFSM extends the conventional state diagrams by the AND, OR decomposition of States
together with inter level transitions and a broadcast mechanism for communicating between
concurrent processes.
28
• HCFSM uses statecharts for capturing the states, transitions, events and actions.
• The Harel Stateehart, UML State diagram, etc. are examples for popular statecharts used for
the HCFSM modelling of embedded systems.
• In statecharts, the state is usually represented using geometric shapes like rounded
l
rectangle, rectangle, ellipse, circle, etc.
ita
• The Harel Stateehart uses a rounded rectangle for representing state.
ig
• Arrows are used for representing the state transition and they are marked with the event
-D
associated with the state transition.
• Sometimes an optional parenthesized condition is also labeled with the arrow.
•
BB
The condition specifies on what basis the state transition happens at the occurrence of the
specified event.
• Lots of design tools are available for state machine and statechart based system modelling.
The IAR visualSTATE
29
Sequential Program Model
• In the sequential programming Model, the functions or processing requirements are executed
in sequence.
• It is same as the conventional procedural programming.
l
ita
• Here the program instructions are iterated and executed conditionally and the data gets
transformed through a series of operations.
ig
• FSMs are good choice for sequential program modeling.
-D
• Another important tool used for modeling sequential program is Flow Charts.
BB
• The FSM approach represents the states, events, transitions and actions, whereas the Flow
Chart models the execution flow.
• The execution of functions in a sequential program model for the ‘Seat Belt Warning’ system
is illustrated below.
30
Sequential Program Model
#define ON 1
#define OFF 0
#define YES 1
#define NO 0
Void seat_belt_warn ()
l
ita
{
wait_10sec ();
ig
if (check_ignition_key()==ON)
{
-D
if (check_seat_belt () ==OFF )
{
BB
Set_timer (5);
Start_alarm();
While ((check_seat_belt () == OFF) && (check_ignition_key ()
==OFF )&& (timer_expire ()==NO));
Stop_alarm ();
}
}
} 31
Concurrent/Communicating Process Model
• The concurrent or communicating process model models concurrently executing tasks/
processes.
• It is easier to implement certain requirements in concurrent processing model than the
l
conventional sequential execution.
ita
• Sequential execution leads to a single sequential execution of task and thereby leads to poor
ig
processor utilization, when the task involves I/O waiting, sleeping for specified duration etc.
-D
• If the task is split into multiple subtasks, it is possible to tackle the CPU usage effectively,
when the subtask under execution goes to a wait or sleep mode, by switching the task
BB
execution.
• However, concurrent processing model requires additional overheads in task scheduling,
task synchronization and communication.
• As an example for the concurrent processing model let us examine how we can implement
the ‘Seat Belt Warning’ system in concurrent processing model.
32
Split the tasks into:
1. Timer task for waiting 10 seconds (wait timer task)
2. Task for checking the ignition key status (ignition key status monitoring task)
3. Task for checking the seat belt status (seat belt status monitoring task)
l
ita
4. Task for starting and stopping the alarm (alarm control task)
5. Alarm timer task for waiting 5 seconds (alarm timer task)
ig
-D
BB
33
• We have five tasks here and we cannot execute them randomly or sequentially.
• We need to synchronize their execution through some mechanism.
• We need to start the alarm only after the expiration of the 10 seconds wait timer and that
too only if the seat belt is OFF and the ignition key is ON. Hence the alarm control task is
l
executed only when the wait timer is expired and if the ignition key is in the ON state and
ita
seat belt is in the OFF state.
ig
• Here we will use events to indicate these scenarios.
-D
• The wait timerexpire event is associated with 1 the timer task event and it will be in the
reset state initially and it is set when the timer expires.
•
BB
Similarly, events ignition on and ignition off are associated with the task ignition key status
monitoring and the events seat belt_on and seat_belt_off are associated with the task seat
belt status morning.
34
• The events ignition j)jf and ignition on are set and reset respectively when the ignition key
status is OFF and reset and set respectively when the ignition key status is ON, by the
ignition key status monitoring task.
• Similarly the events seat_belt_off and seat_belt_on are set and reset respectively when the
seat belt status is OFF and reset and set respectively when the seat belt status is ON, by the
l
ita
seat belt status monitoring task.
• The events alarm Timer start and alarm Timer_expire are associated with the alarm timer
ig
task.
-D
• The alarm Timer start event will be in the reset state initially and it is set by the alarm
BB
control task when the alarm is started.
• The alarm Timer expire event will be in these F state Initialfy-and4tisj£t when ,the alarm
timer expires.
• The alarm control task waits for the signaling of the event wait Timer expire^ and starts the
alarm timer and alarm if both the events ignition on and seat helt off are in the set state
when the event wait Jimer^expire signals.
35
• If not the alarm control task simply completes its execution and returns.
• In case the alarm is started, the alarm control task waits for the signaling of any one of the
events alarm timer expire or ignition off or seat belt on.
• Upon signaling any one of these events, the alarm is stopped and the alarm control task
l
simply completes its execution and returns.
ita
• It should be noted that the method explained here is just one way of implementing a
ig
concurrent model for the ‘Seat Belt Warning’ system.
-D
• The intention is just to make the readers familiar with the concept of multi tasking and task
communication/synchronisation.
•
• BB
There may be other ways to model the same requirements.
The concurrent processing model is commonly used for the modeling of ‘Real Time’ systems.
• Various techniques like ‘Shared memory’, ‘Message Passing’, ‘Events’, etc. are used for
communication and synchronizing between concurrently executing processes.
36
l
ita
ig
-D
BB
37
BB
-D
ig
ita
l
38
Object-Oriented Model
• The object-oriented model is an object based model for modeling system requirements.
• It disseminates a complex software requirement into simple well defined pieces called
objects.
l
ita
• Object-oriented model brings re-usability, maintainability and productivity in system
design. In the object-oriented modeling, object is an entity used for representing or
ig
modeling a particular piece of the system.
-D
• Each object is characterized by a set of unique behavior and state.
• A class is an abstract description of a set of objects and it can be considered as a ‘blueprint’
•
of an object.
BB
A class represents the state of an object through member variables and object behavior
through member functions.
• The member variables and member functions of a class can be private, public or protected.
• Private member variables and functions are accessible only within the class, whereas public
variables and functions are accessible within the class as well as outside the class. 39
INTRODUCTION TO UNIFIED MODELLING LANGUAGE (UML)
• Unified Modelling Language (UML) is a visual modelling language for Object Oriented
Design (OOD).
• ‘Things’, ‘Relationships’ and ‘Diagrams’ are the fundamental building blocks of UML.
Things
l
ita
• A ‘Thing’ is an abstraction of the UML model. The ‘Things’ in UML are classified into:
Structural things: Represents mostly the static parts of a UML model. They are also known as
ig
‘classifiers’. Class, interface, use case, use case realization (collaboration), active class,
-D
component and node are the structural things in UML.
Behavioral things: Represents mostly the dynamic parts of a UML model. Interaction, state
BB
machine and activity are the behavioral things in UML.
Grouping things: Are the organizational parts of a UML model. Package and sub-system are the
grouping things in UML.
Annotational things: Are the explanatory parts of a UML model.
Note is the Annotational thing in UML.
40
l
ita
ig
-D
BB
41
l
ita
ig
-D
BB
42
l
ita
ig
-D
BB
43
Relationships: As the name indicates, they express the type of relationship between UML
elements (objects, classes, etc.).
l
ita
ig
-D
BB
44
l
ita
ig
-D
BB
45
UML Diagrams
• UML Diagrams give a pictorial representation of the static aspects, behavioral
aspects and organization and management of different modules (classes,
packages, etc.) of the system.
l
• UML diagrams are grouped into Static Diagrams and Behavioral Diagrams.
ita
Static Diagrams
ig
• Diagram representing the static (structural) aspects of the system.
-D
• Class Diagram, Object Diagram, Component Diagram, Package Diagram,
BB
Composite Structure Diagram and Deployment Diagram falls under this
category. T
46
l
ita
ig
-D
BB
47
Behavioral Diagrams
These are diagrams representing the dynamic (behavioral) aspects of the system.
l
ita
ig
-D
BB
48
l
ita
ig
-D
BB
49
l
ita
ig
-D
BB
50
The UML Tools
The tools for building UML based models and diagrams are 1 available from different vendors.
Some of them are commercial and some of them are either free or open source. The table
given below gives a summary of the popular UML modeling tools.
l
ita
ig
-D
BB
51
HARDWARE SOFTWARE TRADE-OFFS
• Certain system level processing requirements may be possible to develop in either
hardware or software.
• The decision on which one to opt is based on the trade-offs and actual system
requirement.
• For example, if the embedded system under consideration involves some multimedia
l
ita
codec! requirement.
• The media codec can be developed in either software, or using dedicated hardware chip
ig
(like ASIC or ASSP).
-D
• Here the trade-off is performance and re-configurability.
BB
• A codec developed in hardware may be much more efficient, optimized with low
processing and power requirements.
• It is possible to develop the same codec in software using algorithm.
• But the software implementation need not be optimised for performance, speed and
power efficiency.
52
• On the other hand, a codec developed in software is re-usable and re-configurable.
• With certain modification it can be configured for other codec implementations, whereas a
codec developed in a fixed hardware (like ASIC/ASSP) is fixed and it cannot be changed.
Memory size is another important hardware software trade-off.
• Evaluate how much memory is required if the system requirement under consideration is
l
ita
implemented in software (firmware).
• Embedded systems are highly memory constrained and embedded designers don’t have
ig
the luxury of using extravagant memory for implementing requirements.
-D
• On the other hand, evaluate the gate count required (Normally hardware chips are
BB
implemented using logic gates and the density of the chip is expressed in terms of the
number of gates used in the design (millions of gates ©)), if the required feature is going to
implement in hardware.
• Effort required in terms of man hours, if the required feature is going to build in either
software or custom hardware implementation using VHDL or any other hardware
description languages and the cost for each are another important hardware-software
trade-off in any embedded system development. 53
To summarise, the important hardware-software trade-offs in embedded system
design are
 Processing speed and performance
 Frequency of change (Re-configurability)
l
ita
 Memory size and gate count
 Reliability
ig
 Man hours (Effort) and cost
-D
BB
54
REFERENCES
1. Shibu K V, “Introduction to Embedded Systems, Second Edition, Mc Graw Hill
Education, 2017.
l
ita
ig
-D
BB
55

9 - ES - Hardware Software Co-Design

Uploaded by

Copyright:

Available Formats

9 - ES - Hardware Software Co-Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

9 - ES - Hardware Software Co-Design

Uploaded by

Copyright:

Available Formats

Hardware Software Co-Design and Program

 Data Flow Graph (DFG) model,

You might also like