Computational Models in Embedded Design – Data Flow Graph, Control Data Flow Graph, State Machine Model, Sequential Program Model, Concurrent Process Model, Object-Oriented Model. Hardware Software Co-Design – Traditional Embedded Development Cycle, History, Advantages of the Co-Design Methodology, The Co-Design Process, Fundamental Issues in Hardware Software Co-Design. Hardware software trade-offs.

1. 1 / 51
System Modeling and
Hardware Software Co-Design
Module 2

2. 2 / 51
Computational Models in Embedded Design
●
Data Flow Graph/Diagram (DFG) Model
– Data Flow Graph (DFG) model translates the data processing
requirements into a data flow graph.
– 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 transtorms the input data to output data.
– Indeed Data Flow Graph DEG) 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.

3. 3 / 51
– 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.
– 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.

4. 4 / 51
●
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 DFG Contains only data flow nodes.
– Let us have a look at the implementation of the CDFG for the
following requirement. lf flag = 1, x=a+ b; else y = a- b
– This requirement contains a decision making process.
– The control node is represented by a Diamond' block which is
the decision making element in a normal flow chart based
design.

5. 5 / 51
– 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

6. 6 / 51
– 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.

7. 7 / 51
●
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.
●
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.
●
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.
– States are ‘Alarm Off’, ‘Waiting’ and ‘Alarm On’ and
– Events are ‘Ignition Key ON’,‘Ignition Key OFF’, ‘Timer
Expire’, ‘Alarm Time Expire’ and ‘Seat Belt ON’.

8. 8 / 51
– Using the FSM, the system requirements can be modeled as
– 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.

9. 9 / 51
– 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
– 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.

10. 10 / 51
– 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.

11. 11 / 51
●
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’ to cancel the order and take back the
coin.

12. 12 / 51
●
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 45 th
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.

13. 13 / 51
●
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 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.

14. 14 / 51

15. 15 / 51

16. 16 / 51
●
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 specifi ed 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.

17. 17 / 51
– We can 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)
– 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.

18. 18 / 51
– 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.

19. 19 / 51
– 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 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.
– 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.

20. 20 / 51
– 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.

21. 21 / 51

22. 22 / 51
●
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 defi ned 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 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.

23. 23 / 51
– 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.

24. 24 / 51
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.

25. 25 / 51
●
Selecting the Architecture
– A model only captures the system characteristics and does
not provide information on ‘how the system can be
manufactured?’.
– The architecture specifi es 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.).

26. 26 / 51
●
The Controller Architecture
– implements the finite state machine model using a state
register and two combinational circuits.
– The state register holds the present state and the
combinational circuits implement the logic for next state and
output.
●
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.

27. 27 / 51
●
The Finite State Machine Datapath ( FSMD)
– architecture combines the controller architecture with
datapath architecture. It implements a controller with
datapath.
– The controller generates the control input whereas the
datapath processes the data.
– The datapath contains two types of I/O ports,
●
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.
●
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.

28. 28 / 51
●
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 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
fi le for storing the operands and output.
– RISC instruction set is designed to operate on registers. RISC
architecture supports extensive pipelining.

29. 29 / 51
●
Parallel processing architecture
– implements multiple concurrent Processing Elements (PEs)
and each processing element may associate a datapath
containing register and local memory.
– 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.
– 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.

30. 30 / 51
– 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. 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.

31. 31 / 51
●
Partitioning System Requirements into hardware and software
– So far we discussed about the models for capturing the
system requirements and the architecture for implementing
the system.
– 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.

32. 32 / 51
Hardware Software Trade-off
●
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 effi cient,
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.

33. 33 / 51
●
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, 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.

34. 34 / 51
●
To summarise, the important hardware-software trade-offs in
embedded system design are
– (1) Processing speed and performance
– (2) Frequency of change (Re-confi gurability)
– (3) Memory size and gate count
– (4) Reliability
– (5) Man hours (Effort) and cost

35. 35 / 51
HARDWARE–SOFTWARE CO-DESIGN
●
Traditional design approach has followed the classical models.
●
Such models has been the philosophy in which we design the
hardware components,then design the software components,
and then bring the two together.
●
Often, the hardware components significantly lagged the
software components and yet the software had to fit the
hardware and correct any errors in the hardware design that
may be discovered late in development and test process.
●
The hockey stick curve makes another appearance.
●
Today’s designs are continually increasing in complexity,
decreasing in size, operating at higher frequencies, and utilizing
a growing breadth of exciting new technologies.
●
Integrated circuit mask costs are in the millions of dollars; the
cost of an error in time and dollars can be significant.
●
Spending time testing and debugging later in the development
cycle where cost of change is higher (hockey stick curve again)
can add to the problem.

