Transcript Software and Hardware co-design for Defense

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)
Hand Held Computer
STARS V 5 W FH RADIO
Low Flying Detection Radar
( 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, endto-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 peruser 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
Testing
HW Development
Fabric.
System
Concepts
Sys/HW
Require.
Analysis
Sys/SW
Require.
Analysis
Hardware
Require.
Analysis
Prelim.
Design
Detailed
Design
System
Integ. and
test
Software
Require.
Analysis
SW Development
Prelim.
Design
Detailed
Design
Coding,
Unit test.,
Integ. test
Operation.
Testing and
Eval.
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
Testing
HW Development
Fabric.
System
Concepts
Sys/HW
Require.
Analysis
Hardware
Require.
Analysis
Prelim.
Design
Detailed
Design
Integrated Modeling Substrate
Sys/SW
Require.
Analysis
Software
Require.
Analysis
SW Development
Prelim.
Design
Detailed
Design
Coding,
Unit test.,
Integ. test
System
Integ. and
test
Operation.
Testing and
Evaluation
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
requirements
system
implemented
meets
initial
system
27
Typical Co-design Process
FSMdirected graphs
Another
HW/SW
partition
System
Description
(Functional)
Concurrent processes
Programming languages
HW/SW
Partitioning
Unified representation
(Data/control flow)
SW
Software
Synthesis
HW
Interface
Synthesis
System
Integration
Hardware
Synthesis
Instruction set level
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

GUI Environment
Do this with low and
predictable overheads.
37
Examples of RTOS
•
Proprietary:


















Ardence RTX
BeOS
ChorusOS
DNIX
DSOS
embOS (Segger)
ITRON
integrity
LynxOS
MicroC/OS-II
MQX RTOS [5]
Nucleus
OS-9
OSE
OSEK/VDX
OSEKtime
PDOS
Phar Lap ETS
• Proprietary:



















Phar Lap ETS
PikeOS
Portos
pSOS
QNX
RMX
RSX-11
RT-11
RTOS-UH
RTXC
Salvo RTOS
[6]
SINTRAN III
Symbian OS
ThreadX
VRTX
VxWorks
Windows CE
µnOS
UNIX-RTR
•
Open source:
– eCos
– Fiasco
– FreeRTOS
– Linux
– Phoenix-RTOS
– Nut/OS
– Prex
– RTAI
– RTEMS
– RTLinux
– SHaRK
– TRON Project
– Xenomai
38
THANK YOU
[email protected]
39