5.

Overview of Hardware –
Software co design
Lecture By
Dr. Vikram Kulkarni
Syllabus
 Introduction
Embedded computers are the processing devices.
 Home appliances and entertainment units
 Transportation including automobiles
 Medical instrumentation
 Wireless communication devices,
 Jet engines and other aerospace/space application
 Industrial control, nuclear systems and many more

By many estimates embedded computers make up 99% of

worldwide computers
Embedded Computer Systems are the ideal candidate for
hardware-software codesign.
Page: 3
 Embedded System Design

• Separate HW and SW design has been explored and

examined very thoroughly
• Joint design remains an area of rapidly growing study
• Old embedded devices always built from scratch
– within reasonable amount of time
• Components - smaller and faster - IP cores
• Tools required for the product engineer.

Page: 4
 Embedded System Architecture Design
• Real-time System Design
 Performance analysis
 Scheduling and allocation
• Accelerated systems
• Use additional computational unit dedicated to some
functions?
 Hardwired Logic e.g., FPGA
 Multiple processing elements (PEs) or an extra CPU
• Hardware/software co-design: a joint design of
hardware and software architectures of Embedded
System.
Page: 5
 Traditional Design Practices
• Performance Requirements make it
impossible to execute entire application in
software
• Intensive portions are extracted and
realized as custom hardware
• Early Design Cycle Partitioning
 Design Space is not fully Explored
 High-Cost Design
 Inefficient

Page: 6
Traditional Embedded System Design

• HW/SW Partitioning
performed at an early
stage.
• Design mistakes have
huge negative effect
• Inability to correct
mistakes performed at
the partitioning phase

Page: 7
Traditional Design Practice
Requirements Definition

6-12 Months

Architecture Definition

Hardware Design Software Design

Interface
Design
25-49 Months

Hardware
Software Code and
Manufacture and
Test
Test

Hardware Software
Implementation and Test

Deliverables

Documentation
6-12 Months
Deployment Field Test

Page: 8
Advancements in HW- SW codesign

• VLSI Technology
 Smaller, Faster IP Cores
 Reconfigurable Logic
• Matured Hardware Design Methodology
• Matured Software Design Methodology
• Joint design – Still in Infancy but popular!

Page: 9
 Hardware-Software Co-design

• An approach utilizing the maximum efficiency

of Hardware and Software is needed
• Recent developments in CAD Tools
• Result -- Hardware Software Codesign
 A unified approach
 Large Design Space Exploration
 Improved Time to Market

Page: 10
Codesign Methodology

Page: 11
 Hardware-Software Codesign
• Functional exploration: Define a
System (Embedded)
desired product's requirements and
Functional Exploration produce a specification of the
system behavior.
Architectural Mapping • Map this specification onto various
hardware and software
Hardware-Software architectures.
Partitioning
• Partition the functions between
Hardware Software silicon and code; and map them
Implementation Implementation
directly to hardware or software
System Integration components.
• Integrate system for prototype test.
Page: 12
 HW/SW-Codesign
Co-design of (embedded) computer systems
encompassing the following parts:

• Co-Specification: Describe system functionality

at the abstract level
System description is converted into a task
graph representation
• HW-SW Partitioning: Take the task graph and
decide which components are implemented
where/how ?
i.e. Dedicated hardware,
Software -- one CPU or multiple CPUs
Page: 13
 HW/SW-Codesign
• HW-SW Co-Synthesis: Analyze the task
graph and decide on the system architecture.
(incorporates HW/SW partitioning as heart of
co- synthesis process)
• HW-SW Co-Simulation: Simulate embedded
device’s functionality before prototype
construction. Simultaneous simulation of hardware
and software.
• Co-Verification: Mathematical or simulation-
based verification that device meets
requirements.

Page: 14
 HW/SW Co-Specification
• Model the (embedded) system functionality from an
abstract level.
• Developing system specification that describes
hardware, software modules and relationship
(interface) between the hardware and software.
• No concept of hardware or software yet.
• Common environment
SystemC: based on C++.
• Specification is analyzed to generate a task graph
representation of the system functionality.

Page: 15
 Hardware-Software Co-Synthesis
Four Principal Phases of Co-synthesis:
 Partitioning
Dividing the functionality of an embedded system into units
of computation.
 Scheduling
Choosing time at which various computation units will
occur.
 Allocation
Determining the processing elements (PEs) on which
computations will occur.
 Mapping
Choosing particular component types for the allocated units
(of computations).
Page: 16
 HW/SW Co-Synthesis
 Automatic and semi-automatic design of hardware and
software modules to meet the specification.
 Automatically derive the system architecture.
 Tightly coupled with HW/SW Partitioning along with:
