CPE555A:
Real-Time Embedded Systems
Lecture 1
Ali Zaringhalam
Stevens Institute of Technology
Spring 2016, arz
1
Grader

Qiming Zhao:

qzhao7@stevens.edu
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
2
Grade Distribution
Grade Fall 2014
Spring 2015
Spring 2016
A
6 (14%)
3 (11%)
4 (14%)
A-
6 (14%)
6 (22%)
6 (20%)
B+
15 (38%)
11 (39%)
13 (42%)
B
10 (24%)
4 (14%)
4 (14%)
C
2 (5%)
2 (7%)
3 (10%)
F
2 (5%)
2 (7%)
0
I
0
0
1
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
3
Outline




Embedded systems
Real-time-systems
Taxonomy of real-time embedded
systems
Example applications
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
4
General-Purpose Computer System

A general-purpose computer such as a
desktop or laptop can be used for a
variety of applications (e.g. word
processing, streaming audio, DB)
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
5
Embedded Computer System

An embedded computer system is a component of
a larger system




It is programmed to serve a single set of functions
It generally interacts with the environment and
performs a set of repeated control and monitoring
tasks
Examples include computers embedded in TV, microwave
oven, medical devices, cars, network routers, etc.
There are a lot more embedded computing devices than
desktops, laptops, workstations
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
6
General-Purpose Computer
Intel Pentium 3-4 GHz
3-8MB Cache
~8 GB RAM
~100 W Power
Up to 1000 GB Storage
CD/DVD
10/100/1000
Ethernet & WiFi
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Video card
Stevens Institute of Technology
7
Microcontroller-Based Embedded Computer
ROM or Flash to hold
program
Flash ~256 KB
ARM Core
~ 100 MHz
~100 KB
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
8
Beaglebone Black
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
9
Large Embedded Systems


Embedded doesn’t mean small
Large embedded systems such as network
switches and routers don’t use microcontrollers





CPU is typically in 100’s of MHz
500MB-1 GB RAM
250-500 MB Flash
Power consumption could be an issue
They are embedded systems like their smaller
counterparts in the sense that they perform a
single well-defined set of tasks
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
10
What Is a Real-Time System?

A computer program/algorithm has inputs and
outputs. The response/output to a given input
defines the program behavior.



Sorting algorithm: sort the input and provide as output
There are many sort algorithms with different average
and worst-case complexity (O(n), O(nlogn), etc.)
In a real-time system, the behavior must be both
logically correct and produced at the correct
instant of time.

If the deadline is missed, the behavior is considered
incorrect.
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
11
System/Environment Interfaces


A real-time system
reacts to input from
the environment
(user and the
• Keyboard/Button
controlled object) • Display
“Real” time means
that the reaction of
the system to
• Sensors & actuators
• Control registers
external events
must occur during
its evolution

Using the same
time scale and
clock
Spring 2016, arz
Environment
•
•
•
•
Pedestrian
Car driver
Network operator
Etc.
User
User
Interface
Real-Time System
Control
Interface
•
•
•
•
Traffic light
Brake system
Switching device
Etc.
Controlled Object
Environment
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
12
Real-Time System Example
Feedback Loop
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
13
Classification of Real-Time Systems





Hard real-time vs. soft real-time
Fail-safe vs. fail-operational
Guaranteed timeliness vs. best-effort
Resource-adequate vs. resourceinadequate
Event-triggered vs. time-triggered
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
14
Hard vs. Soft Real-Time: Deadline

A hard real-time system must produce the
result at the correct physical time. Failure
to do so can have catastrophic consequence
and is considered unacceptable.


Nuclear power plant
A soft real-time system can miss a
deadline.


The result may still be useful
If the deadline is missed, there will not be a
catastrophe. (e.g., multimedia)
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
15
Hard vs. Soft Real-Time: Response-Time



A hard real-time system must
respond to events on the order of
milliseconds (e.g., a braking system).
A soft real-time system’s response
can be on the order of seconds (an
ATM machine).
Hard real-time systems use
specialized scheduling techniques
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
16
Hard vs. Soft Real-Time: Peak-Time
Performance


A hard real-time system must meet the
specified deadline under peak/worst
conditions. It must be able to meet
deadlines in rare-event scenarios.
Soft real-time systems are defined in
terms of average behavior. Performance
degradation in worst case scenarios is
accepted for economic reasons
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
17
Real-Time Impact of Common Techniques









