EC8791 EMBEDDED AND REALTIME SYSTEMS.pptx

EC8791
EMBEDDED AND REAL TIME
SYSTEMS
Mr.Renswick.S
Assistant Professor,
Dept of ECE
JCTCET

UNIT I
INTRODUCTION TO EMBEDDEDSYSTEM DESIGN
Complex systems and micro processors– Embedded system design process –
Design example: Model train controller- Design methodologies- Design flows
– Requirement Analysis – Specifications-System analysis and architecture
design – Quality Assurance techniques - Designing with computing platforms
– consumer electronics architecture –platform-level performance analysis.

Today’s Lecture
 What is the embedded system?
An embedded system is one that has
computer-hardware with software
embedded in it as one of its most important
component.
An embedded system has three main components
Hardware ,Application software andRTOS

Block diagram of Embedded System

COMPLEX SYSTEMS AND
MICROPROCESSORS
 Embedding Computers
 Characteristics of Embedded
Computing Applications
 Why use microprocessors?
 Challenges in Embedded Computing
System Design
 Performance in Embedded Computing

Embedding Computers
 Embedded Systemsare
everywhere
 Ubiquitous, invisible
 Hidden (computer inside)
 Dedicated purpose
 MicroProcessor
 Intel: 4004, ..8080,.. x86
 Freescale: 6800, .. 9S12,..
PowerPC
 ARM, DEC, SPARC, MIPS,
PowerPC, Natl. Semi.,…
 MicroController
 Processor+Memory+
I/O Ports(Interfaces)
I/O Ports
Electrical,
mechanical,
chemical,
or
optical
devices
Embedded system
Bus ADC
Analog
signals
Microcontroller LM3S orTM4C
DAC
Processor
RAM
ROM
Medical
Automotive
Communications
Comsumer Industrial
Military

Early History
 Late 1940’s: MIT Whirlwind computer was designed for real-
time operations.
 Originally designed to control an aircraft simulator.
 First microprocessor was Intel 4004 in early1970’s.
 HP-35 calculator used several chips to implement a
microprocessor in 1972.
 Automobiles used microprocessor-based engine controllers
starting in 1970’s.
 Controlfuel/air mixture, engine timing, etc.
 Provides lower emissions, betterfuel efficiency.

A Short List of Embedded Systems
Anti-lock brakes
Auto-focus cameras
Automatic teller machines
Automatic toll systems
Automatic transmission
Avionic systems
Battery chargers
Camcorders
Cell phones
Cell-phone basestations
Cordless phones
Cruise control
Curbside check-in systems
Digital cameras
Disk drives
Electronic card readers
Electronic instruments
Electronic toys/games
Factory control
Fax machines
Fingerprint identifiers
Home security systems
Life-support systems
Medical testingsystems
Modems
MPEG decoders
Network cards
Network switches/routers
On-board navigation
Pagers
Photocopiers
Point-of-sale systems
Portable video games
Printers
Satellite phones
Scanners
Smart ovens/dishwashers
Speech recognizers
Stereo systems
Teleconferencing systems
Televisions
Temperature controllers
Theft tracking systems
TV set-top boxes
VCR’s, DVD players
Video game consoles
Video phones
Washers anddryers

An Application Example: Digital Camera
Digital Camera Block Diagram

Components of Embedded Systems
Analog Digital Analog
Coprocessors
Converters
Processor
Memory Controllers Interface
Software
(Application Programs)
ASIC

Components of Embedded Systems
 Analog Components
 Sensors, Actuators, Controllers, …
 Digital Components
 Processor, Coprocessors
 Memories
 Controllers, Buses
 Application Specific Integrated Circuits(ASIC)
 Converters – A2D, D2A,…
 Software
 Application Programs
 Exception Handlers

Automotive Embedded Systems
 Today’s high-end automobile may have 100
microprocessors:
 4-bit microcontroller checks seat belt;
 microcontrollers run dashboard devices;
 16/32-bit microprocessor controls engine.
 Customer’s requirements
 Reduced cost
 Increased functionality
 Improved performance
 Increased overall dependability

BMW 850i Brake and Stability Control
System
 An antilock brake system (ABS) reduces skidding by
pumping the brakes.
 An automatic stability control Plus Traction (ASC + T)
system intervenes with the engine during drive to
improve the car’sstability
 the ASC + T is integrated with the ABS functions.
There is a single electronic control unit (with more
processing power than an ABS-only unit), and the
same four spinning toothed rings with magnetic
pickups to determine individual wheel speeds.

System
 The purpose of an ABS is to temporarily release the brake on a wheel when it
rotates too slowly—when a wheel stops turning, the car starts skidding and
becomes hard to control. It sits between the hydraulic pump, which provides
power to the brakes, and the brakes themselves as seen in the diagram. This
hookup allows the ABS system to modulate the brakes in order to keep the
wheels from locking. The ABS system uses sensors on each wheel to measure
the speed of the wheel. The wheel speeds are used by the ABS system to
determine how to vary the hydraulic fluid pressure to prevent the wheels from
skidding.
 The hydraulic control unit has four channels. The ABS-only unit has three
channels,only one for both rear wheels. Separate rear channels are required
for individual control of rear wheel spin. (ASC + T system has even better
braking performance).
 ABS has to control the braking force at all four wheels. ASC + T has to control
the power delivery of the engine, and the way the rear differential distributes
torque between the two back wheels.

 The ASC + T control unit has a high-speed (CAN) data link to themain
