2431 SocD 07 Sw es09 - TUT is standard today, while in automobiles the estimated number of lines by...

Erno Salminen - Oct. 2009

TKTTKT--2431 Soc 2431 Soc DesignDesign

LecLec 77 –– Embedded softwareEmbedded software

ErnoErno SalminenSalminen

Department ofDepartment of ComputerComputer SystemsSystemsTampere University of TechnologyTampere University of Technology

Fall 2009Fall 2009

Erno Salminen - Oct. 2009#2/47

ContentsContents

TrendsHardware-dependent SW (HdS)Estimation of execution timeDevelopment guidelines


Copyright noticeCopyright notice

Part of the slidesadapted from slide set by Alberto Sangiovanni-Vincentelli (who got some slides from Prof. Sharad Malik, Princeton University and Prof. Reinhard Wilhelm, Universität des Saarlandes)

course EE249 at University of California, Berkeleyhttp://www-cad.eecs.berkeley.edu/~polis/class/lectures.shtml


At firstAt first

Make sure that simple things work before even trying more complex ones


NoteNote

Sources on the following slides concentrate on software

Especially in extra sectionHowever, the most issues and recommendations apply HW and HW/SW-system design as well

Since HW is nowadays described using HDL, its development looks more and more like SW development


SW toolsSW tools

Usability of CPU is determined by1. Mostly by SW tools

compiler, assembler, linker, debugger

2. Secondly by novelty of HW design frequency, area, ILP, power

Bunch of open source CPUs availablePoor or non-existent SW tools”What you pay is what you get...”

Standalone debugger is not enoughDifficult to perform co-simulation with HDLDifficult to perform multiprocessor simulation


SW tools (2)SW tools (2)

