Software and Hardware Co-design

For Defense Embedded Systems

S.Umamaheswaran
Member (Senior Research Staff)
Central Research Laboratory
Bharat Electronics Limited.,

1
 Overview

 What Is an Defense Embedded System?

 COTS for Defense Embedded Systems

 Software and Hardware Co-Design

 RTOS Options

2
Defense Embedded System

3
 What Is an Defense Embedded System?

 Defense Embedded Systems

 Application-specific systems which contain hardware and software
tailored for a particular task and are generally part of a larger
system (e.g., Handheld Computer, man pack Radio, radar)

STARS V 5 W FH RADIO Low Flying Detection Radar

Hand Held Computer
( INDRA II)
4
 Characteristics

 Characteristics
 Application specific - Optimize for cost, area, power, and performance
 Digital signal processing - Signals are represented digitally
 Reactive - Reacts to changes in the system’s environment
 Real-time - Compute certain tasks before deadline
 Include requirements that span:
 Performance , Reliability , Maintainability, Security

5
 GIG - An Example of Defense Embedded System

 “Will provide the joint and coalition war fighter with a single, end-to-
end information system capability… allowing users to access shared
data and applications regardless of location, and is supported by a
robust network/information-centric infrastructure.”

6
 Defense Embedded Systems: Complexity Issues

 Complexity of embedded systems is continually increasing

 Number of states in these systems (especially in the software) is very
large
 Description of a system can be complex, making system analysis
extremely hard
 Complexity management techniques are necessary to model and
analyze these systems
 Systems becoming too complex to achieve accurate “first pass” design
using conventional techniques
 New issues rapidly emerging from new implementation technologies

7
 Design Challenges

 Low cost  Mixed digital/analog requirements

 Light weight  Shrinking time-to-market

 Reliability  Short product lifetime

 Low power  Real-time processing

 Portable  Inherent concurrency

 Complexity
 HW/SW co-design

 Secure
 Ease of use

8
 Research Topics in Defense Embedded Systems

 Power Management
 Battery life, reliability and thermal issues, energy harvesting
 Coupled with sensor networks
 HW/SW co-design, very limited information processing and
computing
 Energy management
 Adaptation to Applications and Environment
 Reconfigurable and adaptive Systems
 Embedded Software
 Security in Embedded Systems
 physical attack
 Attack through network
9
COTS

10
 COMMERCIAL OFF-THE-SHELF (COTS)

 Implementation of commercially available technologies for

traditionally customized applications
 Examples:
 Military
 Industrial
 Space
 Applies to Hardware and/or Software

11
 COMMERCIAL OFF-THE-SHELF (COTS)

 Examples:
Software:
 Operating Systems (UNIX, Windows/NT, OS2)
 Databases (Oracle, Sybase)
 Graphics Packages (GIS)
Hardware:
 Busses (VME, PCI, cPCI,CAN)
 Processors (TI,Motorola, HP, Sun, Intel)
 Disk Drives (Western Digital, Red Rock)
 Peripherals

12
 COMMERCIAL OFF-THE-SHELF (COTS)

 COTS vs. Custom

Advantages:
 Cheaper (large quantity production)
 General Purpose (more flexible for different applications)
 Shortens design-to-production cycles
 Large user base generally uncovers design defects early
 Provides current technology solutions
 Emerging technology tends to be backward compatible with legacy
products (allows solutions to advance with technology)
 Avoids binding solution to single hardware/software source

13
 COMMERCIAL OFF-THE-SHELF (COTS)

 COTS vs. Custom

Disadvantages:
 May not be suitable for all applications:
 Highly deterministic performance may require special operating system
 Environmental constraints (temperature, radiation exposure, corrosive
exposure)
 Packaging (size, weight, shape)
 Reliability:
 May not meet reliability requirements of mission critical systems (flight
control, weapons direction, medical equipment)
 Obsolescence:
 COTS binds user to market trends - critical components may become
unavailable and impossible to reproduce

14
 COMMERCIAL OFF-THE-SHELF (COTS)

 Issues and Considerations when using COTS

• Supporting, maintaining, and upgrading systems with long life-
cycles (10+years)
• Licensing and Data Rights
 COTS Software is usually distributed under license (a per-user
fee is typical)
 COTS documentation is normally copyrighted - distribution as
part of another product usually requires special arrangements
and a copy fee
 Software source code and designs for hardware are usually
proprietary and protected by copyright or patent - even after it is
no longer distributed

15
Co-Design

16
 Co-design Definition and Key Concepts

 Co-design
 The meeting of system-level objectives by exploiting the trade-
