Module 2:

Hardware Software Co-Design and Program Modelling

TRADITIONAL v/s Hardware Software Co- Design Approach

1. 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, whereas engineers
from the hardware group are responsible for building the hardware required for the
product.

2. There is less interaction between the two teams and the development happens either
serially or in parallel. Once the hardware and software are ready, the integration is
performed. 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.

3. During the co-design process, the product requirements captured from the customer
are converted into system level needs or processing requirements. At this point of time
it is not segregated as either hardware requirement or software requirement, instead
it is specified as functional requirement.

4. 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 architecture design
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.
FUNDAMENTAL ISSUES IN HARDWARE SOFTWARE CO-DESIGN:

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

Selecting the Architecture

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. 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.).
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 software implementations
and languages like VHDL, System C, Verilog, etc. for hardware implementations. 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. 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.

Partioning System Requirements into hardware

from an implementation perspective, it may be possible to implement the system requirements

in either hardware or software (firmware). It is a tough decision-making task to figure out which one to
opt. Various hardware software trade-offs are used for making a decision on the hardware-software
partitioning.

COMPUTATIONAL MODELS IN EMBEDDED DESIGN

1. Data Flow Graph (DFG) model,

2. Control Data Flow Graph (DFG) model,
3. State Machine model,
4. Sequential Program model
Data Flow Graph (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 determined by data. This model emphasises on the data and operations
on the data which transforms the input data to output data. 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 fl ow 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.

Embedded applications which are computational intensive and data driven are modelled using
the [Link] applications are typical examples for it. Now let’s have a look at the
implementation of a DFG. Suppose one of the functions in our application contains the
computational requirement x = a + b; and y = x – c.

Figure illustrates 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.
Control Data Flow Graph/ Diagram (CDFG):

DFG model is a data driven model in which the execution is controlled by data and it
doesn’t involve any control operations (conditionals). The Control DFG (CDFG) model is
used for modelling applications involving conditional program execution. CDFG models
contains both data operations and control operations. The CDFG 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. Let us have a look at
the implementation of the CDFG for the following requirement. If flag = 1, x = a + b; else y
= a – b; This requirement contains a decision-making process. The CDFG model for the same
is given in figure.

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
modelled to a concurrent process model. The decision on which process is to be executed is
determined by the control node.
A real-world example for modelling the embedded application using CDFG is the capturing
and saving of the image to a format set by the user in a digital still camera 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 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.

State Machine Model

• The State Machine model is used for modelling reactive or event-driven embedded
systems whose processing behaviour are dependent on state transitions.
• Embedded systems used in the control and industrial applications are typical examples
for event driven systems. The State Machine model describes the system behaviour 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.
• 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. The system requirements are
captured as. 1. 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. 2.
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 fi rst. 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 Figure.

• 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’.
• When the wait timer expires in the waiting state, the event ‘Timer Expire’ is generated and it
transitions the state to ‘Alarm On’ from the ‘Waiting’ state. 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.
The timer also has certain set of states and events for state transitions. Using the FSM model, the
timer can be modeled as shown in Figure

• from the FSM, the timer state can be either ‘IDLE’ or ‘READY’ or ‘RUNNING’. During the
 normal condition when the timer is not running, it is said to be in the ‘IDLE’ state.

• The timer is said to be in the ‘READY’ state when the timer is loaded with the count
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
Expire’ event.
Design an automatic tea/coffee vending machine based on FSM model for the following
requirement. The tea/coffee vending is initiated by user inserting a 5 rupee coin. After
inserting the coin, the user can either select ‘Coffee’ or ‘Tea’ or press ‘Cancel’ to cancel the
order and take back the coin.

The FSM representation for the above requirement is given in Figure.

• 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 ‘Coffee’ (Tea and Coffee are the drink select button).
• If the event triggered in ‘Wait State’ is ‘Cancel’ button press, the coin is pushed
out and the state transitions to ‘Wait for Coin’. 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.
• Once the coffee/tea vending is over, the respective states transitions back to the
‘Wait for Coin’ state. 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 ‘Error State’ can be added to enhance this design.

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

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)

4. If the line is through, the user is allowed to talk till 60 seconds and at the end of 45th second, 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.

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.
• The FSM model shown in Figure, 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.
• Most of the time state machine model translates the requirements into sequence driven program
and it is difficult to implement concurrent processing with FSM.
• This limitation is addressed by the Hierarchical/ Concurrent Finite State Machine model
(HCFSM).
• The 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.
 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.
• 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 modelling.
• Another important tool used for modelling sequential program is Flow Charts.
• 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.
#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();
}
}
}
Figure illustrates the flow chart approach for modelling the ‘Seat Belt Warning’ system explained
in the FSM modelling section
 HARDWARE SOFTWARE TRADE-OFFS

The important hardware-software trade-offs in embedded system design are

(1) Processing speed and performance
(2) Frequency of change (Re-configurability)
(3) Memory size and gate count
(4) Reliability
(5) Man hours (Effort) and cost
• Certain system level processing requirements may be possible to develop in either
hardware or software. The decision on which one to select is based on the trade-offs and
actual system requirement.
• For example, if the embedded system under consideration involves some multimedia
codec* requirement. The media codec can be developed in either software or using
dedicated hardware chip (like ASIC or ASSP). Here the trade-off is performance and
re-configurability.
• A codec developed in hardware may be much more efficient, optimised 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.
• 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 implemented in
software (firmware).
• Embedded systems are highly memory constrained and embedded designers don’t have
the luxury of using extravagant memory for implementing requirements. On the other
hand, evaluate the gate count required (Normally hardware chips are 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.
The Assembly language program written in assembly code is saved as (Assembly file) file or
a (source) file or a format supported by the assembler
Similar to C and other high level language programming, it is possible to have multiple source
files called modules in assembly language programming . Each module is represented by a .
or file or the assembler supported file format similar to the files in C programming
The software utility called Assembler performs the translation of assembly code to machine code
The assemblers for different family of target machines are different. A51 Macro Assembler from
Keil software is a popular assembler for the 051 family micro controller
Each source file can be assembled separately to examine the syntax errors and incorrect assembly
instructions
Assembling of each source file generates a corresponding ob ect file . The ob ect file does not
contain the absolute address of where the generated code needs to be placed (a re locatable code)
on the program memory
The software program called linker/locater is responsible for assigning absolute address to ob ect
files during the linking process
The Absolute ob ect file created from the ob ect files corresponding to different source code
modules contain information about the address where each instruction needs to be placed in code
memory
A software utility called Ob ect to ex file converter translates the absolute ob ect file to
corresponding hex file (binary file)

sse l language to achine language Con ersion process

 antages

EfficientCode Memory Data Memory Usage (MemoryOptimi ation)

igh Performance
Low level ardware Access
Code Reverse Engineering

ra ac s

igh Development time

Developer dependency
Non portable
 igh le el language to achine language Con ersion process

antages

Reduced Development time

Developer independency
Portability