[Jim Turley, Survey says: software tools more important than chips, Embedded Systems Design, 04/11/05,

[online] http://www.embedded.com/showArticle.jhtml?articleID=160700620.]


Compared to HW, SW...Compared to HW, SW...can be easily over 10x slowerconsumes more energyrequires more memory

codetemporary data

has more varying execution timeespecially with caches, garbage collecting, dynamic memory allcoation

is faster to developis easier to modify at field

programming flash/EEPROM vs. fixed ASICis faster to modify

compilation vs. synthesisallows more complex operations, such as dynamic memory allocation (one reason for varying runtime)


Reminder: Feasible implementationReminder: Feasible implementation

Computational requirements of certain application remain roughly the sameNew, complex applications require ASIC at firstAfter a while, they can be implemented with FPGA

then with DSP, eventually with General Purpose Processor (GPP) time

log (MOPS)

appl A

appl B

GPP

DSP, ASIP

FPGA

ASIC

required technology

CBA

DSPASICN/A FPGAASIC

GPP ...DSPFPGA

ASICN/A

appl C


SW complexitySW complexity

Sangiovanni-Vincentelli, Quo Vadis SLD? Proceedings of the IEEE, 2007.

In cell phones, more than 1 million lines of code is standard today, while in automobiles the estimated number of lines by 2010 is in the order of hundreds of millions.

“Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.”-A. Perlis


The Software Development ProblemThe Software Development Problem

Product Quality is POORDevelopment Productivity is LOWDevelopment Cycle-time is TOO LONG

Industry Average

4.13Ind. Best-in-Class

8.76Customer Expectation

>40

PRODUCTIVITY

Function Point per Staff Month

Industry Average

0.44Ind. Best-in-Class

0.08Customer Expectation

<0.00044

QUALITY

Delivered Defects per Function Point

Industry Average

36Ind. Best-in-Class

25Customer Expectation

<3-6

CYCLETIME

Schedule in Months

System Software (of size 10,000 Function Points)

Source: Roger G. Fordham Motorola, Global Software Group

DAC 2001, June 6, 2001

[Industry Data: Capers Jones(2000) Software Assessments, Benchmarks, and Best Practices, Addison-Wesley.]


SW Complexity

0100200300400500600700800

1995 1997 2000 2003 2005

k-Linesof code

SW defects at End-of-Design

1

10

100

1000

10000

1995 1997 2000 2003 2005

ppmKEY DRIVERSKEY DRIVERS•• QUALITYQUALITY•• TIMETIME--TOTO--MARKETMARKET•• COMPLEXITY MGMTCOMPLEXITY MGMT

WINNING SOLUTIONSWINNING SOLUTIONS••PLATFORM & APPLICATIONSPLATFORM & APPLICATIONS••DESIGN METHODOLOGIESDESIGN METHODOLOGIES••TESTINGTESTING

Time-to-Market

05

10152025303540

1995 1997 2000 2003 2005

Months

COMPLEXITY, QUALITY, TIMECOMPLEXITY, QUALITY, TIME--TOTO--MARKET: MARKET: FUTURE TRENDS FUTURE TRENDS

TelematicsTelematics Power TrainPower Train

Body Body andand NetworkNetwork


HW/SW cost trends [Boehm, 1976]HW/SW cost trends [Boehm, 1976]

Most SoCs are derivativedesignsHence they contain large reused parts (both HW and SW)Reuse often requires maintenance

Fig from [B.W. Boehm, Software Engineering, IEEE Trans. Computers, Vol. C-25, Iss. 12, Dec 1976, pp. 1226 -1241.]


SW maintenanceSW maintenance

Maintenance categories:1. Corrective: finding and fix known bugs2. Adaptive: add or modify the functionality3. Perfective: improve runtime, mem consumption

etc. without changing functionalityFig: [Hatton, Computer, Feb. 2007]“Every program has (at least) two purposes: the one for which it was written, and another for which it wasn't.” –A. Perlis


HW dependent SWHW dependent SW


HW/SW Design challenges [Jerraya]HW/SW Design challenges [Jerraya]

Implementation criterias:1. High performance, low power

ASIC2. Short design cycle

SW : 3-6 monthsASIC :

6-12 months for derivative designs18-24 months for first design

3. Best volume in marketMixed HW/SW


Paradigm shift: from ASIC to SoC designParadigm shift: from ASIC to SoC design

90% of new ASICs already include a CPU in 130nm technology

CPU core ~20k – 100k gatesMultiple CPU fit easily into million-gate chipUp to 20 CPUs in new FPGAs (year 2006)

Heterogeneous cores are exploited to meet the tight performance and cost constraints

RISC, DSP, ASIP, 8b/16b/32b data pathDesign of a SoC will consist of an assembly of processors executing tasks concurrently

Multiprocessor SoC (MPSoC)“MPSoCs combine the difficulties of building complex hardware systems and complex software systems”

Jerraya, Tenhunen, Wolf, 2005.


Raising abstraction levelsRaising abstraction levelsE.g. interconnection (fig 1a)

Metal lines in layout levelSignals in RTL

Above RTL, the abstraction needs to be applied to both SW and HW components (fig 1b)SW components do not communicate with the external world via wires, but via

Assembly instructions (load/store)Function calls (Device driver)

HW/SW interface needs to handle two different interfaces: 1. On SW side using API2. On HW side using wiresHW/SW interface one of the bottle-necks in SoC design


Evolution of abstraction levelsEvolution of abstraction levels

e.g. OCP


Hardware dependent SW (HdS)Hardware dependent SW (HdS)

HW/SW interface gives SW an abstracted view of underlying HW

Hardware dependent SW (HdS or HdSW)Also called HW abstraction layer (HAL)

This facilitatesConcurrent design of both HW and SW

Shorter Time-to-market (TTM)Modular design for mastering complexityEasier validationReuse of SW

”If there is one part that cannot be modified, it is the software” – wisdom from industry


HdSW/HALHdSW/HAL

HAL provides generic device models for classes of peripherals found in embedded systemsSmall HdS enables large HW-independent SW Originally, HAL was part of operating system kernel but now a separate layerFor example, HAL is basically the driver for the motherboard (PC) or accelerator unit (SoC)Examples from RISC OS

int HAL_IRQEnable (int device) int HAL_IRQSource (void)unsigned int HAL_TimerGranularity (int timer)void HAL_TimerSetPeriod (int timer, unsigned int period)unsigned int HAL_CounterRate (void)


MemoryMemory--mapped vs. port I/Omapped vs. port I/O

CPU can access peripherals and other HW via1. port I/O:

Specific instrcutions transfer data to/from CPU’s portsNot directly controllable from high-level language (HLL)Needs inline assembly or special macros/pragmas

2. memory-mapped I/O: Devices are connected to CPU’s memory-busMore generic wayDevices easily accessible from HLLDevices reserve certain part of the memory spacevolatile int* ctrl_reg = (int*) 0x9000;

*ctrl_reg = START;


Pitfalls on memoryPitfalls on memory--mapped HW (1)mapped HW (1)Pointers for mem-map I/O are not defined as volatileA volatile variable may be modified externally from the declaring object,

e.g. by interrupt service routinee.g. by peripheral HW device

Compiler does not create a memory access at all if it thinks that value is constant

int* ctrl_reg = (int*) 0x9000;// wrong*ctrl_reg = 0; // initializewhile (*ctrl_reg ==0){}; // wait (forever!)do_something_else();

While-loop is never exited because value is not checked again from memory bus. The value 0 remains in CPU’s internal register


Pitfalls on memoryPitfalls on memory--mapped HW (2)mapped HW (2)

Mem-map I/O goes to/from cache and not to memory bus (=device)

SW does not see any changes if cache hit occurs Write go at first only to cache

HW deviceHW device

CPUCPU

HdSHdSapp. SWapp. SW

data cachedata cache0memory-mapped

ctrl/status registers

data memorydata memory

One must bypass the cache!Depends on CPU how to do thatE.g. done with uppermost bit of the address in NIOS II

01

12a

2b1

2a

2b

Read register for the first time. Ok.

Wrong way: Polling value (constant 0) from cache

Right way: Bypass the cache and poll value directly from HW

Phases in example figure:


Example: Nios II HALExample: Nios II HAL

About 70 C functionsSee Nios II Software Developer's Handbook for details

Models for the following classes of devices:character mode devices (e.g. UART)timersfile subsystemsEthernet devicesDirect memory access (DMA)flash devices


Example: Nios II HAL (2)Example: Nios II HAL (2)

Each device model defines a set of driver functions necessary to manipulate the particular class of device

They must be provided when writing a driver for a new peripheral

Inevitably, certain peripherals have HW-specific features with usage requirements that do not map well to a general-purpose API.

They are handled UNIX-style ioctl() function.


Example: Nios II HAL (3)Example: Nios II HAL (3)

A file called system.h provides complete SW description of the Nios II system


HdS challenges (1)HdS challenges (1)

Parallel programming model for SoCSpecification of the application-specific design constraints

Scalability and configurabilityThe same HdS API over different HW platforms

Quality-of-Service (QoS)Communication requirements (e.g. bandwidth; delay, jitter)Reliability requirements (e.g. hard or soft real-time, communication ordering and delivery) Cost requirements (e.g. energy consumption, software code size)


HdS challenges (2)HdS challenges (2)

VerificationHow to verify before physical prototype is ready?

CustomizationMore general HdS, less efficient (longer runtime, larger memory requirements)

Application may use only small proportion of featuresMore error-proneTurn off unwanted features

More general, better reuse possibilitiesStandardization

HdS links separate teams that may belong to different companies or even market sectors


Overhead from HdS/OS/middlewareOverhead from HdS/OS/middleware

Operating System (OS) and middleware are starting to consume more of system costs

memory footprint (code + data)runtimeenergy consumption

Two reasons:1. OS needs to be ported to different platforms2. OS needs to implement full-featured functionality

Use OS only on those CPUs that necessarily need it

E.g. DSPs are often devoted to small set of fixed tasks that do not need any OS. Possible scheduling can be handled with manually written scehduling loop


Middleware example [Arpinen]Middleware example [Arpinen]

df

[T. Arpinen et al., Configurable Multiprocessor Platform with RTOS for Distributed Execution of UML 2.0, DATE]

(excluding dynamic mem)


Middleware cost [Silven, Rintaluoma]Middleware cost [Silven, Rintaluoma]

O. Silven, K. Jyrkkä, Observations on power-efficiency trends in mobile communication devices, EURASIP Journal of Embedded Systems, accepted Jan 2007

60 000Middleware400Context switch

300 - 600Interrupt latency1 000 – 2 500System call (user – kernel)

3 - 7Procedure callOverhead [cycles]Mechanism


Middleware cost (2)Middleware cost (2)

The talk time of mobile phones has not increased

despite better batteriesdespite much lower energy per gate

Reasonsmore gatesmore functionality (”feature explosion”)more SW layers to handle the complexity


RoadmapRoadmap

transaction level modeling (TLM)transportlevel /Message passing interface (MPI)

, UML2.0


SW estimationSW estimationMoved here from Lecture 6 Moved here from Lecture 6


SW estimation helps toSW estimation helps to

Evaluate HW/SW trade-offsIdentify the critical portion in the SW implementation

Check performance/constraintsHigher reliability

Reduce system costAllow slower hardware, smaller size, lower power consumption


SW estimation overview: approachesSW estimation overview: approaches

Two aspects to be considered1. The structure of the code (program path analysis)

E.g. loops and false paths2. The system on which the software will run (micro-

architecture modeling)CPU (ISA, interrupts, etc.), HW (cache, etc.), OS, compiler

Needs to be done at right levela) Low-level

