Logical Fault Analysis of Fault Secure Systems Using VHDL

Lieutenant J.M. Coppens, BSc (hon)

A thesis Presented to the School of Graduate Studies

in the Department of Electrical and Compter Engineering

Royal Military College of Canada Kingston, Ontario

In partial fulfillrnent of the requirements for the degree Master of Engineering

May 1997

Copyright O 1997 by J.M. Coppens, Kingston Ontario This thesis may be used within the Department of National Defence but copyright for open publication remains the property of the author.

National Library I*I of Canada Bibliothèque nationale du Canada

Acquisitions and Acquisitions et Bibliogaphic Services services bibliographiques

395 Wellington Street 395. rue Wellington Ottawa ON K1A ON4 Ottawa ON KI A ON4 Canada Canada

Yw? 1SkJ votre M&enw

Our lSle Notre mHrmc8

The author has granted a non- L'auteur a accordé une licence non exclusive licence allowing the exclusive permettant à la National Library of Canada to Bibliothèque nationale du Canada de reproduce, loan, distribute or sell reproduire, prêter, distribuer ou copies of ths thesis in microfom, vendre des copies de cette thèse sous paper or electronic formats. la forme de microfiche/fih, de

reproduction sur papier ou sur format électronique.

The author retains ownership of the L'auteur conserve la propriété du copyright in this thesis. Neither the droit d'auteur qui protège cette thèse. thesis nor substantial extracts kom it Ni la thèse ni des extraits substantiels may be printed or othewise de celle-ci ne doivent être imprimés reproduced without the author's ou autrement reproduits sans son permission. autorisation.

Abstract

This Thesis presents an analysis process targeted for use in the verification

of fault secure systems. Micro-defect modeling based on defective circuit simula-

tion has been used to amve at categories of fault response for cornrnon CMOS

gates, from a commercial standard ce11 library based on a 0.8m BiCMOS process.

The fault modeling covers both logical and performance degradation faulty behav-

ior including IDDQ faults. The VHDL environment has been used for automated

defect injection and circuit output monitoring. VHDL models of CMOS gates

have been created for use in the analysis of cntical design blocks. The analysis

process was then applied to two benchmarks to veri@ their secureness. in order to

arrive at a figure of ment for fault security.

Keywords: VLSI. Defect modeling, Fault Modeling, Testing, Built in Test. Fault Secure, Fail Safe, Fault Injection.

Acknowledgments

1 would like to express my appreciation to my thesis CO-advison. Dr. D. Al- Khalili and Dr. C. Rozon, for their guidance and patience throughour this work.

I would also like to thank. Captain K. Latour. Captain P. Spencer, and T. Broten for their technical advice.

Dedication

This thesis is dedicated to Roxane whose knowledge, understanding, and support. made al1 this possible.

VLSI

IC

MOS

CMOS

SA0

SA 1

NM

VTC

~PHL

t~~~

IDDQ

BIST

SFA

VHSIC

VHDL

S WIFI

MTTF

CSE

Very Large Scale Integrarion

Integrated Circuit

Meta1 Oxide Semiconductor

Complementary Metal Oxide Semiconductor

Stuck at logic level O

Stuck at logic level I

Noise Margin

Voltage Transfer Characteristics

Propagation delay, High to Low output switch

Propagation deiay, Low to High output switch

Quiescent Power Supply Current

Built In SeIf Test

Security Fault Analysis

Very High Speed Integrated Circuit

VHSIC Hardware Definition Language

Software Irnplemented Fault Injection

Mean Time to Failure

Communications Security Establishment

Table of Contents

Chapter

Abstract

Keywords

Abbreviations

Vita

1 Introduction

1.1 Overview

1.2 Motivation

1.3 Synopsis

2 Security Analysis

3.1 Introduction

2.2 Terms and Definitions

2.2.1 Fault Security

2.2.2 Path to Error Generation

7.3 Security Analysis Techniques

2.3.1 Goals of Security Anaiysis

2.3.2 Analysis Methodologies

3 Defect Modeling and Fault Categories

3.1 Introduction

3.2 Defects

3.2.1 IC Defect Ongins

3.2.2 Defect Modeling

3.3 Faults

3.3.1 Logical and Performance

3.3.2 Fault Categories

3.3.3 Fault to Defect Mapping

Page

Table of Contents

Chapter

4 VHDL Modeling

4.1 Introduction

4.2 Characteristics

4.2.1 Component Modeling

4.2.2 Signals

4.3 Fault Injection Methodologies

j Security Analysis Technique

5.1 Introduction

5.2 Environment Framework

5.2.1 Design Constraints

5.2.2 Framework Assurnptions

5.3 Analysis Flow

5.3.1 Overview

5.3.2 Technology Defect Analysis

5.3.3 Gate ModeIing

5.3.4 Bridging Defect Models

5.3.5 Simulation Scenarios

5 -4 Techniques For Results Analysis

5.4.1 Design Aid

5.4.2 Security Failure Analysis

6 Application of Methodology in a Benchmark

6.1 Introduction

6.2 Benchmark Description

6.2.1 Parity Checking System

6.2.2 Complementary Checking System

Page

4- 1

Table of Contents

Chapter

6.3 Methodology Application

Technolou Defect Analysis

Simulation Scenarios

Results on Single Defect injection Scenario

Bridge Defect Injection

Results on Error Masking Scenario

Fault Secunty Figure of Merit

Life Cycle Analysis

7 Conclusion and Future Work

7.1 Surnmary of Objectives

7.2 Concluding Remarks

7.3 Future Research

References

ANNEX A - Fault Category Coverage Statistics for CMOS Gates

ANNEX B - Thesis VHDL Package

ANNEX C - Gate Model Code Example

Page

6-5

6-5

6-6

6-9

6- 18

6-19

6-2 1

6-23

List of Figures

Number Title Page

Sample Design Process

Path of Error Generation From a Defect

Verification in the Design Cycle

Markov Model of a Fault Secure System

Fault Injection at the System Level of Abstraction

Gate Level Fault Injection

Defect Sources and Time

Physical Defect and Schematic Model

Open Defect on a Gate Net

Gate to Charnel Pinhole Model for NMOS Transistor

MOS Transistor Defect Model for OpenIShort Defects

NMOS Transistor Gate Open Defect Model

Stuck at Fault Conditions

Çequential Fault Example

Propagation Increase Example

Noise Margin and IDDQ Fault Exarnple

NAND Gate Example

Defective NAND Categorized Gate Behavior

Entity Declaration

Architectural Examples

Fault Injection Using Simulation Commanc

Using Saboteurs for Fault Injection

Saboteur Code Exarnple

Fault Injection Using Mutants

4.7 Mutant VHDL Code ExampIe 4- 10

5.1 Logical Levels and Restoring Values

5.2 Resolved Signal Example and Resolution Table used for CMOS Technolow

5 -3 Example Method for Fannout Loading Determination

5.4 Flow Diagram of Security Fault Analysis Technique

Technology Anaiysis Defect Mapping File Exarnple

Input Pattern Excitation File Exarnple

VHDL Mutant Model Inter-face

Tmth Table Example for CMOS NAND Gate

Defect and Fault Category VHDL Type Definitions

Injection Decision Code Example from an Inverter Gate

IDDQ Increase Warning Message

Noise Margin Reduction Waming Message

W D L Bridge Model Interface

Bridging Defects Within a Logic Gate

Simulation Experiment

Fault Coverage Vs. Number of Vectors

Fault Masking

Statistical Model for T h e Based Fault Secure Calcutations

Exarnple Plot for Time to Failure Analysis

6.1 Benchmark Example with Parity Checker

6.2 Benchmark Exarnple with Complementary Checker

6.3 Timing Diagram for Complementary Checker Operation

6.4 Setup Time Violations for CMOS D-Latch

6.5 Flow Diagram for Simulation Trials

6.6 Setup of Simulations

6.7 IDoQ and Complementary Code E m r Coverage for Hard Defects

6.8 IooQ and Complementary Code Error Coverage 6- 17

6.9 Statistical Mode1 of the Parity Checker for Time Based Fault Secure 6-73 Calculations

6.10 Statistical Mode1 of the Complementary Checker 6-25

6.1 1 Probability of Secure Operation over time for Parity Benchmark 6-27

6.12 Probability of Secure Operation over time for Complementary 6-28 Benchmark

- sii -

List of Tables

Nurnber Title

MOS Generic Defect List

Generic Gate Level Faults

NAND Example Faulty Response to Hard Defects

NAND Exarnple Faulty Response to Sofi Defects

Fault Modeling Categories

ALU Error Generation Statistics

Parity Checker Error Generation Statistics

Complementary Code Checker Errors Generated by Defect Injection

Security Failures for Parity Checker

Security Failures for Complementary Checker

IDDQ Detections Caused by Defect Injections into ALU

IDDQ Detections Caused by Defect Injections into Parity Checker

IDDQ Detections Caused by Defect Injections into Complementary Checker

Bridge Defect Error Generation

Scenario 2 Security Failures for Parity Checker

Scenario 2 Security Failures for Complementary Checker

Page

3 -6

3-10

3-14

3-15

3-17

6-10

6-1 1

6-12

6-13

6-13

6-15

6.15

6-16

6-18

6-19

6-20

Chapter 1

Introduction

1.1 Overview

For systems where security and reliability are critical, the design must be tolerant to

defects. These tolerant designs must identiQ conditions where the correct operation of the system

is compromised, then react to maintain system integrity, a process commonly referred to as fault

security. As integration levels and design complexity continue to rise within critical systems. sys-

tems increasingly rely on built-in self testing, or error checking schemes as a means to flag a

faulty circuit response. and thus presumably detect device failure [1.2,3.4].

Employment of the critical circuit will dictate the action taken by the system to remain

fault secure. In cryptographic applications, this maintenance of integrity may involve shutting the

system down to prevent data leakage. In some aircraft avionics, redundant circuits are used to

both flag faulty behavior. This redundancy also ensures that the correct operation is not inter-

rupted. Similar design approaches of redundancy and fault diagnostics are also employed in sat-

ellite, railway, and nuclear control systems to allow their continuous correct operation.

Clearly, testing for functionality is insufficient to ensure their operation. The level of con-

fidence in such systems is formed by the analysis methodology and modeling techniques. Verifi-

cation of these critical designs must be complete and satisfy certain requirements. Fault secure

circuits must correctly identiQ when a failure has occurred, and act accordingly to detected fail-

ures. Therefore, any analysis of them must consider realistic operational scenarios, and the

implementation technology[5].

In addition to the above verification requirernents, trends in the implementation of designs

show that the fault analysis process is consistently being pushed forward in the design cycle of

Introduction

Figure 1.1. Reasons for this are clear, cost savings of detecting possible problems earl. and time-

to-market requirements demonstrate the advantages of a concurrent fault analysis. This is the

dilemma facing designers of cntical fault secure systems. A verification process is needed which

can provide realistic appraisal of a systems fault secunty, and can also be applied within the con-

fines of the design cycle of Figure 1.1.

- - - - - - . - - - -

Concept of System Functionality

1 Behavioral Description 1 1 of System Functionality 1

' Verification of Functional Behavior

Synthesis of Design into netlist or Structural description)

Design Modifications Verification of Design Functionality

Figure 1.1 Sample Design Process

To fil1 this need there have been studies aimed at developing statistical or probability met-

ncs which can be applied to critical logic blocks for the determination of their fault secu-

rity[1.3.10]. Typically, these metrics can be applied early in the design cycle however, the

determination of parameters used in the metric calculations is ofien unclear and too general. leav-

ing in doubt the results of these calculations.

The use of fault injection has been advocated by studies to carry out verifications for fault-

tolerant systems[3.6,7,1 O]. Fault injection involves the deliberate introduction of faulty behavior

into a circuit, which is then rnonitored for a response. Chapter two discusses some of the existing

methodologies proposed for such fault analysis. Comrnon injection methods include using physi-

cal realizations, or circuit simulation.

Physical methodologies are costly and limited to areas accessible by device pins or scan

chahs. A simulation approach to would be more appropriate leading to more pertinent results.

The use of simulation for fault injection starts by modeling criticaf blocks using netlist models.

describing the circuit at either the architectural level or gate level. Architectural (or behavioral)

level models limit the possible injectable fault list to logical faults occuning on bus or signal lines

between hnctional blocks. In this case, localized effects and technology specific behavior cannot

be investigated. Gate level circuit modeling is an improvernent, allowing localized effects to be

simulated. However, until now only logical faults have been the focus of gate level fault injec-

tion. Therefore. shortcomings in these verification techniques arise when technoloe dependant

modelins and analysis are required. since many defects do not manifest logical faulty behavior.

In contrast to the above previous approaches, this research c h e s out defect injection into

circuits. allowing for technology specific analysis of system behavior in a multi-fault environ-

ment. Further, since this analysis process models the critical circuits at a gate Ievel of abstraction.

localized effects of faulty behavior can also be explored. ïh i s methodology meets the goal of

developing a technique for use in the venfication of critical fault secure designs, or the cntical

blocks within large high reliability systerns.

To satisQ the design time and flexibility requirements, concepts used for software imple-

mented fault injection (SWIFI) are offered as an efficient means for venfication f?om the concept

stage to final synthesizable design, without the need for excessive additional injection circuitry.

VHSIC Hardware Definition Language (VHDL) and like HDLs present themselves as the ideal

environment for SWIFI. In particular, VHDL's ability to mode1 systems at vimially every level of

abstraction. coupled with its ability to interchange or mix behavioral and stmcniral models. make

Introduction

it flexible enough to cany out fault-tolerant testing concurrent with the design cycle.

[2,3,6,7,819,1 O]

1.2 Motivation

As laid out in the overview, users of highly reliable, and fault secure systems have sought

a technique for verification applicable throughout the design flow. The Communications Security

Establishment (CSE) is one such agency concemed with the analysis of secure designs. Verifica-

tion of cryptographie and similar high reliability designs is crucial before their acceptance into

service. In modem VLSI or ULSI environments, current analysis techniques used by CSE are

inefficient and produce questionable results. Automation and simulation are required. The tech-

nique developed during this thesis will attempt to fil1 this void in fault secure verification.

Therefore the goal of this methodology is the development of an automated detailed veri-

fication technique for logical fault secure designs. The output of this analysis should be a figure

representing the probability that the fault tolerant system will operate in a fault secure state. This

figure will represent the level of confidence inherent in a system's design. Additionally. the anal-

ysis of the rnethodology results should also be able to highlight areas of the design where

improvements in fault or error detection coverage are necessary.

Although the primary concem is the CMOS technology, evolution of the methodology to

inchde other IC technologies is also a requirement.

Finally, this environment must be platfonn independent, and compatible between cornmon

VLSI CAD tools.

In the past, HDL models have been used to represent logical elements for use in fault anal-

ysis[2,6,7]. However, those previous works (and indeed most fault simulation tools) have not

explored the fault universe beyond the logical shick-at (SA) when generating models. Defective

circuit modeling should include more than just logical faults, thus this methodology also

addresses a variety of performance degradation faults not currently dealt with commercial tools.

Introduction

1.3 Synopsis

in chapter 2, ternis and definitions necessary for the discussion of security fault analysis

are discussed. Then a review of current fault analysis techniques will be presented.

Chapter 3 will re-acquaint the reader to issues in defect modeling, and circuit faulty

behavior. A MOS defect mode1 will be described along with fault response examples.

The applicability of VHDL to defective circuit modeling will be discussed in Chapter 4.

Methods of employing defect injection into VHDL models will also be illustrated.

A full technique description and venfication flow is presented in Chapter 5. A set of

defect injectable gate-level models have been developed, and will be described.

Chapter 6 presents the application of the technique, by carrying out the verification pro-

cess on two benchmark circuits. Relative measures of their fault security is calculated and a life-

cycle analysis is conducted.

Lastly, Chapter 7 offers concluding remarks and cornments for fünire work.

Chapter 2

Security Analysis

2.1 Introduction

When systems are considered from a fault security or reliability viewpoint a unit "fails"

when its observed behavior is different from that which is to be expected, given its present state

and stimulus. For a logical circuit such unintended behavior is ofien interpreted as errors. Such

erroneous behavior. propagated to the output signals of the system block could cause the output

results of later design blocks processing those signais to be in error. If such events occurred in an

airliner landing gear controller, as an example, the results could be catastrophic[l I l .

Preventing this leakage of erroneous signals fiom system blocks within a critical system is

the goal of a fault secure or fault tolerant design. A fault secure circuit will detect its own faulty

behavior and react to prevent the error leakage; either by switching to redundant blocks, for

highly reliable systems: or by shutting the system down. as is comrnon in cryptographie applica-

tions.

IdentiQing faulty conditions requires that a circuit possessing diagnostic ability, either

incorporated into the design or as provided by extemal test hardware. Incorporating a self-check-

ing ability into the design has become a popular means of ensunng that fault secure circuits main-

tain their integrity. Many implementations of these built-in self tests (BIST) have been devised

and put into practice for failure critical applications. Two BIST methods are described below.

A method comrnon to highly reliable systems is to design circuits with multiple duplicate

modules, then compare the results From each module to amve at a final output. The cornparison

could be a straight majority voting principle. where the most popular output value is adopted by

the system. However. more comrnonly. a system detemiines the output value which is majority

Secunty Anal y sis 2 - 1

voted, then reduces the voting weight of those modules which arrived at different results. In this

manner. those modules generating consistently erroneous outputs are ignored. while the more

likely correct output is consistently propagated to the rest of the system[4.11].

A second method of BIST and error detection uses a coding scheme together with an error

checker. Error encoding makes use of a relationship between the bit values of output signals. The

relation c m be as simple as a bus containing an equal number of logical"1"s (in the case of parity

codes), or it may involve the generation of additional check bits. The checking hardware then

ensures that the output signals observe the bit relationship or it Rags the output as being in error.

The error detection abilities of such error detection techniques are lirnited by the selection of the

coding scheme used. However, the overhead required to irnplement the error encoding and

checking hardware is often reasonable when compared to the duplication of the design into a

number of distinct modules. As it is also a cornmon method of error detection used, allowing con-

current error checking and operations. error encoding will be the primary focus for this thesis

methodology[l, 41.

In the next section various terms relevant to fault security will be defined. including for-

mal requirements for a fault secure system[12]. The goals for the verification of these fault secure

systems are presented and discussed along with some current methodologies for conducting fault

analysis on fault secure systems.

2.2 Terms and Definitions

2.2.1 Fault Security

For a system using a coding scheme as a means of BIST, there is a valid set of input vec-

tors, 1, defined. This system, or a block within the system utilizing the coding scheme, will also

have a valid set of output codewords. 0. This implies that each specific input i where i E 1. wil1

produce a fauit free (or "correct") output response O, such that O E O. Finally, some systems rnay

Security Xnalysis

also have a set of "safe" output states. S. A safe output state is one which is not the correct output

( O ) for the cumenr input (i). but it is an output which cannot be mistaken for a valid output value

and thus will not be passed to later blocks. An exarnple of a safe state is one where the error

detection flag is set, indicating that the output is not to be trusted.

Using this notation, a forma1 definition for fault secureness can be given. A circuit is said

to be fault secure if in the presence of faults, a valid input i E I generates either the correct output

or an output which cannot be mistaken for another codeword (thus the circuit output e 0)[1.12].

A self-testing circuit is one which in the presence of a fault, will eventually produce an

invaiid codeword (Le. output E O) as an output. An extension of this idea is the totally self

checking (TSC) design. A faulty TSC circuit will continue producing the correct output (output o

for input i). until eventually the output becomes an invalid codeword (output cr O). Thus a TSC

circuit is both self-testing and fault secure[l. 121.

Finally, an extension of the fault secure concept is a fail-safe design. Such circuits are

ofien found in highly reliable or security critical systems. A fault occumng within a fail-safe cir-

cuit with an input i E I will produce either the correct output (O) or a safe output S[1.12].

2.2.2 Path to Error Generation

Typical forma1 methods of verification considered three states of defective circuit opera-

tion [1,3,13]. As illustrated in Figure 2.1, a physical defect occurs in a circuit. This defect may

instantaneously cause a fault. or it may remain dormant until activated by the circuit inputs, tem-

perature or other stimuli. Once excited. a fault cornes into being in whatever level of abstraction

the system is modeled at. The fault could be an incorrect value on a signal line or bus line. If the

fault remains hidden from an observable point (typically the outputs of a circuit block or the sys-

tem). the fault is said to be latent. Propagation of this faulty behavior to an observation point. or

the generation of an observable faulty state, is ten-ned an error. Fault latency or defect dormancy

is not a solution to reducing circuit failures, since complex or multiple errors are likely to result as

accumulated faults are excited. These multiple errors are generally more difficult for checking

schemes to detect.

Excitation Defect FauIt Error Secure

Pl fault 1 defect 1

Latency Dormancy Unsecure

Figure 2.1. Path of Error Generation fiom a Defect

Classically. errors are assumed to be logical in nature. However. because of the intended

direction for this work. and the requirement of the developed technique to consider future tech-

nologies. the assurnption that a fault will cause a change in logical values cannot be made. Thus

the technique proposed in this thesis work is to develop a methodology which can be used to

uncover the propagation of any faults. logical or othenvise. Later, when considering a proposed

design and technology, the methodology can filter the potential faulty behavior to consider only

those responses of interest which will generate "erron".

The previous discussion highlights a potential inadequacy of commercial fault analyzers.

Such tools provide a measure of the testability of a design, and can derennine the propagation of

faults to the circuit's outputs. However, such fault coverage statistics are not sufficient to describe

the fault security of a system since typically their analysis is based on a list of logical faults.

2.3 Security Analysis Techniques

2.3.1 Goals of Security Analysis

Security .\nalysis

Having discussed the operations and properties of fault secure systems. the requirements

for the analysis of such systems can be investigated. Such analysis can be said to have two

thmsts:

1 ) Assurance of the fault security.

2) Highlight areas for design improvement.

The primary goal is to ensure that a proposed secure design will maintain its fault secure

properties. The requirements of such analysis, termed "verification". can be summarized by the

question, "How can oae obtain a level of confidence in the system's ability to maintain fault secu-

rity in the presence of defects?" The level of confidence obtained by a verification is best repre-

sented by the probability P(Secure Operations), of the design not failing, as illustrated by

equation 2.1. For most secunty analysis methodologies and venfications. this probability is their

figure of merit.

P {Secure Operation) = 1 - P (Failure)

= 1 - P {Failure 1 defect) *P (defect )

= 1 - [ P {Failure 1 Fault) * P{Fault 1 defect) * P {defect) ]

= 1 - [ PiFailure 1 Errorl * P{Error 1 Fault } * PIFault 1 defect)

* P (defect) ] (2.1)

