Hardware Software

Co-Design and Program

Modelling

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. 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 p~oduct c'aus for a novel
~pproach for embedded system design in which the har~ware and software are co-developed instead of
1r.dependently developing both. •1 •• • •. •

During the co-design process, the product requirements captured from the customer are converted into
sys~m 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. The system level

I I •
 ¾ J•
ZC.atJ :_ .....

~21~0---------~~~
lntroductton to Embedded Systems
~~::::.:=-=-~.:.:.
:_------------ ---
processi.ng requirem
. , I
ents are then transferred into func
,
. tion s which can be simulated and veri fied
performance and functionality. The Archite aga·Inst
cture design follows the syste~ desi.gn. ~e ..
1eve1processi.ng requi•rements into hardware and software takes place during the arch partition of systein
Each system level processing requirement . itecture design Phas
is mapped as either hardware a~d/o~ soft . . e.
. . • •
partitiomng 1s per1&orm ed based on the hardware-software trade-offs. war e req~tren ient. The
1

software tradeoffs in hardware software co-d • •

We will discuss the vanous hardw
•
esign 1n a ~eparate topic. The ~~h1tectura • • are
the detailed behavioural description of the l design results in
hardware requirement and the definitt~n
for the hardware. The processing requirem of the software required
ent behaviour is usually captured using
and ultimately the models representing the computational models
software processing requirements are tran
implementation using programming languag slated into firmware
es.
•
7.1 FUNDAMENTAL ISSUES IN HARD
WARE SOFTWARE CO-DESIGN
The hardware software co-design is a prob
lem statement and when we try to ·, LO
solve this problem stat~ment i~ re~l life 'i''kn~w; th' ' I t :
we may come across multiple ~ssues !~-
the design. The following_ section illustrat ..- ,.•deSigii
es some of the fundamental 1ssu.es tn ·.::'.
~,PPioa:h~:~
hardware software co-design. eiiihedde~ hard~~re-
•,. ' ., · . . ,, -· , ,
Selecting the model In hardware soft , ~~ ~w ~re ; ..
ware co-design, models are used for • ,·/4, •.

capturing and describing the system charact dev~lopment,; / ·-·~,

eristics. A model is a formal system
consisting of objects and composition rule
s. It is hard to make a decision on which mod
in a particular system design. ~1ost often desi el should be followed
gners switch between a variety of models
specification to the implementation aspect from the requirements
of the system design. The reason being, the
each phase; for example at the specification objective varies with
stage, only the functionality of the system
implementation information. When the desi is in focus and not the
gn moves to the implementation aspect, the
system components is revealed and the desi info rmation about the
gner has to switch to a model capable of
structure. We will discuss about the differen capturing the system's
t models in a later section of this chapter.
Selecting the Architecture A model
only captures the system characteris~ics
information on 'how the system can be man and does not provide
ufactured?'. The architecture specifies how
to implement in terms of the number and a system is going
types of different components and the inte
them. Controller Architecture, Datapath Arc rconnection among
hitecture, Complex Instruction Set Computi
Instruction Set Computing (RISC), Very ng (CISC), Reduced
Long Instruction Word Computing (VL
Multiple Data (SIMD), Multiple Instruction IW), Single Instruction
Multiple Data (MIMD), etc. are the common
in system design. Some of them fall into App ly used architectures
lication Specific Architecture Class (like Con
while others fall into either general purpos trol ler Architecture),
e architecture class (CISC, RISC, etc.) or
(like VLIW, SIMD, MIMD, etc.). Parallel processing class
The Controller Architecture implements
the finite state machine model (which we
section) using a state register and two com will discuss in a later
binational circuits (we will discuss about
a later chapter). The state register holds the combinational circuits in
present state and the combinational circuits
for next state and output. implement the logic
•
The Datapath Architecture is best suited
for implementing the data flow graph mod
is generated as a result of a set of pre~efin el· where the output
ed ~omputations on the input data. A data
between the input and output and in datapath path repr esents a cha~nel
architecture the datapath may contain regi
files, memories and ports along with high sters, counters, reg1ster
speed arithmetic units. Ports connect the data
Most of the time the arithmetic units are path to multiple bu~es.
performance. connected in parallel with pipelining sup
port for bringing high
V
Hardware Software c O .
----------~2~11
.,--------- -------=.:: ~:::_~o-~ es~,g~n~ a~nd~P~ r~og~r~a m~M~o~ de:!!_ll!!! _in~g