E.g. gate-level, assembly-language levelEasy and accurate, but long design iteration time

b) High/system-levelReduces the exploration time of the design space


SW estimation overview: tasksSW estimation overview: tasks

1. Architectural evaluationEvaluate required processing capability -processor selectionEvaluate required communication capacity - bus capacity, memory hierarchy

2. Partitioning evaluationHW/SW partitionco-processor needs

3. System metric evaluationperformance level reached?power constraint met?size constraint met?


Conventional system design flowConventional system design flow

system partition

design criteria: - performance - cost - modifiability - testability - reliability

HW design SW design

requirements

re-partitioning

performance tuning

system debug performance analysisLong iteration loop !!

Low-level performance estimation


SystemSystem--level software modellevel software model

Must be fast - whole system simulationProcessor model must be cheap

“What if” my processor did XFuture processors not yet developedEvaluation of processor not currently used

Must be convenient to useNo need to compile with cross-compilersDebug on my desktop

Must be accurate enough for the purpose


OnOn--Chip Performance Monitoring CountersChip Performance Monitoring Counters

Usually measure only execution timetotal cyclesMonitoring degradades performance slightly

No notion of execution dynamics or locality i.e the cause

instructions fetchedinstructions retirednumber of loads and storescache misses at various levelsnumber of branch instructionsnumber of mispredicted branchesnumber of branches not predictedCycle counter does not tell why runtime is what it is