engine control unit, and has control of a throttle actuator motor. This
allows it to reduce engine power.
 There is a dashboard switch that allows the ASC + T to be disabled (but
the ABS functions remain active).
 The ASC + T system determines that a wheel is spinning by comparing
the rear wheels' speed to the front. Also, there is probably a maximum
wheel acceleration threshold built into thesystem.
 The ASC + T system intervenes in two stages: When it detects one rear
wheel near the threshold of adhesion, it starts to rapid pulse the brake to
that wheel (just like ABS). When the second rear wheel nears the limitof
adhesion, engine power is reduced.
 The first stage (single wheel braking) actually improvesvehicle
performance. The second stage is reducing engine power.
System

BMW 850i, cont’d.
brake
sensor
brake
sensor
brake
sensor
brake
sensor
ABS
hydraulic
pump

Characteristics of Embedded Systems
 Very high performance, sophisticated functionality
 Vision + compression + speech + networking all on the same
platform.
 ComplexAlgorithms
 User Interfaces
 Multiple task, heterogeneous.
 Real-time.
 Often low power.
 Low manufacturing cost..
 Highly reliable.
 I reboot my piano every 4 months, my PC every day.
 Designed to tight deadlines by small teams.

Why Use Microprocessors?
 Alternatives: field-programmable gate arrays
(FPGAs), custom logic, application specific
integrated circuit (ASIC), etc.
 Microprocessors are often very efficient: can use
same logic to perform many different functions.
 Microprocessors simplify the design of families of
products.

 Two factors that work together to make
microprocessor-based designs fast
 First, microprocessors execute programs very
efficiently. While there is overhead that must
be paid for interpreting instructions, it can often
be hidden by clever utilization of parallelism
within the CPU
 Second, microprocessor manufacturers spend
a great deal of money to make their CPUs run
very fast.

 Performance
 Microprocessors use much more logic to implement a
function than does custom logic.
 But microprocessors are often at least as fast:
 heavily pipelined;
 large design teams;
 aggressive VLSI technology.
 Power consumption
 Custom logic is a clear winner for low power devices.
 Modern microprocessors offer features to help control power
consumption.
 Software design techniques can help reduce power
consumption.
 Heterogeneous systems: some custom logic for well-defined
functions, CPUs+ software for everything else.

Microprocessor Varieties
 Microcontroller: includes I/O devices, on-board
memory.
 Digital signal processor (DSP): microprocessor
optimized for digital signal processing.
 Typical embedded word sizes: 8-bit, 16-bit, 32-bit.

Microprocessor Varieties
 4-bit, 8-bit, 16-bit, 32-bit :
 8-bit processor : more than 3 billion new chips per year
 32-bit microprocessors : PowerPC, 68k, MIPS, and
ARM chips.
 ARM-based chips alone do about triple the volume that
Intel and AMD peddle to PC makers.
 Most (98% or so) 32-bit processors are used in
embedded systems, not PCs.
 RISC-type processor owns most of the overall
embedded market [MPF: 2002].

Platforms
 Embedded computing platform: hardware
architecture + associated software.
 Many platforms aremultiprocessors.
 Examples:
 Single-chip multiprocessors for cell phone baseband.
 Automotive network +processors.

The physics of software
 Computing is a physical act.
 Software doesn’t do anything without hardware.
 Executing software consumes energy, requires
time.
 To understand the dynamics of software (time,
energy), we need to characterize the platform on
which the software runs.

Challenges in Embedded Computing System Design
 How much hardware do we need?
How big is the CPU? Memory?
more hardware - capabilities -more money
 How do we meet deadlines?
Faster hardware or cleverer software
 How do we minimize power consumption?
Turn off unnecessary logic
Reduce memory accesses
Run at slower clock rate

Challenges in Embedded Computing
System Design
 Does it really work?
Is the specification correct?
Does the implementation meet the specification?
How do we test for real-time characteristics?
How do we test on real data?
 How do we work on thesystem?
Observability and controllability
What is our development platform?

What does “Performance” mean?
 In general-purpose computing, performance often
means average-case, may not be well-defined.
 In real-time systems, performance means
meeting deadlines.
 Missing the deadline by even a little is bad.
 Finishing ahead of the deadline may not help.

Characterizing performance
 We need to analyze the system at several levels
of abstraction to understand performance:
 CPU: microprocessor architecture.
 Platform: bus, I/O devices.
 Program: implementation, structure.
 Task: multitasking, interaction between tasks.
 Multiprocessor: interaction between processors.

Design methodologies
 A procedure for designing a system.
 Understanding your methodology helps you
ensure you didn’t skip anything.
 Compilers, software engineering tools, computer-
aided design (CAD) tools, etc., can be used to:
 help automate methodology steps;
 keep track of the methodology itself.

Design goals
 Performance.
 Overall speed, deadlines.
 Functionality and user interface.
 Manufacturing cost.
 Power consumption.
 Other requirements (physical size, etc.)

Levels of abstraction
requirements
specification
architecture
component
design
system
integration

Top-down vs. bottom-up
 Top-down design:
 start from most abstract description;
 work to most detailed.
 Bottom-up design:
 work from small components to big system.
 Real design uses both techniques.

Stepwise refinement
 At each level of abstraction, we must:
 analyze the design to determine characteristics
of the current state of the design;
 refine the design to add detail.

