Embedded Computing
Download
Report
Transcript Embedded Computing
Embedded
Computing/Systems
서강대학교
전자공학과
1) General-purpose Processor
a. User-programmable
b. Diverse applications
c. Must provide powerful
programming environment
d. Flexible
e. Platform
• Powerful processor
• OS developed to manage all
resources efficiently
• Higher utilization and less
waiting time desired
• Monopoly (eg. Pentium)
2) Special-purpose Processor
(Embedded Processor )
a.
b.
•
•
•
•
•
c.
Manufacturer-programmable
Dedicated applications
Mostly mobile
Has strict timing constraints
Tasks are periodic
Mostly embedded systems
Battery operation
Platform
• Application-oriented
processor
• Low power, Good UI, Fancy
features desired
• Many different processors
- Short TTM
- Powerful design aids needed
• Opportunities open
How many (µ- )processors
do you own?
Average individual in developed country owns
around 100 (µ-)processors
• Almost all are embedded
Maybe 10,000 processors/person by 2012!
(according to Moore’s Law)
Future Computing Infrastructure
What is an Embedded Computer?
A computer not used to run general-purpose programs,
but instead used as a component of a system. Usually,
user cannot change the computer program (except for
minor upgrades)
Example applications:
•
•
•
•
•
•
•
•
•
Cellphone
Digital camera (some have several processors)
Games machines
Set-top boxes (DVD players, personal video recorders, ...)
Digital Televisions
Car (some have dozens of processors)
Routers
Cellphone basestation
.... many more
Cars
Modern cars: Up to 100 or
more processors
• Engine control unit
• Emissions control
• Diagnostics
• Automatic transmission
• Accessories (doors,
windows, etc)
• CAN
http://www.howstuffworks.com/car-computer.htm
Important Parameters for
Embedded Computers
Real-time performance
• hard real-time: if deadline misses, system fails
• soft real-time: missing deadline degrades
performance (e.g. skipping frames on DVD playback)
Real-world I/O performance
• Sensors/actuators require continuous I/O (can’t
batch process)
Power
- expensive package and cooling affects cost, system size,
weight
Cost
• includes cost of supporting structures, particularly
memory
• static code size very important (cost of ROM/RAM)
• millions of copies (worth engineer time to optimize
cost down)
Performance ?
• Throughput, latency, power, area
Performance in Throughput
Which is best for desktop performance?
Which is best for hard real-time task?
Power versus Energy
Energy measured in Joules
Power is energy consumption measured in Watts (Joules/second)
Battery Capacity Measured in Joules
– 720 Joules/gram for Lithium Ion batteries
– 1 instruction on Intel XScale takes ~1nJ
System A has higher peak power, but lower total energy
System B has lower peak power, but higher total energy
Reducing Switching Power
Power = α * CV2 * frequency
Reduce activity factor α
Reduce switched capacitance C
Reduce supply voltage V
Reduce frequency
Reducing Activity
Clock Gating
• don’t clock f/fs if not needed
• avoids transitioning downstream logic
• Pentium-4 has hundreds of gated clocks
Bus Encodings
• choose encodings that minimize transitions on
average (e.g., Gray code for address bus)
• compression schemes (move fewer bits)
Remove Glitches
• balance logic paths to avoid glitches during
settling
• use monotonic logic (Domino)
Reducing Switched Capacitance
Reduce switched capacitance C
•
•
•
•
Different logic styles (logic, pass transistor, dynamic)
Careful transistor sizing
Tighter layout
Segmented structures
Reducing Supply Voltage/Frequency
Quadratic savings in energy per transition – Big
effect
• Circuit speed is reduced
• Must lower clock frequency to maintain
correctness
Doesn’t save energy, just reduces rate at which it
is consumed
- Some saving in battery life from reduction in rate
of discharge
Voltage Scaling for Reduced Energy
Reducing supply voltage by 0.5 improves energy
per transition by 0.25
Performance is reduced – need to use slower
clock
Can regain performance with parallel
architecture
Alternatively, can trade surplus performance for
lower energy by reducing supply voltage until
“just enough” performance
Dynamic Voltage Scaling
“Just Enough” Performance
Save energy by reducing frequency and voltage to
minimum necessary (usually done in O.S.)
Types of Embedded Processor
General Purpose Processors
- often too expensive, hot, unpredictable, and require too
much support logic for embedded applications
Microcontroller
• emphasizes bit-level operations and control-flow
intensive operations (a programmable state machine)
• usually includes on-chip memories and I/O devices
DSP (Digital Signal Processor)
- organized around a multiply-accumulate engine for
digital signal processing applications
FPGA (Field Programmable Gate Array)
- reconfigurable logic can replace processors/DSPs for
some applications
New Forms of
Domain-Specific Processor
Network processor
• arrays of 8-16 simple multi-threaded processor cores
•
on a single chip used to process Internet packets
used in high-end routers
Media processor
• conventional RISC or VLIW engine extended with
•
media processing instructions (SIMD or Vector)
used in set-top boxes, DVD players, digital cameras
Programming Embedded Computers
Microcontrollers, DSPs, network processors,
media processors usually have complex, nonorthogonal instruction sets with specialized
instructions and special memory structures
• poor compiled code quality
(% peak with compiled code)
• high static code efficiency
• high MIPS/$ and MIPS/W
• usually assembly-coded in critical loops
Worth one engineer year in code development to
save $1 on system that will ship 1M units
Assembly coding easier than ASIC chip design
But, room for improvement…
Embedded Systems
Embedded systems
• ‘A special-purpose processor built into a larger
device’
‘Special-purpose’
• Embedded systems have a (more or less) welldefined purpose
‘Built into a larger device’
• ESs are (usually) part of a larger system (with
limited peripherals), augmenting its capabilities
Application-specific
• Both hardware and software is tailored to
applications, which are well defined
• However, re-programmability is a requirement
• ‘HALT’ is a bad state!
Interaction with the physical world
Embedded Systems in today’s world
Signal processing systems
- Real-time video, set-top boxes, DVD players,
medical equipment, residential gateways
Distributed control
- Network routers, switches, firewalls, mass transit
systems, elevators
“Small” systems
1.Mobile phones, home appliances, toys,
smartcards, MP3, PDAs, digital cameras, sensors,
smart badges
Pervasive/Ubiquitous computing <=
Embedded systems
Ubiquitous Sensor Network/RFID
Small (and cool) SoCs
SPEC: one step closer to “Smart Dust” ㅡ
Mote for Ubiquitous Sensor Network
• 2mm x 2.5 mm
• AVR-like RISC core
• 3k RAM
• 8-bit ADC
• FSK radio transceiver
• Paged memory system
• Lots of other cool stuff…
Manufacturing cost
• $ 0.3 for die
• $ 0.5 for the five external
components (antenna, crystals,
power source etc)
Constraints
Hardware
•
•
•
•
Processor, Memory
Power consumption
Limited peripherals and slower buses
Size, weight, environmental reliability
Software
•
•
•
•
Latency : ‘Hard’ or ‘Soft’ Real-time requirements
Limited HW resources
Reliability : Not very easy to debug
Device heterogeneity
- Interoperability becomes an issue!
Embedded System Hardware
Commercial off-the-shelf components (COTS)
• wireless radios, sensors, I/O devices
• Cheap
Application-Specific ICs (ASICs)
• ICs tailored to meet application needs
• Good performance for their intended task(s)
• Original ESs were ASICs only
Domain-specific processors
• DSPs
• Microcontrollers
• Microprocessors
New trends in ES H/W
Systems-on-chip
• Usual (or desired) specs:
•
•
•
•
•
•
32-bit RISC CPU
Built-in interfaces to RAM and ROM
Built-in DMA, interrupt and timing controllers
Built-in interfaces to disk or flash memory
Built-in Ethernet/802.11 interfaces
Built-in LCD/CRT interfaces
• New SoCs appearing almost every week!
Embedded Software
Principal role:
- ‘Not transformation of data but interaction with
physical world’
Acquires properties of physical world
• Takes time
• Consumes power
• Does not terminate (unless it fails)
Problems with Embedded Software
Vast majority written by people who are not computer scientists
• Challenge for CS: inventing better abstractions for the
domain experts to do their job
• Domain experts are skeptical
• ‘They see Java programs stalling for 1/3 second to perform
garbage collection and update the UI and envision
airplanes falling out of the sky’
The methods used in general-purpose software require
considerable adaptation
- Perhaps new abstractions are needed
Embedded Software Properties
Timeliness
Concurrency
Liveness
Interfaces
Reactivity
Heterogeneity
Timeliness
Time: systematically removed from theories of
computation
RTOSes often reduce the characterization of a task
to a single number (its priority)
Computation does take time
• Even with infinitely fast computers, time would still
•
have to be dealt with
Physical processes evolve over time
Need to find abstractions that regain control of
time!
Concurrency
In the physical world, multiple things happen at once
Challenge: reconcile sequentiality of software with
the concurrency of the real world
• Classic approaches (semaphores, monitors etc)
provide good foundation ? potentially insufficient
• One approach: compile concurrency away (Estrel)
- Estrel: synchronous/reactive language,
FSM based, deterministic behavior
- Pros: Highly reliable programs
- Cons: Too static for some systems
• Middle ground is needed
Liveness
Programs must not terminate
• Unlike the traditional Turing model of
computation, halting is undesirable
• Deadlock is an absolute ‘no-no’
Correctness isn’t just about getting the right final
answer
- Must consider things like timing, power
consumption, fault recovery, security and
robustness
Reactivity
Interactive systems:
- React at their own speed (or the speed of controlling
human)
Transformational systems
- Transform a data input to a data output
Reactive systems
• React continuously with environment, at the same speed
• Must adapt to changing conditions
- Resources and demands may change frequently
• Real-time constraints
• Safety-critical
- Fault-tolerance can be a major issue
Embedded Operating Systems
Office-style OSes
• PalmOS
• WindowsCE
• iOS
RTOSes
• VxWorks
• QNX
Linux
• Linux is already ubiquitous
• Hundreds of different devices are using it
• Several variations – from ‘soft real time’ to ‘hard real
time’
• Numerous commercial + open source products
Others
- TinyOS
* iOS for iPhone
1. Core OS Layer (Framework)
Free BSD-based UNIX
✓ Can use Standard Unix Functions
✓ Can use POSIX Functions
2. Core Service
✓ Core Foundation & Foundation
✓ Core Location
✓ Core Data
✓ Address Book
✓ Store Kit
3. Media
✓ Core Graphics
✓ Audio Toolbox
✓ Audio Unit
✓ AVFoundation
✓ OpenAL
4. Cocoa Touch
✓ 아이폰OS에서 최상위 레벨의 레이어
✓ UIKit Framework 화면표시 담당
✓ Foundation는 큰 수정 없이 아이폰에 적용
Cocoa
Cocoa Touch
AppKit
NSView NSTableView
NSButton
UIKit
UIView UITableView
UIButton
Foundation
NSString NSThread
NSArray
Foundation
NSString NSThread
NSArray
Typical Scheduling Techniques
in Embedded OS
Cyclic executive
• Static schedulability analysis : result used at
runtime
• Great for periodic tasks but inflexible
Event-driven non-preemptive
• Tasks represented by functions (event handlers)
• FIFO
• Safe, but limited
Scheduling (cont’d)
Static/dynamic priority preemptive scheduling
• Static schedulability analysis
• No explicit schedule: at run-time execute
highest priority task first
1. Rate/deadline monotonic (RM),
2. Earliest deadline first (EDF),
3. Least slack (EARSS)
• Flexible, but potentially dangerous
- Priority inversion
- Deadlock
Scheduling (cont’d)
Dynamic planning-based scheduling
• Schedulability checked at runtime for a
dynamically arriving task
- Resulting schedule decides when to execute
- If scheduling fails, take alternative action
• Flexible and fairly predictable
Dynamic best-effort scheduling
• No checks
- No knowledge if timing constraints met
until task finishes (or deadline expires)
• System tries to meet deadlines
- Tasks can be preempted at any time
Which OS to choose?
Depends on the device and the task(s) it needs to
perform
You might even want to build your own
There are cases when an embedded OS is not
needed at all!
• Sometimes all that’s needed is an infinite loop
with a couple of interrupt handlers
• “Getting by without an RTOS”