Pipelined processors with speculative execution
for conditional statemets
Caching
Virtual memory
Compilers with optimization turned on
Garbage collection
Multi-tasking
Networking
Software component
Etc.
All commonly used in generalpurpose computers. Some (such as
virtual memory) are never used in
embedded systems.
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
18
Fail-Safe Vs. Fail-Operational

If a system can enter a “safe” state when failure
occurs, the system is fail-safe



Railway signaling system failure: a safe state is to turn all
lights red.
Example: a watchdog timer must be stroked at regular
intervals by software. If there is a software failure, the
watchdog fires, forces the system into a safe state &
resets the CPU.
In a fail-operational system, a safe state after
failure is not acceptable. The system must remain
operational and provide a minimal amount of
guaranteed service.

An airplane with a single failed engine
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
19
Guaranteed Response Time




Assumption coverage: start by defining a set of
specifications for the expected system failures &
a set of worst-case load assumptions.
Recovery specifications: next specify recovery
strategy to meet fail-safety, fail-operational, etc.
For guaranteed response, the system must be
designed to address all specified failures under
peak load with the specified recovery.
The probability of unknown failure is reduced to
the accuracy of the specification coverage &
recovery spec.
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
20
Best-Effort System




Troutman Postulate:
The worst software bug will
be discovered six
months after field
test.
A system that does not have the guaranteed
response-time properties is considered a best
effort system
In a best-effort system, failures are discovered
through extensive integration testing. When a
failure is discovered during testing, a fix is
proposed and implemented
This is an ad-hoc procedure: there are always
failures that are detected after system
deployment.
For economic reasons, most real-time systems are
best-effort unless they have safety-critical
requirements.
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
21
Resource-Adequacy

In order to have a guaranteed response
time, the system must be engineered to
operate under worst-case conditions


You can’t use probabilistic arguments to
estimate a resource (such as RAM size)
Most soft real-time systems are besteffort and therefore not resourceadequate under worst-case conditions
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
22
Event- vs. Time-Triggered

In event-triggered systems, all processing
activities are driven by some event in the
environment


The computer system receives the event via a
CPU interrupt
In time-triggered systems, all processing
activities are initiated at periodic intervals


There is a single interrupt associated with a
clock to pace the system
The occurrence of events in the environment are
detected via periodic polling or via interrupts
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
23
Dependability

Real-time systems must be dependable: it should
provide the intended service for an extended
interval of time






Reliability
Maintainability
Availability
Safety
Security
Even perfectly designed systems can fail if the
assumptions about the workload and possible
errors turn out to be wrong.

Making the system dependable must not be an afterthought, it must be considered from the very beginning
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
24
Reliability Measure



Reliability R(t) = probability of system working correctly
provided that is was working at t=0
Mean Time To Failure (MTTF): average period of time until a
failure occurs
Failure rate (FIT): a measure of the frequency with which
the system fails; expressed in failures per hour

Failures In Time: FIT measures number of failures per unit time






Unit of time is 109 hours
So 1 FIT means that the MTTF is 109 hours (115,000 years)
In general the failure rate is time-dependent. A car is more
likely to fail after 10 years.
But typically a fixed FIT rate is used as a measure of reliability
R(t) = exp[-lt] where l=1/MTTF
Ultra-high reliable systems typically have a l= 10-9
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
25
Examples

FIT Rate = 109/(MTTF)


MTTF = 100,000 hours (11 years)


MTTF is in hours
FIT = 10,000
FIT Rate = 100

MTTF = 10,000,000 hours (1141 years)
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
26
Safety Measure




How safe is a computer-controlled braking system
in a car?
The failure is critical in the sense that the cost is
immeasurable (loss of life)
The safety of a system with respect to a critical
failure is also measured in terms of MTTF of the
specific failure
A car typically operates a few hours a day. A
failure rate of l= 10-9 (hour-1) translates into
about 10 failures per million cars per year
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
27
Maintainability Measure

Maintainability is a measure of the time
interval to repair a system after a failure
has occurred





Repair could take human intervention or it could
be autonomous
Example of autonomous repair: a computer
software failure triggers a reset
Example of human intervention: craft dispatch
Mean time to repair (MTTR) is the average
time to repair a failed system
Repair rate m=1/MTTR (repairs per hour)
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
28
Availability Measure


Availability is a measure of the delivery of correct
service when the service fails
In a system with MTTF and MTTR



MTBF= MTTF+MTTR
A= MTTF/MTBF
Design tradeoff: you can increase availability by
either increasing MTTF or decreasing MTTR
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
29
Example - 1

A telecom system deployed in the field has a MTTF of
100,000 hours (~11 years) assuming a hardware failure