Requirements
 Plain language description of what the user
wants and expects to get.
 May be developed in several ways:
 talking directly to customers;
 talking to marketing representatives;
 providing prototypes to users for comment.

Functional vs. non-functional requirements
 Functional requirements:
 output as a function of input.
 Non-functional requirements:
 time required to computeoutput;
 size, weight, etc.;
 power consumption;
 reliability;
 Performance -Speed
 Cost – Manufacturing Cost andNonrecurring
Engineering Cost

Our requirements form
name
purpose
inputs
outputs
functions
performance
manufacturing cost
power
physical size/weight

Example: GPS moving map requirements
 Moving map
obtains position
from GPS, paints
map from local
database.
lat: 40 13 lon: 32 19
I-78
Scotch
Road

GPS moving map needs
 Functionality: For automotive use. Show major
roads and landmarks.
 User interface: At least 400 x 600 pixel screen.
Three buttons max. Pop-up menu.
 Performance: Map should scroll smoothly. No
more than 1 sec power-up. Lock onto GPS within
15 seconds.
 Cost: $120 street price = approx. $30 cost of
goods sold.

GPS moving map needs, cont’d.
 Physical size/weight: Should fit in hand.
 Power consumption: Should run for 8 hours
on four AA batteries.

GPS moving map requirements form
name
purpose
inputs
outputs
functions
performance
manufacturing cost
power
physical size/weight
GPS moving map
consumer-grade
moving map for driving
power button, two
control buttons
back-lit LCD 400 X 600
5-receiver GPS; three
resolutions; displays
current lat/lon
updates screen within
0.25 sec of movement
$100 cost-of-goods-
sold
100 mW
no more than 2: X 6:,
12 oz.

Specification
 A more precise description of the system:
 should not imply a particular architecture;
 provides input to the architecture design
process.
 May include functional and non-functional
elements.
 May be executable or may be in
mathematical form for proofs.

GPS specification
 Should include:
 What is received from GPS;
 map data;
 user interface;
 operations required to satisfy user requests;
 background operations needed to keep the
system running.

Architecture design
 What major components go satisfying the
specification?
 Hardware components:
 CPUs, peripherals, etc.
 Software components:
 major programs and their operations.
 Must take into account functional and non-
functional specifications.

GPS moving map block diagram
GPS
receiver
search
engine renderer
user
interface
database
display

GPS moving map hardware
architecture
GPS
receiver
CPU
panel I/O
display frame
buffer
memory

GPS moving map software architecture
position database
search renderer
timer
user
interface
pixels

Designing hardware and software components
 Must spend time architecting the system before
you start coding.
 Some components are ready-made, some can
be modified from existing designs, others must be
designed from scratch.

System integration
 Put together thecomponents.
 Many bugs appear only at this stage.
 Have a plan for integrating components to
uncover bugs quickly, test as much functionality
as early as possible.

Summary
 Embedded computers are all around us.
 Many systems have complex embedded
hardware and software.
 Embedded systems pose many design
challenges: design time, deadlines, power,
etc.
 Design methodologies help us manage the
design process.

⦿ Top down Design or Stepwise Refinement: This starts from the
end solution and works backwards, refining each step along the
way.
⦿ Bottom Up Design: This methodology starts with a foundation
and works up towards a solution.
⦿ Structured Design: This is an industry standard. The technique
starts by identifying inputs and desired outputs to create a
graphical representation.
approach
system's
⦿ Structured Analysis and Design Technique: This
utilizes a diagram to describe the hierarchy of a
functions.
⦿ Data Structured Systems Development:Data structure
determines the system structure in this methodology.
⦿ Object Oriented Design: This methodology is based on a system
of interacting objects

⦿ The goal of a design process is to create a product that
does something useful to the society.
⦿ Functionality (e.g., cell phone),
⦿ Manufacturing cost (must have a retail price below
$200),
⦿ Performance (must power up within 3 s),
⦿ Power consumption (must run for 12 h on two AA
batteries) and
⦿ Time-to-market: Customers always want new features.
⦿ Design cost
⦿Quality

⦿Design flow: sequence of steps in a
design methodology.
⦿May be partially or fully automated.
• Use tools to transform, verify design.
⦿Design flow is one component of
methodology. Methodology also includes
management organization, etc.

⦿Early model for software development:
requirements
coding
testing
maintenance
entails deployment in the field, bug fixes,
and upgrades.
exercise and uncovers bugs
decomposes the functionality into major
components
architecture
implements the pieces
and integrates them
determines the basic characteristics of the
system

⦿Only local feedback---may need
iterations between coding and
requirements
⦿Doesn’t integrate top-down and bottom-
up design.
⦿it is an unrealistic design process

system feasibility
specification
prototype
initial system
enhanced system
design requirements
test

⦿Successive refinement of system.
• Start with mock-ups(proto type), move through
simple systems to full-scale systems.
⦿Provides bottom-up feedback from
previous stages.
⦿Working through stages may take too
much time.

specify
architect
design
build
test
initial system
specify
architect
design
build
test
refined system

requirements and
specification
architecture
hardware design software design
integration
testing

⦿Must architect hardware and software
together:
• provide sufficient resources;
• avoid software bottlenecks.
⦿Can build pieces somewhat
independently, but integration is major
step.
⦿Requires bottom-up feedback.

⦿Embedded systems must be designed
across multiple levels of abstraction:
• system architecture;
• hardware and software systems;
• hardware and software components.
⦿Often need design flows within design
flows.