offs between hardware and software in a system through their
concurrent design
 Key concepts
 Concurrent: hardware and software developed at the same
time on parallel paths
 Integrated: interaction between hardware and software
development to produce design meeting performance criteria
and functional specs

17
 Motivations for Co-design

 Factors driving co-design (hardware/software systems):

 Instruction Set Processors (ISPs) available as cores in many
design kits (386s, DSPs, micro controllers,etc.)
 Systems on Silicon - many transistors available in typical
processes (> 10 million transistors available in IBM ASIC
process, etc.)
 Increasing capacity of field programmable devices - some
devices even able to be reprogrammed on-the-fly (FPGAs,
CPLDs, etc.)
 Efficient C compilers for embedded processors
 Hardware synthesis capabilities

18
 Motivations for Co-design

 The importance of co-design in designing hardware/software

systems:
 Improves design quality, design cycle time, and cost
 Reduces integration and test time
 Supports growing complexity of embedded systems
 Takes advantage of advances in tools and technologies
 Processor cores
 High-level hardware synthesis capabilities
 ASIC development

19
 Categories of Co-design Problems

 Co-design of Defense embedded systems

 Usually consist of sensors, controller, and actuators
 Are reactive systems
 Usually have real-time constraints
 Usually have dependability constraints
 Co-design of ISAs
 Application-specific instruction set processors (ASIPs)
 Compiler and hardware optimization and trade-offs
 Co-design of Reconfigurable Systems
 Systems that can be personalized after manufacture for a specific
application
 Reconfiguration can be accomplished before execution of concurrent
with execution (called evolvable systems)
20
 Components of the Co-design Problem

 Specification of the system

 Hardware/Software Partitioning
 Architectural assumptions - type of processor, interface style between
hardware and software, etc.
 Partitioning objectives - maximize speedup, latency requirements,
minimize size, cost, etc.
 Partitioning strategies - high level partitioning
 Scheduling
 Operation scheduling in hardware
 Instruction scheduling in compilers
 Process scheduling in operating systems
 Modeling the hardware/software system during the design process

21
 A Model of the Current Hardware/Software Design Process
DOD-STD-2167A
HWCI
HW Development Testing
Fabric.
Detailed
Design
Prelim.
Design
Hardware
Require.
Sys/HW
Analysis
Require.
Analysis
System System Operation.
Concepts Integ. and Testing and
Sys/SW test Eval.
Require.
Analysis Software
Require.
Analysis Prelim.
Design
Detailed
Design
Coding,
Unit test.,
SW Development Integ. test CSCI
Testing
22
 Current Hardware/Software Design Process

 Basic features of current process:

 System immediately partitioned into hardware and software
components
 Hardware and software developed separately
 “Hardware first” approach often adopted
 Implications of these features:
 HW/SW trade-offs restricted
 Impact of HW and SW on each other cannot be assessed easily
 Late system integration
 Consequences these features:
 Poor quality designs
 Costly modifications
 Schedule slippages

23
Incorrect Assumptions in Current Hardware/Software Design Process

 Hardware and software can be acquired separately and

independently, with successful and easy integration of the two
later
 Hardware problems can be fixed with simple software
modifications
 Once operational, software rarely needs modification or
maintenance
 Valid and complete software requirements are easy to state and
implement in code

24
 Directions of the HW/SW Co-Design Process
Integrated Modeling Substrate
HWCI
HW Development Testing
Fabric.
Detailed
Design
Prelim.
Design
Hardware
Require.
Sys/HW
Analysis
Require.
Analysis Operation.
System System
Concepts
Integrated Modeling Substrate Integ. and Testing and
Sys/SW test Evaluation
Require.
Analysis Software
Require.
Analysis Prelim.
Design
Detailed
Design
Coding,
Unit test.,
SW Development Integ. test CSCI
Testing
25
 Requirements for the Ideal Co-design Environment

 Unified, unbiased hardware/software representation

 Supports uniform design and analysis techniques for hardware and
software
 Permits system evaluation in an integrated design environment
 Allows easy migration of system tasks to either hardware or software
 Iterative partitioning techniques
 Allow several different designs (HW/SW partitions) to be evaluated
 Aid in determining best implementation for a system
 Partitioning applied to modules to best meet design criteria
(functionality and performance goals)

26
 Requirements for the Ideal Co-design Environment

 Integrated modeling substrate

 Supports evaluation at several stages of the design process
 Supports step-wise development and integration of hardware and
software
 Validation Methodology
 Insures that system implemented meets initial system requirements

