EMBEDDED FIRMWARE DEVELOPMENT

ENVIRONMENT
UNIT III

Mr. S. VINOD
ASSISTANT PROFESSOR
EEE DEPARTMENT
• Embedded product development life Cycle
– Objective
– Different phases of EDLC
– Modeling of EDLC
• Issues in hardware and software co-design
– Data flow Graph
– State machine model
– Sequential program model
– Concurrent model
– Object oriented model
 Introduction
Contents:
 What is EDLC
 Why EDLC
 Objectives of EDLC
 Different phases of EDLC
 EDLC approaches
 oduction
 What is EDLC
 Why EDLC
 Objectives of EDLC
 Different phases of EDLC
 EDLC approaches
 References
Introduction :
Software development company – SDLC
Product development company - EDLC
Example

Preparation of any food dish

 Dish selection and Ingredient list
 Procurement of the items in the list
 Preparation and initial taste testing
 Serving and final taste testing

Embedded Product development view

 Father - Overall management
 Mother - Developing and testing
 We - End user /client
What is EDLC?
 EDLC is an Analysis-Design-Implementation
based problem solving approach for the
product development.

 Analysis – What product need to be

developed
 Design – Good approach for building it
 Implementation – To develop it
Why edlc?
 Essential in understanding the scope and
complexities involved in any Embedded
product development.
 Defines interaction and activities among
Various groups of product development sector.
Project management
System design and development
System testing
Release management and quality
assurance
Objectives of EDLC
 Aim of any product development is the Marginal benefit
 Marginal benefit = Return on investment
 Product needs to be acceptable by the end user i.e. it has to
meet the requirements of the end user in terms of quality,
reliability & functionality.
 EDLC helps in ensuring all these requirements by following
three objective
 Ensuring that high quality products are delivered
to user
 Risk minimization and defect prevention in
product development through project management
 Maximize productivity
Ensuring high quality products
 The primary definition of quality in any
embedded product development is return on
investment achieved by the product.
 In order to survive in market, quality is very
important factor to be taken care of while
developing the product.
 Qualitative attributes depends on the budget of the
product so budget allocation is very important.
 Budget allocation might have done after studying
the market, trends & requirements of product,
competition .etc.
Risk minimization & defect prevention through
project management
 Project management (PM)
 Adds an extra cost on budget
 But essential for ensuring the development process is going in right
direction
 Projects in EDLC requires Loose project management or tight
project management.
 PM is required for
 Predictability
 Analyze the time to finish the product (PDS = no of person days )
 Co-ordination
 Resources (developers) needed to do the job
 Risk management
 Backup of resources to overcome critical situation
 Ensuring defective product is not developed
Increased productivity
 Measure of efficiency as well as ROI
Different ways to improve the productivity are
 Saving the manpower
 X members – X period
 X/2 members – X period
 Use of automated tools where ever is required
 Re-usable effort – work which has been done for the previous
product can be used if similarities present b/w previous and
present product.
 Use of resources with specific set of skills which exactly
matches the requirements of the product, which reduces the
time in training the resource
Different phases of edlc

Alife cycle of product development is
commonly referred as the “model”
 A simple model contains five phases

 Requirement analysis

 Design

 Development and test

 Deployment and maintenance

 The no of phases involved in EDLC model

depends on the complexity of the product
Classic Embedded product development
life cycle model
NEED:
 Any embedded product may evolves as an output of a need.

 Need may come from an individual/from public/from company(generally

speaking from an end user/client)
 New/custom product development
 Product re-engineering
 Product maintenance

CONCEPTUALIZATION:
ANALYSIS:

Analyze and
document
functional and non-
functional
requirements

Interface Requirement
definition and specification Document
documentation document review

Define test plan

and procedure Rework on
requirements
and documents
DESIGN: Deals with the entire design of the product taking the requirements
into consideration and focuses on how the functionalities can be delivered.

•Generates detailed
architecture
•Detailed
•Only i/p & o/p architecture also
are defined here needs approval
•Product will look
like a black box
•Sent for approval
from client
DEVELOPMENT AND TESTING:
 Development phase transforms the design into realizable
product
 Design is transformed into hardware and firmware
 Look and feel of the device is very important

Testing phase can be divided into

 Unit testing – independent testing of hardware and firmware
 Integration testing – testing after integrating hardware and
firmware
 System testing – testing of whole system on functionality and
non-functionality basis
 User acceptance testing – testing of the product against the
criteria mentioned by the end-user/client
 Test reports
DEPLOYMENT:
 A process of launching fully functional model into the market
SUPPORT:
 Deals with the operation and maintenance of the product
 Support should be provide to the end user/client to fix the bugs of the
product
UPGRADES:
 Releasing of new version for the product which is already exists in the
market
 Releasing of major bug fixes.