FIT rate=(1/100000) x 109 = 10,000.
If a blade fails, it requires dispatch of maintenance crew to
replace the blade. This takes about 4 hours.
What is the availability rate?




MTBF=100000+4=100004 hours
A=MTTF/MTBF=100000/100004=0.99996
This system is referred to as meeting four nines
Down-time per year: 365*24*60*(1-0.99996)=21 minutes
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
30
Example - 2


Typically the availability requirement for telecom systems is
five nines
What can be done to increase availability?


Common strategy is to reduce MTTR by providing a
redundant blade which can be placed in service as a standby

Suppose it takes a minute to do a failover switch (for a hot
standby it is instantaneous)
Availability=100000/(100000+1/60)=0.999999 (six nines)
Assumes the redundant blade does not fail before the primary
has been replaced. Double failures are not covered.
Down-time per year: 365*24*60*(1-0.999999)=0.5 minute
For five nine systems it is about 5 minute downtime/year

http://en.wikipedia.org/wiki/High_availability





MTBF= MTTF+MTTR; A= MTTF/MTBF
For more information on high availability, see
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
31
Multi-Component System Reliability

Consider a system with n components




Ri(t) = probability of sub-system i working
correctly
Ri(t) = exp[-lit], i=1….n
Each system’s failure is independent of
others’
What is the MTTF of the whole system?

R(t) = R1(t) x R2(t) x …….. X Rn(t) = exp[lsyst]


lsys =S li
1/MTTFsys = S(1/MTTFi)
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
32
Example

Assume a disk subsystem with the following
components and MTTF:






N disks each rated at 1,000,000 - hour MTTF
1 SCSI Controller rated at 500,000 - hour MTTF
1 Power Supply rated at 200,000 - hour MTTF
1 Fan rated at 200,000 - hour MTTF
1 Processor rated at 100,000 - hour MTTF
How many disks can we support such that the
MTTF of the entire system is at least 4 years?
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
33
Example - Continued



1/MTTFsys = S(1/MTTFi)
1/(4*365*24) = N/(1000,000)
+1/(500,000)+1/(200,000)+1/(200,00
0)+1/(100,000)
N=6.5

N=6 taking the lower bound
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
34
Example - Continued



Suppose MTTR of the entire system
is 200 hours, what is the availability
of the system?
Availability =
MTTF/(MTTF+MTTR)=(4*365*24)/(
4*365*24+200)=0.994
FIT Rate = 109/MTTF=28,500
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
35
Security

Embedded systems must protect against unauthorized
access and denial-of-service (DOS) attacks

File tampering
Code tampering
Etc.

Policing traffic destined for the CPU from the network





Cryptographic theft-avoidance systems for cars (ignition
locking)
Authentication network protocols (e.g., 802.1X)
DOS attacks on servers and routers
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
36
Efficiency

Real-time embedded systems must be efficient

Code-size efficient

Run-time efficient

Weight efficient

Cost efficient

Energy efficient
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
37
Application Areas

Hybrid embedded systems







Aerospace, automobiles, robotics, process control, and sensor
nets
Multimedia
Consumer electronics

Appliances, office electronics, and home/office automation

Bridges, routers, switches, and hubs

Patient monitoring, MRI, and artificial hearts

ATM, vending machines
Network components
Medical instruments
E-Business
Distributed & grid computing
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
38
Hybrid Embedded Systems

Computation systems whose behavior is tightly
integrated with the physical world



Example: the behavior of an unmanned aerial
vehicle (UAV) can be modeled by a combination
of differential equations (the aerodynamics and
low level feedback controllers) and a finite
state automata (high level flight path decisions,
such as to ascend or descend).
Behavior is governed by both continuous-state
dynamics from the physical world and
discrete-state dynamics from the computation
Passage of time during computation affects
the state of the physical world
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
39
Aerospace

Flight control



Positioning & navigation




Global Positioning System (GPS)
Inertial navigation system (INS)
Instrumentation


Stability
Anti-collision systems
Data acquisition, display,
processing, and archive
Radar
Communication
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
40
Automobiles

Engine management





Emission control
Instrumentation
Data acquisition, display, processing
Safety & stability






Fuel, ignition, timing
Airbags
Anti-Lock Braking Systems (ABS)
Electronic Stability Control (ESC)
Theft prevention with smart keys
Blind-angle alert systems
Entertainment & comfort


Radio
Heat & A/C
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
41
Automobiles

Premium-class automobile




Low-end cars



