Content uploaded by Michael Pont
Author content
All content in this area was uploaded by Michael Pont on May 10, 2016
Content may be subject to copyright.
EmpiricalComparisonofSoftware-BasedErrorDetection
andCorrectionTechniquesforEmbeddedSystems
RoyanH.L.Ong
StudentmemberIEE
DepartmentofEngineering,
UniversityofLeicester,
Leicester,UnitedKingdom.
+44(0)1162522873
hlro1@le.ac.uk
MichaelJ.Pont
MBCS
DepartmentofEngineering,
UniversityofLeicester,
Leicester,UnitedKingdom.
+44(0)1162522559
m.pont@le.ac.uk
ABSTRACT
“FunctionTokens”and“NOPFills”aretwomethodsproposedby
various authors to deal with Instruction Pointer corruption in
microcontrollers, especially in the presence of high
electromagnetic interference levels. An empirical analysis to
assess and compare these two techniques is presented in this
paper.
Twomainconclusionsaredrawn: [1]NOPFillsare apowerful
techniqueforimprovingthereliabilityofembeddedapplications
inthepresenceofEMI,and[2]theuseofFunctionTokenscan
leadtoareductioninoverallsystemreliability.
Keywords
Instruction Pointer Corruption, Electromagnetic Interference,
EMI,FunctionToken,NOPFill,Software-basedErrorDetection
Techniques,Embeddedsystems
1. INTRODUCTION
Theuse ofmicrocontrollersin embeddedsystemshas increased
tremendously with the rise in consumer demands for safer,
cheaper and more versatile electronics devices. As for other
sectors, the greater sophistication demanded by modern-day
applications coupled with the miniaturisation trend makes
microcontrollerstheidealelectronicsdeviceinmanyapplications.
Theautomotiveindustryformsa keypart ofthemicrocontroller
market,notleastbecauseofadesiretoimprovepassengersafety
levels.Inthisregard,embeddedelectronicssystems,suchasair
bagsandanti-lockbrakes[9],havealreadyprovedeffectivewhile
adaptivecruisecontrolsystemsarethoughttohavethepotential
to reduce the number of accidents between 3% and 10% [3].
However,theincreasingrelianceonembeddedsystemsforsafety-
related automotive systems also introduces new risks. Many
factors, from the hardware, software and design point of view,
may influence the reliability of embedded systems: within the
present paper, we are concerned with the influence of
electromagnetic interference (EMI) on the microcontroller itself
(see [1]), with specific reference to the corruption of the
instructionpointer(IP).
Thispaperisorganisedasfollows:theproblemassociatedwithIP
errorsandsoftware-basedtechniquesproposedbyotherauthorsto
detectandcorrectsucherrorsaredescribedSection2.Section3
introducesthe experimentalprocedurecarried outtostatistically
evaluate these techniques. Both experimental results and
discussionarefoundinSection4whileSection5concludesthis
paper.
Although the experiment and results were based on the 8051
family of microcontrollers, most topics discussed here are
applicabletoothermicrocontrollerfamilies.
2. SOFTWARETECHNIQUESTODEAL
WITHIPERRORS
Arguably, the most serious form of EMI-induced error in a
microcontroller is corruption of the instruction pointer, the
register that stores the address of the next instruction to be
executed.Thoughsimilarinconstructiontootherregisters,such
astheaccumulator,corruptionoftheIPcanleadtounpredictable
program branches, and – consequently – dramatic changes in
systembehaviour.
The impact of IP corruption is particularly difficult to predict
because most microcontroller instruction sets include some
instructionslongerthanonebyteinsize(“multibyteinstructions”)
[10, 11]. During program execution it is possible that IP
corruption may occur before all the bytes of a multibyte
instructionhavebeenread.Undersuchcircumstances,thecorrect
instruction is executed but with the wrong operands – a
phenomenon we term the “Early Multibyte Instruction Trap”
(EMIT)[11].
FurtherproblemsarisewhenthecorruptedIPpointstoamemory
location thatcontainsthe second orthirdbyte (orgreater) of a
multibyte instruction. The processor will misinterpret the value
found at this location (and, often, at subsequent locations too).
Wereferto thisphenomenon asthe“LateMultibyteInstruction
Trap”(LMIT)[11].NotethatitisalsopossiblethatbothEMIT
andLMITwillbeevident,insuccession,whenanIPerroroccurs.
FunctionTokens(FT)andNOPFills(NF)aretwosoftware-based
techniquesproposedbyvariousauthorssuchasBanyai&Gerke
[2],Campbell [4,5], Coulson[6] andNiaussat [8]to dealwith
programflowerrorsbroughtonbyIPcorruption.
Wedescribebothofthesetechniquesbelow.
2.1 FunctionTokens
TheideabehindFunctionTokens[2,4,5,6,8,10,11]istouse
oneormorefreedatamemorylocations(knownasthe“token”)to
storetheuniqueIDofeachfunction(seeFigure1).Justbeforea
functioniscalled,thetokenisassignedthevalueofthefunction
ID.Thetokenisthencomparedwiththefunction’sIDwithinthe
function itself. If the ID comparison fails, the program will
execute the IP error handler (IPEH); this is diiscussed further
below.
TheaboveschemadescribesthesimplestimplementationofFT,
assuming a one-to-one relationship between caller and callee
functions. However, normal programs usually have functions
with many-to-many relationship, which makes implementation
more complicated. For effective FT implementation, the calls
betweenvariousfunctionsmustbefullymapped.
FTsareimplementedaspartoftheprogramitself,andresultinan
increaseinthefinalcodesize.Coulson[6]estimatesacodeswell
between10-20%inoneFTimplementation.
2.2 NOPFills
NOPFills[4,5,6,8,10,11]arecarriedoutonunusedprogram
locations. Typically, program code iscontiguously programmed
into physical code memory locations from address location
0x0000,whichusuallyleavessomefreememorylocationsatthe
endofthephysicalmemoryspace.
WhatNOPFill(NF)doesistofilltheselocationswiththevalue
of 0x00, equivalent to the “NOP” (No Operation) 8051
instruction. As aresult, anerroneousprogram branchinto this
regionwill notsignificantly altertheprocessorstate. AnIPEH
wouldbelocatedattheendofthephysicalcodememorytodeal
withrunawayprogramexecutioncaughtbytheNOPFill.
Note that, under normal program execution, both the NOP Fill
regionandtheIPEHareunreachable.
2.3 InstructionPointerErrorHandler
The IPEH is a function that carries out the appropriate error
handlingwhenanIPerrorisdetected.Thetypeoferrorhandling
variesgreatlybetweenapplications.Forexample,a“warm”reset
may be appropriate for non-critical systems. Alternatively, a
shutdown may be more appropriate for systems with multiple
redundancies. For some safety-critical applications, such as
engine-managementunits,placingthesystemintoa‘safe’mode
intheeventofanEPerrormaybeparticularlyeffective.
Notethat by locatingthe IPEH atthe endof thephysical code
memory,itispossibleto“share”thisfunctionbetweenNOPFills
and Function Tokens, when both techniques are implemented.
Figure 2 shows a generic physical memorylayout when both
techniquesareimplemented.
3. SIMULATION
ThesimulationdiscussedinthispaperwascarriedoutondScope;
an 8051 simulator developed by Keil GmbH. This simulator is
capable of simulating at the instruction level as well as the C-
syntaxlevel,whichideallysuitsourrequirement.Inaddition,the
simulators’ C-like scripting language allows us to carry out
simulationsalmost autonomously.Unfortunately,its instruction-
level resolution means we could not simulateand detect EMIT
errors,andonlyLMITerrorsareconsideredinthispaper.
3.1 SimulatedPrograms
Three sets of programs, AlarmClock [12], GreenHouse [7] and
CentralHeating[13],wereusedforthesimulationsdiscussedhere.
Eachprogramsethasfourdifferentversionsemployingdifferent
IP error detection and correction techniques. The four
combinationsofeachprogramaresuffixed_A,_B,_Cand_D,
andemploytheerrordetectionandcorrectiontechniquesasso:
Prog_A – Withoutanyformoferrorchecking.
Prog_B – ImplementsNOPFills.
Prog_C – ImplementsFunctionTokens.
Prog_D – ImplementsFunctionTokensandNOPFills
Figure 2 shows the physical code memory layout schematic of
eachprogramversionasitwouldappearwhenprogrammedonto
microcontrollerswithinternalcodememory.Notethatthisfigure
isnottoscale.
Figure1:SchematicofFunctionTokenImplementation
Start
(ID=1)
End
2
FunctionA
(ID=2)
FunctionB
(ID=3)
3
1
2
FT:
FTChecks:
2
Start
(ID=1)
End
2
FunctionA
(ID=2)
FunctionB
(ID=3)
3
1
2
FT:
FTChecks:
2
FT:
FTChecks:
2
All programs were written in C and compiled with the C51
Compiler by Keil GmbH. These programswere chosen for the
simulation as they are representative ofreal-world applications.
Thoughlackingcomputationallyintensivealgorithmsapartfroma
software-basedI2Cprotocol,theseprogramshadcomplexcontrol
structures,themost complexof which,the AlarmClockproject,
wasbuilt on acooperative scheduler[12]. Theseprogramsare
availableviatheirrespectivereferences.
We refer to each program as Alarm_C, Heat_A, etc., or
collectivelyas,program“A”forAlarm_A,Green_AandHeat_A.
Referringto“Alarm”itselfwouldmeanall fourversionsofthat
program.
3.2 ImplementingNFsandFTs
Two methods are generally used when creating the NOP Fill
region. The simpler method involves filling the EPROM
programmer’s code buffer with the value of 0x00, followed by
downloadingthe programcode destinedforthe microcontroller.
Indoingso, allempty locationswould havethe valueof 0x00,
thustheNOPFilliscreated.
ThesecondmethodistocreatetheNOPFillinassemblylanguage
with the help of assembler directives. Although harder to
implement, this method allows greater flexibility and control
especiallywhendifferentNOPFilltopologiesareintended.The
formermethodalsotendstobemoretimeconsuminginthelong
runduetotheoverheadinconfiguringtheEPROMprogrammer
on every programming cycle. Apart from that, modern
microcontrollers with In-circuit Serial Programming (ISP)
programming capabilities can also be programmed without
physically removing the microcontroller. The second “NOP
Filling”methodwasusedinthestudiesreportedhere.
Sincethetest programsweretakenfromvarious sources,allthe
codehadtobemeticulouslyscrutinisedtomapoutallthecallers
and callees of every function, including those called from the
interruptserviceroutine(ISR).Oncethemappingwascomplete,
eachfunctionwasassignedauniqueID.FunctionTokenchecks
were implemented at the start of each function and just after
programexecutionisreturnedtothecallerroutine.
WithISRs,noFunctionTokencheckswerecarriedoutsincethey
couldbecalledfrompracticallyanypartoftheprogram.Though
itispossibletocreatea“local”token,thisapproachwasdeemed
unnecessary,astheISRroutineswereshortandnon-critical.
TheIPEH,asmentionedearlier,residesattheendofthephysical
codememorylocation.Forthesimulationprograms“B”,“C”and
“D”, the IPEH was written in assembler and located at a
predefinedmemorylocationwiththehelpofassemblerdirectives.
Table1showstheprogramandNOPFillsizeofeachprogramas
wellasthenumberofFunctionTokenchecksimplemented.
Due to the increase in code size for Alarm_C and Alarm_D, a
microcontroller with 8kB of internal code memory is assumed,
thoughtheotherprogramscouldfitinto4kBdevices.Thisisdone
toensureastandardbasisofcomparison.
3.3 Simulationprocedure
For theresults to bestatistically convincing,a large numberof
simulationcycleshavetobecarriedout.dScopes’C-likescripting
languagehelpedtoautomatethesimulationprocedure.
The simulation script included all LMIT locations for each
program.Thiswasgeneratedbyan“in-house”programscanning
themicrocontroller-downloadablefile(inIntelH86format).This
script controlled the entire simulation process, classified the
resultsandgeneratedtheappropriatelogfiles.
Onethousandsimulationcycleswerecarriedoutoneachprogram
withanerrorinjectedanywherebetweenthe1stand10000000th
microcontroller instruction cycle. Before commencing each
simulationcycle,theinstruction cyclein whichthe errorwould
occur(ECY),andthecorrespondingerroneousIPvalue(EIP),is
generated randomly. Each simulation cycle also starts from the
beginning,equivalenttoamicrocontrollerreset.
Figure2:GenericMemoryMapwhenImplementingNOP
FillsandFunctionTokens
0x0000
0x1FFF
Programmed
Locations
Empty
Locations
NOPFills
FunctionToken
IPError
Handler
Thesimulatederrorsareclassifiedintofivecategoriesasfollows:
EL – EmptyLocation.Thesimulatederrorpointsthe
IPtoanemptycodememorylocation.
NF – NOP Fill. The simulated error is detected and
correctedbytheNOPFills.
FT – FunctionToken.Thesimulatederrorisdetected
andcorrectedbyanFTcheck.
LMIT– LateMultibyte InstructionTrap. Thesimulated
errorpointstheIPatthesecondorthirdbyteof
amultibyteinstruction.
UE – Undetected Error. The simulated error goes
undetectedbyNForFT.
By evaluating EIP alone, EL, NF and LMIT are immediately
identifiable. The simulation script would first determine if EIP
points to a location outside the programmed code memory, or,
withintheNFregionforprogramsimplementingNF.Ifitdid,the
error was immediately logged as an EL or NF hit and a new
simulationcyclewasstarted.
If EIP pointed to a code memory location within the program
itself(includingtheIPEH,ifany),thesimulationscriptlookedup
theLMITtabletodetermineifthatparticularaddresslocationis
partofthesecondorthirdbyteofamultibyteinstruction.Amatch
in that table caused an LMIT hit to be recorded and a new
simulationcyclewasstarted.
Only when none of the above-mentioned conditions was met
would actualsimulation ofthemicrocontroller fromthe firstto
the ECYth instruction cycle begin. Simulation time is further
shortened by simulating at the fastest possible speed up to the
ECYth cycle, instead of stepping through each instruction. This
wasdonebysettingbreakpointsasnoerrorswereinjectedbefore
theECYthcycle.
Uponthebreakpointtriggering,thevalueoftheIPischangedto
that of EIP by the simulation script. Up to a further 50000
instructioncycleswouldthenbeexecutedinsinglestepmodeto
determineifan FTcheckhas detectedtheerror. OnlyiftheFT
checkfailstodetectanerrorwoulditberecordedasaUEhit.
4. RESULTSANDDISCUSSION
Thesimulationscriptwaswrittentoproducearawtextsummary
ofeachcyclecontainingECYandEIPvalues.TotalhitsforEL,
NF,FT,LMITand UEforeachprogramwerealso displayedat
theendofthesummary,asshowninTable2.
Table2:Simulationresults
Alarm
Clock EL NF FT LMIT UE
A 587 0 0 146 267
B 0 598 0 164 238
C 169 0 460 276 95
D 0 224 405 270 101
Green
House EL NF FT LMIT UE
A 718 0 0 130 152
B 0 711 0 136 153
C 524 0 224 218 34
D 0 526 209 219 46
Central
Heating EL NF FT LMIT UE
A 748 0 0 128 124
B 0 772 0 107 121
C 538 0 145 272 45
D 0 547 163 237 53
4.1 Impactofvariouserrors
Beforediscussingthevariationsbetweendifferentprograms,itis
necessary to discuss the impact of each error category on the
overallprogramreliability.
Jumps to empty code memory locations (EL) should not be
tolerated since program code would be executed at location
0x0000 after the IP points to the address above the highest
physical code memory. This phenomenon is due to memory
aliasingandthoughitissimilartoresettingthemicrocontroller,it
does not reset internal flags and registers to known states. For
embedded systems, this scenario should be avoided, more so
whensafetyisofprimeconcern.
Table1:Programstatistics
Alarm
Clock Totalsize
(bytes) NOPFill
(bytes) FTchecks
(amount)
A 3283 0 0
B 3331 4861 0
C 6535 0 120
D 6535 1645 120
Green
House Totalsize
(bytes) NOPFill
(bytes) FTchecks
(amount)
A 2286 0 0
B 2329 5862 0
C 3940 0 98
D 3940 4245 98
Central
Heating Totalsize
(bytes) NOPFill
(bytes) FTchecks
(amount)
A 1954 0 0
B 1997 6195 0
C 3799 0 120
D 3799 4387 120
On the other hand, any IP errors “falling” into the NOP Fill
regionwillbedetected,andthesuitablerecoverystrategyapplied.
Moreover, only the IP and timing-associated registers change
before the recovery strategy is executed. As a result, this is
probably the best condition for a microcontroller to be in as a
result of IP errors. The main problem with NOP Fills is it is
possiblethat–insystemswithlargeNOPFillareas–therewill
bearelativelylongerror-recoverylatency.Aslightvariationon
the basic NOP Fill technique which is designed to reduce the
recoverylatencyisdiscussedin[11].
Function Tokens do detect IP errors and execute the IP Error
Handler, as shown in programs C and D. However, it must be
stressed that the errors are generally detected some instruction
cyclesaftertheyoccur,asFigure3illustrates.Scenario(i)isthe
typical situation where the IP erroneously “fall” between FT
checksand isdetectedwithin areasonabletime span.However,
scenario(ii)ismuchpreferredastheFTcheckdetectstheerroron
the next instruction cycle: unfortunately, this will very rarely
happen.Inscenario(iii),theFTcheckdiddetecttheIPerror,but
onlyaftercriticalinstructionswereexecuted.
Arguably,theworsterrorsituationhappenswhentheIPcausesan
(L)MIT error. In such circumstances, software-based error
detectionandcorrectiontechniquesmayproveineffective.Hence,
thestateoftheprocessorandprogramflowmaybeunpredictable.
Undetectable Errors (UEs) may also, clearly, prove dangerous,
since the system may still continue to function without any
apparentproblems.Inourexperiment,onlyafewcriticalvariables
were checked to determine system integrity. However, it is
possiblethatmoresubtleproblemscouldarise,suchasincorrect
timerduration,andinputreadings,whichwouldbeveryhardto
detect even with expensive equipment and increased software
complexity.
Note that our simulation actively detects all but “Undetectable
Errors”,whichareinferredbyaprocessofelimination.
4.2 Programvariations
Quite a few points may be made regarding the differences
betweenthevariousprograms.
Thefirstthingtonoteisthevariationincodesize.Aspredicted,
thecodesizesforprogramsemployingerror-checkingroutinesare
largerthan those without(see Table1). However,“B” program
sizesareonlymarginallylargerthan“A”programs,asaresultof
the additional IPEH. By contrast, programs “C” and “D” are
between69% and96%larger thanprograms“A” and“B”. The
huge difference is solely attributed to the implementation of
FunctionTokens,whichinturnisproportionaltothecomplexity
and number of Function Token checks used. Coulson’s [6]
estimatesof10%to20%codeswellareonlyobtainableiftheFT
checksare implementedat thestart and endof eachfunction –
resultinginlessthan100%branchcoverage.
By observing Table 2 alone, we could see that with no error
checking,alargepercentageofIPerrorswillleadtotheexecution
of “empty instructions” (specifically “MOV R7,A”).
ImplementingNOPFillsalonetrapsaroundthesamenumberof
errorsthat would havebeen destined forEL. Weconclude that
NOPFills, whichare easilyimplemented,shouldbeusedinall
situations.
As mentioned earlier, implementing Function Tokens increases
programsize. Asaconsequence,an increaseofLMIThitswas
recordedforprograms“C”and“D”.Thisleadstotheconclusion
that though FT detects and corrects errors, they would also
increasethe probability ofencountering anMIT error,which is
one of the trade-offs of using this technique. The complexity
involved in implementing Function Tokens also opens a new
avenueforsoftwarebugsanddesignerrors.
Theconclusiondrawnbycomparingprograms“B”,“C”and“D”
is most important in this paper. As observed from Table 2,
implementing both techniques simultaneously increases the
number of detected IP errors. However, based on previous
discussion, it would be desirable to have NF detect the errors
insteadofFT.Whenbothtechniquesareimplemented,thesizeof
theNOPFillregiondecreasesduetoanincreaseinprogramsize.
4.3 EffectivenessofNOPFills
The relationship between the NOP Fill region size and its
effectivenessmaynotbeimmediatelyclear.Thekeylieswiththe
assumptionthatwhenanIPerroroccurs,theprobabilityoftheIP
takingonanyaddressablevalue(0to65535)isthesame.Hence,
the size of the NOP Fill region gives a good estimate of its
probabilitytodetect and correctIP errors. Figure4 strengthens
thispointbyshowingthegoodcorrelationbetweenthepercentage
of physical code memory taken up by the NF (black), and the
percentage of errors detected by NF (grey). It also shows the
relationshipbetweenNFsizeandthepercentageoferrorsdetected
byittobedirectlyproportional.Basedonthisfinding, Figure5
showstheinterpolatedresultsforprograms“B”and“D”whenthe
amountofphysicalcodememoryincreases.
Figure3:FunctionTokenErrorDetectionScenarios
Start End
Important/
criticalaction
(i) (ii) (iii)
IPerrorentrypoint FunctionTokencheckingpoint
Start End
Important/
criticalaction
(i) (ii) (iii)
Start EndStart End
Important/
criticalaction
Important/
criticalaction
(i) (ii) (iii)(i)(i) (ii)(ii) (iii)(iii)
IPerrorentrypoint FunctionTokencheckingpointIPerrorentrypointIPerrorentrypoint FunctionTokencheckingpointFunctionTokencheckingpoint
Amathematicalrelationshipbetweencodesize,instructiontypes
andother parameterswiththestatistical effectivenessofFTand
NFcanbefoundin[10].
Thoughitwould begoodto haveaslargeaNOP Fillregionas
possible, this may not an economically-viable solution for all
systems.Hence,acompromisehastobemadebetweenphysical
code memory size and the NF hit probability. There is also a
thresholdbeyond whichincreasedmemorysize haslittleimpact
onNFhitprobability,ascanbeseeninFigure5.
5. CONCLUSION
Function Tokens and NOP Fills do detect and correct errors
associated with IP corruption. However, the effectiveness of
FunctionTokens isquestionableand implementationisan error
prone affair. Overall, FTs may increase a system’s IP error
detectionrate,butitdonotnecessarilyincreaseitsreliability.On
the other hand, NOP Fills are simple and effective, and hence
shouldbeusedinallembeddedsystems.
6. REFERENCES
[1] Armstrong,K.WhatEMCis,andSomeExamplesofEMC
ProblemscausedbySoftware.IEEColloquiumon
ElectromagneticCompatibilityofSoftware(98/471),
Birmingham,UK,1998.
[2] Banyai,C.andGerke,D.EMIDesignTechniquesfor
MicrocontrollersinAutomotiveApplications.Intel
ApplicationNoteAP-711.
[3] Broughton,J.AssessingtheSafetyofNewVehicleControl
Systems.ProceedingsoftheFirstWorldCongresson
ApplicationsofTransportTelematicsandIntelligent
Vehicle-HighwaySystems,Paris,France,1994,2141-2148.
[4] Campbell,D.DesigningforElectromagneticcompatibility
withSingle-ChipMicrocontrollers.MotorolaApplication
NoteAN1263.
[5] Campbell,D.DefensiveSoftwareProgrammingwith
EmbeddedMicrocontrollers.IEEColloquiumon
ElectromagneticCompatibilityofSoftware(98/471),
Birmingham,UK,1998.
[6] Coulson,D.R.EMCTechniquesforMicroprocessor
Software,IEEColloquiumonElectromagneticCompatibility
ofSoftware(98/471),Birmingham,UK,1998.
[7] Meikle,Colin.GreenHouseComputer.EverydayPractical
ElectronicsMagazine,WimbornePublishing,(Jul98)492;
(Aug98)610.
[8] Niaussat,A.SoftwaretechniquesforimprovingST6EMC
performance.STApplicationNoteAN1015/0398.
[9] NHTSALightVehicleAntilockBrakeSystemResearch
ProgramTask4.NationalHighwayTrafficSafety
Administration(NHTSA)Report,1999.
[10]Ong,R.H.L.,Pont,M.J.,Peasgood,W.Acomparisonof
software-basedtechniquesintendedtoincreasethereliability
ofembeddedapplicationsinthepresenceofEMI.
MicroprocessorandMicrosystems,ElsevierScience(in-
press).
[11]Ong,R.H.L.,Pont,M.J.,Peasgood,W.Hardware-Software
TradeoffswhenDevelopingMicrocontroller-Based
ApplicationsforHigh-EMIEnvironments,IEEColloquium
onHardware-SoftwareCo-Design(00/111),London,UK,
2000.
[12]Pont,M.J.PatternsforTime-TriggeredEmbeddedSystems:
BuildingReliableApplicationswiththe8051Familyof
Microcontrollers(inpress).AddisonWesley,2001.(ISBN0-
201-33138-1).
[13]Stone,R.CentralHeatingController.EverydayPractical
ElectronicsMagazine,WimbornePublishing,(Nov96)831.
Figure4:CorrelationbetweenNFhitsandNFsize
Figure5:RelationshipbetweenNFhitsandCodeMemorysize
0.00
0.10
0.20
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00
4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64
Physicalcodememorysize(kB)
ProbabilityofNFhit
ALARM_B ALARM_D
GREEN_B GREEN_D
HEAT_B HEAT_D
0
10
20
30
40
50
60
70
80
90
ALARM_B ALARM_D GREEN_B GREEN_D HEAT_B HEAT_D
Percent(%)
NFRatio(%)
NFHits(%)