RETIREMENT/DISPOSAL:
 Everything changes, the technology you feel as the most advanced and best
today may not be the same tomorrow
 Due to this the product cannot sustain in the market for long
 It has to be disposed on right time before it causes the loss.
EDLC APPROACHES:
Linear/Waterfall Model:
Need

Conceptualization
Each phase of EDLC is
Analysis
executed in sequence
Design
Flow is unidirectional
Output of one phase
Development & testing serving as input of other
Deployment

Support

Upgrades

Retirement
 Iterative/Incremental/Fountain EDLC Model:

Cascaded series of linear models

Do some analysis, follow some
design, then some implementation in
cycles
Repeat the cycles until the
requirements are met
Prototyping/evolutionary model:
 Similar to iterative model, product is developed in multiple
cycles
 The only difference is the model produces more refined
prototype of the product at each cycle instead of just adding the
functionality at each cycle like in iterative model.
Spiral model:
 Spiral model is best suited for the development of complex embedded
products and situations where the requirements are changing from
customer side.
 Risk evaluation in each stage helps in reducing risk
 Hardware Software Co-Design and Program
Modeling
Traditional Embedded System Development Approach

 The hardware software partitioning is done at an early stage

 Engineers from the software group take care of the software
architecture development and implementation, and
engineers from the hardware group are responsible for
building the hardware required for the product
 There is less interaction between the two teams and the
development happens either serially or in parallel and once
the hardware and software are ready, the integration is
performed
 Hardware Software Co-Design and
Program Modeling
Hardware Software Co-design Approach for Embedded System Development

 The product requirements captured from the customer are

converted into system level needs or processing requirements
rather than partitioning them to either h/w or s/w
 The system level processing requirements are then transferred
into functions which can be simulated and verified against
performance and functionality
 The Architecture design follows the system design. The partition
of system level processing requirements into hardware and
software takes place during the this phase
 Each system level processing requirement is mapped as either
hardware and/or software requirement
 The partitioning is performed based on the hardware-software
trade-offs
 Hardware Software Co-Design and Program Modeling
Fundamental issues in H/w S/w Co-design

 Model Selection
 A Model captures and describes the system characteristics
 A model is a formal system consisting of objects and composition rules
 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 to the implementation aspect of the system design
 The objectives vary with each phase
 Architecture Selection
 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 types of different components and the interconnection among them
 Controller architecture, Datapath Architecture, Complex Instruction Set Computing
(CISC), Reduced Instruction Set Computing (RISC), Very long Instruction Word Computing
(VLIW), Single Instruction Multiple Data (SIMD), Multiple Instruction Multiple Data
(MIMD) etc are the commonly used architectures in system design
 Hardware Software Co-Design and Program Modeling
Fundamental issues in H/w S/w Co-design
 Language Selection
 A programming Language captures a ‘Computational Model’ and maps it into architecture
 A model can be captured using multiple programming languages like C, C++, C#, Java etc for
software implementations and languages like VHDL, System C, Verilog etc for hardware
implementations
 Certain languages are good in capturing certain computational model. For example, C++ is a good
candidate for capturing an object oriented model.
 The only pre-requisite in selecting a programming language for capturing a model is that the
language should capture the model easily

 Partitioning of System Requirements into H/w and S/w

 Implementation aspect of a System level Requirement
 It may be possible to implement the system requirements in either hardware or software
(firmware)
 Various hardware software trade-offs like performance, re-usability, effort etc are used for making
a decision on the hardware-software partitioning
 Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design

 Data Flow Graph/Diagram (DFG) Model

 Translates the data processing requirements into a data flow
graph
 A data driven model in which the program execution is
determined by data.
 Emphasizes on the data and operations on the data which
transforms the input data to output data.
 A visual model in which the operation on the data (process) is
represented using a block (circle) and data flow is represented
using arrows. An inward arrow to the process (circle) represents
input data and an outward arrow from the process (circle)
represents output data in DFG notation
 Best suited for modeling Embedded systems which are
computational intensive (like DSP applications)
 Hardware Software Co-Design and Program Modeling
Computational Models in Embedded Design – Data Flow Graph/Diagram (DFG) Model

E.g. Model the requirement x = a + b; and y = x - c;

a b c

Data Flow Node +

x

- Data Flow Node

Data path: 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 feed back to Input), events etc are examples for non-acyclic inputs. A DFG
model translates the program as a single sequential process execution.
 Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design

 Control Data Flow Graph/Diagram (CDFG) Model

 Translates the data processing requirements into a data flow
graph
 Model applications involving conditional program execution
 Contains both data operations and control operations
 Uses Data Flow Graph (DFG) as element and conditional
(constructs) as decision makers.
 CDFG contains both data flow nodes and decision nodes,
whereas DFG contains only data flow nodes
 Hardware Software Co-Design and
