Module-4B

Hardware Software Co design and Program Modelling : (Chapter 7 – Text 1: 7.1,

7.2)

• Fundamental issues in Hardware Software Co-design

• Computational models in Embedded System Design.

FUNDAM ENTAL ISSUES IN HARDWARE SOFTWARE CO-DESIGN

The hardware software co-design is a problem statement and when we try to
solve this problem statement in real life we may come across multiple issues in
the design. The following section illustrates some of the 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

A model only captures the system characteristics and does not provide

Page 1
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. 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.).
1. The Controller Architecture implements the finite state machine model
(which we will discuss in a later section) using a state register and two
combinational circuits (we will discuss about combinational circuits in a
later chapter). The state register holds the present state and the
combinational circuits implement the logic for next state and output.
2. The Datapath Architecture is best suited for implementing the data flow
graph model where the output is generated as a result of a set of predefined
computations on the input data. 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 high speed
arithmetic units. Ports connect the datapath to multiple buses. Most of the
time the arithmetic units are connected in parallel with pipelining support
for bringing high performance.
3. The Finite State Machine Datapath (FSMD) architecture combines
the controller architecture with datapath architecture. It implements a

Page 2
 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 receiving/sending the
control signals from/to the controller unit and the second I/O port interfaces
the datapath with external world for data input and data output. 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.
4. 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. The use of a single complex instruction in place of multiple simple
instructions greatly reduces the program memory access and program memory size
requirement. However it requires additional silicon for implementing microcode
decoder for decoding the CISC instruction. 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.
5. 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.
6. Parallel processing architecture implements multiple concurrent

Page 3
 Processing Elements (PEs) and each processing element may associate a
datapath containing register and local memory.
7 . Single Instruction Multiple Data (SIMD) and Multiple Instruction
Multiple Data (MIMD) architectures are examples for parallel processing
architecture. In SIMD architecture, a single instruction is executed in
parallel with the help of the Processing Elements. 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 (We will discuss about re-configurable processors in a later
chapter). On the other hand, the processing elements of the MIMD
architecture execute different instructions at a given point of time. The
MIMD architecture forms the basis of multiprocessor systems. The PEs in a
multiprocessor system communicates through mechanisms like shared
memory and message passing.
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.
Partitioning System Requirements into hardware and software

Page 4
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
✓ Data Flow Graph (DFG) model
✓ State Machine model
✓ Concurrent Process model
✓ Sequential Program model
✓ Object Oriented model
etc. are the commonly used computational models in embedded system
design. The following sections give an overview of these models.
1. 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 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 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.
Embedded applications which are computational intensive and data driven are
modeled using the DFG model. DSP applications are typical examples for it.
Now let’s have a look at the implementation of a DFG. Suppose one of the

Page 5
functions in our application contains the computational requirement x = a + b;
and y = x – c. Figure 3.1 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.

Fig 3.1 Data Flow Graph (DFG) Model

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

Page 6
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 Fig. 3.2.

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

Page 7
configured by the user.
3. 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 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. 3.3.

Page 8
 Fig. 3.3 FSM Model for Automatic seat belt warning system
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 Fig. 3.4

Page 9
 As seen 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.
Example 1
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’

Page 10
to cancel the order and take back the coin.
The FSM representation for the above requirement is given in Fig. 5.
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. It is left
to the readers as exercise.

Page 11
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
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 Fig. 3.6, is a simple representation and it doesn’t

Page 12
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. 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 modelling of embedded systems. In
statecharts, the state is usually represented using geometric shapes like rounded
rectangle, rectangle, ellipse, circle, etc. The Harel Statechart uses a rounded
rectangle for representing state. Arrows are used for representing the state
transition and they are marked with the event associated with the state
transition. Sometimes an optional parenthesised condition is also labelled with
the arrow. 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
(https://www.iar.com/iar-embedded-workbench/add-ons-and-
integrations/visualstate/) from IAR systems is a popular visual modelling tool
for embedded applications.

Page 13
 3.6 FSM Model for coin operated Telephone system
