Transcript Document

ECOE 560
Design Methodologies and Tools for
Software/Hardware Systems
Spring 2006
Serdar Taşıran
Outline of today’s lecture
 What is a software/hardware (embedded) system?
 Examples
 Characteristics
 The design problem
 Course outline
 Design automation methodologies and tools
 Levels of abstraction in design descriptions
2
ECOE 560, Spring 2006
Definition
 Embedded system: any device that includes a
programmable computer but is not itself a generalpurpose computer.
 Take advantage of application characteristics to optimize
the design:
 don’t need all the general-purpose bells and whistles.
3
ECOE 560, Spring 2006
Examples







4
Personal digital assistant (PDA).
Printer.
Cell phone.
Automobile: engine, brakes, dash, etc.
Television.
Household appliances.
PC keyboard (scans keys).
ECOE 560, Spring 2006
Example: BMW 850i brake and stability control system
 Anti-lock brake system (ABS): pumps brakes to reduce
skidding.
 Automatic stability control (ASC+T): controls engine to
improve stability.
 ABS and ASC+T communicate.
 ABS was introduced first---needed to interface to existing ABS
module.
5
ECOE 560, Spring 2006
BMW 850i, cont’d.
sensor
sensor
brake
brake
ABS
6
hydraulic
pump
brake
brake
sensor
sensor
ECOE 560, Spring 2006
Characteristics of embedded systems





7
Sophisticated functionality.
Real-time operation.
Low manufacturing cost.
Low power.
Designed to tight deadlines by small teams.
ECOE 560, Spring 2006
Functional complexity
 Often have to run sophisticated algorithms or multiple
algorithms.
 Cell phone, laser printer.
 Often provide sophisticated user interfaces.
8
ECOE 560, Spring 2006
Real-time operation
 Must finish operations by deadlines.
 Hard real time: missing deadline causes failure.
 Soft real time: missing deadline results in degraded
performance.
 Many systems are multi-rate: must handle operations at
widely varying rates.
9
ECOE 560, Spring 2006
Non-functional requirements
 Many embedded systems are mass-market items that
must have low manufacturing costs.
 Limited memory, microprocessor power, etc.
 Power consumption is critical in battery-powered
devices.
 Excessive power consumption increases system cost even in
wall-powered devices.
10
ECOE 560, Spring 2006
Design teams
 Often designed by a small team of designers.
 Often must meet tight deadlines.
 6 month market window is common.
 Can’t miss back-to-school window for calculator.
11
ECOE 560, Spring 2006
Example: HP DesignJet drafting plotter
 Plots up to 36 inches wide at 300 DPI.
 Combines a variety of tasks:




12
host communication;
graphics language interpretation;
rasterization;
device control.
ECOE 560, Spring 2006
The plotting process
HP-GL/2
PostScript
rasterizer
raster memory
plotter
controller
13
ECOE 560, Spring 2006
Design considerations
 Memory utilization is important.
 36 inches x large x 300 DPI x n bits/pixel is a lot of memory.
 Requires clever algorithms to minimize raster memory
requirements.
 Requires real-time control.
 Requires concurrency: read new data, rasterize, control
print head.
14
ECOE 560, Spring 2006
HP DesignJet hardware architecture
i960KA
EEPROM
swath
RAM
pen
ctrl
ASIC
servo
proc.
(8052)
front panel
15
stepper
motor
carriage
PC board
adrs
latch
1 MB
ROM
bus
if
2 MB
DRAM
proc.
support
ASIC
DRAM
ctrl
||
if
RS422
ECOE 560, Spring 2006
Early architectural decisions
 Chose Intel 80960KA as main processor.
 Handled parsing, rasterization control, print engine control.
 Multiplexed bus reduced pin count.
 Could be upgraded to floating-point if necessary.
 Used modular I/O to host system.
 Did not use disk for local storage.
16
ECOE 560, Spring 2006
System components
 2 MB RAM (SIMM sockets for more).
 Three ASICs:
 pen interface;
 processor support;
 carriage.
 Servo processing performed by 8052 microcontroller.
17
ECOE 560, Spring 2006
Rasterization
 Plot is generated in swaths.
 Separate swath memory.
 Pixels are generated in row order by main processor.
 Pixels are fed to pens in column order.
 Pen interface ASIC transforms row order to column
order.
18
ECOE 560, Spring 2006
Data flows
parsing and rasterization
i960KA
adrs
latch
1 MB
ROM
bus
if
2 MB
DRAM
swath generation
EEPROM
servo
proc.
(8052)
front panel
19
pen
ctrl
ASIC
swath
RAM
drawing
stepper
motor
carriage
PC board
proc.
support
ASIC
DRAM
ctrl
||
if
RS422
ECOE 560, Spring 2006
Operations
 Servo processor controls stepper motor.
 Carriage processor must write, read pen alignment
marks.
 Processor support ASIC provides multiple functions:
interrupt and mailbox communication.
 Motion controller decodes position of print carriage and
paper; watchdogs servo.
20
ECOE 560, Spring 2006
Pen interface ASIC
 Interfaces to i960 bus, swath memory, carriage ASIC.
 Pen interface reads pixels from swath in predetermined
