Upload
trinhdung
View
218
Download
5
Embed Size (px)
Citation preview
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
Erno Salminen - Oct. 2009#3/47
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
Erno Salminen - Oct. 2009#4/47
At firstAt first
Make sure that simple things work before even trying more complex ones
Erno Salminen - Oct. 2009#5/47
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
Erno Salminen - Oct. 2009#6/47
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
Erno Salminen - Oct. 2009#7/47
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.]
Erno Salminen - Oct. 2009#8/47
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)
Erno Salminen - Oct. 2009#9/47
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
Erno Salminen - Oct. 2009#10/47
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
Erno Salminen - Oct. 2009#11/47
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.]
Erno Salminen - Oct. 2009#12/47
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
Erno Salminen - Oct. 2009#13/47
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.]
Erno Salminen - Oct. 2009#14/47
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
Erno Salminen - Oct. 2009
HW dependent SWHW dependent SW
Erno Salminen - Oct. 2009#16/47
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
Erno Salminen - Oct. 2009#17/47
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.
Erno Salminen - Oct. 2009#18/47
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
Erno Salminen - Oct. 2009#19/47
Evolution of abstraction levelsEvolution of abstraction levels
e.g. OCP
Erno Salminen - Oct. 2009#20/47
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
Erno Salminen - Oct. 2009#21/47
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)
Erno Salminen - Oct. 2009#22/47
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;
Erno Salminen - Oct. 2009#23/47
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
Erno Salminen - Oct. 2009#24/47
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:
Erno Salminen - Oct. 2009#25/47
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
Erno Salminen - Oct. 2009#26/47
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.
Erno Salminen - Oct. 2009#27/47
Example: Nios II HAL (3)Example: Nios II HAL (3)
A file called system.h provides complete SW description of the Nios II system
Erno Salminen - Oct. 2009#28/47
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)
Erno Salminen - Oct. 2009#29/47
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
Erno Salminen - Oct. 2009#30/47
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
Erno Salminen - Oct. 2009#31/47
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)
Erno Salminen - Oct. 2009#32/47
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
Erno Salminen - Oct. 2009#33/47
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
Erno Salminen - Oct. 2009#34/47
RoadmapRoadmap
transaction level modeling (TLM)transportlevel /Message passing interface (MPI)
, UML2.0
Erno Salminen - Oct. 2009
SW estimationSW estimationMoved here from Lecture 6 Moved here from Lecture 6
Erno Salminen - Oct. 2009#36/47
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
Erno Salminen - Oct. 2009#37/47
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
Erno Salminen - Oct. 2009#38/47
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?
Erno Salminen - Oct. 2009#39/47
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
Erno Salminen - Oct. 2009#40/47
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
Erno Salminen - Oct. 2009#41/47
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
Erno Salminen - Oct. 2009#42/47
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
Erno Salminen - Oct. 2009#43/47
[Li, ICCAD, 1995]
An example Control flow graph (CFG)An example Control flow graph (CFG)
Erno Salminen - Oct. 2009#44/47
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
Erno Salminen - Oct. 2009#45/47
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
Erno Salminen - Oct. 2009#46/47
Estimation accuracy over timeEstimation accuracy over time
as
Erno Salminen - Oct. 2009#47/47
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
Erno Salminen - Oct. 2009
Extra slidesExtra slidesDevelopment guidelinesDevelopment guidelines
Erno Salminen - Oct. 2009#49/47
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
Erno Salminen - Oct. 2009#50/47
Software Architecture TodaySoftware Architecture Today
Poor common infrastructure. Weak specialization of functions. Poor resource management. Poor planning.
Erno Salminen - Oct. 2009#51/47
Software Architecture Tomorrow?Software Architecture Tomorrow?
Erno Salminen - Oct. 2009#52/47
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. ]
Erno Salminen - Oct. 2009#53/47
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
Erno Salminen - Oct. 2009#54/47
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 .]
Erno Salminen - Oct. 2009#55/47
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.
Erno Salminen - Oct. 2009#56/47
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.
Erno Salminen - Oct. 2009#57/47
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.
Erno Salminen - Oct. 2009#58/47
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.
Erno Salminen - Oct. 2009#59/47
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.
Erno Salminen - Oct. 2009#60/47
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
Erno Salminen - Oct. 2009#61/47
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.