Program Modeling
Computational Models in Embedded Design

 Control Data Flow Graph/Diagram (CDFG) Model

 A visual model in which the operation on the data (process) is
represented using a block (circle) and data flow is represented using
arrows. An inward arrow to the process (circle) represents input
data and an outward arrow from the process (circle) represents
output data in DFG notation.
 The control node is represented by a ‘Diamond’ block which is the
decision making element in a normal flow chart based design
 Translates the requirement, which is modeled to a concurrent
process model
 The decision on which process is to be executed is determined by
the control node
 Capturing of image and storing it in the format selected (bmp, jpg,
tiff, etc.) in a digital camera is a typical example of an application
that can be modeled with CDFG
 Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design – Control Data Flow Graph/Diagram (CDFG) Model

E.g. Model the requirement If flag = 1, x = a + b; else y = a-b;

flag = 1? Control Node

a b
T
F

+ Data Flow Node

- Data Flow Node

 Hardware Software Co-Design and Program Modeling
Computational Models in Embedded Design
 State Machine Model
 Based on ‘States’ and ‘State Transition’
 Describes the system behavior with ‘States’, ‘Events’, ‘Actions’
and ‘Transitions’
 State is a representation of a current situation.
 An event is an input to the state. 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
 Hardware Software Co-Design and Program Modeling
Computational Models in Embedded Design
 State Machine Model
 Most of the time State Machine model translates the requirements
into sequence driven program
 The Hierarchical/Concurrent Finite State Machine Model (HCFSM) is
an extension of the FSM for supporting concurrency and hierarchy
 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
 HCFSM uses statecharts for capturing the states, transitions, events
and actions. The Harel Statechart, UML State diagram etc are
examples for popular statecharts used for the HCFSM modeling of
embedded systems
 Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design – Finite State Machine (FSM) Model

E.g. Automatic ‘Seat Belt Warning’ in an automotive

Requirement:
When the vehicle ignition is turned on and the seat belt is not fastened within 10 seconds
of ignition ON, the system generates an alarm signal for 5 seconds.
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.

Ignition Key ON
Alarm
Ignition Key OFF Waiting
Off
Seat Belt ON

Alarm
On
 Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design

 Sequential Program Model

 The functions or processing requirements are executed in
sequence
 The program instructions are iterated and executed conditionally
and the data gets transformed through a series of operations
 FSMs are good choice for sequential Program modeling.
 Flow Charts is another important tool used for modeling
sequential program
 The FSM approach represents the states, events, transitions and
actions, whereas the Flow Chart models the execution flow
 Hardware Software Co-Design and Program Modeling

Ignition Key ON
Computational Models in Embedded Design –
Sequential Program Model
Wait for 10 Seconds

E.g. Automatic ‘Seat Belt Warning’ in an Ignitiont ON?

automotive

Y
Requirement:
Seat Belt ON?
When the vehicle ignition is turned on and the
seat belt is not fastened within 10 seconds of

N
Set Timer for 5 Seconds
ignition ON, the system generates an alarm Start Alarm

signal for 5 seconds.

The Alarm is turned off when the alarm time Ignition ON

(5 seconds) expires or if the driver/passenger NO

Y
fastens the belt or if the ignition switch is YES
NO Seat Belt ON?
turned off, whichever happens first.

N
Timer Expired? YES

Y
Stop Alarm

End
 Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design –Sequential Program Model

E.g. Automatic ‘Seat Belt Warning’ in an automotive
#define ON 1
#define OFF 0
#define YES 1
#define NO 0
void seat_belt_warn()
{
wait_10sec();
if (check_ignition_key()==ON)
{
if (check_seat_belt()==OFF)
{
set_timer(5);
start_alarm();
while ((check_seat_belt()==OFF )&&(check_ignition_key()==OFF )&& (timer_expire()==NO));
stop_alarm();
}
}
}
 Hardware Software Co-Design and Program Modeling
Computational Models in Embedded Design
 Concurrent/Communicating Process Model
 Models concurrently executing tasks/processes. The program instructions are
iterated and executed conditionally and the data gets transformed through a
series of operations
 Certain processing requirements are easier to model in concurrent processing
model than the conventional sequential execution.
 Sequential execution leads to a single sequential execution of task and
thereby leads to poor processor utilization, when the task involves I/O waiting,
sleeping for specified duration etc.
 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 execution.
 Concurrent processing model requires additional overheads in task
scheduling, task synchronization and communication
 Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design – Concurrent Processing Model

E.g. Automatic ‘Seat Belt Warning’ in an automotive

Create and initialize events

wait_timer_expire, ignition_on, ignition_off,
seat_belt_on, seat_belt_off,
alarm_timer_start, alarm_timer_expire
Create task Wait Timer
Create task Ignition Key Status Monitor
Create task Seat Belt Status Monitor
Create task Alarm Control
Create task Alarm Timer