• Allocation: select the number and type of communication links
and processing elements for the target system.
• Assignment (Mapping): Mapping tasks to processing elements.
• Scheduling: Timing of task execution and
communications.

Page: 17
Common Co-Synthesis Structure

Page: 18
 System Partitioning
Introduces a design methodology that uses several
techniques:
 Partition the system specification into processes/tasks
The best way to partition a specification depends on the
characteristics of the underlying hardware platform

 Determine the performance of the function when

executed on the hardware platform
We usually rely on approximating

 Allocate processes onto various processing elements

Page: 19
 HW/SW Partitioning
• An area of significant research

• Analyzes task graph to determine each

task’s placement (HW or SW)

• Many algorithms have been developed.

• Major problem involves the computation

time of partitioning algorithm

Page: 20
 Hardware-Software Partitioning
For embedded systems, such partitioning represents a
physical partition of the system functionality into:
 Hardware
 Software executing on one or more CPUs
Various formation of the Partitioning Problem that
are based on:
 Architectural Assumptions
 Partitioning Goals
 Solution Strategies
COWARE: A design environment for application specific
architectures targets telecom applications

Page: 21
 Partitioning Techniques
Hardware-Software Homogeneous System Model =>
Task Graph
For each node of the task graph, determine implementation
choices (HW or SW):
 Keep the scheduling of nodes at the same time
 Meet real-time constraints
• There is intimate relationship between partitioning and
scheduling.
• Wide variation in timing properties of the hardware and
software implementation of a task.
That effects the overall latency significantly

Page: 22
What is an Embedded System ?
• Levels of Abstraction in Electronic System Design
• Typical Design Flow of Hardware-Software Systems
1. Choice of Right Platform
• Processor Less System
System Platform
PLC (Programmable logic unit) instead of Processor
System Platform Microprocessor or Microcontroller or DSP based system

• Processor Based System

System Platform
• IP or FPGA Based System
2. Software-Hardware Tradeoff
• Certain subsystems in hardware (microcontroller), real-time clock,
system clock, pulse width modulation, timer and serial
communication can also be implementable by software.
• Hardware implementations though increase the operation speed but
may increase power requirements.
• A serial communication, real-time clock and timers featuring
microcontroller may cost more than the microprocessor with external
memory and a software implementation
• Simple coding for device drivers
Software implementation advantages
(i) Easier to change when new hardware versions become available
(ii) Programmability for complex operations
(iii) Faster development time
(iv) Modularity and portability
(v) Use of standard software engineering, modeling and RTOS tools.
(vi) Faster speed of operation of complex functions with high-speed
microprocessors.
(vii) Less cost for simple systems
Performance Accelerators - Software
perspective
• Conversion of (Control Data Flow Graphs)CDFGs into DFGs for
example by using loop flattening (loops are converted to straight
program flows) and using look-up tables instead of control condition
tests to decide a program flow path.
• Reusing the used arrays in memory, appropriate variable selection,
appropriate memory allocation and de-allocation strategy
• Using stacks as data structure when feasible in-place of queue and
using queue in place of list, whenever feasible.
• Computing slowest cycle first and examining the possibilities of its
speed-up.
• Code such that more words are fetched from ROM as a byte than the
multi-byte words
Hardware implementation advantages
(i) Reduced memory for the program
(ii) Reduced number of chips but at an increased cost
(iii) Internally embedded codes, more secure than at the external ROM.
Performance Accelerators - Hardware
perspective
• An accelerator may include bus interface unit, DMA, read and
write units, registers and accelerator cores.
• An accelerator uses a programming model to accelerate, unlike the
coprocessor, which has instruction sets for specific tasks.
• A processor registers interact and connect to an accelerator through
buses so that processor controls the accelerator for obtaining a higher
performance.
Performance Accelerators …

- Example - JA108 from Nazonin Communications, a Java accelerator,

which accelerates the JAVA code run by 15 to 60 times.
- Another example is a video accelerator, which accelerates
video processing tasks.
- Hardware accelerator accelerates code execution. It may be an
ASIC, IP core or FPGA.
HARDWARE SOFTWARE TRADE-OFFS
• 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 efficient, optimized 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 optimized for performance, speed and power
efficiency.
• On the other hand, a codec developed in software is re-usable and re-configurable.
• 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.
HARDWARE SOFTWARE TRADE-OFFS
• 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 (Normally
hardware chips are implemented using logic gates and the density of
the chip is expressed in terms of the number of gates used in the
design (millions of gates ☺), if the required feature is going to
implement in hardware.
HARDWARE SOFTWARE TRADE-OFFS
• 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.
• To summarize, the important hardware-software trade-offs in
embedded system design are
• (1) Processing speed and performance
• (2) Frequency of change (Re-configurability)
• (3) Memory size and gate count
• (4) Reliability
• (5) Man hours (Effort) and cost