1. Embedded Real-Time Systems
ES characteristics, design challenges and approaches
Lecturer
Department
University

2. Outline ES characteristics and design challenges
Hardware/software codesign
Rapid prototyping tools

3. Some common characteristics of embedded systems
Single-functioned
Executes a single program repeatedly
Constrained
Cost, power, physical dimensions, processing speed, etc.
Reactive and real-time
Continually reacts to changes in the system’s environment
Must deliver results in real-time (i.e. by certain timing deadlines)

4. An embedded system example: a digital camera
Single-functioned -- always a digital camera
Constrained -- Low cost, low power, small, fast
Reactive and real-time -- metering, shutter control, video compression

5. Design challenge – optimising design metrics
Design goal:
Implement a system with desired functionality (functional requirements)
Key design challenge:
Simultaneously optimise various design metrics (non-functional requirements)
Design metric
A measurable feature of a system’s implementation
Usually captures non-functional aspects of the system (how well it works as opposed to what it does)

6. Design challenge – optimising design metrics
Common metrics
Unit cost: the cost of manufacturing each copy of the system, excluding NRE cost
NRE cost (Non-Recurring Engineering cost): The one-time cost of designing the system
Size: the physical space required by the system
Performance: the execution time or processing throughput of the system
Power: the amount of power consumed by the system
Flexibility: the ability to change the functionality of the system (How easy is it? Does it incur heavy NRE costs?)

7. Design challenge – optimising design metrics
Common metrics (continued)
Time-to-prototype: the time needed to build the first working version of the system
Time-to-market: the time required to develop a system to the point where it can be serially produced for mass market
Maintainability: the ability to modify the system after its initial release
Correctness, safety: the reliability of the system

8. Design metric competition
Rarely can improve everything simultaneously
E.g. reducing power consumption may hurt performance, reducing size may increase NRE, etc.
Power
Design
NRE
Size
Performance

9. Embedded vs “desktop” systems
Expertise with both software and hardware is needed to optimise design metrics
Not just a hardware or software expert, as is common
A designer must be comfortable with various technologies in order to choose the best for a given application and constraints
Hardware
Software

10. Hardware/software co-design
Many trade-offs and decisions:
software
(or firmware)
Choice of technology:
custom VLSI
semi-custom ASIC
programmable logic
Choice of technology:
specialised
general-purpose
ICs for
performing
specific
functions
general-purpose
or specialised
processor
distribution of functionality

11. General-purpose processors
Programmable device used in a variety of applications
Also known as “microprocessor”
Features
Program memory
General data path with large register file and general ALU
User benefits
Low time-to-market and NRE costs
High flexibility
Example: “Pentium” the most well-known, but there are many others

12. Single-purpose processors
Digital circuit designed to execute exactly one program
Examples: coprocessor, accelerator or peripheral controller
Features
Contains only the components needed to execute the program
No need for program memory (all done in hardware)
Benefits
Fast
Low power
Small size

13. Application-specific processors
Programmable processor optimized for a particular class of applications having common characteristics
Compromise between general-purpose and single-purpose processors
Features
Program memory
Optimized data path
Special functional units (specialised ALU)
Benefits
Some flexibility, good performance, size and power

14. Full-custom/VLSI
All layers are optimized for an embedded system’s particular digital implementation
Transistors placing
Routing wires
Benefits
Excellent performance, small size, low power
Drawbacks
Very high NRE costs; as a result, long time-to-market

15. Semi-custom Lower layers are fully or partially built Benefits
Designers do routing of wires and placing some blocks
Benefits
Good performance, good size, lower NRE cost than for a full-custom implementation
Drawbacks
Still require weeks to months to develop

16. PLD (Programmable Logic Device)
All layers already exist
Designers can purchase a ready IC
Connections on the IC are either created or destroyed to implement desired functionality
Field-Programmable Gate Array (FPGA) very popular
Benefits
Low NRE costs, almost instant IC availability
Drawbacks
Bigger, higher unit costs, more power hungry, slower

17. Co-design process System Description (Functional) FSM- directed graphs
Concurrent processes
Programming languages
HW/SW
Partitioning
Unified representation
(Data/control flow) SW HW
Another
HW/SW
partition
Software
Synthesis
Interface
Synthesis
Hardware
Synthesis
System
Integration
Instruction set level
HW/SW evaluation

18. Conventional methodology
Analysis of Constraints
and Requirements
System Specs..
HW/SW
Partitioning
Hardware Descript.
Software Descript.
HW Synth. and
Configuration
Software Gen.
& Parameterization
Interface Synthesis
Configuration
Modules
Hardware
Components
HW/SW
Interfaces
Software
Modules
HW/SW Integration
and Cosimulation
Integrated
System
System Evaluation
Design Verification

19. Unified HW/SW Representation
Unified Representation --
A representation of a system that can be used to describe its functionality independent of its implementation in hardware or software
Allows hardware/software partitioning to be delayed until trade-offs can be made
Typically used at a high-level in the design process
Provides a simulation environment after partitioning is done, for both hardware and software designers to use to communicate
Supports cross-fertilization between hardware and software domains
One of the keys to a GOOD hardware/software codesign process is a unified representation the allows the functionality of the system (at various levels of abstraction) to be specified in a manner that is “unbiased” towards either a hardware or software implementation.
Again, this description must be validated to ensure that it meets the original system specifications. This validation typically happens through simulation although at a high level, formal techniques can sometimes be applied.
[Kumar95]