36. 36 / 51
●
The problem is only partially mitigated with the introduction of
programmable logic devices (PLDs).
●
Today, the evolving world of design is demanding tools and
support that can match the challenges of new and advanced
product features that can meet customer expectations.
●
Traditional Embedded Systems Development
– most embedded systems share a common structure and
common development cycle.
– Through such a cycle, the embedded design is developed.
– Specifically, the hardware design involves the design of the
components, the printed circuit boards (which are becoming
an increasing challenge), and the system.
– The software design may entail the design of the high-level
assembly language and machine code.
– Work at the assembly language level requires detailed
knowledge of the microprocessor architecture and its
register structure.
– The hardware or software constituents may also include
legacy components.

37. 37 / 51

38. 38 / 51
– Immediately following formulation of the high-level
architecture, the contemporary approach has been to break
the system into hardware and software components.
– Each component would be developed separately, often by
separate teams.
– Generally, hardware development lagged behind the
software development. Lead times on parts and the
fabrication of custom circuitry slowed the process but had to
be finished first, before software was introduced and
integrated.
– Such an approach limits hardware–software trade-offs.
– Interactions between them are determined or discovered
later in development.
– Late integration led to the philosophy of “let the software fix
the hardware problems … we can send out updates later,”
potentially poor quality designs, last second modifications,
slipped schedules, costly design changes, the need for
routine updates to correct problems over the product’s
lifetime, and possibly canceled projects.

39. 39 / 51
– The development cycle illustrated in Figure reflects the
potential for a high degree of concurrent hardware and
software development following the specification of the
system architecture.
– Such concurrency demands greater cooperation between all
designers.
– Shorter times to market mitigate against an extended trial
and error approach, although such an approach actually
worked quite successfully during the Soviet space program.
– The traditional development cycle puts an increased
demand that errors be identified and corrected early, that
requirements be very well established and understood prior
to the start of the design, and that a predictable schedule is
essential.
– Under such constraints, the increased reuse of legacy
components could help to reduce the design and
development time.
– Such observations naturally lead to a Co-Design approach.

40. 40 / 51
●
History
– Early computers were known as complex instruction set
computers; the CISC architecture.
– Work at IBM plus other places led to simpler architectures
and a significant reduction in the numbers and complexity of
instructions.
– These machines became known as reduced instruction set
computers or the RISC architecture.
– Such a change simplified the design of both the hardware
and software, thereby increasing the speed of computation
and simplifying and improving performance and flow of
control through the machine.
– In particular, the flow associated with context switching.
– Today’s ARM (Advanced RISC Machine) processor evolved
from this early work.
– Simultaneously, work continued on compilers for such
machines. Developed “independently” or serially, such a
process led to two designs – hardware followed some time
later by the software, neither of which was optimal.

41. 41 / 51
– The thought occurred that if the development and
optimizations of the two components could be executed
simultaneously it would be possible to improve both.
– The fundamental concepts behind Co-Design that have been
around for approximately 30–40 years started to gain
traction around 20–25 years ago with the first international
workshop.
– The approach evolved from thoughts and research in several
areas.
– On the hardware side, the recognition that microprocessor-
based systems were becoming a growing and increasingly
important area for traditional IC and system designers.
– On the software side, the development and growth of
software engineering and the recognition that software was
becoming an integrated and essential component in future
chip and system designs.
– The development of both the hardware and the software
were supported by work in synthesizing designs from
behavioral models.

42. 42 / 51
– Models, and modeling, have grown to become a significant
and integral component of the Co-Design process.
– The early objectives of the Co-Design methodology were to
gain control of the design of the hardware- and software-
based systems and to ensure greater predictability in
meeting initial goals and requirements.
– Supporting such objectives was the desire to give designers
tools to assess and verify that the delivered system met the
specified speed, power, cost, reliability, performance, and
complexity goals while enabling them to explore and
evaluate alternative designs at the detailed level without
having the cost of a full implementation.
– Essential to the Co-Design methodology was the use of
computer-based tools and models. – the Unified Modeling
Language (UML) and the Structure Analysis and Design
methodology have become very good tools contributing to
and supporting that process.