Program path analysisProgram path analysis

Basic blocksA basic block is a program segment which is only entered at the first statement and only left at the last statement.The Worst-case-execution-time WCET (or best-case-execution-time, BCET) of a basic block is determined

A program is divided into basic blocksProgram structure is represented on a directed program flow graph with basic blocks as nodesA longest / shortest path analysis on the program flow identify WCET / BCET


[Li, ICCAD, 1995]

An example Control flow graph (CFG)An example Control flow graph (CFG)


MicroMicro--architecture modelingarchitecture modeling

Micro-architecture modelingModel HW and determine the execution time of sequences of instructionsCaches, CPU pipelines, etc. make WCET computation difficult since they make it history-sensitiveProgram path analysis and micro-architecture modeling are inter-relatedAssuming constant execution time for instructions is not accurate

Must model the pipeline, cache, branch prediction, varying execution timePipelines and caches are hard to predict

Stalls depend on execution history and cache contentsExecution times depend on execution history


Experimental ResultsExperimental Results

Intel i960KB Measurements

0.00

100.00

200.00

300.00

400.00

500.00

600.00

700.00

circ

le des

dhry

djpe

g

fdct fft

line

sort

sort

2st

ats

stat

s2wh

etst

one

Program

Est. WCET w/o cache analysis

Est. WCET with cache analysis(loop bounds only)

Est. WCET with Cache Analysis

52,515

Nor

mal

ized

Exe

c. T

ime

Mea

sure

d W

CE

T =

100


Estimation accuracy over timeEstimation accuracy over time

as


ConclusionConclusion

HdS provides HW abstraction to SW designerSmall HdS enables large HW-independent SWConcurrent SW and HW design

CPU usability defined by its SW toolsSW estimation helps system design

Evaluate different choices fastProgram path analysis

Define basic blocksCreate Control Flow GraphDefine constraints

e.g. max iteration count for loopDefine cache hits and misses

Make sure that worst-case estimates are on the safe side


Extra slidesExtra slidesDevelopment guidelinesDevelopment guidelines


Abstraction levelsAbstraction levels

Func 0Func 0 Func 1Func 1 Func 2Func 2

interfaceinterface interfaceinterfaceSWSW HWHW

refine

communication networkcommunication networkinterfaceinterface interfaceinterface

CPUCPU HWHWHdSHdSSWSW

refine

HW IP designHW IP design

HW/SW Interface design

HW/SW Interface design

SW design

SW design

HW interconnect

HW interconnect

APIAPI

glueglue

comm levelcomm level

OS levelOS level

HAL levelHAL level

ISA levelISA level

transaction leveltransaction level

bus cycle accuratebus cycle accurate

register transfer accurate

register transfer accurate

increasing abstraction


Software Architecture TodaySoftware Architecture Today

Poor common infrastructure. Weak specialization of functions. Poor resource management. Poor planning.


Software Architecture Tomorrow?Software Architecture Tomorrow?


Why software failsWhy software failsProject management -related

poor project managementunrealistic or unarticulated project goalsinaccurate estimates of needed resourcesbadly defined systems requirementspoor reporting of the project’s statusunmanaged risks

Implementation-relateduse of immature technologyinability to handle the project’s complexitysloppy development practices

Context –relatedpoor communication among customers, developers, and usersstakeholder politicscommercial pressures