The probability of a defect being excited into a fault is represented by P {Fault 1 defect 1.

The probability of a fault rnanifesting itself as an error in the system is expressed by P{Error 1

Fault). Finally, the probability of these errors being passed out of the system, or out of a checked

block. without detection (or removal by redundancy) is P (FaiIure 1 Error).

If a system was implemented without fault security attributes. such as the ability to detect

errors, then P(Fai1ure 1 Error} = 1. Thus the target of a fault secure design would be to have

P(Fai1ure 1 error} -b O, meaning that the system detects al1 errors. Meanwhile. increasing

P{Error 1 Fault} -+ 1 and P(Fau1t 1 defect) -+ 1. is also desired to avoid domancy or Iatency

within the system and the possibility of multiple fault interactions.

The naniral by-product of such a verification process would be to use any weaknesses in

security uncovered by the analysis results to highlight areas within the system susceptible to faults

or defects. Afier verificaiion, if the probability of failure is higher than that acceptable for the

cntical nature of the system's application, then irnprovements to the design will be necessary.

Irnprovement of a design's fault security c m assume several forms, the most comrnon of which

are discussed in Chapter 5. These design modifications might be undertaken to increase the

defect coverage of the checking system by increasing the number of checked signal nets within a

block. Altematively. the code scheme itself may not provide the necessary error coverage. requir-

ing an upgrade of the system's coding scheme to a stronger code able to detect additional bit

errors.

The relationship between the verification and design aid processes is an iterative one. As

shown in Figure 2.2. afier a system meets the functional requirements of its operations. its secu-

rity against potential defecis is assessed. Test scenarios are developed to represent the operating

conditions of the circuit. The design is analyzed for these scenanos and a figure of merit is

obtained. If the required confidence in fault security has not been met, design modifications may

be undertaken as discussed above. The circuit is then re-verified to ensure that fault tolerant per-

formance bas been met.

Functional Testing I 1

hprovements Verification Incorporated Process into Design

3

flaws in .

Continuation of Design Cycle

Figure 2.2. Verification in the Design Cycle

In order to implement the verification process as illustrated in Figure 2.2, three

be addressed:

1) First, a process used to conduct the analysis is chosen.

2) Secondly, a level of abstraction for circuit and fault modeling is selected.

3) Thirdly, the tested scenarios are defined.

Selection of an analysis process is intimately comected to both the levef of abstraction

used for modeling and the test scenanos. As the level of abstraction is lowered (fiom system's

level to gate level) more details regarding the construction of the design become availabie, and an

in-depth analysis can be employed. In addition, the abstraction level will set bounds on the poten-

tial design improvement. Testing scenarios consist of input stimulus and a list of potential faults

or defects. The input pattern stimulus attempts to match operation conditions. and thus is com-

mon for a11 modehg levels and methodologies. However. the list of faults or defects possible for

consideration will be selected depending on those which are meaningful for the chosen analysis

methodology. Additionally, the level of modeling abstraction used b y the methodology to

describe the system will decide if the injectable faults include logical errors on IC pins or defects

into logic gates.

2.3.2 Analysis Methodologies

Previous studies have introduced several methodologies for the analysis of fault secure

systems[1.2.3,5.6.7,16.23]. There have been two trends in the evolution of these techniques. One

direction performs an analysis using probabilistic models. The other trend seeks to employ sorne

means of fault injection, and simulation.

Probability or Statistical Modeling

In order to meet the demand of system venfication as early as possible in the design cycle,

frameworks have been developed for the creation of probabilistic models based upon circuit

parameters. These analytical rnodels are ofien composed of reliability block diagrams. Markov

state transitions, or Petri nets[l, 141.

Using a Markov mode1 as an example, the use of these probability analysis can be illus-

trated. Figure 2.3 shows the form of a Markov modei of a fault secure systern[l]. For any given

design incorporating reliability or fault tolerant amibutes (Le. fault secure, fail-safe, or strongly

fault secure), there are four possible system states. The first is normal fault fiee operations (FF).

The remaining three states represent the possible outcomes fiom a defect occumng within the cir-

cuit. If the defect is excited to produce a faulty response, the circuit can either detect and flag this

fault, leading to a failed secure (FS) condition. Alternatively, the defect's faulty response may

propagate to the system's outputs, and thus to later system blocks, without any detection flag

causing an unsecure failure (FU). The final option is one of defect latency (L). In this case. the

defect present within a design may not be excited to generate a faulty output response. The defect

will remain dormant or latent within the circuit until excited causing a secure or unsecure failure.

Sscurity Analysis 2 - 5

Therefore. whereas a state of FS or FU is an endpoint for the possible Markov transitions. a srate

of latency remains dynaniic dependant upon the coverage of the input stimulus and the rate at

which

Figure 2.3 Markov Mode1 of a Fault Secure System[l]

P(Fau1t Security} = 1 - Probability of an Unsecure Failure

= 1 - PfÙ, + PL(PL~us) 1 (2.2)

By resolving the possibilities required to move between states, a rneasure of the fault secu-

rity of a design can be determined. The probabilities governing the transitions between the possi-

ble states are calculated based upon the qualitative attributes of the circuit complexity, the error

detection capabilities of the coding scheme used by the checker, and the defect/fault coverage of

the input patterns applied to the system. In the case of the Markov mode1 of Figure 2.3, equation

7.2 gives the figure of merit discussed earlier. The probability of a defect causing faulty behavior

which is undetectable by the checking scheme is represented by the probability PhS. Conversely,

Pfs is the probability of a defect's faulty behavior being detected by the checker. The probability

of fault latency or defect dorrnancy for a given input set is PL. Given that a circuit containing a

defect or fault which is unexcited or unobservable, the probability of it remaining so is PLL

whereas the probability of the latent faulty behavior being detected is PLfs. Finally the probability

of a latent faulty behavior passing undetected outside the checked block is PLhs Equation 2.2

Security .Analysis 2 - 9

then represents the total probability that a defect within a circuit will not cause an unsecure fail-

ure.

Missing from the above Markov model is a time dependency. The mode1 of Figure 2.3

assumes that a defect already exists within the circuit. If the rate at which defects occurred within

the circuit (ofien called their "amval rate") was known then the probabilities could be calculated

over tirne. in such cases these models could be used to model the fault security of the system dur-

ing its life cycle. as the defect arriva1 rate typically changes with an IC's age. In addition, suc h an

analysis can provide the "instantaneous" estimation of the fault security of a system during tran-

sient increases in defects, as may be caused by environmental conditions.

However, there are drawbacks to this methodology. Having been conceived For applica-

tion early in the design process, these frameworks may not consider the target technology of the

IC implementation. Without technology consideration, these methodologies can focus only on

errors involving logical values. Another concern is centered around the determination of the

model pararneters themselves. Parameter calculations such as probabilities of fault latency, rnay

involve steps including the counting of nets or pins as a measure of circuit complexity[i]. Natu-

rally this parameter becomes more abstract and unmanageable as circuit complexity increases.

Finally, the parametric models do not take specific input panerns or system conditions into con-

sideration as would be the case where sirnulation is used. Rather, attempts are made to generalize

the faulty conditions instead of highlighting specific input vectors or defects which may threaten

the inregrity of the system.

Therefore. while these parametric models do provide useful information towards an esti-

mation of a system's dependability in a timely fashion, the calculations necessary to determine the

transition probabilities quickly become curnbersome for complex designs, or as more circuit

detail is considered. The probability methodologies by themselves are sufficient to prove the the-

oretical detection capabilities of the coding used, yet they lack the detail to provide any firm level

of confidence in a systems fault security. However, when more definitive simulation techniques

are used to detemine the transition probabilities, these probability models can be used efficiently

in a time dependant secwity analysis.

Fault ~Modeling and Injection

The second trend in secwity analysis is to develop methodologies incorporating fault

modeling. Fault models can be applied at levels of abstraction from the system level to the gare

level; these will be discussed later in the next Chapter. In such methodologies, analysis is con-

ducted by the injection of faults into the design model, and observing the faulty response. In this

section, current techniques of fault injection are descnbed including manual analysis, fault simu-

lation at the architectural level and gate-level, and finally injecting faults into a physical proto-

type-

Some existing techniques employed for secwity critical systems verification involve the

manual injection of faults into circuits[l5]. In such methodologies, circuits or components are

considered under the influence of a given fault condition and the circuit's output response is deter-

mined. Although logical errors are most cornmon. virhially any fault model can be used to deter-

mine output response. The output response is then propagated to the following blocks in the

design until the overall response of the system is detemined. Afier an investigation of the faults

of interest, an appraisal of the fault security of the system can be expressed as a percentage of

faults causing unsecure failure.

Manual examination of defective cornponents does allow for a detailed analysis. However.

there is an obvious time cost for complex calcuiations. Hand calculations may be feasible for

investigations of small cornponents containing only a few gates, but computations will quickly

become unmanageable for systems of a reasonable size of several thousand gates. Clearly auto-

mation is required.

To be applicable early in the design cycle, many analysis methodologies modeled systerns

ar the architectural level of abstraction. In such techniques faults are injected in the form of logic

errors. If the design model exists only as a behavior, the erroneous or non-codeword patterns are

applied to the circuit inputs. This form of analysis is referred to as "pin-level" fault injection.

There is also the possibility that some structural decomposition of the design is known. In such

cases. the logic faults can be applied directly ont0 the bus lines b e ~ e e n the design blocks. rele-

Sscurity Anal ysis

vant to the specific circuit topo log^ or functions.

System Under Input Patterns O Output Response

Investigation

Force ~ o ~ i c 1 ' Pin Level Analysis

1

I System Under Investigation I

I Force '~o~ ic ' 1 ' on a bus line I

Bus Level Analysis

1 I

Figure 2.4. Fault Injection at the System Level of Abstraction

Input Patterns O 1 +

I

Illustrated in Figure 2.4, the injectable fault models are applied to both intemal bus lines

I

. I I Output Response

!

, / BIock 1

OI'-

and input pins. Simulations of these faulted systems yield a measure of the design's ability to

Block 2

uncover errors on those faulted signal lines. With this approach. conditions of specific logical

errors, and input patterns can be tested; representing an improvement in accuracy and detail over

probability modeling approaches.

Yet, architectural level fault analysis c m provide misleading results. Without knowledge

of technology specific structures and performance, the list of possible "faults" is lirnited to stuck

at 1 's and O's[3,6,7,11,16]. Again, this raises the issue of realistic analysis results since no map-

pins is established between the injected logical erron and actual defective circuit components.

Improved approaches to injection techniques have descended below architectural level

descriptions of systems. The prediction is that at the gate level of abstraction, a more definite con-

fidence in a circuits reliability can be obtained. Approaches to gate-level fault injection Vary

between existing tools and methodologies. Some techniques employ complex bridging between

the signal lines of the circuit. Othen inject faults by mapping (or masking) signal bits to faulty

values which are then applied to the inputs and outputs of existing gate models[6,7]. Still other

methodologies force faults onto signal lines in a similar fashion to the architectural level tech-

niques[l6]. Exarnples of these approaches are shown in Figure 2.5.

Simulations of circuits containing faults at the gate level of abstraction will detemine

overall fault security of the circuit as a percentage of total faults, and uncover the location of

faults which may compromise the system's security. The result is a more complete picture of the

security of a design than is possibly derived from architectural level models.

Signal line Bridging Short

s r-J+j-

Bit Masking or Mapping

Force line to logic 'O'

I/ Logical Stuck At Faults

Figure 2.5. Gate Level Fault Injection

Gate level approaches have significant merit, and are discussed further in Chapter 4.

There are however, drawbacks to gate-level fault analysis. When modeling at lower levels of

abstraction there is a loss of generality in the analysis results. The faulty behavior used for mod-

eling defective circuits may be specific for the gate structure of a particular process, bringing into

question the applicability of the results to implementations fabricated using different technolo-

gies. A second concem is the defect site selection. As the level of modeling descends a circuit's

hierchy. the possible selections for a defect or fault's electrical location within the circuit

increases. While this creates the advantage of investigating localized behavioral results. site

selection is an additional source of possible error unless exhaustive injection is undertaken.

Thirdly, gate level modeling implies that a gate level implementation of the design is available.

This is not a concern for final security verification of systems, since netlist mode1 is typically

available. Finally, the simulation time required to analyze a detailed gate-mode1 description is

larger than for architectural models.

Previous work has focused upon the injection of logical faults in the signal lines between

eates. None of these approaches have performed an inductive fault analysis style of modeling the C

faults for injection into systems under test[S.17,18,23]. As a result. no direct link is made

between the injectable faults and possible defect mechanisms. A defect injection solves this

dilernma of realistic fault lists, since defect rnodeling includes al1 possible faul ty behavior. Sys-

tems can then be studied under the infiuence of fauity behavior such as reductions in signal per-

formance or circuit current increases.

The last injection methodology currently employed for fault security analysis is conducted

using a physical implementation of the circuit. The emergence of rapid prototyping technologies

and heavy-ion radiation Iead to the ability to inject faults into these physical implementations of a

system. A more cornmon rnethod of physical fault injection uses "pin level" faults which are

applied to the inputs of a prototype circuit[3]. In such techniques, faulty input patterns are forced

onto the input pins of the IC, or the ion radiation is used to 'Yip" register values within the physi-

cal circuit. The same limitations in the possible fault list, as those inherent in the architectural

level modeling discussed earlier, are present for this physical methodology. Further, since a

physical realization is needed, the extra tirne and expense to fabncate (or program) a prototype

design will place this form of analysis too late in the design cycle.

Improvements in recent fault injection methodologies are clearly aimed at a detailed anai-

ysis of logical systems. Injection techniques and simulations of defective circuits can be com-

bined to create models suitable for defect injection at the gate level of abstraction. For the highly

critical applications envisioned for such automated analysis, gate-level resolution and multiple

fault conditions will need to be considered. Potential improvements in the trust placed in analysis

results are possible because of the realistic fault responses provided by defect injection into gate

models. This makes defect injection. conducted at the gate-level of abstraction the method of

choice for future fault security analysis.

Security Xnalysis

Chapter 3

Defect Modeling and Fault Categories

3.1 Introduction

In order to achieve a valid fault security analysis, the gate models and their appiications

must be as realistic as possible. By first considering the defects as the mechanism for generating

Bults within a given technology, a complete fault set can be established. In this chapter. physical

anomalies common for the CMOS are investigated. Simulations of defective circuits. are used to

eenerate categorïes of faulty gate behavior and to fom a basis for defective circuit modeling. b

3.2 Defects

3.2.1 IC Defect Origins

A physical anomaly present in a transistor or interconnect is termed a defect. A conve-

nient classification for the source of physical defects can be made. depending on the time the fail-

ure occurred: during the fabrication process and assembly or during in-service operations. They

eenerally lead to time dependant failures such as the well known "bathtub" curve shown in Figure c.

3.1 [4.25]. Early in the lifecycle of a system, the high failure rates are dorninated by fabrication

defects. At the end of the lifecycle, another increase in the failure rate is due to wear-out defects.

In critical systems, fault secure behavior must be maintained throughout the system's life-span.

thus both fabrication and wear-out defects must be considered in any technoloey analysis.

Chapter 3

i n 1

I ( ~ e a r - o u t Mechanisrns 1 Fabrication Errors - Electrornigration

r Oxide Breakdown c Process Impurities - - - - - - - - - - - - C

* Mask misaligrment Doping errors

Figure 3.1. Defect Sources and Time

Design errors can be another source causing defective circuit operation. Improperly

applied scaling of devices. or violation of process design rules are the two common mechanisms

for these errors.

Fabrication Process Defects

Failures in ICs resulting fiom defects occurring during the fabrication process are defined

by the yield of the process. Process monitoring and manufacturing tests (such as device bum-in.

current testing, or voltage stress testing) are applied to ICs dunng production in atternpts to elimi-

nate defective devices entering into service. Even though modem defect escapes from these man-

ufacninng testing are becoming small. consideration must be given for this source class.

Fabrication defects are not typically ataibuted to hurnan error, rather they stem from fabri-

cation process imperfections or abnomalities. When considering these imperfections their

effects may be viewed as global (circuit wide) or localized to a particular device. Mechanisms for

global fabrication errors include photolithic mask mis-aiignment and silicon wafer imperfections. - Localized or point-defects can result from such physical conditions as process impurities, or thin-

ning coverage of metallization steps[17,18.19,20]. One additional source for Iocalized defects

results from variations in device doping, which can cause parametric deviations in the MOS

device11 7,18,20].

In-Service Defec ts

In-service defects pose a threat to the reliability of an IC, which in tum affects its ability to

maintain secure operation. As geornetry sizes in integration are rapidly scaled down. device cur-

rent densities and electric field strength increase. Studies into deep sub micron processes. have

illustrated their elevated susceptibility to the in-service class of defects[24]. Phenomena such as

electromigration. oxide Wear out, and hot-carrier effects represent aging mechanisms which can

lead to shorts and opens between device terminals andlor interconnects, or affect the parameters

of the devices themselves[23].

Electromigration in metal intercomects is a cumulative process. As current densities

increase. electron momentum can be transferred to atoms of the conducting material. Over time.

material can be "swept" along the conductor path leading to a "void" or break in the conductive

path. Conversely. the displaced material may accumulate nearby causing a short to interconnects

in proximity.

Hot-carrier effects are more significant for NMOS devices than for PMOS

devicesr2 1,22.24]. Hot-carrier degradation is a condition whereby charged particles (electrons

for a NMOS device) are injected into the gate oxide iayer. Two mechanisms have been identi-