⦿Large projects use many people from
multiple disciplines.
⦿Work on several tasks at once to reduce
design time.
⦿Feedback between tasks helps improve
quality, reduce number of later design
problems.

⦿Cross-functional teams - including manufacturing,
hardware and software design,marketing
⦿Concurrent product realization - designing various
subsystems simultaneously
⦿ Incremental information sharing - helps minimize the
chance
⦿ Integrated product management - ensures that someone
is responsible for the entire project
⦿ Supplier involvement - make the best use of suppliers’
capabilities.
⦿ Customer focus - ensure that the product best meets
customers’needs.

⦿ Requirements: informal description of what
customer wants.
⦿ Specification: more detailed, precise, and
consistent descriptions of the system that can
be used to create the architecture .
⦿The overall goal of creating a requirements
document is effective communication between
the customers and the designers.

⦿Functional: input/output relationships.
⦿Non-functional:
• timing;
• power consumption;
• manufacturing cost;
• physical size;
• time-to-market;
• reliability.

⦿C orrectness
⦿Unambiguousness
⦿Completeness
⦿Verifiable: is each requirement satisfied
in the final system?
⦿Consistent: requirements do not
contradict each other.

⦿Modifiable: can update requirements
easily.
⦿Traceable:
• know why each requirement exists;
• go from source documents to requirements;
• go from requirement to implementation;
• back from implementation to requirement.

⦿Customer interviews.
⦿Comparison with competitors.
⦿Sales feedback.
⦿Mock-ups,prototypes.
⦿Next-bench syndrome (HP): design a
product for someone like you.

⦿C apture functional and non-functional
properties:
• verify correctness of spec;
• compare spec to implementation.
⦿Many specification styles:
• control-oriented vs. data-oriented;
• textual vs.graphical.
⦿UML is one specification/design
language.

⦿Used in
telecommunications
protocol design.
⦿ Event-oriented state
machine model.
telephone
on-hook
dial tone
caller goes
off-hook
caller gets
dial tone

⦿Statecharts are used to describe the behaviour of a
system and describe all of the possible states of an
object as events acting upon it.The Statechartnotation
uses an event-driven model.
⦿Ancestor of UML state diagrams.
⦿Provided composite states:
• OR states;
• AND states.
⦿Composite states reduce the size of the state transition
graph.
⦿ Statecharts are useful for describing large,complex,
reactive systems

⦿Use statecharts for classes where it is necessary to
understand the behaviour of the object through the
entire system.
⦿Not all classes will require a statechart, and there aren’t
useful for describing the collaboration of all objects in
a use case.
⦿ Statecharts are combined with other diagrams such as
interaction diagrams and activity diagrams

⦿ States: they’re represented by rounded boxes and show the state of the
object. The arrow between states indicates the transition.
⦿ All the diagrams begin with a“start state”and ends with a“final state”.
Transition: they’re represented by an
arrow from one to other state.

⦿ -> And-states: Have orthogonal components that are related by
“and”. They’re represented graphically as rounded rectangles
(parent state) divided by dashed lines
⦿-> Or-states: This is, if the state of the high level is active, only one
of the internal states will be active.

⦿Well-known method for analyzing a system and
developing an architecture.
⦿ It encourages the encapsulation of data and functions
⦿CRC:A Class Responsibility Collaborator (CRC) model
is a collection of standard index cards that have been
divided into three sections
• Classes;
• Responsibilities of each class;
• Collaborators are other classes that work with a
class.
⦿Team-oriented methodology.

Class name:
Superclasses:
Subclasses:
Responsibilities: Collaborators:
Class name:
Class’s function:
Attributes:
back
Classes define the logical groupings of data and functionality
front
Responsibilities describe what the classes do
Collaborators are the other classes with which a given class works

⦿Develop an initial list of classes.
• Simple description is OK.
• Team members should discuss their choices.
⦿Write initial
responsibilities/collaborators.
• Helps to define the classes.
⦿C reate some usage scenarios.
• Major uses of system and classes.

⦿Walk through scenarios.
• See what works and doesn’t work.
⦿Refine the classes, responsibilities,and
collaborators.
⦿Add class relatoinships:
• superclass, subclass.

⦿Real-world classes:
• elevator car,passenger,floor control,car control,
car sensor.
⦿Architectural classes: car state,floor
control reader, car control reader,car
control sender,scheduler.

class responsibilities collaborators
Elevator car* Move up and down Car control, car
sensor, car control
sender
Car control*
Car state
Transmits car
requests
Reads current
position of car
Passenger
, floor
control reader
Scheduler
, car
sensor

DESIGNING WITH
COMPUTING PLATFORMS
Designing with microprocessors.
Development and debugging.
System-level performance analysis.

System architectures
Architectures and components:
software;
hardware.
Some software is very hardware-
dependent.

Hardware platform
architecture
Contains several elements:
CPU;
bus;
memory;
I/O devices: networking, sensors,
actuators, etc.
How big/fast much each one be?

Software architecture
Functional description must be broken into
pieces:
division among people;
conceptual organization;
performance;
testability;
maintenance.

Hardware and software
architectures
Hardware and software areintimately
related:
software doesn’t run without hardware;
how much hardware you need is
determined by the software requirements:
speed;
memory.

