Overview of Hardware–Software Co-Design

(Reference: Chapter 7 K.V Shibu)

# Hardware-Software Co-Design:

* The term ‘co-design’ implies that hardware and software design be considered concurrent and be done
together.

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

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

Q. What are the factors in the current design scene which support co-design?

i) The availability of hardware components like processors which are programmable-MCUs, DSP processors,
etc.

ii) The availability of re-configurable hardware like FPGAs and CPLDs.

Note: Design is made easy because of efficient C compilers and hardware description languages that
automate design using simulation and synthesis tools.
# Steps in Hardware-Software Co-design:

* The first step in any design is the step of making a ‘requirements specifications’.

* The list of requirements includes functional aspects and non-functional aspects like speed, power, cost,
etc.

* The next step is to divide the functionality into two parts for the purpose of implementation, that is,
into hardware and software. This is called partitioning.

* Hardware and software design proceeds in two separate directions. But there is continuous interaction
between these two design teams, such that feedback, correction and re-design is done.

Fig: Co-design development Process

# Fundamental Issues in Hardware-Software co-design:

* Selecting the model

* Selecting the Architecture

* Selecting the Language

* Partitioning System requirement into Hardware and Software

# Computational models in Embedded system design:
* The processing requirement behaviour at system level is usually captured using computational models.

* Commonly used computational models in embedded system design are:

- Data Flow Graph/Diagram (DFG) Model

- Control Data Flow Graph/Diagram (CDFG)

- State Machine Model

- Sequential Program Model

- Concurrent/Communicating Process Model

- Object-Oriented Model
# Data Flow Graph/Diagram (DFG) Model:

* The Data Flow Graph (DFG) model translates the data processing requirements into a data flow graph.

* This model emphasises on the data and operations on the data which transforms the input data to
output data .

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

* Embedded applications which are computational intensive and data driven are modeled using the DFG
model.

Fig: Data flow graph (DFG) model

# Control Data Flow Graph/Diagram (CDFG):

* Data Flow Graph does not consist of any conditional or control operation, it is simply a data driven
model.

* The control DFG (CDFG) is used for modelling applications involving conditional program execution.

* It involves both data and control operation.

Fig: Control Data Flow Graph (CDFG) Model

Q. Now, what do we do with this kind of a system model? Do we realize these DFDs in hardware or
software?

Ans: They can be realized in either ways and that would have been decided at the time of ‘partitioning’ in
the first level
# State Machine Model:

* This is a very commonly used system model suggested for the design of hardware and software.
The State Machine model is used for modelling reactive or event-driven embedded systems whose
processing behaviour are dependent on state transitions.

* The idea of a ‘state machine’ is that, on the occurrence of events, the ‘state’ of the machine changes.
(A state can be thought of as a stored information possessed by the system, like for instance, the
contents of a number of registers).

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

Fig: FSM Model for Automatic seat belt warning system

Example: Design of an embedded system for driver/passenger "Seat Belt Warning" in an automotive using
FSM model.

System Requirements:

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.

Fig: FSM Model for Automatic seat belt warning system

HomeWork: Go through Example 1 and 2

Chapter 7, K.V Shibur

Fig: FSM Model for timer

# Sequential Program Model:

* In the sequential programming Model, the functions or processing

requirements are executed in sequence.

* Flow charts and FSM can be used to perform sequential program

modelling.

* The program instructions are iterated and executed conditionally

and the data gets transformed through a series of operations.

Fig: Sequential Program Model for seat belt warning system

# Concurrent/Communicating Process Model:
* Sequential execution 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.

Example: Implementation of the ‘Seat Belt Warning’ system in concurrent processing model.

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)
4. Task for starting and stopping the alarm (alarm control task)
5. Alarm timer task for waiting 5 seconds (alarm timer task)

These tasks cannot execute them randomly or sequentially. Their execution needed to be synchronised
through some mechanism.
# Object-Oriented Model:

* An Object-Oriented model disseminates a complex software requirement into simple well defined pieces
called objects.

* It brings re-usability, maintainability and productivity in system design.

* 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 considered as a ‘blueprint’ of an object.
# Introduction to Unified Modeling Language (UML):

* UML is a visual modelling language for Object Oriented Design (OOD).

* It consists of an integrated set of diagrams for capturing the processing requirement during system design.

* The fundamental building blocks of UML are:

- Things
- Relationships
- Diagrams

Homework: Read the basics of UML.(Section 7.3, K.V Shibu)

# "Hardware Software Trade-offs":

Homework: Read section 7.4 (K.V Shibu)