he Finite State Machine Datapath (FSMD) .

T th architecture. It implements a contr 11 .architecture combines the controller architecture with
datapa the datapath processes. the data Tho der with datapa~h. The controller generates the control input
whereas • e atapath . contains t f I/ f h' h
s the control port for receiving/sendin th wo types o O ports, ~ut o w ic one
second
acts a rt interfaces the datapath with externaf e tontrol s1g~als from/to the controller umt and the
mput and data output. Normall y the datapath is
VO Po t din a chip and the 1/0 . Of h wor_d for data ports for the chip resident
itnplemen e pins t e chip acts as the data input output
data path. .
The Comple.x Instruc .
tion .Set Computing (CISC) arch'itecture uses an instruction set representing
CISC instruet·ion set to perform a large complex operation (e.g. .
comple
x operatio
. . a.
ns. It is possible for
• n to a new
value and compan ng it with a gi·ven va1ue and then transfer the program executio
Read1·ng a register
. . .
complex
address location (The CJN~ ins~cti on for 8051 ISA)) with a single instruction. The use of a single
program
instrUctio~ in plac~ of multiple simpl~ instructions greatly reduces the program memory access and
for
memory size requir.ement. _However it requires additional silicon for implementing microcode decoder
Reduced
decoding the CISC 1nst~ct1on. The datapath for the CISC processor is complex. On the other hand,
ns and it
1nstn1ction Set Co~putlng (~ISC) architecture uses instruction set representing simple operatio
path of RISC
requires the execution of multiple RISC instructions to perform a complex operation. The data
is designed
architecture contains a large register file for storing the operands and output. RISC instruction set
.
to operate ~n registers. RIS<;: arcqitecture supports extensive pipelining.
(ALUs,
The Very Long lnstr~ction Word (VLIW) architecture implements multiple functional units
al unit
multipliers, etc.) in the datapath. The VLIW instruction packages one standard instruction per function
of the datapath.
each
Parallel processing architecture implements multiple concurrent Processing Elements (PEs) and
Instruction
processing element may associate a datapath containing register and local memory. Single
s for parallel
Multiple Data (SIMD) and Multiple Instruction Multiple Data (MIMD) architectures are example
help of the
processing architecture. In SIMD architecture, a single instruction is executed in parallel with the
performed
Processing Elements. The scheduling of the instruction execution and controlling of each PE is
r (We will
through a single controller. The SIMD archit~ctur¢ forms -the basis of re-configurable processo
s of the
discuss about re-configurable processors in a.later chapter). On the other hand, the processing element
forms the
MIMD architecture execute different instructions at a given point of time. The MIMD architecture
sms like
basis of multiprocessor systems. The PEs in a multiprocessor system communicates through mechani
shared memory and message passing.
it into
Selecting the language A programming language captures a 'Computational Model' and maps
this model..
architecture. There is no hard and fast rule to specify this language should be ·used for capturing
software
A model can be captured using multiple programming languages like C, C_++, C#, Java, etc. for
. On the
implementations and languages like VHDL, System C, Verilog, etc. for hardware implementations
es are good
other hand, a single language can be used for capturing a variety of models. Certain languag
g an object
in capturing certain computational model. For example, C++ is a good candidate for capturin
is that the
oriented model. The only pre-:-requisite in selecting a programming language for capturing a model
language should capture the model easily.
about the
Partitioning System Requirements into hardware and software So far we discussed
From an
?1odels for capturing the system requirements and the architecture for implem~nting th~ sy~tem.
hardware
implementation perspective, it may be possible to implement the system requirements 1n either
hardware
or software (firmware). It is a tough decision making task to figure out which one to opt. Various
will discuss
software trade-offs are used for making a decision on the hardware-software partitioning. We
them in detail in a later section of this chapter.
 212 Introduction to Embedded Systems