43. 43 / 51
●
Advantages of the Co-Design Methodology
– The Co-Design methodology permits both the hardware and the
software to influence the design during early stages of
development and supports a continual verification of the design
and design alternatives throughout the development cycle.
– Co-Design supports and encourages models and the
interoperability of hardware and software design tools
throughout process, particularly during architecture definition.
– It enables greater exploration of design trade-offs and more
interesting architectures.
– Reuse is an integral part of the process, specifically of
components whose behaviors have been previously verified
and co-verified as part of an existing design.
– Such reuse enables one to reduce integration and test times,
leading to quicker time to market, and to approach the
boundary of one pass silicon.
– We may be moving a design flaw in an original design where it
was not a problem forward to where it may become one.
– The European Space Agency’s Arianne 5 rocket is one such
example.

44. 44 / 51
●
Co-Design Process Overview
– The hardware/software Co-Design approach to embedded
systems design suggests tools and approaches /
methodologies that integrate the design and development of
both the hardware and the software components.
– Co-Design focuses on the following major areas of the
embedded development cycle:
●
Ensuring a sound hardware and software specification as
input to the process.
●
Decomposing the system into functional modules.
●
(Iteratively) partitioning and mapping the functional
modules onto the hardware and software.
●
Based upon the hardware–software partition, formulating
the architecture for the system to be designed.
●
An iterative process of hardware–software synthesis,
simulation, and verification.
– Following the six steps to successful design, the Co-Design
process comprises a number of subprocesses.

45. 45 / 51
– The UML echoes many of these same ideas. Included among
these are:
●
System Specifications – Requirements and Design
– Develop and validate the specification for both sets of
components.
– This is an essential and core aspect of the approach.
●
Functional Decomposition
– Partition the system into major functional blocks.
●
Partitioning – Co-Design
– Partition and map the functional blocks onto hardware
and software components; define and refine the inter
process communication.
●
Modeling – Architecture
– Develop a system architecture from the hardware and
software models that takes into consideration both
aspects and works to model the complete system then
validate those models.
– Synthesize hardware–software interfaces.

46. 46 / 51
●
Co-Synthesis – Prototype
– Synthesize both the hardware and software
components from higher-level models.
– Software synthesis will target specific tasks to
designated hardware components and hardware
synthesis will decompose computation steps into clock
cycles then bring two pieces together under co-
simulation.
●
Co-Simulation – Prototype
– Simulate the architecture using the modeled hardware
running real software.
– Later we migrate toward real hardware.
– The goal is to keep both simulations – hardware and
software – synchronized to ensure proper performance
in the ultimate target platform.
●
Co-Verification – Test
– Verify that the architecture meets the specification.
●
Repeat the Process
– Explore alternate partitions as necessary or
appropriate.

47. 47 / 51
●
The Co-Design Process
– The focus of the methodology is on the design and synthesis
aspects. Its domain is indicated in the boxed portion.
– Examining the Co-Design methodology a little closer, we can
list the essential concepts that underlie and guide the
process:
– Ideals
●
Transparent methods of modeling hardware and software.
●
Transparent design and analysis techniques.
●
Interoperability of tools and methods.
●
Seamless migration of pieces of functionality between
hardware and software.
●
An iterative design approach.
●
The ability to quickly evaluate a number of different
hardware–software partitions and trade-offs.
●
The ability to evaluate system performance in a unified
design environment.
●
The ability to incrementally segue real hardware and
software into models and simulations.

48. 48 / 51

49. 49 / 51
●
The ability to seamlessly move from high level models
into real hardware and software.
●
The ability to work at multiple levels of abstraction.
– As we study and practice the design and development of any
serious large-scale systems, we must consider both the
system to be designed and the environment in which it must
operate.
– We will refine the model as our discussion evolves and we
iteratively develop ideas.

50. 50 / 51
– As our design progresses, we decompose the top-level
system block into modules and subsystems.
– Some of those modules will be hardware, some software, and
some in a middle area that may be combinations of both.
– Components that must or should be either hardware or
software are generally clear.
– We can say: this part must be hardware or this part must be
software.
– For example, the power supply, display, communications port
are necessarily hardware.
– We can agree that the operating system and associated
communications drivers are necessarily software.

51. 51 / 51
– Co-Design emphasizes models – working from the abstract to
the concrete.
– It is inherently a top-down process that flows as illustrated in
high-level blocks in Figure.
– Recall that the major elements of the Co-Design process
include: specification, functional decomposition, partitioning,
Co-design, modeling, architecture, co-synthesis, co-simulation,
and co-verification.
– In our discussions, we will go through each process step and
examine the critical points.