@ McGraw-Hill Education

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

1
 @ McGraw-Hill Education

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

2
 @ McGraw-Hill Education

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

3
 @ McGraw-Hill Education

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)

4
 @ McGraw-Hill Education

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
5
sequential process execution.
 @ McGraw-Hill Education

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

6
 @ McGraw-Hill Education

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 T b
F

+ Data Flow Node

- Data Flow Node

7
 @ McGraw-Hill Education

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
 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 8
 @ McGraw-Hill Education

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

9
 @ McGraw-Hill Education

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

10
 @ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design –Sequential
Ignition Key ON
Program Model
Wait for 10 Seconds
E.g. Automatic ‘Seat Belt Warning’ in an automotive
Requirement: Ignitiont ON?

 When the vehicle ignition is turned on and the seat belt

Y
is not fastened within 10 seconds of ignition ON, the Seat Belt ON?

system generates an alarm signal for 5 seconds.

N
 The Alarm is turned off when the alarm time (5 Set Timer for 5 Seconds
Start Alarm

seconds) expires or if the driver/passenger fastens the

belt or if the ignition switch is turned off, whichever Ignition ON

happens first. NO

Y
YES
NO Seat Belt ON?

N
Timer Expired? YES

Y
Stop Alarm

End

11
 @ McGraw-Hill Education

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();
}
}
}

12
 @ McGraw-Hill Education

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

13
 @ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

Computational Models in Embedded Design – Concurrent Processing Model
E.g. Automatic ‘Seat Belt Warning’ in an automotive

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
Create and initialize events { Set Event alarm_timer_expire;
Start Alarm();
wait_timer_expire, ignition_on, ignition_off, Set Event alarm_start;
seat_belt_on, seat_belt_off, Ignition Key Status Monitor Wait for the signaling of
Task alarm_timer_expire or
alarm_timer_start, alarm_timer_expire while(1) { ignition_off or seat_belt_on;
Create task Wait Timer if (Ignition key ON)
{
Stop Alarm();
}
Create task Ignition Key Status Monitor Set Event ignition_on;
Create task Seat Belt Status Monitor Reset Event ignition_off;
Ignition Seat belt Status Monitor
}
Create task Alarm Control else Task
{ while(1) {
Create task Alarm Timer Set Event ignition_off; if (Seat Belt ON)
Reset Event ignition_on; {
(a) } Set Event seat_belt_on;
} Reset Event seat_belt_off;
}
else
{
Set Event seat_belt_off;
Reset Event seat_belt_on;
}
}

(b)

 The processing requirements are split in to multiple tasks

 Tasks are executed concurrently
 ‘Events’ are used for synchronizing the execution of tasks 14
 @ McGraw-Hill Education

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

15
 @ McGraw-Hill Education

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.

16
 @ McGraw-Hill Education

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

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

Structural A collection of externally visible operations

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.

Component Physical packaging of classes and interfaces. Name

A computational resource existing at run time.

Node Represented using a cube with name. Name
17
 @ McGraw-Hill Education

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.
18
 @ McGraw-Hill Education

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

19
 @ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

UML Building Blocks – Relationship
Element Description Representation
It is a structural relationship describing the link
Association between objects. The association can be one-to-one or relationship
one-to-many. Aggregation and Composition are the two
variants of Association.
It represents is “a part of” relationship. Represented by
Aggregation a line with a hollow diamond at the end. a part of

Aggregation with strong ownership relation to

Composition represent the component of a complex object.
Represented by a line with a solid diamond at the end.
Child
Generalization Represents a parent-child relationship. The parent may
be more generalized and child being specialized version
of the parent object. Parent

Represents a relationship in which one element (object,

Dependency class) uses or depends on another element (object,
class). Represented by a dotted arrow with head
pointing to the dependent element.
Element 1
The relationship between two elements in which one
Realization element realizes the behavior specified by the other
element.
Element 2

20
 @ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

UML Relationship - Examples

Alarm is a special type of Audio Visual Indicator (Generalization)

Alarm is a part of Warning System (Aggregation)

21
 @ McGraw-Hill Education

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.
22
 @ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

UML Building Blocks – UML Diagrams
Behavioral Diagrams: Diagram representing the dynamic (behavioral) aspects of the system. Use case Diagram,
Sequence Diagram, State Diagram, Communication Diagram, Activity Diagram, Timing Diagram and Interaction
Overview Diagram are the behavioral diagrams in UML model

Diagram Description
Use cases diagrams are used for capturing system functionality as seen
by users. It is very useful in system requirements capturing. Use case
Use case Diagram diagram comprised of use cases, actors (users) and the relationship
between them. In use case diagram, an actor is one (or something) who
(or which) interacts with the system and use case is the sequence of
interaction between the actor and system.
Sequence diagram is a type of interaction diagram representing object
Sequence Diagram interactions with respect to time. It emphasizes on the time ordering of
messages. Best suited for the interaction modeling of real-time systems.
Collaboration or Communication diagram is a type of interaction
Collaboration (Communication) diagram representing the object interaction and ‘how they are linked
Diagram together’. It gives emphasize to the structural organization of objects
that send and receive messages. In short, it represents the collaboration
of objects using messages.
A diagram showing the states, transitions, events and activities similar
State Chart Diagram to a State Machine representation. Best suited for modeling reactive
systems.
It is a special type of state chart diagram showing activity to activity
Activity Diagram transition in place of state transition. It emphasizes on the flow control
23
among objects.
 @ McGraw-Hill Education

Hardware Software Co-Design and Program Modeling

UML Diagrams - Examples

Actors
Enable or Disable
Seat Belt
Alarm

Use case Alarm

Ignition Key

Use case diagram for Seat Belt Warning System

Wait Timer Alarm Alarm Timer

3 OFF
5 Trigger

Ignition Key Seat Belt

1 Trigger
2 Timeout
6 Timeout

4 ON

Sequence diagram for one possible sequence for the Seat Belt
Warning System 24
 @ McGraw-Hill Education

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

25