7.2 COMPUTATIONAL MODELS IN EM

BEDDED DESIGN
Daat Flow Graph (DFG) model, State Machine model, Concurrent
ObJ•~ct o·
Process model, Sequential Program model,
etc. are the commonly used computational nented modie,
models in embedded system
design. The following sections give an overvie
w of these models.
7 .2.1 Data Flow Graph/Dlagrani (DF
G) Model
The Data Flow Graph (DFG) m~del transl~t
es the dat~ pro~essing requirements i~to a
Data Flow Graph (DFG) model 1s a data driven data flow graph. •
model m which the program execution is dete
This model emphasises on the da~a an~ operatio rmined b lie
ns _on th~ data which ~ansforms the input data
Indeed Data Flow Graph (DFG) is a visual mod to outp:i d::·
. el in which the operation on the data (process
using a block (circle) and data fl ow is
•
represented usin •g An • d
) is repre •
represents input data and an outward arrow arro.ws. inwar arro w to the proc ess sente d
(circle)
from the process (crrcle) represents output
Embedded applications which are computa data in DFG notati
tional intensive and data driven are modeled
model. DSP applications are typical exam using the D;~
ples for it. a b
Now let's have a look at the implementation
of a DFG. /
Suppose one ~f the fun:tions in our application c
contains
~e computa~ional requirem~nt x =a + b.; and
Figure 7.1 illustrates the implementa y = x - c. Data flow node ,,,~\-
tion of a DFG
model for implementing these requireme~ts ,,;,.>:<?;

.
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 Data flow node
for a given
set of input(s). Feedback inputs (Output
is fed back
to Input), events, etc. are examples for
non-acyclic ·.y
inputs. A DFG model translates the program
as a single Fig. 7.1 Data flow graph (OFG) model
• sequential process execution.

7 .2.2 Control Data Flow Graph/

Diagram (CDFG)
We have seen that the DFG model is• a data
driven model in
which the execu.tion is controlled by data and it
doesn't involve Control node
any control operations (conditionals). The
Control DFG
(CDFG) model is used for modelling applica
tions involving
conditional program execution. CDFG mod
els contains
both data operations and control operatio
ns. The CDFG
uses Data Flow Graph (DFG) as element
and conditional
(constructs) as decision makers. CDFG con Data flow node
tains both data
flow nodes and decision nodes, whereas DFG
contains only
data flow nodes. Let us have a look at the imp
lementation of
, the CDFG for the following requirement.
If flag =1, x =a + b; else y =a - b;
This requirement contains a decision mak
ing process.·
The CDFG model for the same is given in Fig.
7.2.
Fig. 7.2 Contr.ol Data Flow Graph (COFG) Model
 213