Evaluation boards
Basic Platform chip and a variety ofI/O
Devices
Designed by CPU manufacturer orothers.
Includes CPU, memory, some I/O devices.
May include prototyping section.
CPU manufacturer often gives out
evaluation board netlist---can be usedas
starting point for your custom board
design.

Beegle board
open source platform is used to develop a
low-cost board for embedded systems. This
board consists of ARM Cortex TM –A8
processor, several built-in I/O devices and
many connectors (flash memory, video and
audio). It is primarily intended to support
software development and serve as a
starting point for a product design

Adding logic to a board
Programmable logic devices (PLDs)
provide low/medium density logic.
Field-programmable gate arrays (FPGAs)
provide more logic and multi-level logic.
Application-specific integrated circuits
(ASICs) are manufactured for a single
purpose.

The PC as a platform
Advantages:
cheap and easy to get;
rich and familiar software environment.
Disadvantages:
requires a lot of hardware resources;
not well-adapted to real-time.
More power hungry
More expensive

Typical PC hardware
platform
CPU
CPU bus
memory
DMA
controller
timers
bus
interface
bus
interfac
e
high-speed bus
low-speed bus
device
device
intr
ctrl

Typical PC hardware
platform
 The CPU provides basic computational facilities.
 RAM is used for programstorage.
 ROM holds the boot program.
 A DMA controller provides DMA capabilities.
 Timers are used by the operating system for a variety of purposes.
 A high-speed bus, connected to the CPU bus through a bridge,
allows fast devices to communicate efficiently with the rest ofthe
system.
 A low-speed bus provides an inexpensive way to connectsimpler
devices and may be necessary for backward compatibility aswell.

Typical busses
PCI: standard for high-speed interfacing
33 or 66 MHz.
PCI Express.
USB (Universal Serial Bus), Firewire (IEEE
1394): relatively low-cost serial interface
with high speed.

Software elements
IBM PC uses BIOS (Basic I/O System) to
implement low-level functions:
boot-up;
minimal device drivers.
BIOS has become a generic term forthe
lowest-level system software.

Example: StrongARM
StrongARM system includes:
CPU chip (3.686 MHz clock)
system control module (32.768 kHz clock).
• Real-time clock;
• operating system timer
• general-purpose I/O;
• interrupt controller;
• power manager controller;
• reset controller.

Host/target design
Use a host system to prepare software for
target system:
target
system
serial line
host system

Host-based tools
Cross compiler:
compiles code on host for target system.
Cross debugger:
displays target state, allows target system to
be controlled.

Software debuggers
A monitor program residing on the target
provides basic debugger functions.
Debugger should have a minimal footprint in
memory.
User program must be careful not to destroy
debugger program, but , should be able to
recover from some damage caused by user
code.

Debugging Techniques
 The serial port (USB)- development debugging but also for
diagnosing problems in thefield.
 A breakpoint allows the user to stop execution, examine system
state, and change state and to specify an address at which the
program’s execution is to break
 LEDs can be used to show error conditions, when the code enters
certain routines, or to show idle timeactivity
 The microprocessor in-circuit emulator (ICE) is a specialized
hardware tool that can help debug software in a working embedded
system. Allows you to stop execution, examine CPU state, modify
registers.
 A logic analyzer is an array of low-grade oscilloscopes

Breakpoints
A breakpoint allows the user to stop
execution, examine system state, and change
state.
Replace the breakpointed instruction with a
subroutine call to the monitor program.

Breakpoint handler actions
Save registers.
Allow user to examine machine.
Before returning, restore system state.
Safest way to execute the instruction is to replace it and execute in place.
Put another breakpoint after the replaced breakpoint to allow restoring
the original breakpoint.

In-circuit emulation &
logic analyzer
*In-circuit emulation (ICE) is the use of a hardware device or in-
circuit emulator used to debug the software of an embedded system.
It operates by using a processor with the additional ability to support
debugging operations, as well as to carry out the main function of the
system.
*A logic analyzer is an electronic instrument that captures and displays
multiple signals from a digital system or digital circuit. A logic analyzer
may convert the captured data into timing diagrams, protocol
decodes, state machine traces, assembly language, or may correlate
assembly with source-level software. Logic analyzers have advanced
triggering capabilities, and are useful when a user needs to see the
timing relationships between many signals in a digital system

Logic analyzers
A logic analyzer is an arrayof low-grade
oscilloscopes:

Logic analyzer
architecture
UUT
sample
memory
microprocessor
controller
system clock
clock
gen
state or
timing mode
vector
address
display
keypad

Debugging Challenges
 Logical errors in software can be hard to track down, but errorsin
real-time code can create problems that are even harder to
diagnose.
 Real-time programs are required to finish their work within a
certain amount of time; if they run too long, they can create much
unexpected behavior.
 The exact results of missing real-time deadlines depend on the
detailed characteristics of the I/O devices and the nature of the
timing violation. This makes debugging real-time problems
especially difficult

Boundary scan
Simplifies testing of
multiple chips on a
board.
Registers on pins can
be configured as a
scan chain.
Used for debuggers,
in-circuit emulators.

How to exercise code
Run on host system.
Run on target system.
Run in instruction-level simulator.
Run on cycle-accurate simulator.
Run in hardware/software co-simulation
environment.

Debugging real-time code
Bugs in drivers can cause non-
deterministic behavior in the foreground
problem.
Bugs may be timing-dependent.

