Unit-III

Hardware software co-design and program modelling

• In traditional embedded system development approach, the
h/w s/w partitioning is done at early stage.
• Engineers from s/w group take care of s/w architecture
development and implementation and h/w engineers look
into building of h/w required for product.
• Less interaction between two groups, once h/w & s/w ready
the integration performed.
• The increasing competition, and need for reduced ‘time-to-
market’ the product calls for a novel approach for embedded
system design in which h/w and s/w are co-developed instead
of independently developing both.
• During co-design process: the product requirement captured from
the customer are converted into system level needs or processing
requirements. At this point it is not segregated as either h/w or
s/w requirements, it is specified as functional requirements.
• 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 h/w and s/w takes during the architecture design
phase.
• The architectural design results in detailed behavioral description
of the h/w requirement and the definition of the s/w required for
h/w.
• The processing requirement captured using computational models
and model representing s/w processing requirements are
translated into firmware.
 Fundamental issues in hardware software co-design
• Selecting the model
• Selecting the architecture
– Controller architecture
– Datapath architecture
– Finite State Machine Datapath (FSMD)
– Complex Instruction Set Computing(CISC)
– Very Long Instruction Word(VLIW)
– Parallel Processing architecture
• Selecting the language
• Partitioning system requirements into H/W and S/W
 Selecting model
• Models are used capturing and describing the system
characteristics
• Model is a formal system consisting of objects and composition
rules.
• Hard to decide on which model should be followed in a particular
system design.
• Designers switch between a variety of models from requirement
specifications to the implementation aspect of the system design.
• The reason: the objective varies with each phase:
• Example: At specification stage, only the functionality of the
system is in focus not the implementation information, when
design moves to implementation, the information about the
system components is revealed and designer has to switch to a
model capable of capturing the system structure.
 Selecting the Architecture
• A model only captures the system characteristics and
does not provide information on ‘how the system
can be manufactured’?

• A architecture specifies how a system is going to

implement in terms of number and types of different
components and the interconnection between them.
• The controller architecture implements the finite state machine
model using state register and two combinational circuits. The
state register hold the present state and combinational circuits
implement the logic for next state and output.
• The datapath architecture is best suitable for data flow graph
model as output is generated as a result of predefined
computation on the i/p data.
• The finite state machine datapath architecture combines the
controller architecture with datapath architecture. It implements
a controller with data path.
• The complex instruction set computing (CISC) architecture uses
an instruction set representing complex operations. Performs
large complex operations. Ex: CJNE
• Reduced instruction set computing (RISC) architecture instruction
set representing simple operations and requires execution of
multiple RISC instruction to execute complex operations.
• The very long instruction word (VLIW) architecture
implements multiple functional units(ALUs, multipliers, etc.)
in the datapath.
• Parallel processing architecture multiple concurrent
processing elements (PEs) each processing element may
associate a datapath containing register and a local memory.
ex: single instruction multiple data (SIMD)
multiple instruction multiple data (MIMD) architectures.
 Selecting Language
• A programming language captures ‘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 by multiple language like C, C++, C#,
Java, etc. for s/w implementations.
• Languages like VHDL, System C, Verilog, etc. for h/w
implementations.
• 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 H/W and S/W
• It may be possible to implement the system
requirements in either h/w or s/w.
• 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.
 Data flow graph/diagram (DFG) Model
• Translates data processing requirements into a data flow
graph.
• Data driven model in which program execution determined
by the data.
• Model emphasis on data and operations on data which
transforms input data to output data.
• It’s a visual model in which the operation on data represent
by a block (circle) and data flow represented using arrows.
• Inward arrow: input data
• Outward arrow: output data
• Example: DSP applications
• x=a+b and y=x-c
 Control Data Flow Graph/diagram(CDFG)
• Involving conditional program execution.
• It contains both data operations and control
operations.
• CDFG uses DFG as element and conditional as
decision makers.
• It contains data flow nodes and decision nodes.

• Ex: if flag=1, x=a+b; else y=a-b;

• Ex: capturing and saving of the image to a format set
by the user in a digital still camera.
 State machine model
• Is used for modelling reactive or event-driven systems whose
processing behavior are dependent on state transitions.
• Used in control and industrial applications.
• Describes system behavior with ‘states’, ‘events’, ‘actions’
and ‘transitions’.
• State: representation of current situation
• Event: is input to the state, act as stimuli for state transition.
• Transitions: is movement from one state to another.
• Action: activity performed by the state machine.
• Ex: driver passenger seat belt warning in an automotive using
FSM model.
 Example-1 : Design an automatic coffee/tea vending