(a)

 The processing requirements are split in to multiple tasks

 Tasks are executed concurrently
 ‘Events’ are used for synchronizing the execution of tasks
Wait Timer Task Alarm Control Task Alarm Timer Task
Sleep(10s); Wait for the signaling of Wait for the Event alarm_start;
//Signal wait_timer_expire wait_timer_expire Sleep(5s);
Set Event wait_timer_expire; if (ignition_on && seat_belt_off) //Signal alarm_timer_expire
{ Set Event alarm_timer_expire;
Start Alarm();
Set Event alarm_start;
Ignition Key Status Monitor Wait for the signaling of
Task alarm_timer_expire or
while(1) { ignition_off or seat_belt_on;
if (Ignition key ON) Stop Alarm();
{ }
Set Event ignition_on;
Reset Event ignition_off;
} Ignition Seat belt Status Monitor
else Task
{ while(1) {
Set Event ignition_off; if (Seat Belt ON)
Reset Event ignition_on; {
} Set Event seat_belt_on;
} Reset Event seat_belt_off;
}
else
{
Set Event seat_belt_off;
Reset Event seat_belt_on;
}
}

(b)
 Hardware Software Co-Design and Program Modeling

Introduction to Unified Modeling Language (UML)

Unified Modeling Language (UML) is a visual modeling language for Object
Oriented Design (OOD). UML helps in all phases of system design through a
set of unique diagrams for requirements capturing, designing and deployment
UML Building Blocks
 Things
An abstraction of the UML Model
 Relationships
An entity which express the type of relationship between UML elements (objects,
classes etc)
 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
 Hardware Software Co-Design and Program Modeling

UML Building Blocks

 Things

 Structural things: Represents mostly the static parts of a UML model. They are also known as
‘classifiers’. Class, interface, use case, use case realization (collaboration), active class, component
and node are the structural things in UML.
 Behavioral things: Represents mostly the dynamic parts of a UML model. Interaction, state
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.
 Hardware Software Co-Design and Program Modeling
UML Building Blocks - Things

Thing Element Description Representation

A template describing a set of objects which
Identifier
Class share the same attributes, relationships,
operations and semantics. It can be considered Variables
as a blueprint of object. Methods

Class presenting a thread of control in the

Identifier
Active Class system. It can initiate control activity. Active
class is represented in the same way as that of a Variables
class but with thick border lines. Methods

A collection of externally visible operations

Structural Interface which specify a service of a class. It is
represented as a circle attached to the class
Defines a set of sequence of actions. It is
Use case normally represented with an ellipse indicating Name
the name.
Collaboration (Use Interaction diagram specifying the collaboration
case Realization) of different use cases. It is normally represented Name
with a dotted ellipse indicating the name.
Name
Component Physical packaging of classes and interfaces.

A computational resource existing at run time.

Node Represented using a cube with name. Name
 Hardware Software Co-Design and Program Modeling
UML Building Blocks - Things

Thing Element Description Representation

Behavior comprising a set of
Interaction objects exchanging messages to
accomplish a specific purpose. Name
Represented by arrow with name
Behavioral of operation
Behavior specifying the sequence
State of states in response to events, Name
Machine through which an object
traverses during its lifetime.
Organizes elements into
Grouping Package packages. It is only a conceptual
Name
thing. Represented as a tabbed
folder with name.
Explanatory element in UML
Annotational Note models. Contains formal informal
explanatory text. May also Text
contain embedded image.
 Hardware Software Co-Design and Program Modeling

The Seat Belt Warning System – UML modeling

The Alarm Class State Representation for ‘Alarm ON’ state

Alarm – Timer Class interaction for the Seat belt Warning System
 Hardware Software Co-Design and Program Modeling
UML Building Blocks – UML Diagrams
Static Diagrams: Diagram representing the static (structural) aspects of the system. Class Diagram, Object
Diagram, Component Diagram, Package Diagram, Composite Structure Diagram and Deployment Diagram falls
under this category

Diagram Description
Gives a pictorial representation of a set of objects and their
Object Diagram relationships. It represents the structural organization between
objects.
Gives a pictorial representation of the different classes in a
Class Diagram UML model, their interfaces, the collaborations, interactions
and relationship between the classes etc. It captures the static
design of the system.
It is a pictorial representation of the implementation view of a
Component Diagram system. It comprises of components (Physical packaging of
classes and interfaces), relationships and associations among
the components.
It is a representation of the organization of packages and their
Package Diagram elements. Package diagrams are mostly used for organizing use
case diagrams and class diagrams.
It is a pictorial representation of the configuration of run time
Deployment Diagram processing nodes and the components associated with them.
 Hardware Software Co-Design and Program Modeling

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
Processing speed, performance, memory requirements,
effort, re-usability etc. are examples for some of the
hardware software trade-offs in the partitioning of a
system requirement