System-level performance
analysis (platform level)
Performance depends
on all the elements of
the system:
CPU.
Cache.
Bus.
Main memory.
I/O device.
memory
CPU
cache

Bandwidth as performance
Bandwidth applies to several components:
Memory.
Bus.
CPU fetches.
Different parts of the system run at
different clock rates.
Different components may have different
widths (bus, memory).

Bandwidth and data
transfers
Video frame: 320 x 240 x 3 = 230,400
bytes.
Transfer in 1/30 = 0.034 sec.
if Transfer 1 byte/sec, then
230400/1000000= 0.23 sec/ frame.
Too slow.
Increase bandwidth:
Increase bus width.
Increase bus clock rate.

Bus bandwidth (W)
T: # bus cycles.
P: time/bus cycle.
Total time for
transfer:
t = TP.
D: each data
payload length.
O1 + O2 = overhead
O.
N-Total no. of payload
O1 D O2
W
Tbasic(N) = (D+O)N/W

Bus burst transfer
bandwidth(Burst size=B)
T: # bus cycles.
P: time/bus cycle.
Total time for
transfer:
t = TP.
D: data payload
length.
O1 + O2 = overhead
O.
B O
W
burst
T (N) = (BD+O)N/(BW)
1 2
…

Memory aspect ratios (variable bus
width memories-select one based on application)
16 M
64 M
8 M
1 4 8

Memory access times
Memory component access times comes
from chip data sheet.
Page modes allow faster access for
successive transfers on same page.
If data doesn’t fit naturally into physical
Words, total no of access reqd to read
E data elements, each of w bits:
A = [(E/W)mod W]+1 and W is memory
width.

Bus performance bottlenecks
Transfer 320 x 240
video frame @ 30
frames/sec = 612,000
bytes/sec.
Is performance
bottleneck bus or
memory?
memory CPU

Bus performance
bottlenecks, cont’d.
Bus: assume 1 MHz bus, D=1, O=3:
Tbasic = (1+3)612,000/2 = 1,224,000 cycles = 1.224 sec.
Memory: try burst mode B=4, width w=0.5.
Tmem = (4*1+4)612,000/(4*0.5) = 2,448,000 cycles = 0.2448 sec.

Parallelism
Speed things up by
running several units
at once.
DMA provides
parallelism if CPU
doesn’t need the bus:
DMA + bus.
CPU.

Consumer electronics
architecture
A.Functional requirements:
1. Multimedia – mp3,mp4,mpeg,jpeg
2. data storage and management – PC compatible files
3. Communications – USB, Ethernet
B. Non-Functional requirements- Low power, Cheap, High
performance, Sophistication
C. Hardware architectures-RISC CPU, DSP
D.Operating systems-Processes, concurrency, dynamic
operation
E.DOS file systems - Small
F.Flash memory – Simple to Write/Delete

Consumer electronics use
cases
Multimedia: stored in
compressed form,
uncompressed on viewing.
Data storage and
management: keep track of
your multimedia, etc.
Communication: download,
upload, chat.

Non-functional requirements
for CE
Often battery-operated, strict power budget.,
Very inexpensive.
User interface must be capable but
inexpensive.

CE devices and hosts
Many devices talk to host
system.
PC host does things that are hard
to do on the device.
Increasingly, CE
devices communicate
directly over the
network, avoiding the
host for access.

Platforms and operating
systems
Many CE devices use a DSP for
signal processing and a RISC
CPU for other tasks.
I/O devices include buttons,
screen, USB.

Flash file systems
Flash is widely used for mass storage.
Flash wears out on writing (up to 1 million
cycles).
Directory is most often written, wears out first.
Flash file system has layer that moves
contents to levelize wear.
Hides wear leveling from API.

Cell phones
Most popular CE
device in history;
most widely used
computing device.
1 billion sold per year.
Handset talks to cell.
Cells hand off handset
as it moves.

Cell phone platforms
Today’s cell phones use analog
front end, digital baseband
processing.
Future cell phones will perform IF
processing with DSP.
Baseband processing in DSP:
Voice compression.
Network protocol.
Other processing:
Multimedia functions.
User interface.
File system.
Applications (contacts, etc.)

Quality Assurance Techniques
Quality management based on ISO 9000:
•Process is crucial. Haphazard development leads to haphazard products and low
quality. Knowing what steps are to be followed to create a high-quality product is
essential to ensuring that all the necessary steps are in fact followed.
• Documentation is important. Documentation has several roles: The creation
of the documents describing processes helps those involved understand the
processes; documentation helps internal quality monitoring groups to ensure that
the required processes are actually being followed; and documentation also helps
outside groups (customers, auditors, etc.) understand the processes and how they
are being implemented.
•Communication is important. Quality ultimately relies on people. Good
documentation is an aid for helping people understand the total quality process.
The people in the organization should understand not only their specific tasks but
also how their jobs can affect overall system quality.

Quality Assurance Techniques contd…
Capability Maturity Model (CMM) - five levels of maturity:
1.Initial. A poorly organized process, with very few well-defined
processes. Success of a project depends on the efforts of individuals,
not the organization itself.
2. Repeatable. This level provides basic tracking mechanisms
that allow management to understand cost, scheduling, and how well
the systems under development meet their goals.
3.Defined. The management and engineering processes are
documentedandstandardized. All projects make use of documented
and approved standard methods.
4. Managed. This phase makes detailed measurements of the
development process and product quality.
5.Optimizing. At the highest level, feedback from detailed
measurements is used to continually improve the organization’s
processes.