[N. Holmes, The Data Doughnut and the Software Hole, Computer, Vol. 39, Iss. 6, June 2006, pp. 100 - 99.]

[R.N. Charette, Why software fails [software failure],Spectrum, IEEE, Vol. 42, Iss. 9, Sept. 2005, pp. 42 - 49. ]


SW defect reduction Top 10SW defect reduction Top 10

1. Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase

2. Current software projects spend about 40 to 50 percent of their effort on avoidable rework

3. About 80 percent of avoidable rework comes from 20 percent of the defects

4. About 80 percent of the defects come from 20 percent of the modules, and about half the modules are defect free

5. About 90 percent of the downtime comes from, at most, 10 percent of the defects

6. Peer reviews catch 60 percent of the defects


SW defect reduction Top 10 (2)SW defect reduction Top 10 (2)

7. Perspective-based reviews catch 35 percent more defects than nondirected reviews

8. Disciplined personal practices can reduce defect introduction rates by up to 75 percent

9. All other things being equal, it costs 50 percent more per source instruction to develop high-dependability software products than to develop low-dependability software products. However, the investment is more than worth it if the project involves significant operations and maintenance costs

10. About 40 to 50 percent of user programs contain nontrivial defects

[B. Boehm, V.R. Basili, Software defection reduction Top 10 list,

Computer, Vol. 34, Iss. 1, Jan. 2001, pp. 135 - 137 .]


Almost 101 Rules, Guidelines, and Best Almost 101 Rules, Guidelines, and Best practices: Organizational and policy issuespractices: Organizational and policy issues

0. Don’t sweat the small stuff (OR: Know what to standardize).1. Compile cleanly at high warning levels.2. Use automated build system.3. use version control system.4. Invest in code reviews.


Rules ... (2): Design styleRules ... (2): Design style

5. Give one entity one cohesive responsibility.6. Correctness, simplicity, and clarity come first.7. Know when and how to code for scalability.8. Don’t optimize prematurely.9. Don’t pessimize prematurely.10. Minimize global and shared data.11. Hide information.12. Know when and how to code for concurrency.


Rules ... (3): Coding styleRules ... (3): Coding style

14. Prefer compile- and link-time errors to run-time errors.15. Use const proactively.16. Avoid macros.17. Avoid magic numbers.18. Declare variables as locally as possible19. Always initialize variables.20. Avoid long functions. Avoid deep nesting.22. Minimize definitional dependencies. Avoid cyclic dependencies23. Make header files self-sufficient.


Rules ... (4): Functions, Errors handlingRules ... (4): Functions, Errors handling

25. Take parameters appropriately by value, (smart) pointer, or reference.31. Don’t write code that depends on the order of evaluation of function arguments.68. Assert liberally to document internal assumptions and invariants.


Rules ... (5): Type safetyRules ... (5): Type safety

91. Rely on types, not on representations.94. Avoid casting away const.97. Don’t use unions to reinterpret representation.98. Don’t use varargs (ellipsis).

Rules taken from: H. Sutter, A. Alexandrescu, C++ Coding Standards: 101 Rules, Guidelines, and Best Practices (C++ In-Depth Series), Addison-Wesley Professional, Nov. 2004.


10 rules for safety10 rules for safety--critical codecritical code1. Restrict all code to very simple control flow constructs

Do not use goto statements, setjmp or longjmp constructs, or direct or indirect recursion

2. Give all loops a fixed upper boundIt must be trivially possible for a checking tool to prove statically that the loop cannot exceed a preset upperbound on the number of iterations

3. Do not use dynamic memory allocation after [program’s] initialization

4. No function should be longer than what can be printed on a single sheet of paper in a standard format with one line per statement and one line per declaration

5. The code’s assertion density should average to minimally two assertions per function

6. Declare all data objects at the smallest possible level of scope


10 rules for safety10 rules for safety--critical code (2)critical code (2)

7. Each calling function must check the return value of nonvoid functions, and each called function must check the validity of all parameters provided by the caller

8. The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions

9. The use of pointers must be restricted Specifically, no more than one level of dereferencing should be used. Function pointers are not permitted

10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the most pedantic setting available. All code must compile without warnings

[G.J. Holzmann, The power of 10: rules for developing safety-critical code, Computer, Vol. 39, Iss. 6, June 2006, pp. 95 - 99.

Date post:	30-Mar-2018
Category:	Documents
Upload:	trinhdung
View:	217 times
Download:	5 times

2431 SocD 07 Sw es09 - TUT is standard today, while in automobiles the estimated number of lines by...

Documents