Software
ware~~ ~~ ':! esign !..
Co-D!!! !.~ram
and Prog Mod
!!! !!! __ _ _ _ _ _ _~
elling
--- --- --- --- --~ .:. Hard
=. :..
..
element in a normal
mond' block which is the decision making
fhe control node _is represented _by a 'Dia ch is modeled to a concurrent process mod
el.
CD FG_ tran slat es the req~ irem ent, whi
floW ch~ based de~ign.
cuted is determined by the control node.
'fhe decision on which process is to ?e exe tion using CDFG is the capturing and sav
ing
le for mo delling the emb edd ed app lica
A real world examp en starting from
to a form at s~t by the use r in a digi tal still camera where everything is data driv
of the ima ge
ch con vert s the CC D sen sor gen erated analog signal to Digital Signal and the task
the Analog Front End whi orms various
data from ~C to a fram e buf fer for the use of a media processor which perf
hich stores the
on, whi te bala nc~ adju stin g, etc. The decfaion on, in which format the image is
:perations like, ~uto correcll by the user.
s like JPE G, TIF F, BM P, etc. ) is con trolled by the camera settings, configured
stored (format
achine Model
7.2.s State M reac tive or eve nt-driven embedded systems whose processing
~s use d for mo dell ing
The State Machine model l applications
dep end ent on stat e tran sitio ns. Em bed ded systems used in the control and industria
behaviour are system behaviour with
exa mpl es for eve nt driv en syst ems . The State Machine model describe~ the is an
are typi cal
State is a repr esentation of a current situation. An event
'Ac tion s' and 'Tra nsit ion s'.
'States', 'Events', nt from one state to
the state. The eve nt acts as stim uli for state transition. Transition is the moveme
input to
ed by the state machine.
another. Action is an activity to be perfonn In other words the •
te Stat e Ma chin e (FS M) mod el is one in which the number of states are finite. of an
A Fini
g a finite num ber of pos sibl e states. As an example let us consider the design
system is described usin FSM model. The
d sys~ em for driv er/p asse nge r 'Sea t Belt Warning' in an automotive using the
embedde
system requirements are captured as. nds of ignition
the veh icle ign ition is turn ed on and the seat belt is not fastened within 10 seco
1. When
for 5 seconds.
ON, the system generates an alarm signal r fastens the
rm is turn ed off whe n the alar m time (5 seconds) expires or if the driver/passenge
2. The Ala
whichever happens first.
belt or if the ignition switch is turned off, ition Key. ON',
states are 'Ala rm Off , 'Wa itin g' and 'Alarm On' and the events are 'Ign
Here the ng the FSM, the system
rm Time Expire' and 'Seat Belt ON'. Usi
'Ignition Key OFF', 'Timer Expire', 'Ala
Fig. 7.3.
requirements can be modeled as given in

c s-eat belt warn ing system

Flg. 7.3 FSM Madel far Automati
a 'Seat
ON ' event triggers the 10 seco nd timer and transitions the stat~ ~o '~aiti~g'. If
The 'Ignition Key ns into Alarm Off'.
ON ' or 'Ignition Key OF F' event occ urs during the wait state, the state transitio
Belt
 ' ·- .

214 Introduction to Embedded Systems

When the wait timer expires in the waiting state,

the event 'Timer Expire' is generated and it tran
the state to ,Alaml On, from the 'Wa1•tmg • ' stat~. Th ..
, e 'Alarm_ On' state con1·inues untt·1 a ,Seat Belt sitions
'Ignition Key OFF' event or 'Alarm Time Expire ON'
event, whichever occurs first. The occurrence of 0
these events transitions the state to 'Alarm Off' . Th r
e wait• state is
• 1mp
• 1
emente d using
•
a •
time r. The tim any of
has certain set of states and events for state trans1t1on
• • s. U_sing
• the FSM d 1 h •
mo e , t e timer can be modeerledalso
as
shown in Fig. 7.4.
•
,~ "°, I
,r.1,./,:

Event: Load Timer

IDLE
Action: Timer Count = New Count ;.,.,. ',
i~Y::; ~~- 1/:;:. ,
;
·.{

Fig. 7.4 FSM Model for timer

As seen from the FSM, the timer state can be eithe
r 'IDLE' or 'READY~ or 'R ~G '. During the
normal condition---w~en the timer is not running, it
is said to be in the 'IDLE' state. The timer is said
in the 'READY' state when the timer is loaded with to be
the count corresponding to the required time delay
The timer remains in the 'READY' state until a 'Star .
t Timer' event occurs. The timer changes its state
'RUNNING' from the 'READY' state on receiving to
a 'Start Timer' event and remains in the 'RUNNING
state until the timer c~unt expires or a 'Stop Ti~e '
r' ev~n occurs. The timer state changes to 'IDLE'
'RUNNING' on receiving a 'Stop Timer' or 'Time~ from
Expire' event. .
Example 1 -·-· . . · _-:
Design an automatic tea/coffee vending machine base
d 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 canc
el the order and take back the coin.
The FSM representation for the above requirement
is given in Fig. 7.5. .
In its simplest representation, it contains four states nam
ely; 'Wait for coin' 'Wait for User Input', 'Dispense
Tea' and 'Dispense Coffee'. The event 'Insert Coin
' (5 rupee coin insertion), transitions the state to 'Wai
User Input'. The system stays in this state until a user t for
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' butto
press, the coin is pushed out and the state transition ~
s 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 'Disp~nse Tea' and 'Dis~ens~
Coffee' respectively. Once the coffee/tea vending is
over, the respective states transitions back t~ the W,~t
for Coin' state. A few modifications like adding a time
out for the 'Wait State' (Currently the 'Wait State 18
infinite; it can be re-designed to a timeout based 'Wai
t State'. If no user input is received within the timeo
period, the coin is returned back and the state auto ut
mati~ally transitions to 'Wait for Coin' on the time~
event) and capturing another events like, 'Water not ut
available', 'Tea/Coffee Mix not available' and chang
the state to an 'Error State' can be added to enhance ing •
I
I
this design. It is left to the readers as exercise.

\ ◄
 215
Hardware Software Co-Design and Program Mode/1/ng

Event: Insert Coin State A: Wait for coin

Action: ok State B: Wait for user input
Event: Cancel Butto State C: Dispense tea
~"'c'1}11,,
Action: Coin Out • '· C State D: Dispense coffee
. o~c

C1011,
• 0 ne

Fig. 7.5 FSM Model for Automatic Tea\Coffee Vending Machine

Example 2
l for the following requirements.
Design a coin operated public telephone unit based on FSM mode
ok) of the telephone unit
1. The calling process is initiated by lifting the receiver (off-ho
to make the call.
2. After lifting the phone the user needs to insert a 1 rupee coin
er back on the hook (on-hook)
3. If the line is busy, the coin is returned on placing the receiv th
If the line is through, the user is allowed to talk till 60 secon ds and at the end of 45 second, prompt for
4.
inserting another 1 rupee coin for continuing the call is initiated
nated on completing the 60 seconds time
5. If the user doesn't insert another 1 rupee coin, the call is termi
slot.
er fa placed back on the hook (on-hook)
6. The system is ready to accept new call request when the receiv
line fault.
7. The system goes to the 'Out of Order' state when there is a
and it doesn't take care of scenarios like,
The FSM model shown in Fig. 7.6, is a simple representation
receiver, user inserts coins other than a one
user doesn't insert a coin within the specified time after lifting the
ise.
rupee etc. Handling these scenarios is left to the readers as exerc
reme nts into sequence driven program and it
Most of the time state machine model translates the requi
limitation is addressed by the Hierarchical/
is difficult to implement concurrent processing with FSM. This
M is an extension of the FSM for supporting
Concurrent Finite State Machine model (HCFSM). The HCFS
diagrams by the AND, OR decomposition
concurrency and hierarchy. HCFSM extends the conventional state
mechanism for communicating between
of States together with inter level transitions and a broadcast
the states, transitions, events and actions.
concurrent processes. HCFSM uses statecharts for capturing
for popular statecharts used for the HCFSM
The Harel Statechart, UML State diagram, etc. are examples
ly represented using geometric shapes like
modelling of embedded systems. In statecharts, the state is usual
hart uses a rounded rectangle for representing
rounded rectangle, rectangle, ellipse, circle, etc. The Harel Statec
they are marked with the event associated
s~te. Arrows are used for representing the state transition and
condition is also labelled with the arrow. The
With the state transition. Sometimes an optional parenthesised
the occurrence of the specified event. Lots of
~on~tion specifies on what basis the state transition happens at
system modelling. The IAR visualSTATE
esign tools are available for state machine and statechart based
216 Introduction to Embedded Systems

(https://www .iar.com/iar-embedded-workbench/add-ons-and-integrations/visualstate/) from IAR s t

a popular visual modelling tool for embedded applications. YS ems is

State A: Ready State E: Call in progress

State B: Wait for coin State F: Call terminated
State C: Wait for number State G: Unable to make call
State D: Dialling State H: Invalid number input
State I: Out of order
El'e11t• C .
• o111 L
A.ct· llsen
. 1011: 01(_

.
.
~
.
..:,~

.'!ti} .
. te;
}t\~:~ . .
.
·c{/'

. .

.
.
..
.

fig. 7.6 FSM Modal for Coln Operated Talaphona System