The longer a bug survives in the system, the more expensive it will be to fix. A
coding bug, if not found until after system deployment, will cost money to recall
and reprogram existing systems, among other things. But a bug introduced earlier
in the flow and not discovered until the same point will accrue all those costs and
more costs as well.

A design review team has several types of members:
•The designers of the component being reviewed are, of
course, central to the design process. They present their design
to the rest of the team for review and analysis.
• The review leader coordinates the pre-meeting activities, the
design review itself, and the post-meeting follow-up.
• The review scribe records the minutes of the meeting so that
designers and others know which problems need to be fixed.
•The review audience studies the component. Audience
members will naturally include other members of the project
for which this component is being designed. Audience members
from other projects often add valuable perspective
and may notice problems that team members have missed.

The audience should look for all types of problems
at every level of detail:
•Is the design team’s view of the component’s
specification consistent with the overall system
specification, or has the team misinterpreted
something?
• Is the interface specification correct?
•Does the component’s internal architecture work
well?
• Are there coding errors in the component?
• Is the testing strategy adequate?

© 2000 Morgan
Kaufman
Overheads for Computers as
Components 2nd ed.
Introduction
Example: model train controller.
Train on the rail track electrically powered
through rail track. (no overhead electrical
wire)
8 trains on the track controlled from a
single station on the ground (control box)
Electrical powersupply on the rail track is
modulated and commands are sent from
ground. (no wireless comm)

© 2008 Wayne Wolf
Components 2nd ed.
Purposes of example
Follow a design through several levels of
abstraction.
Gain experience with UML.

Console can control 8 trains on 1 track.
Throttle (to control speed of train) has at
least 63 levels.
Inertia control adjusts responsiveness of
train to given speed commands with at
least 8 levels.
Emergency stop button.
Error detection scheme on messages.
© 2008 Wayne Wolf Components 2nd ed.
Requirements

© 2008 Wayne Wolf
Components 2nd ed.
Requirements form
name
purpose
inputs
outputs
functions
performance
model train controller
control speed of <= 8 model trains
throttle, inertia, emergency stop,
train #
train control signals
set engine speed w. inertia;
emergency stop
can update train speed at least 10
times/sec
manufacturing cost $50
power
physical
size/weight
wall powered
console comfortable for 2 hands; < 2
lbs.

Digital Command Control
DCC created by model railroad hobbyists,
picked up by industry.
Defines way in which model trains,
controllers communicate.
Leaves many system design aspects open,
allowing competition.
This is a simple example of a big trend:
Cell phones, digital TV rely on standards.

DCC documents
Standard S-9.1, DCC Electrical Standard.
Defines how bits are encoded on the rails.
Standard S-9.2, DCC Communication
Standard.
Defines packet format and semantics.
© 2008 Wayne Wolf
Components, 2nd ed.

DCC electrical standard
Voltage moves
around the power
supply voltage; adds
no DC component.
1 is 58 s, 0 is at
least 100 s.
© 2008 Wayne Wolf
Components 2nd ed.
time
logic 1 logic 0
58 s >= 100 s

DCC communication
standard
Basic packet format: PSA(sD)+E.
P: preamble = 1111111111.
S: packet start bit = 0.
A: address data byte.
s: data byte start bit.
D: data byte (data payload).
E: packet end bit = 1.
© 2000 Morgan
Kaufman
Components

DCC packet types
Baseline packet: minimum packet that
must be accepted by all DCC
implementations.
Address data byte gives receiver address.
Instruction data byte gives basic instruction.
Error correction data byte gives ECC.
© 2008 Wayne Wolf
Components, 2nd ed.

© 2008 Wayne Wolf
Components 2nd ed.
Conceptual specification
Before we create a detailed specification,
we will make an initial, simplified
specification.
Gives us practice in specification and UML.
Good idea in general to identify potential
problems before investing too much effort in
detail.

© 2008 Wayne Wolf
Components 2nd ed.
Basic system commands
command name parameters
set-speed speed
(positive/negative)
inertia-value (non-
negative)
none
set-inertia
estop

© 2008 Wayne Wolf
Components 2nd ed.
Typical control sequence
:console :train_rcvr
set-inertia
set-speed
set-speed
estop
set-speed

© 2008 Wayne Wolf
Components 2nd ed.
Message classes
command
set-inertia
value: unsigned-
integer
set-speed
value: integer
estop

© 2008 Wayne Wolf
Components
Roles of message classes
Implemented message classes derived
from message class.
Attributes and operations will be filled in for
detailed specification.
Implemented message classes specify
message type by their class.
May have to add type as parameter to data
structure in implementation.

© 2008 Wayne Wolf
Components 2nd ed.
Subsystem collaboration
diagram
Shows relationship between console and
receiver (ignores role of track):
1..n: command
:console :receiver

© 2008 Wayne Wolf
Components 2nd ed.
System structure modeling
Some classes define non-computer
components.
Denote by *name.
Choose important systems at this point to
show basic relationships.

Console:
read state of front panel;
format messages;
transmit messages.
Train:
receive message;
interpret message;
control the train.
Major subsystem roles

© 2008 Wayne Wolf
Components 2nd ed.
Console system classes
1
1
1
1
console
1 1
formatter
panel
1 1
receiver*
transmitter
1 1
sender*