fied[î 1.221. The first is Quasi-Elastic scattenng of chamel electrons. the second is impact ioniza-

tion. In the fint case, hi& energy (hot) eiectrons in the channel jump the potential bamer of the

gate interface and enter the gate oxide. Those which are not swept back into the channel by the

gate field add to a gate current or can accumulate. Impact ionization occurs when an NMOS tran- C

sistor is operating in the saturated region. Hot electrons traveling along the channel create elec-

tron-hole pain at the drain. While most eiectrons and holes are swept away by the gate field.

adding to the substrate current, some electrons may have sufficient kinetic energy to enter into the

gate oxide. In either case, electrons accumulating in the gate oxide create a trapped charge. Caus-

ing NMOS performance degradation as the threshold voltage is altered.

Chapter 3

In addition to the above ageing or wear-out mechanism. environmental stimulus can

cause defects wirhin ICs. Static charges. or voltage spikes on the pins of a circuit. can breakdown

dielectric materials, including the gate oxide layer of MOS transistors, causing pinholes and

shorts[17,18,24].

3.2.2 Defect Modeling

For this research, opens and shorts occuming in CMOS devices were modefed using para-

sitic circuit elements placed between the electrical sites of the defect. For most defect instances a

simple paralleled resistance and capacitance (shown in Figure 3.2) is sufficient. There are how-

ever. two exceptions.

Gate-Drain short Interconnect Break

Figure 3.2. Physical Defect and Schematic Mode1

The first exception occurs as a result of an open on a MOS gate. S h o w in Figure 3.3. a

gate interconnect break occurring during the operation of a circuit has been modeled by two

extreme initial conditions. If the gate net was being driven to the supply voltage at the time of

defect occurrence, then there will be a charge trapped in the gate of the MOS transistor as mod-

eled by the parasitic capacitors in Figure 3.3. in another case, if the net was discharged prior to

the defect occurrence, then the gate will have no trapped charge. The effect of these two condi-

tions is to introduce a memory in the gate net, keeping the device on or off dependant upon the

initial conditions. There is one other possibility for an open gate net. This floating net could be

influenced by another interconnect line in its proximity. In such cases, layout information would

Chapter 3 3 - 4

be an a priori essential for detemining which of the surrounding signal lines could influence the

open gate net. This eRect was not modeled due to the likely lack of detailed layout information

for fauit secure circuits.

VDD

Figure 3.3. Open Defect on a Gate Net

The second exception case occurs as a result of a gate oxide pinhole located over the

device channel. A pinhole in the gate oxide of a MOS transistor creares a short between the gate

and the chamel region beneath. This defect is modelled by two parasitic transistors and resis-

tors[ 1 81. The parameters of these two parasitic transistors, such as channel length. are dependant

upon the physical location of the defect. The resultant pinhole defect mode1 for NMOS device is

provided in Figure 3.4.

Chapter 3

Drain

P

Core transistor width reduced by defect size

.C

. J drain-to-pinhole parasitic transistor

Gate

1 parasitic bdnsistor

O Source

Figure 3.4. Gate to Channel Pinhole Mode1 for a NMOS Transistor

A consideration of the possible defect sites for a typical MOS technology leads to a nine

defect transistor model. These nine defects are listed in Table 3.1.

Table 3.1. MOS Generic Defect List

Defect Defec t

Gate Drain Short Drain Open

Gate Source Short Source Open

Drain Source Short Drain Substrate Short 1 The sub-circuits modeling the opens and shorts defects were combined to form a defective

transistor model comprised of circuit elements as shown in Figure 3.5. This model can be used to

construct CMOS logic gates and to perform defective circuit simulation. For modeling a gate

pinhole defect during simulation. the circuit of Figure 3.4 is used.

- - - - - - -

Gate Chamel Short

Gate Open

Chapter 3

Source Substrate Short

Defect Free

Figure 3.5. MOS Transistor Defect Mode1 for Open/Shon Defects

S ~ d i e s have provided statistics for the physical sizes of defects within ICs[18, I9.îOl.

These studies also provide typical open and short resistance values for the model's parasitic cir-

cuit elements[l8.19]. Two defecr classes are identified. "Hard" defects, which represent severe

physical conditions. manifest faults usually logical in nature. In contrast, "Sofi" defects rnay be

of srnaller physical size, or the begimings of a larger defect. Typically, gates influenced by a soft

defect will exhibit a performance degradation. Performance degradation and logical fault condi-

tions will be discussed in the next section.

The critical resistive values (for both shorts and opens). defining a boundary benveen

these rwo classes of defects have been discussed in previous studies[l8.19]. Results of this

research suggest the following defect resistance values:

"Hard" Defects: Open resistance of 100MOhm or more; and

Short resistances of I KOhm or less.

"Soft" Defects: Open resistances of 500KOhm to 1 OOMOhrn: and

Short resistances of 5KOhm to 1KOhm.

Due to the cntical nature of this analysis rnethodology, the worst case or boundary values

of the above resistances were chosen for the defect models. fhe output response from simula-

tions of logic gates consmicted from the defective transistor models shown in Figure 3.4. 3.5 and

3.6. forrned the basis for the defective circuit mappings of the next section.

VDD

Gate Net 1- nBuk

Figure 3.6. NMOS Transistor Gate Open Defect Mode1

Chapter 3

3.3 Faults

3.3.1 Logical and Performance

If a defect within a circuit is excited such that it affects the output of that circuit. then a

fault is said to have occurred. Thus a fault is a description of the effect or symptom of the defect.

Faults can be lumped into two broad categories as described below.

The first category is called logical faults. In logical faults, the output signal of a faulty cir-

cuit still maintains valid voltage levels and input noise margins of the technology. Further, the

timing characteristics of faulty devices if switching occurs, are also maintained. However, the

fault will cause an incorrect output value. The classical example of this type of fault is the stuck-

at fault model. Other logical fault examples include altered logic functions. and sequential behav-

io r.

The second fault category is performance degradation. Circuits having faults of this type

may still produce proper output functions, but the characteristic of the output signal is altered.

Examples of such degradations can be reduced noise margins, reduced output voltage swing (not

sufficient to be considered stuck at), or increased propagation delay.

3.3.2 Fault Categories

Having established a transistor level defect model suitable for CMOS technologies, the

response of vanous gate structures infiuenced by each of the nine defects needed to be deter-

mined. In previous work, analog simulations were performed using circuits contained within

Nortel's 0 . 8 ~ BiCMOS standard ce11 library, consmcted using the MOSFET model of Figure 3.6

with comrnon gates [17,18]. Results were obtained for an exhaustive gate input pattern and defect

injection of both the "Hard and "Soft" ranges of defect parameters. The behavioral resuits

yielded the set of generic fault categories shown in Table 3.2, covenng both logical and perfor-

mance degradation faults. From these responses, a mapping can be established between a defec-

tive circuit and its faulty output for each gate structure of interest.

Chapter 3

Table 3.2. Generic Gate Level Faults.

l Fault Categones

Delay Faults

Possible Mechanism

Snick-at (SA) Faults

Sequential Faults

Channel pinholes. floating gate charge decay.

Inputs/outputs shorted to VDD/ VSS

NMOS or PMOS terrninals stuck open

Noise Margin faults Pinholes, NMOSRMOS stuck on

Shorts. transistors stuck on. pin- holes

Stuck at Faults

Classical fault modeling employed stuck at conditions on signal lines as a means for mod-

eling circuits influenced by short or open defects. A stuck at condition on a net is essentially

equivalent to a low resistance short between that signai line and either the VSS (stuck at O) or

VDD (stuck at 1) supply. Another snick at condition considered for this work is a signal line

becorning stuck at another signal line's value. In such situations the net with the stuck at fault

tracks the value of influencing net. Examples of both stuck at faults are shown in Figure 3.7

VDD VDD

VDD

input Stuck At Logicai " 1 ,, 4

OF+ . ; \-+=-O Output Stuck

YI at ~nput Value

Figure 3.7. Stuck at Fault Conditions

Chapter 3

Sequential Faults

A sequential fault is one for which a sequence of inputs must be applied to the gate in

order to activate the fault. Figure 3.8 illustrates a possible defect mechanism for a sequential

fault and its behavior. In this case. a "Hard" (very hi& resistance) break in the comection of the

NMOS transistor to the VSS supply is the cause of a sequential fault. If the gate's output was Iow

before the open defect occurred, then a logical "O" will continue on the gate's output. If however.

the gate is first "initialized" so that its output is at the VDD supply (logical "1" ) then the load

capacitor (Cr), is charged to VDD. When the gate input is then switched to logical "1" the

NMOS is prohibited from clearing the charge on the Ioad capacitance because of the open path.

VDD

Input Pattern: 0 4 1

Break in Path to VSS 1 VSS

Fault Free Response

Response with Open Defect

Figure 3.8. Sequential Fault Example

Delay Faults

An increase in propagation delay is the first of three performance degradation categories

modeled in this study. Figure 3.9 presents an example defect. which would cause an increase in

the propagation delay of the gate. In this case, a resistance is placed in the path of the current dis-

charging the load capacitance by a "soft" open of the connection to the VSS supply. When the

inverter attempts to pull the output low, this RC circuit increases the time required. Dependant

upon the seventy and type of the defect, the increase in delay may be placed in either the Delay -

Chapter 3 3 - 1 1

1 or Delay-2 sub-categories. Both categones are defined with respect to the defect-free operation

of the gate. If a defect increases the propagation delay of a gate by more than 20% but less than

50%. then the gate is considered to exhibit behavior defined by the Delay- 1 category. If however.

the delay increase is greater than 50 % of the defect fiee propagation delay. the faulty behavior is

classified as Delay-2.

Input O

Pattern:

- ;nupq Lower Resistance Break in Path to V .SS I defect -

Fault Free Response

vss

Figure 3.9. Propagation Increase

Noise iMargin Faults and Current Increases

VSS Time

Response with Open Defect

VSS Time

Examp te

The next example, s h o w in Figure 3.10' covers the two remaining categories of defects.

The most obvious example of a noise margin defect is one where the output is prevented from

achieving M l swing between the supply voltages. A "soft" short between the source and drain of

an inverter's NMOS transistor will prevent the output signal frorn reaching the VDD supply volt-

age. In addition, the shori will provide a path for increased static current (termed quiescent or

Iddq) Bow between the two supplies. Once again, dependant upon the type and severity of the

defect, two possible sub-classifications of noise margin (NM) faults can be defined. A reduction

in the NM (average of VIH - VOL and VOH - VIL) of greater than 20 % is classified as a voltage

transfer characteristic (VTC) degradation fault. If the reduced noise margin is still between 80 $6

to 50 % of its defect Free value then the fault is a VTC- 1 type. If the reduction in noise rnargin is

Chapter 3

Iower than 50 % of its defect fiee vaIue, then the behavior is classified as a VTC-2 type of îàult.

Quiescent current or IDDQ draw can be a usefbl testing method for CMOS ICs[l7.18.24].

To reflect this form of faulty behavior, quiescent current is monitored during defective circuit sim-

ulation. For this snidy, the IDDQ threshold current above which a CMOS circuit is considered

faulty is 200 PA.

VDD

Input Pattern: dC Fault Free Response

Higher Resistance L t Source Drain Short - - IDDQ VSS

OUT

Response with Open Defect

Tirne iDoQ Response

Figure 3.10. Noise Margin and Iddq Fault Example

3.3.3 Fault to Defect Mapping

Using the defect categories fkom Table 3.1, an example NAND gate can be used to illus-

trate the mapping of defects to faulty response. Figure 3.11 provides the standard structure of a

CMOS NAND gate. Each transistor (MI to M4) is simulated for each of the 9 possible defects.

for both "Hard" and "Sofi" values. The output of the gate is monitored and classified. A sampIe

Chapter 3 3 - 13

of the classification is presented in Tables 3.3 and 3.4 for the case where transistor M2 is inflicted

with two possible short defects and two open defects. TabIe 3.3 contains the response for "Hard"

defect mode1 values, and Table 3.4 describes the faulty behavior for "Soft" defects. n i e second

colurnn provides the categorized fault response of the gate. Colurnn three lists any input pattern

that is necessary to excite the defect, or to observe each of the possible fault categories. Note that

sequential inputs are required for the gate open defects, considering two cases: trapped charge. or

no trapped charge.

Figure 3.11. NAM3 Gate Example

Table 3.3. NAND Example Faulty Response to Hard Defects

Defect (Hard) I Faul t Response 1 Input Necessary

1 M2 Gate-Source Short 1 Out SA 1 , Iddq Increase / Any (logical); I l (Iddq) 1 1 M? Gate Open <NO Charge) 1 Sequential 1 xO or Ox + 1 1 (Sequential) 1

Chapter 3

M2 Drain Open SequentiaI 1 xO or Ox + 1 1 (Srquential)

Table 3.4. NAND Example Faulty Response to Soi? Defects

l Defect (Sot?) I Fault Response / Input Necessary

1 M2 Gate-Source Short 1 Reduced NM. Iddq Increase. 1 x 1 (NM): 1 1 (Iddq) 1 1 M2 Gate Open 1 Large increase in delay. 1 0 1 + 1 1 (delay) 1

Defect mode1 simulations and response analysis were performed for several basic CMOS

Dates under the influence of both "Hard" and "Soft" defects. A surnmary of these simulation z

results. providing the statistical descriptions of the behavior of the CMOS gate. is presented for

the NAND in the charts of Figure 3.12. Similar charts for other CMOS gates are presented in

Annex A[17.18].

M2 Drain Open

Chapter 3

Reduced NM. large increase in de lay.

1 1 (NM): Out I +O(delay )

There are 36 Total Defects

No Stuck At Delay VTC Faul t

Type of Faults Iddq

No Stuck At Delay VTC Fault Type of Faults

Iddq

Figure 3.12. Defective NAND Categorized Gate Behavior

The numbers on the y-axis are the total possible defects causing the behavior of each cate-

gory. Noteworthy is that for restable fault categories (Stuck at, Iddq, and Delays) these charts

represent the possible defect coverages by the testing methods for each gate of interest.

Simulation response resulis compiled for the NAND gate and for other gate structures.

lead to the creation of a detailed fault respoose list. This list was designed for use by the fault

secure verification technique to mode1 defective circuit behavior. A sample of ihis expanded fault

Chapter 3

list is given below in Table 3.5. The "Symbol" Iisted in the first column for rach type of fault is a

code used by the VHDL models as discussed in Chapter 5. A description of each type of inject-

able faulty behavior is given in the second column.

Table 3.5. Fault Modeling Categories

1 AA 1 Output Stuck At (SA) 1 1 BA 1 Delay -1 tplh 1 AB

AC

AD

/ AF 1 Input "B" SA O 1 BF 1 VTC-1 Reduction from VSS 1 AE

1 AH 1 ~ n p u t 'Y SA 1 1 BH 1 VTC- 1 Reduction h m VDD 1

OutputSAO

Input "A" SA 1

Input "A" SA O

Input "B" SA 1

I ( VSS

BB

BC

BD

AI

AJ

AK

Delay -1 tphl

Delay -2 tplh

Delay -2 tphl

BE

1 1 sequeniiil A VSS Break

Sequential B VDD Break

Sequential B VSS Break

VTC-1 Reduction fiom VDD

Input "C" SA O

Output SA Input "A"

Output SA Input "B"

AL

AM

Iddq increase: Input 00

Iddq Increase: Input 10

Output SA Input "C"

Sequential A VDD Break

BO 1 Iddq Increase: Input I I I

BI

BJ

BK

-

BP [ lddq Increase: Input 100 1

and VSS

DS Reduction from VDD

DS Reduction frorn VSS

DS Reduction from VDD and

AQ Sequential C VDD Break BQ

AR

AS

AT

AU

Iddq Increase: Input 10 1

BR

BS

GG

SequentialCVSSBreak

Output SA Input "A"

Output SA Input "B" Function change

,

Iddq Increase: Input 1 10

Iddq Increase: Input 1 I 1

Fault Free

Where necessary. the input patterns necessary to activate the fault is included. Examples

of this are the Iddq increases which are activated by a particular input. or the increases in rise and

fa11 times which are dependant on the input switching.

Discriminating fault category excitation by the input paaern allows these same fault mod-

eIs to be used by models of gate-level behavior for different gate structures. The increased mode1

complexity resulting from distinguishing the electrical "source" of the fault, provides the oppor-

tunity for realistic pattern dependant defect simulations. At the sarne time, for cases where this

distinction is not necessary, generic (non-input dependant) fault modeling is still possible. For

instance. the injection of both an increase in and tplh will have the same effect as injecting a

generic increase in delay.

Chapter 3

Chapter 4

VHDL Modeling

4.1 Introduction

VHDL has now become an industry standard hardware description language. During both

the design specification and fùnctional testing, VHDL descriptions of systems are often created to

mode1 the system behavior. or (during the synthesis process) for the partitioning of a design into

an implementation. As hardware description languages become more popular, VHDL system

descriptions become increasingly available during the design process. It seems natural that the

advantageous characteristics of VHDL as a tool for circuit modeling and development would be

applied to defective circuit modeling. test generation, and design verification[2.6.7.16..16.77].

The use of language based methodologies towards system venfication is gaining accep-

tance. Borrowing concepts of faulty behavior rnodeling used in software testing. HDL versions of

"mutation" and g'sabotag" have been devised for injecting faults into system descriptions[2.6].

In this chapter several useful characteristics of VHDL are discussed as they relate to cir-

cuits modeling. Then, techniques for rhe implernentation of fault injection in the VHDL environ-

ment are suggested.

4.2 C haracteristics

4.2.1 Component Modeling

In the VHDL environrnent, cornponents connected by signals are used to mode1 circuit

structures. A component can be created to represent circuits of any complexity. from a single

transistor to entire computer networks. A VHDL component has two elements to its description.

First an interface is defined using an "entity" declaration. ï h e statements contained within a com-

ponent's entity declaration provide a list of VO ports and variables available for access by extemal

models. Figure 4.1 illustrates a simple entity declaration for a generic gate. The second element

in a component model is a description of its functionality. Such descriptions are called architec-

tures, and can be defined behaviorally or structurally. Examples of both types are provided in Fig-

ure 4.2.

A behavioral description is comprised of a processes which performs the hnction of the

component. Although the instructions contained within a process are carried out sequentially.

each separate process is executed concurrent with al1 others. Accommodation of the concurrent

execution of these processes require that the simulation time be "fiozen" until the statements can

be evaluated, and new outputs be generated.

- 1 Entity Gate is 1 /

Port ( A : IN bit; B : IN bit; Z : OUT bit ); /

End Gate;

Figure 4.1. Entity Declaration.

A structural description is a hierarchy of subcomponents connected by signals. The sub-

components are bound to their descriptive models by a configuration statement contained in the

component's architecture. As each is instantiated, their ports are mapped to the signals of the

structure. The formation of a structural description implies a prior knowledge of the circuit's

implementation. However, the model defining any subcomponent can br easily replaced by

changing the binding specified in the configuration statement. The effect of such abilities implies

that a component can have several modeled implementations. An example of a structural descrip-

VHDL blodeling

tion

their

is ziven in the nght hand side of Figure 4.2.

Architecture Behavior of Gate is; . . . . . .

Begin Process: functions IF B = 'O' THEN

CASE A is when '1 ' then ZOUT <= '1 '; when 'O' then ZOUT <= '0';

ELSlF B='1' THEN CASE A is

when '1 ' then ZOUT <= '0'; when 'O' then ZOUT <= '1 ';

END IF; end functions; * - . . , .

end behavior

Architecture Structure of Gate is . . . . . .

Signal signall : bit; . . . . . .

for sub-componentl : use work.and(behave) . . . . . .

Begin sub-componentl : a n d j s t e

Port rnap ( A => signall, B => signal2, Z => signal3 );

sub-component2 : invgate Port map (

A => signal3, Z => signal4 );

ZOUT <= signal4; . . . . . .

end structure;

Figure 4.2. Architectural Examples

Behavioral descriptions allow systems or circuits to be modeled without knowledge of

structure. These higher level abstracted models are easy to construct and readily portable

between targeted technologies. since the function perfomed by logical cornponents does not

change. However, there are difficulties for using behavioral abstractions in defective circuit anal-

ysis. Although behavioral architectures can be used for the "pin-level" fault analysis discussed in

Chapter 7. defects tend to have localized or unique effects on the circuits in which they occur- To

model defects/faults occumng within a component described behaviorally, the description must

provide an output response for al1 possible defect-input stimulus cornbinations. Very quickly the

model description will becorne unreasooably large and complex for circuits beyond the size of

basic gates.

Structural architectures of systems allow fault analysis to be conducted on any subcompo-

nent. or if this subcomponent is defined smicturally the analysis can extend to sub-subcompo-

nents. continuing to descend the hierarchy until behavioral models are reached. By replacing

VHDL Modeling 4 - 3

subcomponents or altering signal paths, structural models can be used to snidy different irnple-

mentations of components. This flexibility will enable the insertion of faulty/defective subcom-

ponents into otherwise fault free system, effectively modeling the localized effects of a realistic

physical defect.

When the intent is to mode1 an entire IC design using VHDL, neither approach by itself

may prove efficient, since the blocks responsible for ensuring fault secure operations are typically.

embedded within the larger system. Naturally, within a component's architecture. behavioral and

stnictural descriptions can be mixed, and cornplex-circuit modeling takes advantage of both

types.[8.9] In such cases. high level behavioral models may be sufficient for blocks within the

systern which do not influence the fault security of the critical circuit functions. Selection of

these non-security critical blocks must be cautious not to include those functions whose faulty

operations would prevent the propagation of faulty behavior to observation points within the cir-

cuit or the outputs. The design blocks whose fault security is under scrutiny should be modeIed

using structural architectures. A structural description will enable rnodeling of defective subcom-

ponents. In addition any design changes made for irnprovement can be back annotated into the

component design. Careful combinations of behavioral and structural modeling techniques will

allow both detailed analysis while irnproving processing efficiency over solely structural descrip-

tions.

4.2.2 Signals

When a component assigns a value to a signal, that value will propagate to al1 other com-

ponents (or processes) connected to that signal in zero time. To accomplish concurrent changes in

signal lines the signal value is evaluated, and the results propagated at the beginning of each sim-

ulation time-step. During those evaluation and assignments, as in process evaluation. the simula-

tor fieezes time until al1 of the concurrent statements and assignrnents are completed. Therefore.

if a propagation delay is required for a signal to travel between components, then the delay must

be applied before the signal is assigned.

Signals in VHDL behave in a similar manner to wires or interconnects. As in the physical

VHDL klodcling 4 - 4

circuit. multiple drivers can attempt to force values ont0 resolved signal lines. A resolved signal

uses a resolution hnction to determine the dominant or resulting signal line value. when dr i~en

by multiple sources. Another useful charactenstic of VHDL signals is the ability to define cus-

tom types. These signals can utilize any format (records, busses. etc.) or values (characten. logi-

cal values, or integer). Further, for any signal type, resolution functions or logical operators can

also be customized. Typically, the definitions of signal types and their operators or functions are

contained in a listing called a "package".

In circuit modeling, where cases of signal drive strength and intercomect contentions are

an important consideration. the usefulness of these abilities is clear. Signal values represen ting

voltage levels or drive strengths typical for technologies can be defined. For technologies of

interest, signal resolution hnctions, and logical functions can be placed in a package representing

that technology. Models c m then switch their signals and functions between packages. essen-

tially switching technologies.

4.3 Fault Injection Methodologies

Many approaches have been proposed for using VHDL for fault injection[2.6.7.16].

Regardless of the actual methodology, al1 techniques fa11 into one of two categories. The first cat-

egory relies on simulator commands. The second requires the modification of the VHDL design

code.

The most obvious advantage of using the first category is that no modification of the

VHDL code is required. Simulation engine commands can be used to force values on a signal

line. force values into variables, or skip sections of processes. Using these actions, stuck-at faults

can be injected. For each desired fault injected, a sequence of simulator commands is necessary.

Figure 4.3 provides a sequence of steps resulting in a snick-at condition being injected on

a signai line. Two scenarios are possible. The first situation considers a constant stuck-at condi-

tion being applied to the signal lines. When the thne for the fault to be injected is reached. then

the desired fault value is injected ont0 the signal line. The simulation is then resumed until the

VHDL Illodeiing 4 - 5

observation period has expired. If a transient fault analysis is required. then the simulation forced

value can be removed from the signal line. and fault free simulation can be resumed for the

remainder of the observation period.

Steps For Stuck-at fault Injection Additional Steps for Transient Fault Injection

Continue simulation for the observation period.

@

Figure 4.3 Fault Injection Using Simulation Comrnands

Sirnulate Design until fault time is reached. I

The obvious drawback of using simulation commands is the Ievel of involvement required

by the user during the simulation process. Although scripting can be used to reduce this involve-

ment. there is still no portability between simulation engines. A sirnilar, secondary concem is thar

simulator comrnands necessary for the injection steps may not be available for a11 VHDL simula-

tion packages.

Several groups have elected to modi& the VHDL code to ca ry out their injection. Arlet

et al. introduced terminology usefùl in the description of VHDL modification.[6] The terminol-

ogy identifies two common techniques of VHDL modification: placement of saboteurs: and

mode1 mutation. Figure 4.4 contains an examples o f saboteur placement. Figure 4.5 illustrates

methods in mode1 mutation.

VHDL Modeling

"Saboteurs" are placed extemally to the existing logic gate. and can be used without alter-

ing existing device models. There are two possible placements of saboteurs. The saboteur in Fig-

ure 4.4(a) is used in series with existing cornponents. [n such cases, faults are injected by forcing

changes to the output signal of the component before it reaches the remainder of the circuit.

When placed in parallel, as in Figure 4.4(b), saboteurs make use of signal resolution functions to

inject faults on Iines. Saboteurs can be used to model a wide variety of faults. However becausc

they inject faults without knowledge of the gate they are affecting, saboteurs cannot model faults

below the gate level of abstraction. Most cornmonly, they are used to force stuck-at conditions

on signal lines, or to simulate environmental conditions such as noise or ESD.

Normal Component Nonna1 Cornponent Mode1 Saboteur

Mode1 Fault free

output

Fault injection 1 controI

a) Using Saboteurs in Series

Saboteur Normal Component Models Fault contra, injection -q O cr] 0

Common Signal bus

b) Using Saboteurs in Parallel

Figure 4.4. Using Saboteurs for Fault Injection

The code for a saboteur can be quite simple as shown in Figure 4.5. In this example. a

control signal is used to activate the fùnction of the saboteur. The faulty value is then forced on

the signal line, or in some cases, a mapping is performed for the input signal to arrive at the output

value.

Entity Saboteur is PORT (

ff-input : IN bit; ctl : IN control; ah-out : OUT bit; );

End Saboteur;

Architecture behav of Saboteur is

Begin Process faulty CASE ctl IS

when 'on' then altout <= '0'; when 'off' then altout <= ff-intput;

END CASE; END faulty;

end behav;

Figure 4.5. Sabatour Code Examples.

"Mutation" of VHDL models c m be accomplished in two fashions. The simplest f o m of

mutation is to replace existing component models with faulty ones. This can be as simple as

replacing a NAND gate with an AND gate, or it may involve replacement of a component with a

copy of itself containing faulty statements. Both these techniques are s h o w in Figure 4.6(a) &

( b ).

Mutation takes advantage of the power of VHDL as a modeling tool. The complete faulty

behavior of a component can be modeled by a mutant and simulated in place of the functionin_g

device, receiving and providing the same signal paths. Because the faulty response is generated

intemally within the model, mutants can be used at any level of abstraction for fault injection.

However, the use of mutants requires that the original gate models be replaced by the new mutant

models. Replacement of existing models can be accomplished automatically by changing the

configuration statements in system architecture description.

VHDL Modelintg

Normal Cornponent Faulty Component Mode1 Model

a) Component Replacement by Functional Mutation

LMutant Normal Component Cornponent Model

Primary Inputs - Output

Fault injection control

b) Replacement using Controllable Mutation