Millions of LOC in a premium class
automobile
Execute on 70-100 μP
Electronics & SW cost is ~40% of the
car’s cost, and rising
30-50 μP
Processors are networked
throughout the car
Source:
http://spectrum.ieee.org/greentech/advanced-cars/this-carruns-on-code
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
42
Robotics





Implies autonomous
operation
N physical degree of
freedom
Artificial intelligence
Control heavy
Mission oriented

Repair, search, rescue,
investigate, and perform
physically difficult tasks
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
43
Process Control



Industrial automation
Plant monitoring and production control
Similar to control systems but with
emphasis on management
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
44
Sensor Nets

Many sensor nodes each capable (but
limited) of sensing, computation/storage,
and communication





Structure safety
Search and rescue
Military use
Energy Efficient
Distributed
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
45
Multimedia

Functions include

Signals, analog to digital conversion,
quantization, sampling, processing, and digital to
analogue conversion
Compression
Images, audio, video

Jitter-intolerance





Virtual Reality
Presentation
Quality of service
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
46
Consumer Electronics

Home appliances



Office electronics


Scanner/Printer/Fax
Home/office automation


Microcontroller-based
Future: add networking (HeMS)
Automated home or office with lights and appliances
that operate by themselves or with minimal effort
Internet of Things


http://en.wikipedia.org/wiki/Internet_of_Things
Typically has embedded systems hanging off the end
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
47
Network Components

Switching LANs



Switch large volumes of data at high-speed line
rate (1/10/100 Gbps)




Bridge: connects two parts of the same multicast
domain/subnet
Router: links nodes of different subnets
Packet classification and filtering based on packet
header
Deep packet inspection
Quality of Service (policing and shaping in packet
networks)
An embedded computer controls the datapath
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
48
Medical Instruments

Perform diagnosis
(screening/evaluation)




Observation or monitoring
Sensing and instrumentation


Data collection
Appraisal of that data
Accuracy and precision
Other applications:


Radiation therapy
Artificial hearts, arms, legs, …
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
49
E-Business

Information processing
systems






ATM
Cash registers
Scanners
Credit-card readers
Often the interface behind a
database
Automation and convenience
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
50
Elements of Computer Architecture

Instruction Set Architecture (ISA)


Microarchitecture


how to tell the processor what to do?
includes CPU internal organization, memory
hierarchy, etc.
Hardware Implementation



circuit design
packaging
etc.
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
51
Instruction Set Architecture



Interface between machine & “programmers”
 machine’s Application Programming Interface
(API)
The“programmers” who care about this API
 for the most part compiler developers
care……but also ...
 assembly programmers (low-level code)
 Real-time system developers
most programmers write portable code in highlevel language and do not care about ISA
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
52
Microarchitecture

Specification of Functional Blocks





Specification of Interfaces Between Building Blocks




internal registers (how many, special- vs. general-purpose, etc.)
Arithmetic & Logic Unit (ALU) , FP units
memory organization & cache design,
etc.
interconnection structure (bus, point-to-point, etc.)
data flow between instructions (register, broadcast bus, etc.)
control (hardwired, microprogrammed, centralized, distributed)
Implementation of ISA



whether CPU is single-cycle, multi-cycle, pipelined, etc.
organization of pipeline (number of stages, functions in each
stage)
single-issue, multiple-issue (superscalar), etc.
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
53
Hardwired Processing
Custom Hardware
{X}
Input
F
Output
{Y=F(X)}
•Special-purpose processor
•A different computation requires rewiring
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
54
General-Purpose Processor
CPU is a general-purpose instruction set processor
Instruction
Instruction Decoder
Control Signals (S)
{X}
Input
Spring 2016, arz
General-Purpose ALU
Output
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
{Y=F(X,S)}
55
Von Neumann Machine
Input/Output
CPU
ALU/Datapath
Main
Memory
Control Unit
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
56
Von Neumann Machine: Key Concepts

Stored Program Control



Memory is Addressable by Location for Both Data &
Executable code
Control Unit



Arithmetic & Logical Operations on Binary Data
Input/Output


Fetch & Execution of Sequential Instructions From Memory
Branch Instructions
Arithmetic & Logic Unit (more generally: datapath which
includes functional units for fetch & store, decode, etc.)


Storage of Both Data & Executable Instructions in Main Memory
Controlled by Control Unit (directly or indirectly)
First Prototype: IAS in 1952
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
57
Fetch/Execute Cycle
Interrupts
Disabled
Start