© 2008 Wayne Wolf
Components 2nd ed.
Console class roles
panel: describes analog knobs and
interface hardware.
formatter: turns knob settings into bit
streams.
transmitter: sends data on track.

© 2008 Wayne Wolf
Components 2nd ed.
Train system classes
1
1 motor
interface
1 1
pulser*
train set
1 1..t
train
1 1
controller
1
1
receiver
1 1
detector*

© 2008 Wayne Wolf
Components 2nd ed.
Train class roles
receiver: digitizes signal from track.
controller: interprets received commands
and makes control decisions.
motor interface: generates signals
required by motor.

© 2008 Wayne Wolf
Components 2nd ed.
Detailed specification
We can now fill in the details of the
conceptual specification:
more classes;
behaviors.
Sketching out the spec first helps us
understand the basic relationships in the
system.

© 2008 Wayne Wolf
Components 2nd ed.
Console physical object
classes
knobs*
train-knob: integer
speed-knob: integer
inertia-knob: unsigned-
integer
emergency-stop: boolean
pulser*
pulse-width: unsigned-
integer
direction: boolean
sender*
send-bit()
detector*
read-bit() : integer

© 2008 Wayne Wolf
Components 2nd ed.
Panel and motor interface
classes
panel
train-number() : integer
speed() : integer
inertia() : integer
estop() : boolean
new-settings()
motor-interface
speed: integer

© 2008 Wayne Wolf
Components 2nd ed.
Class descriptions
panel class defines the controls.
new-settings() behavior reads the controls.
motor-interface class defines the motor
speed held as state.

© 2008 Wayne Wolf
Components 2nd ed.
Transmitter and receiver
classes
transmitter
send-speed(adrs: integer,
speed: integer)
send-inertia(adrs: integer,
val: integer)
set-estop(adrs: integer)
receiver
current: command
new: boolean
read-cmd()
new-cmd() : boolean
rcv-type(msg-type:
command)
rcv-speed(val: integer)
rcv-inertia(val:integer)

© 2008 Wayne Wolf
Components 2nd ed.
Class descriptions
transmitter class has one behavior for
each type of message sent.
receiver function provides methods to:
detect a new message;
determine its type;
read its parameters (estop has no
parameters).

© 2008 Wayne Wolf
Components 2nd ed.
Formatter class
formatter
current-train: integer
current-speed[ntrains]: integer
current-inertia[ntrains]:
unsigned-integer
current-estop[ntrains]: boolean
send-command()
panel-active() : boolean
operate()

© 2008 Wayne Wolf
Components 2nd ed.
Formatter class
description
Formatter class holds state for each train,
setting for current train.
The operate() operation performs the
basic formatting task.

Use a soft panel to show current panel
settings for each train.
Changing train number:
must change soft panel settings to reflect
current train’s speed, etc.
Controlling throttle/inertia/estop:
read panel, check for changes, perform
command.
Control input cases

© 2008 Wayne Wolf
Components 2nd ed.
Control input sequence
diagram
:knobs :panel :formatter :transmitter
inertia/estop
change
in
change
in
speed/
train
number
change in
control
settings
read panel
panel settings
panel-active
send-command
send-speed,
send-inertia.
send-estop
read panel
panel settings
change in
train
number
set-knobs
read panel
panel settings
new-settings

© 2008 Wayne Wolf
Components 2nd ed.
Formatter operate
behavior
idle
update-panel()
send-command()
panel-active() new train number
other

© 2008 Wayne Wolf
Components 2nd ed.
Panel-active behavior
panel*:read-train()
current-train = train-knob
update-screen
changed = true
T
panel*:read-speed() current-speed = throttle
changed = true
T
F
...
F
...

© 2008 Wayne Wolf
Components 2nd ed.
Controller class
controller
current-train: integer
current-speed[ntrains]: integer
current-direction[ntrains]: boolean
current-inertia[ntrains]:
unsigned-integer
operate()
issue-command()

© 2008 Wayne Wolf
Components 2nd ed.
Setting the speed
Don’t want to change speed
instantaneously.
Controller should change speed gradually
by sending several commands.

© 2008 Wayne Wolf
Components 2nd ed.
Sequence diagram for set-
speed command
:receiver :controller :motor-interface :pulser*
new-cmd
cmd-type
rcv-speed set-speed set-pulse
set-pulse
set-pulse
set-pulse
set-pulse

© 2008 Wayne Wolf
Components 2nd ed.
Controller operate
behavior
issue-command()
receive-command()
wait for a
command
from receiver

© 2008 Wayne Wolf
Components 2nd ed.
Refined command classes
command
type: 3-bits
address: 3-bits
parity: 1-bit
set-inertia
type=001
value: 3-bits
set-speed
type=010
value: 7-bits
estop
type=000

© 2008 Wayne Wolf
Components 2nd ed.
Summary
Separate specification and programming.
Small mistakes are easier to fix in the spec.
Big mistakes in programming cost a lot of
time.
You can’t completely separate
specification and architecture.
Make a few tasteful assumptions.

EC8791 EMBEDDED AND REALTIME SYSTEMS.pptx

Recommended

Recommended

More Related Content

Similar to EC8791 EMBEDDED AND REALTIME SYSTEMS.pptx

Similar to EC8791 EMBEDDED AND REALTIME SYSTEMS.pptx (20)

Recently uploaded

Recently uploaded (20)

EC8791 EMBEDDED AND REALTIME SYSTEMS.pptx