Figure 4.6. Fault injection Using Mutants

Mutants can be controllable through the use of signals as shown in Figure 4.6(b). or global

variable assignments[8,9.27]. A controHable mutant is a mode1 which contains dormant or

altered code blocks within the normal gate description. The fault injection signals activates these

.'mutantw code blocks which in tum will change the operation of the logic gate itself. Controllable

mutants have the advantages over non-controllable types. Using controllable mutants. fault frer

and defective behavior can be simulated using the same model. Controls can activateldeactivate

the faulty behavior of the component, or the controls can be used to choose the type of faulty

behavior to be activated.

VHDL modelling of mutants can be very complex dependant on the number of possible

fault responses rnodeled by the mutant. In the code example of Figure 4.7 a control signal is used

to select between the type of fault to be injected into the gaie model. This example considered

two faults: logical stuck at and an increase in propagation delay

Entity Mutant-NAND is PORT (

A : IN bit; B : IN bit; ctl : IN control; Z : OUT bit; );

End MutantNAND;

Architecture behav of MutantNAND is

Begin Process faulty (A,B)

VARIABLE out-temp, outold : bit; VARIABLE prop :TIME := O ns;

out-temp := A NAND B; CASE ctl IS

when 'sa1 ' => out-temp := '1 '; when 'saO' => outtemp := '0'; when 'tphl' =>

IF (out-old = '1' && out-temp = '0') THEN prop := 2 ns;

END IF; when 'tplh' =>

IF (out-old = 'O' && outtemp = '1 ') THEN prop := 2 ns;

END IF; END CASE;

z <= out-temp AFTER prop; outold := out-temp; END faulty;

end behav;

Figure 4.7. Mutant VHDL Code Example

Although there is an overhead associated with the addition of mutant control signals (or

variables). it is felt that this penalty is outweighed by the advantages of this approach. Controlla-

ble mutants allow the most flexibility of the types of faults modeled. The methodology proposed

by this work also makes use of saboteurs to mode1 bridging defects between intercomects. A

more complete description of the mutant gate and bridging models will be described in the next

chapter.

VHDL blodeIIing

Chapter 5

Security Analysis Technique

5.1 Introduction

This chapter describes the c hni que de veloped to perform security fault analysis of the

critical building blocks within fault secure systems. The analysis process developed here is based

on a defect injection: the deliberate introduction of modeled physical anomalies into a target cir-

cuit. This injection is carried out using gate level models of faulty circuit behavior.

The process presented here consists of tasks ranging fiom circuit modeling and test pattern

generation to the calculation of a figure of merit used as an indicator of the levrl of fault secure-

ness for the system targeted by the methodology analysis.

It is proposed that this rnodeled defect injection coupled with gate level circuit simulation

will produce realistic measures of the error detection abilities of a fault secure system[2.3]. The

simulation results are then used to satisfy the goals of the security fault analysis as suggested in

Chapter 2: namely design aid and design verification. The use of simulation enables this process

to be conducted before prototypes need to be fabricated. while modeling defects at the gate level

is favorable for uncovering areas at potential risk for causing a security compromise.

The defect injection and defective circuit simulation are handled entirely by the VHDL

models created dunng this thesis. Packages have been developed to contain types and functions

required by the analysis process. ïhese packages are comparable with the IEEE Standard Logic.

Although this methodology has been developed for CMOS technologies. there exists the possi-

Sscuri t! .-\nalysis Tcc hniqut.

bility to expand the gate and fault models to other technologies.

In the next section the environment frarnework for this analysis technique. including

assumptions, is defined. Following that, the flow of a typical analysis using this technique is pre-

sented and descnbed. Finally, simulation scenarios and calculations using the simulation data are

discussed.

5.2 Environment Framework

5.2.1 Design Constraints

When designing a large fault secure systern, a security fault analysis process may be

employed in two likely areas. One case is to ver$ the fault security of a previous design for use

in the new system. Another situation might be to provide a common framework metric for design

agencies (interna1 or extemal) to veriQ the fault security of their designs pnor to submission for

inclusion into the systems. Finally. submitted designs are analyzed, to ver@ the designer's fault

security results and to ensure interactions between other design blocks do not reduce the overall

huit security of the system.

Given these possible ernployment scenarios, three conditions with respect to the tarseted

circuits's design must be satisfied to use this process to its full potential:

1 ) A structural decomposition of the design must be available. preferably in a

netlist format.

2) A target technology or technologies for the implernentation of the design should

be known.

3) The design must make use of some form of hardware checking scheme to ensure

its fault secureness.

Socurity .\nalysis T echniqus

The first and second constraint ensure that the circuit under analysis is represented accu-

rately. Having chosen to conduct defective behavior analysis at the gate level of abstraction.

knowledge of the circuit's structure is necessary to allow for proper replacement of logic gates

with defect injectable mutant style rnodels. ïhe defect lists used by these models can also differ

between technologies. Realistic faulty behavior modeling has aspects specific to each technolog.

For instance, output voltage swings, propagation delay, and static current draw. Therefore.

knowledge of the technology of interest is required to obtain an accurate and reliable fault model-

ing.

The final constraint is to ensure a measurable means for amving at meaningful failure data

for use in statistical analysis. During simulations, there must be some observable system output

that reflects the current state (operational, or failed secure) of the system. A "Pass/Fail" flag on a

checking scheme would meet this requirement. Other fault tolerant systems may make use of

software diagnostic programs running on the system to ensure its fault secureness. however. this

methodology has no ability to gauge their success.

5.2.2 Framework Assumptions

Signal Levels

The logic signal type "levels" has been defined for use in this analysis process. Al1 sig-

nals of type "levels" are translatable to IEEE Standard Logic values. Logical " H and "L" repre-

sent degraded logical "1" and "0" respectively. Although degraded, these values are still within

the noise margins of the technology, and are usually restored to the full logic "1" and "0" by sub-

sequent logic gates. A seriously degraded signal would be represented as a "W" value. Since its

voltage value is outside the noise margins for a given technology. no accurate assumption can be

made as to which logic level a "W7* will restore to. To solve this problem, an "X" is used as the

restoring value. A " X represents an unknown logic level condition, meaning that an "X" could

potentially occupy any value between "1" and "0". A similar condition occurs before a signal

value is initialized. In such circumstances, there is no assurance of the signal's condition and thus

uninitialized signals are modeled by a "U" value. The final Logic value is a high impedance con-

Sscuri ty Analysis Technique 5 - 3

diiion or "Z". In situations when a signal driver is disconnected from the signal line. a "2" value

is placed on the signal line. Gates encountenng the disconnect signal. will treat it as an unknown

value. The relationship of the logic levels and the restoring logic rnappings are shown in Figure

5.1.

Logic Level Relationship: Logic I Unknown Conditions: X. U. Z

Restoring Logic:

Figure 5.1. Logical Levels and Restoring Value

Signal Drive o r Contentions

In this work, it is assumed that any two signals will assert their values with an equal drive.

In physical circuits. a gate's drive is affected by circuit parameters such as transistor sizes. para-

sitic. or voitage levels. Further, if the contention is a result of a bridging type short between two

signal line, then the loading of each gate and the defect resistance also affect the results of a signal

contention. Therefore, it would have been irnpractical to have gate models calculate their loading

and alter its drive strength.

Signal values resulting fiom contentions or other conflicts are evaluated using a cornmon

resolution function defined for the technology of interest. The nature of such resolved signals was

discussed in Chapter 4. As an exainple. the resolution function defined for CMOS technolog.

and incorporated into the current analysis models is presented in Figure 5.2.

Security Analysis Technique

Inverter forces a "On\ CONSTANT resolutiontable : levelstable := (

NAND forces a "1 " 1

