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

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

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)

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

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)

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?)

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

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.

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].

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].

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]

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

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

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

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