Fetch Next
Instruction
Execute
Instruction
Handle
Interrupts
(If Any)
The address of the current instruction is the
Program Counter (PC) register.
After the instruction is fetched, PC is
automatically incremented to point to the
next instruction
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
58
Need for Instructions

We need a way to tell the processor what steps to
take to execute our program. In the Von Neumann
model this includes





fetching data from memory
performing arithmetic & logical operations on the data
storing the results of computation in memory
performing input/output
In addition the processor must support certain highlevel programming constructs. These include
 modifying the sequential flow of control for if then else

and case
subroutine calls to support structured programming
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
59
Examples of Instructions
Here are some example instructions:
 Loading data from a memory location into a register
load Register1, Memory_Address
 Storing data from a register to a memory location
store Register1, Memory_Address
 Adding the contents of two source registers and storing the
result in a third destination register
add Register3, Register1, Register2
 Comparing two registers and fetching the next instruction
based on the result of comparison (either sequential or from
a branch)
bne Register1, Register2, Instruction_Address
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
60
RISC Instruction Set Architecture


MIPS is a flavor of the more generic class of Reduced
Instruction Set Computer (RISC) Instruction Set
Architecture (ISA)
Here are some examples of RISC processors






ALPHA (Digital/Compaq)
PowerPC (Motorola & IBM)
SPARC (Sun Microsystems)
MIPS
ARM (heavily used in embedded systems today)
The ISAs implemented in these machines are not quite the
same but share a large set of common characteristics (to be
discussed shortly)
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
61
Summary: MIPS Instruction Formats
6
opcode
5
5
5
5
rs
rt
rd shamt
6
func
R-Type Format
6
opcode
5
5
16
rs
rt
immediate
I-Type Format
6
opcode
26
immediate
J-Type Format
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
62
What’s in an ISA?


Above all an ISA is a set of specifications
An ISA gives you a set of requirements on what to build (i.e.,
support) in a processor. These include:






the set of instructions that the processor must support
the number of programmable registers
instruction format including size and encoding
the interface between the processor and the operating system
for exception handling
what features are required and what features are optional (for
example in MIPS integer arithmetic is required but floatingpoint arithmetic is optional)
in short: whatever is required to ensure binary compatibility
between two machines implementing the same ISA
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
63
What Isn’t in an ISA?


An ISA doesn’t tell you how to build a processor. Should it
be pipelined? How many instructions should be issued per
cycle? etc.
This permits


processor vendors to implement the ISA in different ways
based on technology/performance/cost requirements
compiler developers to develop compilers to translate to an ISA
independent of the processor’s specific implementation


this is not entirely true when it comes to performance optimization
an ISA to live longer than a specific implementation (a
particular processor becomes obsolete long before an ISA is
abandoned in favor of a new one)
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
64
Characteristics of RISC Processors






Large number of General Purpose Registers
Strictly load/store
Fixed-size instructions
Variable-format instructions
Limited number of addressing modes
Small instruction set (MIPS32 has 168
instructions vs. ~700 in VAX)
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
65
RISC Alternative: CISC

CISC: Complex Instruction Set Computer
CISC  RISC





variable-length, variable format instructions
complex instructions
memory-register instructions
complex addressing modes
Example: Intel’s IA32
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
66
What’s a General-Purpose Register?
A general-purpose register (GPR) is a programmable register which can be
used for any purpose the programmer deems necessary. By programmer
here we generally mean developers of compilers and low-level code such as
drivers. They can use GPRs in any way that suits their purpose to optimize
performance. The (General in) GPR should be contrasted with specialpurpose registers. These include the accumulator register and registers
reserved for holding the base address and offset index of arrays. Specialpurpose registers were common in early processors because registers were
expensive and compilers weren’t smart enough to exploit them.
Processors
such as those from Intel which are based on the legacy 8086 ISA continue
to support special-purpose registers.
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
67
Storage-Device Hierarchy
0.25-0.5 ns
Increasing Access Time
0.5-20 ns
80-250 ns
4 GHZ CPU Cycle T=0.25 ns
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
68
Why a Large Number of GPRs?


Registers are cheaper to make now
Registers offer compiler writers flexibility




compiler developers prefer unreserved registers
Registers are faster to access than main memory or cache
Registers can store variables for as long as necessary. This
reduces the need to access memory for data
We can address registers with fewer bits compared to
addressing main memory. This reduces code density


in MIPS we need 5 bits to address 32 registers
in a 32-bit machine we need 32 bits to address a memory
location
Spring 2016, arz
CPE555A – Real-Time Embedded Systems
Stevens Institute of Technology
69