1 Resolved Value ( Y, x 0 O O I L ' L ) , --O ( 1 1 1 1 1 lZ1 1Ll, #Hl, lW4) > T t 1 9 , --z

Figure 5.2. Resolved Signal Example and Resolution Table used for CMOS Technology

Timing Issues

The goal of this work is not to create a timing analysis tool. thus a simplistic approach to

circuit timing was adopted. Computations to derive the btlL or t p L ~ delays for any particular

gate would involve similar measurements and layout information as was discussed in the previous

section regarding drive strength. This level of involvement was not seen as critical for failure

analysis as this methodolog will flag areas of concem. which can be analyzed later usine proper

timing analysis tools. Instead of modeling cornplex propagation delays. a standard unir of delay

time was adopted. Based on analog simulation data, a unit delay is defined as the propagation

delay of the fastest gate (an inverter in the CMOS case). Unit delays are then computed for the

other gates based on their fault free simulation. Delay fault behavior is thus simplified to adding a

lump delay ont0 the fault free propagation delay of the defective gate. This extra delay is propa-

gated through other gates to the output nodes, possibly delaying their switching. The size of the

delay fault is dependent on the fault category being modeled, as discussed in Chapter 3.

One potential rnethod for including delay measurements would be accomplished by defin-

ing an additional two ports in each mode1 to resolve fan-in and fan-out. As shown in figure 5.3. a

resolved signal line connects the fan-out port of the driving gate to the fan-in pons of each of the

driven gates. Each driven gate sends a number down the signal line representing the load it would

place on the driving gate. A resolution function could then determine the total load. However.

this rnethod can not consider the length of the intercomect in the load detemination. Also. the

Security .-Inalysis Technique

overhead required for such timing accuracy is deemed to be excessive for any design greater in

size rhan a hundred gates. For these reasons this approach was abandoned.

Figure 5.3. Example Method for Fannout Loading Determination.

I Function Loading (input : load-buss) Return load is VARIABLE result : load; BEGIN

IF (input'LENGTH =1) THEN result := input (input'LOW);

Life Cycle Analysis

2.5

Failure calculations derived from the results of the defect injection and simulation are

detenninistic rather than time dependent. Thus the analysis results represent an average probabil-

ity of failure over the entire simulation scenano regardless of variations or changes in the rate of

defect injection or application of input stimulus.

ELSE result := 0; FOR i IN inputiRANGE LOOP

result := result + input(i);

In sorne situations however, a time based fault analysis is required. In these cases. a statis-

tical model is created using the defect coverage and failure probabilities detemined through this

analysis process. This probabiliîy model is used to calculate temporal figures and rnean time to

failure (MTTF), or if considered with a known defect arriva1 rare, the probability of failure for a

given time can also be detemined. This allows the probability of fault secure system failures to C

be modeled throughout the life cycle of the system.

END LOOP; END IF;

- RETURN resuit; F-in END loading;

Security Analysis Technique

5.3 Analysis Flow

A flow diagram illustrating the tasks undertaken during this security fault analysis process

is presented in Figure 5.4. The analysis of a targeted design is performed in four phases as dis-

cussed below.

In the setup phase, the modeling environrnent is established. If an input technolog for the

design's implementation is known. then a defect analysis is performed to determine likely defects

and their faulty behavioral response. Results of the technology analysis are used to create a defect

to fault mapping file or alter the VHDL gate models used in the security fault analysis (SFA mod-

els). Concurrent with the technology analysis, test patterns for the targeted system or block would

also be generated. The last step in the first phase is to generate a structural VHDL description of

the design or system blocks of interest. If a VHDL model of the circuit is already available, then

this step can be skipped.

The modeling phase generates the injectable models for VHDL simulation. Having

obtained a structural description of the circuit of interest from phase one. the logic gate compo-

nents within diis structure are replaced with the controllable mutant gate models developed as pan

of this thesis. The replacement is accomplished by editing the configuration statements contained

in the design's structural architecture. Bridge rnodels are also placed between signal lines in the

design. If however, the VHDL model of the system was extracted during the first phase of this

process, then the extraction tool can be instructed to generate structural VHDL using the security

fault analysis (SFA) gate library as the default, removing the need to replace the gate models.

In the simulation phase. the defect injectable model of the design created in the second

phase. is placed within a test bench architecture. The injectable models are simulated using a

commercial VHDL simulation tool. During the simulation the testbench controller manages the

application of the input vectors and injection of defects. Two output files are generated by the

Security Xnaiysis Technique

simulation. One file contains the results of Iddq monitoring. while the other contains logical mis-

matches fiom output monitoring data.

The analysis phase of this security analysis methodoiogy is the post processing of the sim-

ulation results. The data contained in the output files is compiled to generate defect coverage and

failure statistics. Using the statistical calculations, figures describing the probability of fail safe

operation are generated. [n addition, this phase pinpoints areas in the design where fault security

against defects needs improvement.

Due to their importance in the analysis flow, tasks such as the technology defect analysis.

faulty gate modeling and test scenano generation will be discussed in greater detail below.

Sccurity .Analysis Technique

Design Netlist

Setup ; 1 1 1

Input Test Vectors D & Fault

Database

--Ir: -

Fault Model Generat ion

Design in

\ I I Mode1

I

Gate mode1

Injectable \ [g 1 Simulation -

Analysis 1 Post Processing R I l I I

Failure Data I I

I Design 1 /Attributes /C

Security Xnalysis Technique 5 - 9

5.2.2 Technology Defect Analysis

Regardless of the methodologies proposed for injection. a cornmon issue regarding the

validity of injected faults can be summed up by the question: "Are the injected faults representa-

tive of the actual faults?"[l J I To answer this question a defect analysis study can be performed

for each technology of interest during the first phase of the SFA analysis flow of Figure 5.4. The

defect analysis determines the types or classes of physical anomalies possible for the process. A

circuit mode1 of each of the defect classes is created and simulated within a gate structure using an

analog simulation tool. The output responses of these defective gates are used to create a behav-

ioral description of the defect in tems of fault categories. This procedure ensures that the faulty

behavior exhibited by a "defective" sate dunng this methodolog is representative of the physical

behavior[5.18.20].

In this thesis CMOS defects were modeled with parasitic circuit elements. Analog simu-

lations were perfomed for representative standard cells. in the manner described in Chapter 3.

Simulation results were used to provide the defective behavioral descriptions in terms of the

classes of faults and inputs necessary for defect excitation.

Defects within gates often lead to faulty behavior which can be classified into multiple

fault categories[l8,13]. In this case the defect injection is similar to multiple fault injection.

where many of the measurable properties such as voltage level, supply current draw, and propaga-

tion delay, of gare response could be altered[l8,20]. A defect within a gate could then be repre-

sented by the manner and severity, if any. that each of the measurable responses are altered from

their fault fi-ee behavior. Defects are injected into the gate mode1 which then interprets the fault

categories of behavior to exhibit based upon a defect mapping file and the gate's inputs. Mecha-

nisms for this behavior determination are discussed later in the next section.

As a result of the defect analysis, a defect file is created for the gates of interest. These

files contain a list of the possible defects for the gate, with the corresponding faults. A sample of

a defect file is presented in Figure 5.5. A defect is represented by a code corresponding to the

transistor number in the basic gate and an identification code. Afier the defect identification. the

Sccurity .Anrilq.sis Technique 5 - 10

behavior exhibited by the gate containing that defect is classified using the fault categories dis-

cussed in Chapter 2. Storing these defect-to-fault mappings in a file makes it possible to mode1

diRering gate stmcnires by altering this file without changing the VHDL description of the gate.

Additionally, the defect file can be generated to allow the rnodels to exhibit the faulty behavior

induced by "Soft" or "Hard" defects.

#NAND Gate Hard Mapping - File Header F--=.. .

Defect Al AJBOBLBM; Identifications Listings of Fault

BI ACBLBM; Catagories Exhibited C l AABO; Bv Defective Gate D l ACBLBM; El AMBQ \ ,Line terminator FI AM; H l AM; II AABO;

Transistor Number

4 File Terminator

Figure 5.5. Technology Analysis Defect Mapping File Example

Finally. there may be situations where a technology analysis is not possible, and thus

defect behavior cannot be simulated. In such circumstances, the mapping file can be created to

allow the injection of the individual fault categories. The fault analysis process could then deter-

mine the abilities of the checking system to detect types of faulty behavior. which could

related to actual defects.

The second file created by the defect analysis is the fault excitation file. This file (

ater be

~ntains

a listing of possible fault categories excited by each possible input. This file is used to mode1

defect dormancy within the gate structure. Like the defect mapping file, the pattem excitation file

can be unique to a specific gate structure, or made genenc to allow excitation of a11 possible faults

regardless of the gate inputs. An example pattern file is provided in Figure 5.6. Each line lists a

possible input pattern and the potential faults excited by that input. For the cases where the inputs

of the gate do not match any of those provided in the file, it is assumed that for these inputs. al1

potential faults are exhibited.

Securi ty h a l y s i s Tsc hniquc

#NAND Input Pattern Fault Excitation File

Input 01 AAABACAMBM. . . Patterns Listing of J&Y,"A","A"M"Bo: . Fault Catagories

. . . .------ #END File

Figure 5.6. Input Pattern Excitation File Example

The relation between the two files can be illustrated by an exarnple. Using the NAND

aate structure shown in Chapter 3 Figure 3.11, as our modeled gate, we can determine the fault b

response for a open drain defect on the PMOS transistor MI. The defect mapping file provides

the possible faulty behaviors for this defect (listed as "E 1"). The first fault (identified as "AM") is

a sequential fault influenced by the gate's A input. which affects the gate output's ability to reach

VDD. Looking at the pattern excitation file of Fi,we 5.6, it is seen that for this NAND gate

structure. the defect is hidden by a logical "O" on the B input. turning on the other PMOS transis-

tor M3.

5.2.3 Gate Modeling

The flow diagram of Figure 5.3 introduced a iibrary of VHDL models of vanous logic

gates developed as part of this work for use in the proposed defect injection methodology. These

models follow the "mutant" concept introduced in Chapter 4, and as such they contain both the

lo@c function of the gate along with the code necessary for fault injection. A block diagram

showing the interface for these VHDL models is given in Figure 5.7.

Sscurity .-\ndysis Technique

---C Fa~lt-Free Output Inputs ----+

Model - Faulty-Response Output

De fect Conrrol Messages

Figure 5.7. VHDL Mutant Model Interface

In addition to the defect mapping and fault excitation files discussed in the previous sec-

tion. a look-up table is used to define the fault-fiee logic function. It is in the form of a truth table

that utilizes the logical signal type "levels" introduced in the section 5.2.2. A typical example of

such a table representing a two input NAND gate is shown in Figure 5.8. The tables for vanous

logic gates have been placed in a package calledjàriltpak, a listing of which is given in Appen-

dix B.

CONSTANT nand2table : levels-table := ( -- U X I O Z L H W

(Lulllu'l'ul,'l ll'ul,ll 'llul,'u')l -4 ('U1llX1l'X1l~l 'llX'l'l I1'X1>'X1)> --X ( I J ~ ~ ' ~ * ~ ~ ~ ~ , ~ I l l tx l l ' l 71101,*w1)1 --i ('1 l1 '1 '>'1 ','1 1111 '171 y 1 '1 --O (LU1,lX1llX','l ','X1>I1 ~l~X1tlX1)l --z ('1 *, 1111'1 y l,'1 11'1 '1 '), --L ( L ~ l l l ~ T l l ~ r , l ~ *11~9t1i l l l ~ t l l ~ l ) l --H ('UtllX'llX1lll 'l'X1lll t,'X1llW1));--W

Figure 5.8. Tmth Table Example for CMOS NAND Gate

Editing the tmth tables to produce different mappings for inputs such as "Lm. "H". "W. or

"X" can be used to mode1 different structures of the sarne logic gate. For example another NAND

gate structure may have a higher threshold voltage than the one represented by the tmth table of

Figure 5.8. If this were the case, an input of " 1" and "W" may not produce an unknown output.

but rather a " W input would likely be interpreted as a logic low. Thus the output would be a " 1"

or "H" instead of an unknown "Y.

Secunty Xnalysis Technique 5 - 13

During simulation, defects are injected into the gate models by means of control signals.

The injection control signal is actually a record containing information identifying the type of

defect and the transistor affected. Listed in Figure 5.9. is the definition of the dejèct type. The

type fault-i is the fault category response as defined in Chapter 3. fazrZtJ is a basic type of 26

characters and one control character used to create the type farrlt_l.

. . . TYPE faultb IS

('G*l*~l1B*,'C*,'D*l*E*l'F1l*H'l*l*l*J1lyK'l1~,1M*l*N'l'O*l*P*,'Q1l*R1l1S*,'TlyU',1V*,1W'l 'Xfl'Y** 'ZY,'z') ;

TYPE faultl IS ARRAY (O TO 1) of faultb; TYPE defect IS RECORD

ident : fault-b; transistor : natural;

END record;

Figure 5.9. Defect and Fault Category VHDL Type Definitions

Fault fiee gate response simulation occurs in parallel with the defective simulation. The

two are conducted through independent processes. Having received a control signal instructing

the gate to model a specific defective behavior. the decision Bow followed by the model is illus-

tnted by the example code of Figure 5.10. In the first step of the injection loop. the defect file for

the gate is scanned by the inject function to produce a list of fauit caregories defining the defective

behavior. Sequentially. each fault category renimed from the defect file search is checked against

the pattern file by the txcite fùnction to ensure that the fault category is excited by the current gate

inputs. The faulty behavioral response is placed in the faulty output variable pl-out. and the

response is resolved with any previous faulty responses. Delay increases are not cumulative.

Rather. the maximum delay category (delay-maïf is added to the gate delay of the gate @!-op).

After injection is complete. the escape code is generated ("zz'") and the resolved faulty response is

placed on the faulty output port, f-out, afier the new propagation delay.

Security .c\nalysis Technique

. . . injection: LOOP

counter:= counter + 1 ; if (ctl-ident = 'G') then flt := "GG"; Else

flt := inject(ct1, counter, inv); END IF; EXIT injection WHEN flt = uzzn;

--*---------------------------------*----------

CASE flt IS (each fault is sequentially tested and applied} . . . When BA" => --delay-1 (tplh)

(check for fault category excitation} IF (excite (input, "BA", inv)) THEN

fltout := invt( input-f, current-out-f); IF ( (fltout = '1' OR flt-out = 'H') AND

(out-f = 'O' OR out-f = 'C) ) THEN delay := 0.5 ns;

ELSE delay := O ns; END IF;

END IF;

When "ABn => --out SA0 . . .

END Case; ----------------------------------------------------

{ Gate delay is accumulated (if faulty)) IF delay-max c delay THEN delay-max := delay; END IF; { actuai output value is resolved) outtemp := resolved( outtemp & flt-out );

END LOOP injection;

o u t f <= out-temp AFTER prop + delay-ma;

Figure 5.10. Injection Decision Code Example for an Inverter Gate

Since the defective and fault free output response are generated independently, a signal

Iine composed o f two separate bits is used to connect the VNDL models used in the secunty fault

analysis. Once again, a resolved signal has been defined in the fatrltpak package. This signal

type, called gategort, can pass two independent values. Dunng gate replacement, or VHDL

extraction. all signals connecting the gate models are switched to this gategor-t type.

Security Anaiysis Technique

The last intefiace of the VHDL gate models illustrated by Figure 5.7 are messages sent to

the simulation engine by the models. In an attempt to generate statistics for a hypothetical current

monitoring test. conditions causing excessive supply current draw (Iddq) are flagged by the gate

models using simulation messages. These conditions and the Iddq threshold for detection are

identified fiom simulations undertaken as part of the technology analysis of section 5.2.2. and

were discussed in Chapter 3. Conditions may include defects within a gate: signal contentions

frorn resulting multiple drivers, or bndging defects; or degraded voltage inputs to a logic gate.

# " Note: Possible lddq detectable fault caused by: 1 and 1 value on inputs. # Erne: 17652902 ns Iteration: O Instance:/ i-03647/ fl3/ slave

Figure 5.11. Iddq Increase Warning Message

A sample of an Iddq simulation message is provided in Figure 5.11. If the cause of the

Iddq increase was a defective gate or a bridge contention, the input values are provided as a possi-

ble aid for generating test patterns to excite Iddq faults. Also in these messages. the tirne of the

Iddq increase is listed in the second line of the text along with the instance identification of the

logic gate or device sensing the increase.

Similar in nature to the Iddq fiags. conditions of reduced noise margins for logic gares are

also flagged by simulation messages. An example of a noise margin warning message is listed in

Figure 5.12. A condition of reduced noise margins could result kom degraded input logic levels

or as a result of a defect excited within a gate which reduces its drive capabilities. Again. the

thresholds for noise margin wamings and conditions leading to them are determined fiom the

technology analysis task.

# ** Note: Possible noise margin decrease on inputs # Tme: 6357400 ns Iteration: O lnstance:/i_03647/f9/master

Figure 5.12. Noise Margin Reduction W m i n g Message

SecuRty Analysis Technique

Wamings of reduced noise margin are included in the methodolog to reflect the potential

susceptibil ity of a technolog or circuit irnplementation to reduced or degraded signal values.

Such degradation could be caused by defects, or environmental noise sources[l]. Given the crit-

ical nature of the functions provided by many fault secure systems. and their potentially varied

field operating conditions, such tolerance data is deerned prudent.

5.3.4 Bridging Defect Models

Bridging defect models are also contained in the SFA model library which is required for

the second phase of the analysis process; as shown in Figure 5.4. As illustrated in Figure 5.13.

these bridge models are placed between signals and activated by a control signal in the same fash-

ion as the gate models. A bridge resolution table is used to determine the resulting signal value

from two bridged signal lines. The resolved value is propagated along the fault response signal

corresponding to each of the bridged lines.

Fault-response Outputs:

Signal 1 ---*f VHDL Bridge 1- Signai 1 output

Defect Control Messages

Figure 5.13. VHDL Bridge Mode1 Interface

Placement of the bridge defect models is a critical issue to their effective employ-

ment[7.16]. Bridge defects occumng within a gate structure are covered by shorting defects con-

tained in the existing nine fault transistor model. As shown in Figure 5.14 the gate drain and drain

substrate shorts of the PMOS transistor will provide results equivalent to an input to output

bridge. or a VDD to output bridge respectively.

Security .Analysis Technique

Gate - Substrate Short

-q _ - l-oUT Gate - Output Short

Figure 5.14. Bridging Defects within a logic Gate

For defects occurring outside the gate structure, proper bridge placement requires that lay-

out information be available to determine the physical proximity of interconnects. Often when

dealing with the verification of systems designed by other parties, detailed information is pro-

tected or proprîetary. Without layout information and thus without the ability to obtain realistic

bridging sites. the use of pseudo-realistic defects has been proposed[l6]. Pseudo-realistic defects

are described as bridging defect placed in areas of likely physical proximity. Estimations are

based on common VO pins. or power supply connections. In the standard ce11 or sea-of-gates

environments where functional location has little to do with a gate's physical location. the srlec-

tion of even pseudo-realistic defects is sketchy[5.16.23].

Because of the unavailability of layout information, this analysis process places bridge

models randomly throughout the design. Such a random distribution of bridging defects will pro-

vide a non-specific overall assessrnent system's security against bridging[6.16.28].

5.3.4 Simulation Scenarios

To a large extent the accuracy of the results From any defective circuit simulation will be

govemed by the simulation scenarios applied to the system[3,13]. For the technique presented in

this thesis, a simulation scenario will contain a list of injections, and a list of stimuli. During sim-

ulations, the application of both the input stimulus and the injections is managed by a testbench

controller. This testbench controller is also responsible for probing the outputs of the circuit and

the checker, creating an output file of simulation results. A typical simuiation scenario is illus-

trated in Figure 5.1 5.

Security .\naiysis Tcc hnique

(, WI Injection Control

Output 1 - - - - l - - l Probing

Defect Population

~ y s t e m J ~ u t p u t s 1

Stimuli I

1 stimulus ontm ml 1 9 Figure 5.15. Simulation Experirnent

Defect Injection Scenarios

An injection list for this proposed technique will be composed of a set of injectable

defects. along with an arrival rate (h) and possibly a time limit for their influence. as illustrated in

Figure 5.15. The defect analysis discussed earlier is performed to uncover possible defects for the

technolom of interest. Their arrival rate is the rate at which the defects occur within an IC. and is

dependent on several conditions. Initially, IC defects escaping manufacturing tests fom an initial

defect level DLinitial described as a function of yield Y and rnanufacturing test fault coverage

T[8.9]:

DLinilial = 1 - Y l-T (5- 1)

Durin; the life of an IC, the rate at which defects occur will be govemed by the rate of the wear-

out mechanisms discussed in Chapter 3. and environmental conditions. Faulty behavior occumng

as a result of external stimuli such as bornbardment by radiation, could be transient in nature.

These external stimuli could trigger an increase in the physical defect rate by increasing wear-out

mechanisms; or in the case of EM interference, they could influence faulty behavior within the

circuit then disappear without the creation of physical anomalies.

Security .AnaIysis Technique 5 - IL)

If an amval rate can be estimated. then temporally accurate defect injection can br accom-

plished. To accomplish this the testbench controller c m inject defects into the circuit allowing

them to accumulate in accordance with the amival rate. Altematively. the defects can be removed

afier a given time to simulate transitory environmental conditions. A limitation however, of the

current testbench controller is that currently no mechanism exists for complex rates of defect

injection (i.e. bursts of defects), thus transitory increases in the defect rate will require multiple

simulations.

Even without defect arriva1 information, it is still possible to an-ive at a valid figure of

merit. This figure is calculated by deterrnining the probability that a defect occumng will not

upset the fault secunty of the system. For these calculations it is assumed that the defect will

occur or already exists somewhere within the circuit. rernoving time from the equations. This

fom is presented later in this chapter.

The defect list is fomed through a combination of the defect mapping file. and the injec-

tion process located in the testbench controller. As discussed in previous sections, the defect file

contains the fault category definition of the injection codes. Defect tiles can be created to include

any number of defects. both "soft" andor "hard" for each type of gate.

Input Stimulus Scenarios

Whenever possible, the input stimulus should as closely as possible refiect the operating

conditions of the system. However. it is not always possible to use operational input patterns.

either because such information is not available during the tirne of the analysis. or because the

stimulus encountered by a system during operations cannot be characterized. Without the avail-

ability of an operational input vector set, studies have suggested two options to arrive at a suitable

input stimulus set[ 11.

The first is to use the vector set developed during the functional testing of the system.

Two imrnediate problems arise with this approach. The first is that this set rnay be incomplete. or

not statistically significant when compared with the actual operational set. The second problem

Ssciirity .Analysis Technique

with this approach is of primary concem to users who wish to use "otTthe shelf' systems. or ofien

contract extemal agencies to design ASICs. In such circurnstances, even the hnctional vector set

may not be accessible.

The second solution for the generation of input stimulus without knowledge of the opera-

tional set is to use a pseudo random sarnple of the total possible inputs for the system. Work done

by Sousa et al. showed that for a randornly generated test vector set the p p h of logical errors

produced by the excitation of weighted faults would take the generic fonn of Figure 5.16[4.13].

Weighted faults are potential faults in a circuit which have been assigned a probability of occur-

rence (excitation) determined by a defect analysis performed on the circuit[% 131. This graph

shows that as the size of the input pattern set is increased (K + a) the number of additional faults

uncovered by the vectors (N) levels off to a maximum defined by the testability of the circuit.

# of Faults Uncovered (at the checked circuit outputs)

iç of Vectors Simulated (size of input pattern set)

Figure 5.16. Fault Coverage Vs. Number of Vectors

Two general vector set sizes can now be discussed. If we assume that the plot of Figure

5.16 represents the realistic fault excitation of the circuit under test, then choosing a sample size

of the order specified by region A, would represent a situation where defect domancy and/or fault

latency within the circuit is still high. Al1 possible faulty behaviors of the circuit are thus not

tested. As the size of the pattern set is increased into region B. additional faults are excited pro-

viding a more complete measure of the checking scheme's ability to detect al1 potential faults and

thus defects[l,3,13]. Although the analysis results for such a large test set will be slightly opti-

mistic. this choice ensures potentially critical failures are not missed[l].

Sscuriry Analysis Technique

The suggestion is then to choose a vector set of suficient size to elirninate as much as pos-

sible, the effects of defect dorrnancy and fault latency. The methodology presented in this thesis

will provide statistics of the defect coverage obtained by the stimulus set for the checked circuit.

This coverage can be compared to the maximum coverage possible for the given technology and

ce11 structure. determined during the technology analysis as detailed in Chapter 3, to decide if the

test set is sufficient for the analysis requirements. Although larger test sets are likely to produce

the most complete analysis results, a trade-off must be made between the time to complete the

analysis and the length of the test set.

5.4 Techniques For Results Analysis

The previous section described some possible testing scenarios for use with this methodol-

ogy. The result of these defect injection simulations is a matched set of fault detections and secu-

rity failures for the system under test. In addition. the defect list injected into the circuit is knom

a priori. as also discussed in the previous section. The introduction of this chapter identified two

strearns of analysis:

1 ) Design Aid.

2) Security Failure Analysis.

In the following sections, a technique for conducting each of these analyses is proposed.

For such discussions, some notation is introduced[3]. For a given fault injection experiment. four

elements must be present. A set of input patterns must be applied to the circuit. The system is

subjected to a set of defect injections 1, which lead to a set of observable fault conditions (or

errors) E. appearing on the outputs of the system, and a set of detections D by the checkinz

scheme. Then usuig the above notation, a set of unsecure failures U can be defined as the set F Q

D.

Security .4nal>sis Teclinique

5.4.1 Design Aid

A consideration of the design implementation of a fault secure system is straightforward

based on the results of the defect injection. Design aid is an attempt to determine if changes in

the circuit design are required to improve the fault security of a system.

From Chapter 2. the probability of a failure occuring is given by the foHowing:

P (Failure} = P {Faliure 1 Error) * P(Error 1 Fault) * P (Fault 1 defect )* P {defect ) (5.2)

The Iast two terms of equation (5.2) show that a reduction in the fault propa,oation to the

outputs, or defect excitation may improve the overall security of the system. This rnay be mis-

leading if equation (5.2) is intrepreted literally, as illustrated in a simple example. The circuit in

Figure 5.17 initially contains a fault, 0. If the circuit uses an odd-parity checking scheme. then

the first fault is latent. At a later tirne, when the input pattern changes. fault @ occurs. The erro-

neous output transitions without the second fault (shown in parenthesis) would have been

detected by the checker. However the amval of the second fault @. masks both faults e\.en

though the output is in error. If the second fault occurs before the outputs are checked then the

circuit would have passed and a failure would have occurred, illustrating how multiple faults can

hide errors from checking systems.

Figure 5.17. Fault Masking

Thus to avoid such defect interactions. the goal for designers of fault secure systems

Securitj, .Anal_vsis Technique

should be to rnaximize the defect coverage possible for a given circuit. This will represent an

increase in the P ( Error 1 Fault ) and P { Fault 1 defect ternis of equation (5.2). Thus it is the detec-

tion abilities of the checking or coding scheme employed by the fault secure design which reduces

the probability of a failure by reducing P { failure 1 Error J which is 1 - P {detection ( Error 1 .

The defect coverage of a design follows directly From the simulation results. For a given

injected defect list i the defect coverage can be detemiined by EII. Although this coverage will

also be representative of the fault coverage of the circuit, since not every defect is excited into

producing a fault. the coverage EU will be lower than the actual fault coverage. An additional

note from the defect coverage results presented at the end of Chapter 3. is that unlike fault cover-

age. there is an upper limit on the attainable defect coverage. From the analysis performed in

Chapter 3 for CMOS processes. this upper limit on defect coverage was found to be 78 %.

A payback for the overhead associated with the use of control lines for defect injection is

that signal lines clearly indicate which faulty response is matched with which defect injected into

the system. Therefore. in the matched set of IrE. I contains both a defect identification and a loca-

tion within the design. By grouping the subsets of defect injection and fault detections. according

to location. defect coverages for each design block within a system can be attained. highlighting

areas requiring improved coverage. More importantly, failure statistics for defect injections into a

particular design block rnay dictate that some f o m of re-design be necessary. For such areas.

additional testing points are likely to improve the coverage. but at a cost of increasing the size of

the checking scheme. In other cases, the block may be inherently untestable and require re-

designing to include features such as self-testing, or scan path chain.

Another method for irnproving fault security could be to change the checking scheme used

to monitor the circuit, or to incorporate an additional testing method. Any checking scheme used

will have an upper limit on its error detection capability, as defined by the coding scheme used.

As an example, a parity checking scheme is incapable of detecting any defects which cause two

Iogic errors on the tested nets. If for example the simulation results show that defects are produc-

ing a high proportion of multiple errors on the checked nets, and thus a significant number of fail-

ures, then the coverage afforded by a parity coding scheme would prove insufficient.

Secority .Annlysis Technique

Alternatively. another testing method may be incorporatrd into the system. A feature of

this methodology is its ability to flag conditions of potentially elevated Iddq. The resulting defect

coverage attained by monitoring the Iddq flags will be an indication of the potential coverage of a

current monitoring scheme.

5.4.2 Security Failure AnaIysis

There are typically two statistical analyses performed using the results of the defective cir-

cuit simulations. The first is the calculation of a "Figure of Merit" which will represent the level

of confidence in the fault security of a system. The second set of statistics of interest involve a

Iife-cycle anaiysis geared at arriving at a mean time for the system to Fail to an unsecure srate

(MTFU). Both analysis techniques are presented below.

Figure of Merit Calculations

One of the motivating goals of this research was to define a technique able to arrive at a

quotable figure representing the level of confidence for fault secure, or fail safe operations of a

system. The tenn "figure of merit" is used to describe this analysis result. This figure of merit is

the probability that the system in the presence of a defect will maintain fault secure operations.

The calculation of this figure assumes that a defect has already arrived and thus does not consider

the defect amval rates. Recalling the notation used in Chapter 2, the figure of ment can be

expressed as:

P {Secure Operations ) = 1 - P (Failure) (5.3)

The t e m P {Failure) in equation (5.3) can be determined directly from the results of the

defective circuit simulation. Therefore, the analytical process developed by this thesis caIcu1ates

the probability of errors being generated relative to defects within the circuit. This leads to a fig-

ure of ment equation as shown below:

Secunry AnaIysis Technique

P (Failure l. = P{ Failure ( Error) *P {Errors 1 defect ) ( S A )

For cases where every faulty output is considered as an error then the probability of pro-

ducing an error on the outputs given a defect in the circuit, is:

# mismatches detected by testbench monitor - P (Error 1 defect ) = E - -

# of injected defects i

However, there may be situations where not evety mismatch detected by the testbench is

considered an enor. Again, such distinctions are made by this technique due to the requirement to

consider vanous technologies. In such circurnstances, as an example, a logic level of "H" may

not prove sufficient to be considered a "1". Therefore, after filtenng the non-error mismatches out

we end up with a set of "filtered" errors EF E E. Leading to:

P ( Error 1 defect ) = EF / I (5.6)

The first term in equation (5.4) representing the probability that an error is not detected by

the checking scheme is slightly more cornplex. In the case of the checked circuit under

test (CUT):

PlFailure )m = 1 - DF- /EF

Where DF is a filtered checker flag value.

Another factor needing to be considered in the P(Error 1 defect} term is the possibility of

an erroneous input being placed into the checked circuit causing an error, while a defect exists

within the checking scheme. This t e n would also describe the probability of an error caused by

a defect in the checked circuit being masked by a defect in the checking hardware. These condi-

tions provide a determination of the robustness of both the coding scheme and the susceptibility

of the hardware checker to defects. A specialized simulation is required to amve at this calcula-

Sscurity AnaIysis Technique

tion. For such simulations. errors are placed on the inputs to the checker. The checker was then

injected with defects. The probability of the checker detecting an error in the presence of a defect

is given as follows:

- # Failures P(Fai1ure 1 Error on input 1 d e f e ~ t ) ~ ~ ~ ~ ~ ~ ~ - (5-8)

# Defects injected into the checker

- - ( L>hecker ' Ichecker )

Where Ucheke, is the failure recorded during simulation.

For systems where the inputs into the monitored circuit are cenified as correct. or only sin-

gle defects are considered this term can be ignored. Combining the probabilities of equations

(5.4). (5.7). and (5.8) we get a Figure of Merit calculation:

P (Secure Operation 1 = 1 - [ [ ( l - $ ) x ~ ] +(::r*r)(-)}

Life - Cycle Analysis

The figure of merit calculations provide a good measure of a fault secure systern's ability

to "cope" with a defect. However, such calculations do not consider time, nor the defect arrival

rate. Often the in-service thne before likely failure is critical to place limits on a system's security

certification, and schedule replacement. Thus a time dependent measure of a system's fault secu-

rity is warranted. Although the goal is to arrive at an in-service time Iimit on the confidence in a

circuit's fault security, this analysis can also be used to determine instantaneous probabilities of

failure for: different stages in the circuit's life cycle (refer to Chapter 3); or elevated environrnen-

ta1 effects on the defect amval rate.

Such analysis could be performed by simulation results. Simulations of the system under

multiple defect conditions can be camed out and figures of merit calculated, for each defect

arrival rate. Clearly the potentially vast combinations of defect injection possibilities would make

Securi ty .Anal p i s Tec hniq~ie

this approach infeasible.

A second approach could be based on the Markov statisticai model proposed by RTL to

obtain a t h e dependent analysis. Again, the defective injection simuiation results are used to

arrive at the probabilities of error detection and defect dormancy. nie Markov model is shown in

Figure 5.1 8. Where the transition probabilities have been defined From the equations and notation

described earlier.

t is the time.

Figure 5.18. Statistical Model for Time Based Fault Secure Calculations

Simulations of the above metric using statistical tools such as Matlab. would provide the

instantaneous probabilities of a system remaining in the fault secure state over time.

Seciirity .Analysis Technique

To solve for the mean time to failure. a defect arrivai rate is calculated using manufactur-

ing statistics. or is estimated based on the technology defect analysis performed in setup phase of

the security fault analysis flow. The probability of a system operating in the secure state is set to

the desired level of confidence and equation (5.10) is solved for a time value.

PiSecure Operation} = I - [ Ph, + PL(PLh) ] ht

For highly critical systems, fault security failure probabilities as low as 1 in 109 are

sought[I 11. Dependent on the requirements of the application. other values for P(Secure Opera-

tion) will be used. Plotting the probability of secure operation over time using equation (5.10)

provides an efficient means of identifying the trade-off between desired level of confidence in the

ICs within a system and maximum time in service, as illustrated in Figure 5.19.

A note regarding life cycle analysis is that the calcularions require a knowledge of the

defect amval rate for both the process and environmental conditions. Given the standard life-

cycle increases and decreases in IC mortality rate (Chapter 2). three or more MTTF calculations.

utilizing different defect rates would prove a more accurate description. An example charactens-

tic plot is shown in Figure 5.19.

O l

Time in Service

Figure 5.19. Example Plot for Time to Failure Analysis

Life Cycle Analysis Limitations

The statistical mode1 used for this analysis is accurate only up to a given time, dependant

upon the defect arrival rate. The reason for this breakdown lies in the use of single defect injec-

Sccurity .Anrilysis Technique

tion results to mode1 the transition probabilities of multiple defects. when ideally these multiple

defect probabilities should be determined fiom multiple defect injection. However. the size of the

simulation set required to conduct multiple defect injections on even a small sized design is

unreasonable.

As an example, consider a small design containing 1.000 defects. The nurnber of injec-

tions considering every possibility of 2 defects occurring is given by, ( 'y0) giving some

500,000 possible combinations, or if 3 defects are considered the nurnber of required defect sce-

narios becomes over 160 million.

Sccurity .-\nalysis Technique

Chapter 6

Benchmark Analysis and Results

6.1 Introduction

The best illustration of the employment of the secunty analysis process is to apply it to a

typical benchmark circuit. In this chapier such a sample analysis is conducted usine two moder-

ate s i x benchrnarks.

Defect coverage, and failure statistics are presented, as we1l as a figure of merit for both

single and multiple defect environrnents. Finally, Markov statistical rnodels discussed in Section

5.4.2 are generated for each benchmark fkom the simulation results, and used in a time to failure

anal ysis.

6.2 Benchmark Description

As a proof of concept of this methodology the critical block for the benchmark fault

secure system will be represented by an eight bit ALU. This ALU was synthesized fiom a behav-

ioral VHDL description to a structural architecture. The logic gate models within the design were

then replaced by the mutant gate models developed for use with this methodology. Finally. to

dernonstrate their use, 50 bridge models were placed randomly throughout the ALU. This bench-

mark circuit is of moderate complexity, containing over 500 logic gares.

Application of kléthodolog in a Benchmark

Two hardware checking schernes were designed for use with this cntical block bench-

mark: a pariîy checking scheme; and a complementary checking scheme. Both checking systems

and the ALU critical block were designed using NORTEL's 0 . 8 ~ BiCMOS process.

6.2.1 Parity Checking System

The first checking scherne considered is a simple even parity checking scheme. A com-

mercially designed parity checking circuit schematic was obtained. Mentor Graphic's Quick

VHDL Write tool was used to extract a stmctural VHDL description using the methodology's

mutant logic gates as components. Bridge models (34 in total) were then manually inserted into

the structural VHDL description. A block diagram of this system is iliustrated in Figure 6.1.

Critical Block C hec king Hardware

c To other BIocks

- k + L z ? x L Result

Result

Figure 6.1. Benchmark Example with P a d y Checker

The parity checker uses two output pins POUT and POUT to flag pasdfail operations.

When rhe two pins are complements of each other. then the system outputs are deemed hul t

secure. if the two pins are equal then the pGty checking scheme has detected an error on the out-

put bus of the ALU (Result), or detected a defect within itself. if the benchmark was part of a

larger fault secure system, the Resrilt bus would represent the outputs passed to later design

blocks.

6.2.1 Complementary Checking System

The second benchmark also uses a built in self testing system. This checking scheme is

based on a self testing cornplementary code checker. A block diagram of this circuit is presented

in Figure 6.2. The original ALU has been implemented in complementary logic to produce M U .

Again. the Result bus represents the fault secure outputs passed to later design blocks.

- For this design, the two output pins good and fail are used to flag the operational condition -

of the systern. A good, fail output of "0.1" certifies that the system outputs (Resuh) are error fiee.

Any other combination indicates an error. The self testing ability of the checker takes two foms.

A linear feedback shift register generates a complemented pseudo random pattern into the com-

plementary checking hardware. This ensures that there is continuous toggling on the signal nets

within the checker. Additionally, a self test is conducted for the flag generating gates of the

checker during the high phase of each dock cycle. A timing diagram illustrates the function of

the complementary checking hardware.

As in the par@ checker example, a checker circuit used in industry for fault secure appli-

cations was obtained, and a structural MiDL description generated. The VHDL model used the

mutant logic gate components from this methodology and in addition, a total of 53 bridges were

placed rnanually through out the checker structure.

Application of .llsthodology in a Benchmark 6 - 3

Cntical BIock

Control

ALU

9

Result Resul t

Checking Hardware

Blocks

Flag TSC Complementary

Checker

Figure 6.2. Benchrnark Example with Cornplementary Checker

/ i / Good/Fail

As shown in Figure 6.3, the Result output from the critical block (the ALU benchmark) is

ipored at the beginning of each cycle until the checking hardware perforrns a self test. Follow-

ing the successful outcome of the self-test, the checking system venfies that the output from the . . . . . . . . . . . . . . . . . . . . . . . . . . . .

cntical block Result. is the complement of Resulr, andsets ifs 3ag: - - - -

- - - - - - - - - - - -

2

ALU Resrtlt New Result Valid

Good/Fail Flag )( Self test Flag Valid X Circuit Check Flag Valid

CLK Self-test Circuit Check

Figure 6.3. Timing Diagram for Complementary Checker Operation

Application of Methodolog- in a Benchrnark

6.3 SFA Methodology Application

6.3.1 Technology Defect Analysis

As descnbed in Chapter 5, a technology defect analysis was conducted in preparation for

the security fault analysis. Investigations of standard cells from the NORTEL 0 . 8 ~ BiCMOS pro-

cess yielded a list of possible defects for their specific smicture[l8]. Using this list. faulty behav-

iors of the four basic logic gates (Lnverter, NAND. NOR and XOR) encountered in the

benchmark designs were defined, using the fault categories from Chapter 3. This modelled

behavior enabled the generation of defect to fault mapping files and fault excitation pattern files

for each of the basic gates.

The comparator checking hardware contained sequential gates in the form of D Flip-

Flops. These were constructed using D-Latches from the sarne standard ce11 library. Analysis of

the Iatch structures introduced an additional fault category not covered in Chapter 3. This cate-

oory models violations of the required setup time or hold time for sequential devices. The illus- 2

tration of Figure 6.4 provides two example cases. In case 0, the violation is a result of the faulty

behavior from another gate causing a delay on the input data signal for the sequential device.

Altematively, in case @ the violation is the result of a defect interna1 to the sequential device

itself. This causes an increase in the setup time required by the D-Latch. possibly beyond the

setup time afforded by fault fiee data signals. In both cases the output Q will be have reduced

voltage swing or the logic value will be invalid.

Application of Msrhodology in a Benchmark

D (nom)

D (delayed)

Q Faulty

Q ( n o m

D - Latch

Figure 6.4. Setup Time Violations for CMOS D-Latch

6.3.2 Simulation Scenarios

Since both benchmarks make use of the same ALU design as their critical block. a com-

mon set of input test patterns can be used. Assuming no operational vector set is available for

either design. a set of pseudo random vectors can be used. As discussed in section 5.3.1. the

cyclic length of such a set should be chosen suficiently large to decrease the effects of defect dor-

mancy and fault latency within the critical block.

Mentor Graphie's QuickFaultII fault analysis tool was used to select a randomly

sequenced set of patterns which achieved a 99% stuck at fault coverage for the ALU circuit. This

set is 250 vectors in length with a word size of 23 bits covenng the two 8 bit operands, the 6 bit

operator control, and a cany-in bit.

In order to provide statistics covering al1 possible physical anomalies for a CMOS imple-

mentation of the benchmarks. an exhaustive defect injection was employed. A flow diagram illus-

trating the defect injection and simulation phase of the analysis process is contained in Figure 6.4.

.\pplicrition of ,Methodoiogy in a Benchmark 6 - 6

Without the necessary statistics from which a defect arrivai rate could be derived. each defect ivas

injected and the circuit was simutated for the entire test pattern set. After which. the system was

reset to rernove any faulty behavior and the next defect injected.

Defect injection, test pattern stimulation, and output monitoring is managed by a Test

Bench. Figure 6.6 illustrates the setup for each of the simulations. nie test patterns are applied.

and the output of the circuit is sampled at a rate of IOMHz. The testbench has been setup to sam-

ple the output of the critical block and the checker flags before the next pattern is applied. hoiv-

ever. because of VHDL concurrent abilities. both operations occur at the same instant in time.

The selection of 100 ns for the sample cycle was made to be sufficientfy large so as not to stress

the timing of the critical circuit, while remaining at a speed of operation in the same order of mag-

nitude as commercially used cntical systems[l 11. Still possible effects from the selection of any

oiven sampling time must be remembered when considering failure data. There were two simula- - tion scenarios applied to the benchmark checking scheme designs.

Defect List Reset Circuit For

Next Injection a 1 [F-

Patterns

[/ Sirnulate Design 1 )-

Figure 6.5. Flow Diagram for Simulation Trials

Application of .CIethodoiogy in a Benchmark 6 - 7

The first scenario injects single defects throughout the entire benchmark. The output

Result. is monitored for errors generated by the defect injection. and the checker flags are sam-

pled to ensure that the generated errors are detected by the hardware checking scheme. This setup

simulates the operation of the system in the presence of a single defect. Data obtained from this

scenario can be used to generate defect coverage statistics of the test pattern set, and a figure of

ment for a single defect environment.

Input Patterns

1 Critical Block Under 1 r-! Ven fication b

Output Probes

m Input Pattern

File Margin Flag File bProbe Sample File

Figure 6.6. Setup of Simulations

The second simulation scenario targets the checking hardware to look for enor masking

by defects. The testbench controlIer is configured to input patterns into the checkin; system

which violates its coding scheme. The checker will attempt to generate flags corresponding to an

"output in error" state. The testbench will inject defects into the checking circuit and moniror the - pass/fail Rags to detemine the ability of the checking design to fiag output errors in the presence

of defects. Such a situation wouId be analogous to a worse case multiple defect environment.

Exhaustive defect injection will be used throughout the simulations. The defect sites are

those discussed in Chapter 3. For basic gates such as NANDs, or NORs, this leads to 36 possible

defects for the gate. For complex gates such as an XOR or D-Latch, there are up to 108 defects

possible. Results from both of these two scenarios are provided below.

Additionally, bridge defects have been inserted into the VHDL models of the critical block

and the checking hardware. Without layout information for the benchmark, a pseudo-defect

approach for bridge locations was adopted. The placement of the bridges was random throughout

Applicrition of Mcthodology in a Benchmark 6 - 5

the critical block benchmark. and the checker circuits.

6.3.3 Results on Single Defect Injection Scenarîo

In this scenario individual defects are injected into the building blocks, the circuits are

simulated and corresponding outputs are monitored. Statistical results are categorized into three

Eroups: C

A. Defect Coverage

The Table 6.1 lists a summary of the error generation statistics From defect injection inro the ALU

benchmark. These figures were obtained by simulations during the first scenario discussed in the

previous section.

In the tables. results are provided for each defecr category and for each seventy classifica-

tion. "Hard" or "Sofi". "Caused Errors" represents the number of errors generated by each of the

types of defects injected into the circuit. The ratio of caused errors to total injected defects for a

given type of defect is represented by the "Percentage" column. "Percentage Errors" is the corn-

bined percentage for both Hard and Sofi defects.

.4pplication of Methodology in a Benchmark

Table 6.1 ALU Error Generation Statistics

1 2 ) Numbers in brackets represent possible Enors. 1

The numbers in brackets in the "Caused Errors" columns represent the numbers of defects

which have the possibility of causing an error. For these CMOS benchmarks. such conditions

would result fiom an unexpected " X or "W' appearing on the Result outputs. Since one cannot

be sure of the interpretation of these values, a 'bpossible" error is seid t~ have occurred. The val-

ues in brackets in the "percentages" columns represent the percentage of defects which generated

mors or possible errors, £tom the total number of defects injected.

. Percentage E mors

44% (8 1 %)

54% (78% j

7 1 % (80%)

65% (73%)

5 1 % (64%)

55% (67%)

53% (64%)

Table 6.2 presents the same defect error generation statistics for the parity checking hard-

ware, and Table 6.3 contains the error generation results for defect injection into the complemen-

tary checker.

HARD

Application of 'ulethodology in a Benchmark

SOFT

Dnin Sub Short

Source Sut, Short

TOTAL

Caused Errors

39 ( 1.458)

427 (948)

1.108 (338)

1,089 ( 187)

705 (452)

886 (474)

8 16 (434)

Percentage

85.3%

86% (86%)

85% (86%)

74% (82%)

64% (69%)

66%

65%

1.297 66% 879 (18 1) 45% (54%) 55% (60%)

44 t ( 2 ) 22% (22%) 145 (1) 7% (7%) 15% ( 15%) -

1 2.169 ( 196) 69%(70%) 6,074 (4,473) 34% (60%) 52 96 (6joh)

Caused Errors

- Percentage

2% (76%)

32% (70%)

56% (73%)

55% (65%)

36% (59%)

35% (69%)

4 1 % (63%)

Note: 1) Each type of defect is injected for a total of 1.970 tirnes.

Gate-Dnin Short

Gate-Source Short

Drain-Source Short

Gate-Chan Shon

Gate Open

Drain Open

Source Open

1-68 f

1.696 (3)

1.687 (2)

1,465 ( 15 1 )

1,327 93)

1,292

1.283 -

Table 6.2 Parity Checker Error Generation Statistics

CLASS

- - - -

Gare-Dnin Short

Drain-Source Short

1 Gate Open

Drain Open

Source Open t-- Drain Sub Shon

Source Sub Shon

1 TOTAL

KARD I SOFT

1 krcentage Caused 1 E m r Percentage

Error

Note: 1) Each type of defect is injected for a total of 168 times. 2) Numbers in brackets represent possible Errors.

Percentage Errors

- -

From TabIes 6.1 and 6.2 we see that for the ALU circuit, 70 % of the "Hard" class of

injected defects cause errors on the Resulf output. While 10% less "Sofi" defects cause output

errors. This leads to an ovenll error generation of 65 %.

For the parity checking hardware, approximately equal percentages of the "Hard and

"Soft" classes of defects generate errors on the POUTPOUT flags. leading to a total of 82 % of

injected defects causing error.

Table 6.3 provides the percent possibility that a single defect will cause an error in the - pass/fail flags of the complementary checker. These results show again that a "Hard defect is

more likely to cause an error in the checker output than a "Soft" defect. Combining the two

defect classes injected into the checker, shows that the flags will be in error under the influence of

68 % of al1 injected defects.

.Application of Methodology in a Benchmark

Table 6.3 Complementary Code Checker Errors Generated by Defect Injection

CLASS

Gate-Drain Short

Gate-Source Short

Drain-Source Short

Gate-Chan Shon

Gate Open

Dnin Open

Source Open

1 D n i n Sub Shon

1 Source Sub Shon

1 TOTAL

Caused Error Percentage

SOFT I Percentage 1 Percentage Error

Note: 1) Each type of defect is injected for a total of 1 .O38 times. 2) Numbers in brackets represent possible Errors.

B. Security Failure Statistics

The possibility that one of the defects causing an error as described above, will be missed

by the error detection flags of each of the nvo checkers, and thus will cause an insecure failure is

described by the results of Table 6.4 and 6.5.

.Application of Methodology in a Benchmark

Table 6.4 Secunty Failures for Parity Checker

SOFT I Percentage

Failures + Security Percentase FaiIures

# Security Percentage Failures

Gate-Drain Short

Gate-Source

Drain-Source 1 Shon

1 Gare Open

1 Drain Open

1 Dnin Sub Shon

1 Source Sub Shon

1 TOTAL

1 'iote: 1) Each type of defect is injected for a total of 2.138 time.

Table 6.5 Security Failures for Complementary Checker

DEFEC

Percentage Failures Y secun' Percemage

Failures # Secunty Percentage Failures

1 Drain-Source Short 1

Drain Open

1 Drain Sub Short 1 1 Source Sub Shon 1 1 TOTAL 1 1 ?lote: 1 ) Total nurnber injected for each type of defect is 2.998.

From Table 6.4 the possibility of a defect occumng within the circuit and causin, a an error

which is not detected by the pari. checker is 17 % of ail injected defects.

For a critical block benchmark using the complementary checker, the possibility of an

error occumng which does not register a fail fiag, given by Table 6.5, is 1 % of al1 defects.

C. Iooq Detection

In addition to the logical error generation statistics, the defect detection statistics for a

hypothetical Iddq test based on the simulation messages is also considered. These statistics may

support the use of a Iddq monitoring in addition to output monitoring as a means of in proving

fault security. Tables 6.6, 6.7 and 6.8 detail the defect coverage of an Iddq test for the input pat-

tern set. Again. the defect categories are split into, "Hard" and "Soft" classes. The number of

defects generating an increase in Iddq draw is listed in the first column of each class, beside which

is the percentage. The last column lists the total percentage of defects causing an increase in Iddq

current.

.r\pplicrition of btethodology in a Benchmark 6 - 14

Table 6.6 [ddq Detections Caused by Defect Injections into ALU

Percentage Iddq FauIts

Table 6.7 Iddq Detections Caused by Defect Injections into Parity Checker

HARD

SOFT

SOFT

Percentase Iddq Faults

Caused Iddq Increase

1,885

1.88 1

Percentage

95 %

94 %

Caused Iddq Increase

Caused Percentage Iddq Increase

Percen tage

95 %

95 %

92 '10

83 '/O

1 ?/O

7 1 O/O

78 O h

59 943

10 ?/O

65 OIo

Gate-Drain Short

Gate-Source Short

1 Note: 1 ) Each type of defect is injected for a total of 1.970 tirnes.

1.582

1,863

Drain-Source Short

Gate-Chan S h m

Gate Open 1

Dnin Open

Source Open

Drain Sub Short

Source Sub Short 1

TOTAL

1.825

1.833

1.828

84

113

1.441

497

1 1,253

92 O h

93 %

93 %

4676 %

6 %

73 %

25 %

63 O h

Caused Iddq Increase

1 Drain-Source Short 1 159 ( 95 %

1.82 1

1.64 1

39

1,410

1,550

1.160

207

1 1.594

Percentage

Gate-Drain Short

Gate-Source Short

1 Gate-Chan Shon 1 158 1 94 %

1 Dnin Open 1 O

159

159

1 source ~ p e n 1 O 1 0 %

95 %

95 %

1 Drain Sub Short 1 132 1 78 %

( TOTAL 1 965 1 64%

( Note: 1 ) Each type of defect is injected for a total of 168 tirnes.

Application of Methodolocp in a Benchmark

Table 6.8 Iddq Detections Caused by Defect Injections into Complernentary Checker

From these tables we see that the combined Iddq defect coverage of the ALU benchmark

alone would be 64 %. If designed as a fault secure system incorporating the parity check or com-

plementary code checking circuitry, then probability of an IDDQ monitor on its own detecting a

defect is:

For Panty:

P ,DDQ {detect} = P (defect in ALU} P ( ~ d d q defect coverage O ~ A L U ) (6-1)

HARD

+ P~tdefec t in parity checker) P (Iddq defect coverage of parity checker)

= 0.92(0.64) + 0.08(0.67) = 64 %

Note: 1 ) Each type of defect is injected for a total of 1.028 times.

Where P represents an estimated probability value based on the results of the defect injection

simulations performed for a limited input pattern set.

Percentage Iddq Increase

96 96

97 O/O

- -

87 %

93 %

50 %

32 %

36 %

43 %

50 %

69 ?/O

SOFT

Percentage

98 %

99 %

87 %

95 %

58 %

3 %

8 %

85 %

66 %

67 %

Iddq [ncrease

Application of Methodolog in ri Benchmark

Caused Iddq Increase

97 1

980

902

920

434

r

Gate-Drain Short

Gare-Source Short

Drain-Source Short

Gate-Chan Short

Gate Open

Drain Open

Source Open

Drain Sub Short

Source Sub Short 1

TOTAL -

Percentage

94 %

95 %

88 %

89 %

42 O h

1 ,O 12

I ,O 19

899

983

599

30

84

877

676

6.1 79

62 1

654

60 %

64 O h

I

807

353

6,642

78 %

34 %

72 '10 -

For Complementary:

P rDDQ(detect)= 0.66(0.64) + 0.34(0.69) = 66 %

By combining the output monitoring and curent monitoring results obtained from the sce-

nario one simulations. it is possible to obtain the irnprovement in security if both a cornpiemen-

tary checking scheme and an Iddq monitoring circuit were used. For the "Hard" class of defects.

such a situation is illustrated by the plot of Figure 6.7. The combined results from both hard and

Soft defects classes are given in Figure 6.8.

Complementary Checker Detection: Combined with Iddq Detecrion: Hard m

100% 100% 100% 100% 99% 98.9% 98.9% ' 000h99.6% 1 O o O / O

99% 98.9% 98.9% 99.1% - -

. b Defect Gate Gate Drain Gate Gate Drain Source Source Drain Drain Source Source Chan Open Open Open Subsmte Substrate Short Short Short Short Short Short

Figure 6.7. IDoQ and Complementary Code Error Coverage for Hard Defects

Cornplementary Checker Detection: Combined with IDoO Detection: n Hard m Soft g@q

Gate Drain Short

Gate Drain Gate Gate Drain Source Source Chan Open Open Short Short Short

+ De fect - - Source Source Drain Open Substrate Subsmte

Shon short

Figure 6.8. IoDQ and Complementary Code Error Coverage

AppIication of Methodology in a Benchmark 6 - 17

For the Hard class of defects. an IDDQ monitoring built-in test completely covers al1 mors

missed by the cornmendatory checker for 6 of the 9 possible defects. Only the hard open defects.

where no direct path between the supplies exists, escape the combined test. Combined results

from both classes of defects, shows a similar improvement in detection statistics. with 4 of the 9

defect category errors no longer causing unsecure failures.

6.3.4 Bridge Defect Injection

Due to their random placement, the results of the bridge defect injection is provided in

Table 6.9. Since a mismatch between the signal values of those lines being bndged results in an

unknown state, al1 of the erron generated are probable errors. Such mismatches aIso cause an

increase in IDDQ current draw. Once excited, al1 of the probable faulty signal values were

detected by the checking schemes, causing no failures.

Table 6.9 Bridge Defects Error Generation

Scenario 1 IDDQ Monitor

Caused Percentage Errors

Penientage lddq lncrease

ALU (53) 88 % (53) 85 %

Complementary (54) IO0 % (54) 100 %

Pan ty Checker (34) IO0 % (34) 1 O0 YO

.Application of biethodology in a Benchmark

6.3.5 Results on Error Masking Scenario

In this second scenario, errors are placed on the inputs to each of the checking systems.

then defects are injected into the checker circuits. When an error flag is masked by the defect.

then an unsecure failure has occurred.

The results from the simulations of the second scenario are presented in Tables 6.10 and

6.1 1. The results of these simulations represent the possibility of a defect occumng within either

checking scheme. masking an output error.

Table 6.10 Error Masking Secunty Failures for Parity Checker

As is shown by the resuIts of Table 6.10, hard defects, especially those which usually man-

ifest as logical errors, have twice the probability of masking an error flag as the sofi class of

defects. Overall, of the possible defects injected within the parity checking hardware, 1.5 %

rnasked the error signal being generated by the checker.

Application of Methodology in a Benchmark

1

Percentage Failures

4 ?O

2 ?/O

- 7 46 4 110

1 ?/a

0

0.2 Oh

O

O

1.5 OIo

Note: 1 ) Each type of defect is injected for a total of 168 times. I

HARD SOFT

Percentage

5 O h

5 %

5 O h

3 %

O

0

O

O

O

1.9 % m

# Secunty Failures

4

O

O

8

4

O

1

O

O

17

' Failures

Percemage

2 %

O

O

5 %

3 %

O

0.5 %

0

O

1 %

Gate-Drain Short

Gate-Source Short

Drain-Source Short

Gate-Chan Short

Gate Open

Drain Open

Source Open

Drain Sub Shon

Source Sub Shon

TOTAL

9

8

8

5

0

O

O

0

O

30

Table 6.11 Error Masking Security Failures for Complementary Checker

HARD SOFT

Gate- Drain Short 9 0.8 % 32 3 %

Gate-Source Short 8 0.8 % 29 3 %

Drain-Source Shon 10 10 % 19 2 %

Gate-Chan Short 13 12 % 32 3 %

Gate Open 18 17 % 30 3 %

Drain Open 0 0 3 0.3 ?/O

Source Open 1 0.1 % 1 0.1 %

Drain Sub Short 10 10 % 15 I %

Source Sub Short O O 7 0.6 %

TOTAL 69 0.7 % 168 1.8 %

Note: 1 ) Each type of defect is injected for a total of 1 .O28 times.

Percentage Iddq Increase

Table 6.1 1 illustrates that 1.3 % of the possible injectable defects wiH mask a flag from

the complementary checker.

Application of blsthodology in a Benchmark

6.3.6 Fault Security Figure of merit

From the results obtained fiom the first scenario simulations, it is possible to determine

the figures of ment for both the parity checker and complementary checker fault secure imple-

mentations of the benchmark, valid for a single defect environment.

From Chapter 5. it was shown that for a fault secure system incorporating some form of

coding scheme. the pr0bab;lit.y of maintaining secure operations given that a defect has occurred

is:

P { Secure Operations) = 1 - P (Failure 1 defect) (5-4)

From the single defect scenano results with the panry checker benchmark vie have:

P { Failure 1 defect ) = P { Defect causing an error in Result not detected by checker ) (6.2)

= 0.17

Therefore. equation (5.4) for the parity checking benchmark in a single defect environ-

ment is:

P {Secure ope ration^)^,,, = 1 - 0.17 = 83 % (6-3

Results for the complementary code benchmark shows a greater than 10 % improvement

in secure operations over the parity checking approach:

P (Secure ope ration^)^,,^^,^ = I - 0.0 l = 99 %

For a multiple defect environment, there must be some accounting for dormancy, and

defects in the checking hardware masking a "fail" flag. As mentioned in Chapter 5 equation (5.9).

.\pplication of Methodolog>. in a Benchmark 6 - 21

accounts for such situations when the possibility of two defects existing within a system are con-

sidered[ 1 ].

For the parity benchmark, this gives:

P (Failure 1 defect) = P {Failure 1 defect) + f (Error Flag Masked ( defect) (6.5)

x P {defect in checker)

= O. 17 + 0.0 Z 5 (0.08)

= 17.1 %

Since the size of the parity checking hardware is much smaller than the total size of the

circuit, the figure of merit From equation (6.5) representing the probability of fault secure opera-

tions for the parity checker is virtually identical to the single defect case:

P { Secure Operations) = 1 - 0.17 1 = 82.9 % (6.6)

For the complementary code checker the figure of ment is similar to that of the sinzle

defect case, however, since the size of the complementary checker is on the order to that of the

checked circuit the second term reduces the probability of secure operations by 0.5 % . The level

of confidence in a complementary checked system is higher than the parity checking system. and

is shown as:

f {Secure Operations} = 1 - [ 0.0 1 + (0.0 13) 0.34 ] = 98.5 %

Additionally, the improvement in error coverage, described by Figure 6.8, combining an

IoDq detection scheme with the complementary checking system could be used to calculate a new

failure probability for a hypothetical fail-safe system incorporating both detection methods:

Application of Mtthodology in a Benchmark 6 - 22

The IDDQ detection scheme catches more than half of the failure conditions from the

complementary checking scherne. The new figure of ment for this combined detection system for

single defects and multiple defects h m equations (6.4) and (6.7) would be

P (Secure Operations) ,fect = L - 0.004 = 99.6 % ; and (6-8)

P {Secure Operations )Multiple defect = 1 - [ 0.004 + (0.0 13) 0.34 1 = 99.2 % (6.9)

In both cases the improved failure coverage leads to an improvement in attainable level of

confidence.

6.3.7 Life Cycle Analysis

To perform life cycle analysis, the use of a Markov statisrical model requires that the tran-

sition probabilities between States be calculated. This will require the extraction of the necessary

parameten from the simulation data. The results of the simulation scenarios discussed in the pre-

vious sections were used to generate a Markov model for each of the benchmarks; Figures 6.9.

and 6.10. For these Markov models h, is the defect amval rate. and t represents time.:

1 -kt 1

0.56 ht

0.34ht 1

Figure 6.9. Statistical Modei of the Parity Checker for T h e Based Fault Secure Calculations

.Application of b1ethodoIogy in a Benchmark 6 - 23

From the terminolog of Chapter 5 and using the tables in the Results section above:

DFEF (EFA) = DFA = [ ( 1 - ALU Failures in scenario I)(Error 1 defect in ALU) (6.10)

x (defects in ALU / 1) ] + (Errod defect in checker)(defects in checkedl):

Uchecker/Ichecker = Failmes in scenario 2 : defects h checker (6.11)

For Parity = 0.0 15 . and For Complementary = 0.0 13 ; and

Finally Ichecker/I : For P a n y = 3.024 / 38,484 = 0.08

For Complementary = 18,504 / 53,964 = 0.34

From these statistics equations from Chapter 5 were used to calculate the transition proba-

bilities for the Markov mode1 of Figure 6.9. as follows:

Application of Methodology in a Benchmark 6 - 21

Figure 6.10. Statistical Mode1 of the Complementary Checter

For the statical rnodel of the complementary checker in Figure 6.10. the probabilities for

state transitions are defined from the same notation as the parity example as follows:

Application of Methodology in a Benchmark 6 - 35

P LL= P (defect in ALU} x ( 1 - P { Error) ) + P {defect in checker)( 1 - f ( Errori ) (6.24)

= 0.66 (1 - 0.65) + O . N ( 1 - 0.68) = 0.34

Using the previous parameter value rnodels of Figures 6.9 and 6.10, along with a defect

rate and a desired probability of secure operation, the MTTF can be calculated. However. since

this design is hypothetical, no manufacture yield or testing information is available fiom which to

estimate a defect amval. Therefore, more than one defect arrival rate (A) must be selected to rep-

resent a likeIy h bounds. A plot of the resulting curve for the probability of fault secure opera-

tions verses tirne can then be created for these different A. Such plots show the effect of detèct

arriva1 rate on secure operations. The estimation of the circuit replacement time. then becomes a

maaer of choosing a time value which rneets the probability of fault secureness desired. as read

along one of the defect amval curve of interest.

By following the closed loop Markov chain around the loops to a failed unsecure we can

gei the probability of a system failing unsecure, and alternatively the probability of a system

rernaining secure over tirne as was shown in Chapter 5.

P (Secure Operation) = 1 - [ P + P L( P Lnis) ] ht

The charts of Figures 6.11 and 6-12 represent this probability of a system remaining fault

secure over time. In each plot. three selections of a defect arriva1 rate (h ) were chosen[l. 1 11.

Application of Miietliodology in n Benchmark 6 - 26

Figure 6.11. Probability of Secure Operation over time for Pariry Benchmark

~ppiicafton of ivlethodoiogy in a Benchmark

Figure 6.12. Probability of Secure Operation over rime for Complementary Benchmark

Fmrn the Plots of Figure 6.1 L and 6.12, the improvement in probability of fault secure

opention by the complementary checker cm be seen. If we assume that the cntical application

perfomed by the benchmark required a >90 % level of fault security for a possible defect arriva1

rate up to 1 defect every 100,000 hours, then the use of a cornplementary code checker would pro-

vide a in-service time which is an order of magnitude greater than that afforded by the parity

benchrnark. Requiring the parity benchrnark be replaced in approximately 5 years compared to

about 50 years for the complementary design.

Application of Merhodology in a Benchmark

Chapter 7

Conclusion and Future Work

7.1 Summary of Objectives

This research anempted to produce a framework towards the verification of highly fault

secure systems. From Chapter 1, the goals set out as targets for the framework developed by this

thesis work were:

I ) Automation of the analysis process.

2) Relevant results applicable for design verification and design aid.

3) Mode1 portability to different technologies.

4) Compatibility berneen comrnon VLSI CAD tools.

7.2 Concluding Remarks

This thesis has presented a technique suitable for conducting fault secunty analysis. with

emphasis on integrated circuit technologies. It is believed that this analysis process fulfills the

above requirements necessary for the venfication of highly fault secure or high reliable digital

designs.

The use of the VHDL simulation environment to achieve statistical results. introduces

automation into the analysis. This is accomplished by the creation of a testbench controller

defined for use with this process, which automates the defect injection during simulations. Fur-

ther. programs have been developed for post processing of the simulation data.

As illustrated by the benchmark examples, this technique as presented, can determine

defect coverage and error detection statistics of a given checking hardware. VHDL simulation

Conclusions and Future 1Vork

results are used to calculate a figure of ment representing the level of confidence achievablr by

fault secure designs. Relative strengths between competing checking systerns can also be estab-

lished aiding designers in improving the fault tolerance of critical systems.

The technology defect analysis provides fault response models for the defects of interest.

The use of files to store defect to fault mapping data, and fault excitation information. allows the

same VHDL mode1 to be applied to different gate structures. Additional defect analysis can be

performed on other technologies in the sarne manner as was illustrated by the CMOS analysis per-

fonned as part of this thesis work. Further, this file system also models the effects of defect

dormancy and fault latency.

Finally, since the VHDL models make use only of standard VHDL comrnands to conduct

defect injection and output monitonng, no sirnulator commands are required. Further. the anaiy-

sis technique uses only the "Std VHDL library for types and functions. al1 other Functions and

data types are contained within a package created for use with this technique. Segments of this

package are included in Annex B.

Some notable results were uncovered by the benchmark analysis usine the technique

developed here. The first noticeable trend is the importance of the selection of the coding scheme

used by the checking hardware. Although both benchmarks were monitoring the same critical

block. the high possibility of a defect producing multiple errors presented a problem for the parity

checker whose figure of ment represented a 10 % lower level of confidence in its fault srcure

operation. even though the defect covenge of the checker itself was higher then that of the com-

plementary checker.

The second result of interest was the improvement afforded by an IDoQ testing system

used in conjunction with a logical checking scheme. By itself current monitoring provided a

66 % defect coverage for the ALU block, which is a similar coverage to the output error results.

However the addition of an IDDO test based upon the IDDQ increase flags fiom the simulation to

the complementary checking system, showed a 50 % reduction in the failure probability of the

Conclusions and Future Work

complemenrary checker. highlighting the usefulness of IoDq tests for CMOS designs.

Although temporal dispersion of defect injections during a simulation can be used to

detennine fault security of a system over a given time, a statistical model has been proposed for

time to failure analysis. As illustrated in Section 6.3.4, a plot of the probability of fault secure

operations over time can be generated fkom results obtained from the defect injection simulations.

These plots c m be used to gauge the trade-off between the fault security of a system. and its in-

service life span. The selection of a level of confidence in fault secure operations then leads to a

maximum time for this system to be in operation. This time represents the MTTF for that system.

Limitations of Life Cycle Analysis

A first order approximation was used in the statistical model for multiple defect effects.

although not ideal, still yieids useful results as exemplified by the error masking probabilities

from the benchmark analysis. and represents an improvement over previous work. In industry.

restino y paradigns most often use statistics for built-in test coverages based upon single faults

rxisting within the circuit[l. 131. This thesis has stepped beyond these approaches by considering

multiple fault behavior generated by likely defects. Then using these results to estimate security

of a fault secure system. The exact extension of analysis techniques towards multiple defects will

be left to future works

7.1 Future Research

Defect iMode1ing

Previous studies have illustrated the difficulty in mapping fault injection results to actual

IC defects[3,7,13,16]. By defining the level of abstraction for the fault models as the gate level.

and creating VHDL behavioral descriptions from the results of defective gate analog simulations.

realistic fault categones have been predicted.

Therefore, critical to the results provided by this analysis technique is the accuracy of the

Conclusions and Future iVork

fault categories used to model defective gate behavior. Extensive simulation has been used to

eenerate the mappings used for the benchmark analysis, however the correlation between these L

simulation results and real life defects is still an area of possible concem. A proposed solution for

this issue would be the fabrication of a test IC containing purposely defective gate ce11 structures.

Physical testing of these structures wouid verifi or correct the faulty behavior proposed in this

work.

Bndging defects also pose a unique problem. The modeling technique presented in this

thesis treats signal line bridges as a single class of defects. Other studies have separated signal

line bridges into classifications dependant upon the types of signal lines bridged: power lines:

clocking signals: or gate interconnects. Further investigation into bridge distribution. and model-

ing may be required.

Lastly, technologies other than CMOS should be investigated to determine additional fault

categories. Studies of additional IC processes will not only produce a more complete set of fault

categories. but may also require different VHDL gate models. The mechanism of the technolog

analysis phase of the analysis process covers this issue.

Simulation Time

Aithough the presented framework is complere as a proof of concept and. as illustrated in

Chapter 6 , for application to circuits of moderate size, improvements need to be made before this

technique can be efficiently used for the analysis of large designs. The time required for defect

injection and simulation present a bamer for practical use of this analysis technique indusw

ivide. For an exhaustive defect injection s h o w here, simulations times are on the order of days.

Clearly this is excessive for design cycle applications.

Defect collapsing techniques could be used to reduce the defect list required for injection.

Defect collapsing involves the rernoval of defects whose physical site or electncal location pro-

duce identical faulty behavior as other defects.

ConcIusions and Future h'ork

Increased Automation

The final area for irnprovement of this analysis process is to increase the automation of the

oate mode1 placement into pre-existing VHDL descriptions of fault secure systems. Even though V

the programming of such automated tools wouid not represent a major effort, it was beyond the

scope of this thesis.

C~nclusions and Future Work

References

[Il "Fail-Safe Design and Evahation Techniques", US Department of Defence Contract

#MDA904-93-C-4027 Final Report, Submitted by Centre for Digital Systems Engineering,

Research Triangle Institute, Sept. 1994.

[2] J. Coppens, D. Al-Khalili, C. Rozon, and M. Hossain, "Deject Mapping and Farrft Injection

into CMOS CHDL Models", Accepted for IAS'IZD Control '97, May 1997.

[3] J. Arlat. M. Auguera, L. Arnat, Y. Crouzet, J.-C. Fabre, J.-C. Lapne. E. Martins, and D. Pow-

el 1. "Farrh injection for Dependabiliy Vaiidaiion: a Me thodology and Some Applicarions ". E E E Transaction on Software Engineering, Feb. 1990, pp 166- 182.

[4] M. Abrarnovici. M. A.B reuer. A.D. Friedman, Digilal xvstems Tesring and Tesrable Desip.

IEEE Press. 1990

[5] F.J. Ferguson. and J.P. Shen, "E~traciion and Simtrlation of Realisiic CMOS Fardis rrsing

Indrrciive Farrlr A n a b i s ". IEEE International Test Conference, 1988. pp 475 - 484.

[6] E. Jenn. I. Mat . M. Rimén, J. Ohlsson, and J. Karlsson, "Fault Injection into VHDL ModeZs:

The MEFIS70 Tool", Proc. 24th International Symposium Fault-Tolerant Computing. IEEE . 1994. pp 66-75.

[7] T. Delong, B. Hohnson, and I. Profeta III, "A Fault Injection for VHDL Beltavioral-Level

Models", IEEE Design and Test of Computers. Winter 1996, pp 24-33.

[8] R. Lipsett, C. Schaefer. and C. Ussery, VHDL: Hardware Description and Design. Kluwer

Academic hblishers, 1 989.

[9] D.L. Peny. VHDL Second Ediiion, McGraw-Hill, 1994.

[10]J. Coppens. D. Al-Khalili, C. Rozon, M. Hossain, "Security Foult Anal~vsis Using VHDL -

Interim Report", RMC Tech Report Dec 96.

[l IlS. Owre, J. Rushby, N. Shankar, and F. von Henke, "Forma1 Verification for Fault-Toleranr

Architectures: Prolegomena to the Design of PVS", IEEE Transactions on Software Engineer-

ing. Vol 21, No 2, Feb 1995, pp 107-125.

[12]T. Nanya and T Kawamura, "A Note on Strongtv Fault-Secure Sequential Circzii~s," IEEE

Trans. on Computers, Vol C-36, No. 9, Sept 1987, pp 1 12 1 - 1 123.

[13]5. Sousa, F. Goncalves, J. Teixeira, and T. Williams, "Fault Modeling and Defecr Level Pro-

jections in Digiral ICs", IEEE Transactions on Computers. March 1994. pp 436-442

[14]C. Ash. The Probabiliy Tuloring Book. IEEE Press. 1993

[15]J. Coppens, M. Hossain. D. Al-Khalili, and C. Rozon, "CiMOS VLSl Fault Modes". RMC

Tech Report. Dec 1996.

[ 16JF. Celeiro et al, "Defect Oriented IC Test Diagnosis Using VHDL Fault Simulation". IEEE

International Test Conference, 1996.

[ 1 7]B .E. S tewan, "BICMOS Testability Ana[vsis and Fault Modeling ", MSc. Engineering Thesis.

RMC, May 199 1.

[18]M. Hossain, D. Al-Khalili, C. Rozon, and I. Coppens, "Defect Models of CMOS Devices '',

RMC Tech. Report. Feb. 1996.

[19]D. Thompson. and R. Wood, "Semicondz[ctor Defect Reliability Modeling". IBM Technical

Report 1996.

[ZOIC. Hawkins, "IC Trends. Qualify, Defects. Testing and Reliabiliy", Intemal course. Norte].

1996.

[ 2 1]K. Quader, E. Minarni, W. Huang, P. Ko. and C. Hu, "Hot-carrier-Reliabiiity Design Gtiide-

iinesfbr CMOS Logic Circuits", IEEE Journal of Solid-State Circuits, Vol. 29. No. 3. March

1994, pp 253 - 261.

[22]Y. Leblebici. and S. Kang, "Modeling and Simulation of Hot-Carrier-lndtîced Device Degra-

dation in MOS Circuits", IEEE Journal of Solid-State Circuits, Vol. 28, No. 5 . May 1993.

pp 585 - 595.

[23]G. Choi. an R. Iyer, " Wear-Out Simularion Environment for VLSI Designs". IEEE. 1993.

pp 320-329.

[24]J. Soden, C. Hawkins, and A. Miller, "Identzfiing Defects in Deep-Submicron CMOS ICs".

IEEE Spectrum, Sept 1996. pp 66-71.

[25]C. Hu, "IC Reliability Simulation", IEEE Journal of Solid-State Circuits. Vol 27, No 3.

March 1992. pp 24 1-246.

[26]A. Miczo, " VNDL A s a kfodeling-For-Testabiiity Tool", Proc. COMPCON'90, IEEE. Feb.

1990, pp 403-409.

[27]D.E. Mercer, "Performance Measurement of VHDL Models", MSc Engineenng Thesis,

Royal Military ColIege of Canada (RMC), April 1993.

[28]g. Choi, and R. Iyer, "FOCUS: An Experimental Environment for Fatilt Sensitivi~ Ana&sis".

IEEE Transactions on Cornputers, Vol 41, No 12, Dec 1992, pp 15 15- 1526

Annex A

Fault Category Coverage Statistics for Basic CMOS Gates

inverter Total Defects: 18

Hard Defects Sofi Defects

NAND Total Defects: 36

LEGEND

0 IDDQ Increase

Delay Faults

Noise Magin Faults

S tuck at Faults

NOR Total Defects: 36

Hard Defects Soft Defects Hard Defects Soft Defects

XOR Total Defects: 108

D - Latch Total Defects: 108

Hard Defects Soft Defects Hard Defects Soft Defects

Annex B

Thesis VHDL Package - Faultgak

--This is a package for use with the fault rnodels developed --- --in the Security Fault Analysis. --- -- --Tpes of faults and logic levels considered in the --simulations are defined below, and described in the --package documentation. -- --Resolution function and constant tables are also included --- -- --- --Written by Jason Coppens Version 3.0 Date: 17 Dec 96 ---

TYPE fault-b 1s (bG','A','B','C*,'D'.'E'.'F','H','I'l'J','K','L*,'M'l'N'. 'O'.*P7.'Q','R'~'S',?T'.'U','V'.~W'.'X*,~Y'.'Z'.'z'):

TYPE fault-1 IS ARRAY (O TO 1) of fault-b; TYPE faults 1S ARRAY (natural RANGE O) of fault-1; TYPE faults-vec IS ARRAY (natural RANGE 0, natural RIWGE 0) of fault-1: TYPE defect f S RECORD

ident : fau l tb : transistor : natural; END record;

TYPE defects IS ARRAY (natural RANGE 0) of defect; TYPE levels IS ('U','X','l'.'O'.'Z','L','H','W'); TYPE Ievels-vec IS ARRAY (natural RANGE O) of levels; FUNCTION resolved (input : levels-vec) RETURN levels; SUBTYPE logic-lvls IS resolved levels; TYPE logic-lvl-vec IS ARRAY (natural Range 0) OF logic-lvls; TYPE gateqort IS ARRAY (O TO 1) OF logic-lvls; TYPE portbus IS ARRAY( natural Range O) OF gategort; FUNCTION invt (input, output : levels) RETURN levels; FUNCTION nand2 (ina:levels; inb:levels; output: levels) RETURN levels; FUNCTION nor2 (ina, inb, output : levels) RETLRN levels; FUNCTION xor2 (ka, inb. output : levels) R E W levels; FUNCTION latch (ind, inen, output : levels) RETLlRN levels; FUNCTION mux2 (ina, inb, sel: levels) R E W levels; FUNCTION to-string (input : levels) RETURN string; FUNCTION from-string (input : character) RETURN levels; FUNCTION check (simulator, sample : INTEGER) RETURN boolean;

END fault;

PACKAGE BODY fault IS

--Types and constants for use in the logic models:

TYPE levels-table IS ARRAY (levels, levels) OF levels; CONSTANT resolution_table : levels-table := ( -- U X I O Z L H W

(~u','x',lx',lx'~'u',lx'~'x',lx')~ --u ('x','x','x'.lxl~'xl,'xl,'x',lx')~ --x ('x','x','l','x','11,'H','11,1H')9 --1 (bx','x'*'x','ol,'o'''o','~,'L1), --O ('u',.x',l 1 ',~o',lz~,'r,lH',lw')~ --z ('X','X','H','0'.'~,'L','X',~L1), --L (bX'.*X'.' 1 ','L.'H1,'X','H','H'), --U ('X','X'.'H','L,'W1.'L,'H'l'W'));--W

TYPE oneD-table [S ARRAY (levels) OF Ievels; CONSTANT inv-table : oneD-table :=

(bu'**x','o',' 1 '"X',' 1 l,'o','x'): -- U X I O Z L H W - - CONSTANT nand2-table : levels-table := ( -- U X l O Z L H W

('u-.'ul,lul,' 1 ','U9,' 1 '.'U','U')* --u (Lu','x'.'x',' 1 '"X',' 1 ','X','X1), --x (bu7,7x',90y 1 1,qx9,v 1 1,701,9w7), -- i ( b 1"' 1','1',' l'.'l'.'l','l','l'), --O ('U','X'.'X9,' 1 '.lx',' 1 ','X','X'), --z (- l ' . ' l ' ,~ l '~ ' l ' , ' l ' , ' l~ l l l ' , ' l ' ) , --L (bU','X','O1,' l'l*X',l ll,'O1,lX1), --H ('u','x'.lx',' 1 ','XT,' 1 ',*X','W1));--w

CONSTANT no-able : Ievels-table := ( -- U X I O Z L H W

('u1,'u',10',7u1.'u','u1,'0111u1)l --u (iu'~'x','o','x','x','x','o'*'x')l --x ~ ~ 0 ~ ~ 1 0 ~ , ~ 0 ~ ~ ~ 0 * , ~ 0 ~ , 1 0 ~ , 9 0 ~ , 1 0 ~ ~ , -- 1 ('u','x'llo',' 1 l,'xl,' 1 ','o',lx'), --O ('u','x'.'o*l'x'~'xl,'x','o','x'), --z (4u9,1x-110*17 1 '11x1,7 i 9,901,7x7, --L ~ b 0 1 , ~ 0 9 , 1 0 = ~ ~ 0 1 , 1 0 3 , ~ 0 7 ~ 9 0 9 ~ ~ 0 ~ ~ , --FI (4u','x','0111x1,1x~,1x9,'01,'w'));--w

CONSTANT ~or-table : Ievels-table := ( -- U X I O Z L H W

(LU','U','U'~'U','U'~'u','u7~fu'), --U

-- CONSTANT r n ~ t a b l e : levels-table := ( -- U X I O Z L H W

--This fûnctions perfomes a resolution of multiple logic -4evel drivers on the sarne signal. *-----

FUNCTION resolved (input : levels-vec) RETURN levels IS VARIABLE result : levels; BEGIN

IF (input'LENGTH = I ) THEN result := input(input'L0W); ELSE

result := input(input ' LOW); FOR i M input'RANGE LOOP

result := resolution~table(result, input(i)); END LOOP;

END IF; RETURN resul t;

END resolved;

CASE flt [S

When "AA" => -- OUT SA 1 If (exc ite(ina-fc, inb-fc, "AA" , nandtwo) ) THEN

fltout := ' 1 '; END IF; delay := O ns;

When "AB" => -- OUT SA O delay := O ns; IF excite(ina-fc. inb-fc. "AB" . nandtwo) THEN

fltout := 'OT; END IF;

When "AC" => -- A SA I delay := O ns; IF excite(ina-fc, inb-fc, "AC" . nandtwo) THEN

fltout := invt(inb-fc. out-f); END IF;

When "AD7'=> -- A SA O IF excite(ina-fc, inb-fc. "AD" , nandtwo) THEN

fltout := ' 1 O:

END IF; delay := O ns;

When "AF" => -- B SA O IF excite(ina-fc. inb-fc. "AF" . nandtwo) THEN

flt-out := 1 '; END IF; delay := O ns;

When ''AEV=> -- B SA 1 delay := O ns; IF excite(ina-fc, inb-fc, " A E , nandtwo) THEN

flt-out := invt(ina-fc, out-f); END IF;

When "AJ"=> --Out SA A Input If excite(ina-fc. inb-fc, "Aj" , nandtwo) THEN

f l tout := ha-fc; END IF;

When "AK"=> --Out SA B Input If excite(ina-fc, inb-fc, "AK" , nandtwo) THEN

flt-out := inb-fc; END IF;

-- --Sequencial Faults

-- When "AM"=> -- A iduenced break to VDD

IF excite(ina-fc. inb-fc, "AM" , nandtwo) THEN Atout := o u t f :

END IF; delay := O ns;

When "AOW=>-- B influenced break to VDD IF excite(ina-fc, inb-fc, "AO", nandtwo) THEN

fltout := out-fi END [F; delay := O ns;

When "AN" 1 "AI"'=>-- A B influenced break to VSS IF (excite(ina-fc, inb-fc, "AP", nandtwo) OR

excite(ina-fc, inb-fc, "AN", nandtwo)) THEN fl tout := out-f;

END IF; delay := O ns;

--PERFORMANCE FAULTS --Delay Faults

When ''BAW=> --delay- 1 (tplh) IF (excite(ina-fc. inb-fc, "BA", nandtwo)) THEN

flt-out := nand2(ina-fc, inb-fc, out-0; IF ((fit-out = ' 1 ' OR flt-out = 'H') AND (out-f = 'O' OR out-f = 'L')) THEN

delay := 1 ns; ELSE delay := O ns; END IF;

END IF; When "BB"=> --delay- 1 (tphl)

IF (excite(ina-fc, inb-fc, "BB", nandtwo)) THEN flt-out := nand2(ina-fc, inb-fc, out-f); IF ((flt-out = 'O' OR fltout = 'L') AND ( o u t f = ' 1 ' OR out-f = 'H')) THEN

delay := 1 ns; ELSE delay := O ns; END IF;

END IF; When "BC"=> --delay-2 (tph)

IF (excite(ina-fc, in-, "BC", nandtwo)) THEN flt-out := nand2(ina_fc, inb-fc, out-0; IF ((flt-out = ' 1 ' OR flt-out = 'H') AND ( o u t f = 'O' OR out-f = 'L')) THEN

delay := 46 ns; ELSE delay := O ns;

END IF: END IF;

When "BD" => --delay-2 (tphl) IF (excite(ina-fc, inb-fc, "BD", nandtwo)) THEN

flt-out := nand2(ina_fc, inb-fc, out-f); IF ((flt-out = 'O' OR flt-out = 'L') AND (out-f = ' 1 ' OR o u t f = 'H')) THEN

delay := 46 ns; ELSE delay := O ns; END IF;

END IF; -- --VTC Faults --

When "BEw=> --VTC-1 (VDD Reduced) IF (excite(ina-fc, inb-fc. "BE", nandtwo)) THEN

flt-out := nand2(ina-fc, inb-fc, out-0; IF (NOT(flt-out = out-0) THEN IF (flt-out = ' 1 ') THEN

fltout := 'H'; END IF; vtc := true; END IF:

END IF; delay := O ns;

When "BF"=> --VTC- 1 (VSS Reduced) IF (excite(ina-fc, inb-fc, "BF", nandtwo)) THEN

Rt-out := nand2(ina_fc. inb-fc, outf); IF (NOT(flt-out = out-0) THEN IF (flt-out = '0') THEN

fltout := 'L'; END IF; vtc := m e ; END IF;

END IF; delay := O ns;

When "EUT'=> --VTC-l (VDD and VSS Reduced) IF (excite(ina-fc, inb-fc, "BR', nandtwo)) THEN

flt-out := nand2(ina_fc, inb-fc, outf); IF (NOT(flout = out-0) THEN IF (flt-out = '0') THEN

fltout := 'L'; ELSIF (fit-out = ' 1') THEN

fltout := 'H'; END IF; vtc := m e ;

END IF: END IF: delay := O ns;

When "BI"=> --Deg. Swing(DS) (VDD Reduced) IF (excite(inafc, inb-fc, "BI", nandtwo)) THEN

flt-out := nand2(inaefc, inb-fc, outf); IF (NOT(flt-out = out-0) THEN IF (flt-out = ' I ') THEN

fltout := 'W'; ELSIF (fltout = '0') THEN

fltout := 'L': END IF; vtc := me; END IF;

END IF; delay := O ns;

%%en "BJ"=> --DS (VSS Reduced) IF (excite(ina-fc, inb-fc, "BJ", nandtwo)) THEN

flt-out := nand2(ina-fc, inb-fc, outf) ; IF (NOT(flt-out = out f ) ) THEN IF (At-out = 'O1) THEN

fltout := 'W'; ELSIF (fltout = ' 1 ') THEN

fltout := 'Hl: END IF; vtc := tnie; END IF;

END IF; delay := O ns;

M e n "BK"=> --DS (VDD and VSS Reduced) IF (excitetina-fc, inb-fc, "BK", nandtwo)) THEN

flt-out := nand2(ina-fc. inb-fc, outf); IF (NOT(flt-out = ou t f ) ) THEN IF (fit-out = 'O' OR fltout = ' 1 ') THEN

flt-out := 'X': END IF; vtc := true; END IF;

END IF; delay := O ns;

--IDDQ Faults. These are exceptional fault catagories. They can be used as individual --Iddq Aags (for detection statistics) or in conjection with other faults to simulate --realistic defect responses. --

M e n "BL3'=> --IddqO (increased Iddq draw)

IF (excite(ina-fc.inb-fc. --BL". nandtwo)) THEN iddq := tue; END IF; deiay := O ns;

When "BM"=> --Iddq 1 (increased Iddq draw) IF (excite(ina-fc, inb-fc, "BM, nandtwo)) THEN iddq := me: END IF; delay := O ns;

When "BN"=7 -4ddq2 (increased Iddq draw) IF (excite(ina-fc, inb-fc, "BN", nandtwo)) THEN iddq := me: END IF; delay := O ns;

When ''BO"=> --Iddq3 (increased Iddq draw) IF (excite(ina-fc'inb-fc, "BO", nandtwo)) THEN iddq := tme; END IF; delay := O ns:

-- --unfaulty : --

When "GG"=> fit-out := nand2(ina-fc'inb-fc'out-f); delay := O ns; EXIT injection:

When others=> fltout :='Z'; END CASE;

IF delay-max < delay THEN delay-max := delay; END IF: out-temp := resolved(out~temp&flt~out);

END LOOP injection;

--output checking. IF (out-temp = '2 ' ) THEN out-temp := nand2(ina-fc,inb-fc,outt); END IF: -------------_---_-----"--------------------d-----------------

o u t f <= out-temp AFTER prop+delay-max;

delay := O ns; delay-max := O ns; counter := 0;

AS S ERT (NOT(iddq)) REPORT "Possiable Iddq detectable fault caused by:"

& to-saing(ina-fc) &" and " &to-string(inb-fc) & " value on inputs."

SEVERITY note; iddq := false;