machine based on FSM model for the following
requirement.
• 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 order and take back the coin.
• It contains four states namely:
State A - wait for coin
State B - wait for user input
State C - dispense tea
State D - dispense coffee

• The event ‘insert coin’, transitions the state to ‘wait for user input’.
• The system stays in this state until a user input is received from buttons
‘cancel’, ‘tea’ or ‘coffee’.
• 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.
 Assignment
• Design a coin operated public telephone unit
based on FSM model
• Page no. 210 & 211
 Sequential Program Model

• Executed in sequence
• It is same as conventional procedural programming
• The program instructions iterated and executed
conditionally and the data gets transformed
through a series of operations.
• FSMs and flow charts are good for sequential
program modelling.
The execution of functions in a sequential program
model for ‘seat belt warning’ system is illustrated
#define ON 1
below
#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();
}
}
}
 Concurrent/Communicating Process Model
• Models concurrently executing tasks/processes
• It easier to implement certain requirements in concurrent processing model
than the conventional sequential execution.
• Sequential leads to a single execution of task and leads poor processor
utilisation.
• If the task is split into multiple subtasks, it is possible to tackle the CPU usage
effectively.
 Seat belt warning in concurrent processing model: we can split the tasks into:
1. Timer task for waiting 10 seconds (wait timer task).
2. Task for scheduling 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).
 Object Oriented Model
• Is object based model for modelling system requirements.
• Disseminates a complex s/w requirement into simple well
defined pieces called objects.
• It brings reusability, maintainability, productivity in system
design.
• Object is an entity used for representing or modelling a
particular piece of the system.
• Each object is characterized by a set of unique behavior and
state.
• A class is an abstract description of a set of objects and it is
considered as blueprint of an object.
• A class represents the state of an object through a member
variables and object behavior through member functions.
• Member variables and member functions of class may be
private, public or protected.
• Private members and functions are accessible only within
class.
• Public variables and functions are accessible within and
outside class.
• Protected are protected by external access.
• Class derived by parent class can access protected.
• The concept of object and class bring
• Abstraction: Abstraction means displaying only essential
information and hiding the details.
• Hiding:
• A key feature of object oriented programming is
'data - hiding' i.e., the data is concealed within a
class, so that it cannot be accessed mistakenly by
functions outside the class. 'private' and 'public' are
two types of protection available within a class.
• Protection:
• Data is not accessed by the other classes. Data is
protected within the class.
 Unified Modeling Language (UML)
• Is a standardized modeling language consisting of an integrated set of
diagrams, developed to help system and software developers for
specifying, visualizing, constructing, and documenting the artifacts of
software systems.
• The main aim of UML is to define a standard way to visualize the way a
system has been designed. UML is not a programming language, it is
rather a visual language.
• As well as for business modeling and other non-software systems. 
• The UML represents a collection of best engineering practices that have
proven successful in the modeling of large and complex systems.
• The UML is a very important part of developing object oriented software
and the software development process.
• The UML uses mostly graphical notations to express the design of
software projects.
• Using the UML helps project teams communicate, explore potential
designs, and validate the architectural design of the software. 
 UML Building Blocks
• Things, relationships and diagrams are building blocks of UML.

 Things :
 Structural things: represents mostly the static (lacking in
movement, action) part of a UML model. They are also known
as classifiers.
 Behavioural things: represents mostly the dynamic
(characterized by constant change, activity, or progress) parts
of a UML model. Interaction, state machine and activity are
the behavioural things in UML.
 Grouping things: are the organisational parts of a UML model.
Package and subsystem are the grouping things in UML.
 Annotational things: are the explanatory parts of a UML
model. Note is the annotational thing in UML.
Behavioural diagram
 Hardware Software Trade-Offs
• Certain system level processing requirements may be possible to
develop in either hardware or software.
• The decision is based on the trade offs and actual system
requirement.
 Ex: Multimedia Codec (compression and decompression algorithm)
 developed either s/w or h/w chip.
 here trade off is performance and re-configurability.
 developed in h/w may be more efficient, optimised with low-
processing and power requirements.
 It is possible to develop in s/w using algorithm, but need not be
optimised for performance , speed and power efficiency.
 A codec developed in s/w is re-usable and re-configurable
 Developed in h/w is fixed and can not be modified.
 h/w s/w trade offs in embedded system
design
 Processing speed and performance
 Frequency of change
 Memory size and gate count
 Reliability
 Man hours (effort) and cost