Slides - NTU

canolaokahumpkaElectronics - Devices

Nov 2, 2013 (3 years and 7 months ago)

94 views

SE 746
-
NT

Embedded Software Systems Development


Robert Oshana









Lecture #
9












For more information, please contact:





NTU Tape Orders:






NTU Media Services: (970) 495
-
6455


tapeorders@ntu.edu

oshana@airmail.net

Lecture 9

The selection


process

Agenda


Packaging the silicon


Adequate performance


RTOS availability


Tool chain availability

Chapter 2

The selection process


Embedded systems represent target
platforms specific to a single task


Range of tasks is well bounded


Design highly optimized


Selection criteria


Available in suitable implementation?


Capable of sufficient performance?


Supported by suitable OS ?


Appropriate and adequate tools?

Suitable implementation


Off the shelf highly integrated


Single chip to reduce gate delays


20 lifetime support


Military version


Packaging and implementation
technology

Choosing the right
processor

Sufficient performance


Must be able to do the job on time


The job is becoming harder to
characterize


Bottlenecks are not necessarily with
the computational power but with the
architectural fit


Difficult to correlate benchmark
results with actual performance

Appropriate OS


Commercial OS becoming common
in embedded world


Porting an RTOS to a specific
architecture highly optimized is very
difficult


Processor selection may be based
on preferred OS

Tools


Good tools are critical to project
success


Tools needed partially depends on
the nature of the project


Cross compiler ad debugger
minimum


Maybe also an ICE


TTM may be driven by what the team
is familiar with

Microprocessor vs micro
controller


Microprocessor; CPU w/o any
additional peripheral or support
devices


Microcontroller; designed to need a
minimum complement of external
parts


Moist embedded systems use
microcontrollers

Microprocessor vs
microcontroller

Microprocessor vs micro
controller


Advantages of microcontroller


Lower cost; one part replaces many


More reliable; fewer packages, fewer
interconnects


Better performance; system
components optimized for their
environment


Faster; signals stay on the chip


Lower RF signature; fast signals don’t
radiate as much

Adequate performance


Benchmarking has become
synonymous with Dhrystones and
MIPS (Meaningless Indicator of
Performance for Salesmen)


VAX 11/780 was first machine that could
run 1 millions instructions/second


Instructions vary widely by architecture
such as RISC or CISC

Adequate performance


Dhrystone is a simple C program


Compiles to about 2K loc of asm


Independent of OS


Calibrated to VAX 11/70


1757 loops through Dhrystone in 1 sec


That’s referred to as 1 Dhrystone


Compiler vendors can optimize for
Dhrystone


misleading


Silicon vendors tweak micros for this
as well!

Distorting Dhrystone

Meaningful benchmarking


Must carefully balance system
requirements and variables


How a processor runs on your app
may be totally different than how it
performs on mine


Important to analyze the real
-
time
behavior of the processor


How does it respond to real
-
time
events?

Meaningful benchmarking


Real
-
time performance


Interrupt handling


Task switching


Varies by processor


Predicting performance is not easy


Don’t blindly rely on simplified
benchmarking results

EEMBC


Embedded Microprocessor
Benchmark Consortium


Reps from semiconductor, compiler
vendors, customers


Industry specific tests


More “realistic”

EEMBC test list

Automotive/industrial
suite

Angle to time
conversion

CAN remote data
request

Basic floating point

FFT

Bit manipulation

FIR and IIR

Cache buster

Tooth to spark
calculation

EEMBC test list

Consumer suite

Compress JPEG

RGB to CMYK
conversion

Decompress JPEG

RGB to YIQ
conversion

Bit manipulation

High
-

pass gray scale
filter

EEMBC


Represent real world algorithms


Statistics include number of times
the algorithm executes per second
and the size of the compiled code


Must include details on compiler
settings/optimization switches


For embedded systems, its better to
have raw data instead of a scalar

Running a benchmark


Use an evaluation board

DSP Starter Kit

150 MHz

‘C6211

DSP

150 MHz

‘C6211

DSP

AD535 16

-

bit

Codec

AD535 16

-

bit

Codec

4

MBytes

SDRAM

4

MBytes

SDRAM

128

KBytes

Flash ROM

128

KBytes

Flash ROM

Daughter

Card

Expansion

Slots

Daughter

Card

Expansion

Slots

Universal

(CE Compliant)

Power Supply

Universal

(CE Compliant)

Power Supply

Parallel Port

Parallel Port

JTAG

Controller

JTAG

Controller

Buffer &

Process

to

PC

Analog I/O

Running a benchmark


Compare similar systems


Try to prevent biasing


Published results need to be verified
against your application


Eval boards are also great learning
opportunities


Debugging, optimization, RTOS, etc

This is hard!

CPU and Memory Utilization for Application 2

0

20

40

60

80

100

120

140

160

180

1

3

5

7

9

11

13

15

17

19

21

23

25

27

29

31

33

35

37

39

41

Date/Time

Percentage of Resource Utilization

CPU

Memory

Requirement

Initial Discrete

Event

Simulation

Actual

meaasurement

from

prototype

system

Algorithm

optimization

Actuals from

processor

VHDL

simulation

Add more H/W

to the system

Actual measurements

on small scale target H/W

Move S/W functionality

into H/W ASIC

S/W code and

algorithm level

optimization

Measurement on

full scale H/W array

Code optimization

RTOS availability


Almost as important as choosing the
processor


RTOS kernel should be optimized to
the platform its running on


Porting without optimizing can lead
to a significant performance hit

RTOS checklist


Language/microprocessor support


Tool compatibility


Services


Footprint


Performance


Software components


RTOS checklist


Device drivers


Debugging tools


Standards compatibility


Technical support


Source versus object code


Licensing


Reputation


Services

Other issues in the
selection process


Prior commitment to a processor
family


Code and architecture compatibility


Prior restriction on language


Ada for military


Tools may only support C/C++/asm


Time to market factors


Miss market by month => up to 30%
profitability on that market


“Time to money”

SE 746
-
NT

Embedded Software Systems Development


Robert Oshana









End of Lecture












For more information, please contact:





NTU Tape Orders:






NTU Media Services: (970) 495
-
6455


tapeorders@ntu.edu

oshana@airmail.net