pattern using pixel address generator.
 Must support bidirectional printing since head prints both
ways.
21
ECOE 560, Spring 2006
Carriage ASIC
 Interfaces to carriage processor bus, pen interface ASIC,
servo controller.
 Reads timing control registers using the CPU bus.
 Delay registers add correction for pen alignment.
22
ECOE 560, Spring 2006
Development process
 Pixel shuffling algorithm for pen interface/carriage ASICs
was prototyped in C.
 Built emulators for ASICs to allow parallel development
of i960 software and hardware.
23
ECOE 560, Spring 2006
Software development environment
 Plotter software could be run on Unix workstation or
target platform.
 Differed in I/O and print engine subsystems.
 Print engine was emulated on host with X window interface
showing swath state.
 Used in-house RTOS.
 HP-GL/2 parser was legacy code.
24
ECOE 560, Spring 2006
Software development environment, cont’d.
 Rewrote vector/raster converter from assembly language
to C to port to i960.
 Used gdb960 as monitor debugger on target system,
communicating with host.
 Front panel developed on PC, tested by user interface
designers, marketing.
 Paper loading designed by mechanical engineers.
25
ECOE 560, Spring 2006
Outline of today’s lecture




26
What is a software/hardware (embedded) system?
Course outline
Design automation methodologies and tools
Levels of abstraction in design descriptions
ECOE 560, Spring 2006
Course Outline
 System design flow
 Modeling, specifying, and representing systems:
 Description languages for design specifications and implementations
 Modeling formalisms: Models of computation and concurrency
 Fundamentals:
Boolean algebras, functions, relations. Propositional logic, first-order logic. Temporal
logics.
 Hardware implementation (component) technologies:
CPUs, ASICs, FPGAs, DSPs, IP blocks, I/O components, networks, buses, on-chip
communication networks, reconfigurable platforms.
 Software implementation (component) technologies:
Operating systems, real-time operating systems, inter-process communication,
scheduling.
 Analysis, verification, testing: Functionality.
Design and implementation verification. Simulation, emulation, formal verification.
 Analysis, verification, testing: Performance and timing.
Timing analysis and verification of hardware and software. Performance evaluation
and estimation.
 Analysis, verification, testing: Power.
Power analysis, optimization of hardware and software. Power minimization
techniques.




27
System partitioning, architecture exploration.
Hardware synthesis.
Software synthesis
Interface design and synthesis
ECOE 560, Spring 2006
Outline of today’s lecture




28
What is a software/hardware (embedded) system?
Course outline
Design automation methodologies and tools
Levels of abstraction in design descriptions
ECOE 560, Spring 2006
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.
29
ECOE 560, Spring 2006
Design goals
 Performance.
 Overall speed, deadlines.




30
Functionality and user interface.
Manufacturing cost.
Power consumption.
Other requirements (physical size, etc.)
ECOE 560, Spring 2006
Complexity
Design Challenges:
Increasing Device and Context Complexity
 Exponential increase in device complexity—increasing with
Moore’s law (or faster)!
 System context in which devices are deployed (e.g. cellular
radio) are increasing in complexity as well exponential
increases in design productivity
We have exponentially more components!
31
ECOE 560, Spring 2006
Design Challenges: Deep Submicron Effects
 Smaller geometries are causing a wide variety of effects that
we have largely ignored in the past:
DSM Effects
 Cross-coupled capacitances
 Signal integrity
 Resistance
 Inductance
Design of each transistor is getting more difficult!
32
ECOE 560, Spring 2006
Design Challenges: Heterogeneous Components
Heterogeneity
 Greater diversity of on-chip elements




Processors
Software
Memory
Analog
More components doing different things!
33
ECOE 560, Spring 2006
Design Challenges: Stronger Market Pressures
Time-to-Money
 Decreasing design window
 Less tolerance for design revisions
Exponentially more complex, greater design risk,
greater variety, and a smaller design window !
34
ECOE 560, Spring 2006
Complexity
A Quadruple-Whammy
Time-to-Money
Heterogeneity
DSM Effects
35
ECOE 560, Spring 2006
Role of CAD: Helping humans cope
Intelligence
Quotient
Transistors
PPC603
Pentium
10M
80486
1M
68020
100K
10K
Pentium Pro
PPC601
80386
68000
180
68040
MIPS R4000
160
140
8086
120
4004
8080
1K
100
100
80
10
50
1
1975
36
1980
1985
1990
1995
Processor Complexity
Avg. Human IQ
ECOE 560, Spring 2006
Outline of today’s lecture




37
What is a software/hardware (embedded) system?
Course outline
Design automation methodologies and tools
Levels of abstraction in design descriptions
ECOE 560, Spring 2006
Phases of a design flow
requirements
specification
architecture
component
design
system
integration
38
ECOE 560, Spring 2006
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.
39
ECOE 560, Spring 2006
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.
 Design: specify and enter
the design intent
Verify:
verify the
correctness of
design and
implementation
Implement:
refine the
design
through all
phases
40
ECOE 560, Spring 2006