27
 Typical Co-design Process

System
FSM- Description Concurrent processes
directed graphs (Functional) Programming languages

HW/SW Unified representation

Partitioning (Data/control flow)

SW HW
Another
HW/SW Software Interface Hardware
Synthesis Synthesis Synthesis
partition

System Instruction set level

Integration HW/SW evaluation

28
RTOS

29
 RTOS

 Three groups
 Small, fast, proprietary kernels
 Real-time extensions to commercial operating systems
 Research operating systems

 Small, fast, proprietary kernels

 homegrown
 commercial offerings:
 QNX, PDOS, pSOS, VCOS, VRTX32, VxWorks, Windows CE

30
 RTOS

 To reduce the run-time overheads incurred by the kernel and to

make the system fast, the kernel
 has a small size
 responds to external interrupts quickly
 minimizes intervals during which interrupts are disabled
 provides fixed or variable sized partitions for memory
 management as well as the ability to lock code and data in
memory
 provides special sequential files that can accumulate data at
a fast rate

31
 RTOS

 To deal with timing constraints, the kernel

 provides bounded execution time for most primitives
 maintains a real-time clock
 provides primitives to delay processing by a fixed amount of
time and to suspend/resume execution
 Also, the kernel
 performs multitasking and intertask communication and
synchronization via standard primitives such as mailboxes,
events, signals, and semaphores.
 For complex embedded systems, these kernels are inadequate as
they are designed to be fast rather than to be predictable in every
aspect.

32
 Common RTOS Features

 Utilities
 Bootstrapping support
 “Headless” operation
 Display not necessary
 APIs (Application Programming Interfaces)
 Multiple threads and/or processes
 Mutex /semaphore support with priority inheritance support
 Timers/clock
 Graphics support
 Device drivers
 Network protocol stack
33
 RTOS Considerations

 What processor(s) does it run on?

 8-bit, 16-bit, 32-bit, …
 Intel Pentium® Processor, PowerPC, Arm/StrongArm Intel
Xscale®, MIPS, SuperH, DSP,FPGA…
 IBM and Intel® Network Processors

 What board(s) does it run on?

 Complete software package for a particular hardware board is
called a BSP (Board Support Package)

 What is the software environment?

 Compilers and debuggers
 Cross-compilation + symbolic debugging on target?
 Profilers (CPU, memory)
 Test coverage tools
 Native simulation/emulation support?
34
 Metrics in Real-Time Systems (1/2)

 End-to-end latency:
 E.g. worst-case, average-case, variance, distribution
 Can involve multiple hops (across nodes, links, switches
and routers)
 Behavior in the presence or absence of failures
 Jitter
 Throughput:
 How many X can be processed?
 How many messages can be transmitted?
 Survivability:
 How many faults can be tolerated before system failures?
 What functionality gets compromised?

35
 Metrics in Real-Time Systems (2/2)

 Security:
 Can the system’s integrity be compromised?
 Can violations be detected?
 Safety:
 Is the system “safe”?
 Can the system get into an ‘unsafe’ state? Has it been
‘certified’?

 Maintainability:
 How does one fix problems?
 How does the system get upgraded?
 Dynamism and Adaptability:
 What happens when the system mission changes?
 What happens when individual elements fail?
 Can the system reconfigure itself dynamically?
36
 Emerging RTOS Requirements

 Full-featured operating system

 Support for new processors and devices
 Support for Internet protocols and standards
 Support for Multimedia protocols and standards
 Support for File Systems
 Memory protection
 Resource protection, security
 Development tools and libraries Do this with low and
predictable overheads.
 GUI Environment

37
 Examples of RTOS

• Proprietary: • Proprietary: • Open source:

 Ardence RTX  Phar Lap ETS – eCos
 BeOS  PikeOS – Fiasco
 ChorusOS
  Portos – FreeRTOS
DNIX
 DSOS  pSOS – Linux
 embOS (Segger)  QNX – Phoenix-RTOS
 ITRON  RMX – Nut/OS
 integrity  RSX-11 – Prex
 LynxOS  RT-11
 – RTAI
 MicroC/OS-II RTOS-UH
 MQX RTOS [5]  RTXC – RTEMS
 Nucleus  Salvo RTOS – RTLinux
 OS-9 [6] – SHaRK
  SINTRAN III
OSE – TRON Project
 OSEK/VDX  Symbian OS – Xenomai
 OSEKtime  ThreadX
 PDOS
 Phar Lap ETS  VRTX
 VxWorks
 Windows CE 38
THANK YOU

sumamaheswaran@bel.co.in

39