20. Abstract Hardware-Software Model
Uses a unified representation of system to allow early performance analysis
General
Performance
Evaluation
Abstract
HW/SW
Model
Evaluation
of Design
Alternatives
Identification
of Bottlenecks
An abstract HW/SW model is developed to promote early performance analysis. Using unified representation based on data/control flow concepts, the abstract HW/SW model supports general performance evaluation, the identification of bottlenecks, the evaluation of HW/SW tradeoffs, and the evaluation of design alternatives. The model can be used to assess the consequences of various HW/SW partitioning decisions before committing to a particular design.
[Kumar95]
Evaluation
of HW/SW
Trade-offs

21. Examples of Unified HW/SW Representations
Systems can be modeled at a high level as:
Data/control flow diagrams
Concurrent processes
Finite state machines
Object-oriented representations
Petri Nets
There are numerous methods that are candidates to be used for a unified representation. Most all of them have been tried in one codesign system or another with varying levels of success. Typically the methods are more suited to systems of a certain type, e.g., data flow diagrams are more suited to data driven applications like Digital Signal Processing (DSP) systems.

22. Hardware/Software Partitioning
Definition
The process of deciding, for each subsystem, whether the required functionality is more advantageously implemented in hardware or software
Goal
To achieve a partition that will give us the required performance within the overall system requirements (in size, weight, power, cost, etc.)
This is a multivariate optimization problem that when automated, is an NP-hard problem
Partitioning the system into dedicated hardware components and software components executing on Instruction Set Processors is a vital part of the codesign process.
Partitioning requires the use of performance and other metrics to assist the partitioner (either human or automated) in choosing from among several alternative hardware and software solutions.
Because there are multiple metrics that must be optimized at the same time, finding an optimum partition is an NP-hard problem.
[Gajski94].

23. HW/SW Partitioning Issues
Partitioning into hardware and software affects overall system cost and performance
Hardware implementation
Provides higher performance (no instruction parsing, parallel execution of operations)
Incurs additional expense of fabricating ASICs
Software implementation
May run on high-performance processors at low cost (due to high-volume production)
Incurs high cost of developing and maintaining (complex) software
Issues of hardware implementation vs software implementation must be addressed when performing partitioning. There are pros and cons to both hardware and software implementations. The system requirements and performance goals must be examined to determine which criteria are most critical for the particular system.
In general, HW implementation supports parallel execution of operations while incurring the cost of hardware fabrication. Software implementation is generally slower than custom hardware implementation, but does not require high cost of fabrication. Similarly, partitioning may be driven by schedule requirements in which there is not time to build custom hardware.
[DeMicheli93].

24. Partitioning Approaches
Start with all functionality in software and move portions into hardware which are time-critical and can not be allocated to software (software-oriented partitioning)
Start with all functionality in hardware and move portions into software implementation (hardware-oriented partitioning)
There are two basic approaches that most designers use when performing partitioning.
They either start with all operations in software and move some into hardware (when speed is critical) or they start with all operations in hardware and move some into software. Different design environments support one or the other. For example Cosyma, a cosynthesis approach to design, starts with all functions generated in software and then moves operations to hardware only as time constraints are violated.
A team at the University of Braunschweig, Germany, explored codesign tradeoffs in systems that were originally implemented in software (written in C)
A partitioning program identified the computational bottlenecks and migrated the corresponding functions to application-specific hardware
With system-level partitioning, a critical loop which took up 90% of the software execution time for a HDTV Chromakey algorithm was implemented in hardware (as a 17,000 gate ASIC) leading to a 3X speedup
A team at Stanford University explored migrating hardware components to software routines
Identifying non-critical tasks which can be migrated from hardware to software implementations lead to significant size and cost reductions without reducing performance
A system model which specified performance requirements in terms of latency and data-rate constraints was used to support the partitioning
A 20% reduction in gate count was achieved
[DeMicheli94]

25. Rapid prototyping tools
Development platforms that allow embedded system designers to quickly build system prototypes for verification, testing, and demonstration
memory
processor
programmable
logic for ASIC
emulation
interfaces
(serial, network,
etc)
peripheral
devices

26. Rapid prototyping tools
software for the final system can be developed and tested on the emulated hardware
memory
processor
programmable
logic for ASIC
emulation
interfaces
(serial, network,
etc)
large choice of ready-to-use interfaces simplifies integration testing
low-cost emulation of custom ICs plus ready designs for popular functions

27. From prototype to final system
Since the development board essentially emulates the final system, conversion to the ready product becomes a matter of retaining the necessary hardware and software parts from the development prototype
memory
processor
programmable
logic for ASIC
emulation
interfaces
(serial, network,
etc)
software
final embedded
system
hardware
development board

28. Summary
Main embedded systems design challenge -- simultaneous optimisation of numerous design metrics
Unlike with desktop systems, expertise with both hardware and software is required – hardware/software co-design
Rapid prototyping tools help to evaluate hardware/software partitioning and other design decisions