4. 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. Here 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

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

Figure 3.7 illustrates the flow chart approach for modelling the ‘Seat Belt Warning’
system explained in the FSM modelling section.

Page 15
5. Concurrent/Communicating Process Model
The concurrent or communicating process model models concurrently
executing tasks/processes. So far we discussed about the sequential execution
of software programs. It is easier to implement certain requirements 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 utilisation, 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. However, concurrent
processing model requires additional overheads in task scheduling, task
synchronisation 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. We can split the tasks into:
1. Timer task for waiting 10 seconds (wait timer task)

Page 16
 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)
4. Task for starting and stopping the alarm (alarm control task)
5. Alarm timer task for waiting 5 seconds (alarm timer task)
We have five tasks here and we cannot execute them randomly or sequentially.
We need to synchronise 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 executed only when the wait timer is expired and if the ignition
key is in the ON state and seat belt is in the OFF state. Here we will use events
to indicate these scenarios. The wait_timer_expire event is associated with the
timer task event and it will be in the reset state initially and it is set when the
timer expires. 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. The events
ignition_off 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 seat belt status monitoring task. The events alarm_timer_start and
alarm_timer_expire are associated with the alarm timer task. The
alarm_timer_start event will be in the reset state initially and it is set by the
alarm control task when the alarm is started. The alarm_timer_expire event will
be in the reset state initially and it is set when the alarm timer expires. The
alarm control task waits for the signaling of the event wait_timer_expire and

Page 17
starts the alarm timer and alarm if both the events ignition_on and seat_belt_off
are in the set state when the event wait_timer_expire signals. 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 signalling of any one of the events
alarm_timer_expire or ignition_off or seat_belt_on. Upon signalling any one of
these events, the alarm is stopped and the alarm control task simply completes
its execution and returns. Figure 3.8 illustrates the same.
It should be noted that the method explained here is just one way of
implementing a concurrent model for the ‘Seat Belt Warning’ system. The
intention is just to make the readers familiar with the concept of multitasking
and task communication/synchronisation. There may be other ways to model
the same requirements. It is left to the readers as exercise. The concurrent
processing model is commonly used for the modelling of ‘Real Time’ systems.
Various techniques like ‘Shared memory’, ‘Message Passing’, ‘Events’, etc.
are used for communication and synchronising between concurrently executing
processes.

Page 18
6. Object-Oriented Model
The object-oriented model is an object based model for modelling system
requirements. It disseminates a complex software requirement into simple well
defined pieces called objects. Object-oriented model brings re-usability,
maintainability and productivity in system design. In the object-oriented
modelling, object is an entity used for representing or modelling a particular
piece of the system. Each object is characterised by a set of unique behaviour
and state. A class is an abstract description of a set of objects and it can be

Page 19
considered as a ‘blueprint’ of an object. A class represents the state of an object
through member variables and object behaviour 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. The protected variables and functions are protected
from external access. However classes derived from a parent class can also
access the protected member functions and variables. The concept of object
and class brings abstraction, hiding and protection.
As mentioned at the beginning of this book, an embedded system is a
combination of special purpose hardware and software (firmware). The
hardware of embedded system is built around analog electronic components
and circuits, digital electronic components and circuits, and Integrated Circuits
(ICs). A Printed Circuit Board (PCB) provides a platform for placing all the
necessary hardware components for building an embedded product, like a
chess board where you can move the pawns, rookies and bishop. If you are
building a simple hardware or a test product, you can use a bread-board to
interconnect the various components. For a commercial product you cannot go
for a bread-board as an interconnection platform since they make your product
bulky and the breadboard connections are highly unstable and your product
may require thousands of inter connections. Printed Circuit Boards (PCB) acts
as the backbone of embedded hardware. This chapter is organised in such a
way to refresh the reader’s knowledge on various analog and digital electronic
components and circuits, familiarise them with Integrated Circuit designing
and provide them the fundamentals of printed circuit boards, its design and
development using Electronic Design Automation (EDA) tools.

Page 20
Page 21