Nofault ET

No Faulting Techniques in Encounter
Test
Product Version 15.x

October, 2015
Copyright Statement
2015 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence and the Cadence logo are
registered trademarks of Cadence Design Systems, Inc. All others are the property of their respective
holders.
Learn more at Cadence Online Support - http://support.cadence.com

2015 Cadence Design Systems, Inc. All rights reserved worldwide. Page 2
No Faulting Techniques in Encounter Test
Contents
Purpose ....................................................................................................................... 4
Audience ...................................................................................................................... 4
Overview ...................................................................................................................... 4
Build Fault Model ......................................................................................................... 5
Controlling the Modelling of Faults............................................................................... 7
Excluding the dynamic faults from fault list .............................................................. 7
Fault Rule Files ........................................................................................................ 7
How to IGNORE few selected faults from the fault list ........................................... 18
How to No-Fault only the pins of a modules ........................................................... 21
How to ignore scan-enable/reset faults during TFT................................................ 22
How to migrate faults from the block level to the top level ..................................... 23
How to Fault-Only at the pins of an instance .......................................................... 25
How to ignore faults around blackboxes ................................................................ 27
Support ...................................................................................................................... 28
Feedback ................................................................................................................... 28

Purpose
This application note illustrates how to use various Faultmodel options efficiently
to control and modify the modelling of Faults as per user requirements.
Audience
All Encounter Test (ET) users who want to modify the Faultmodel.
Overview
This document describes various techniques used to control the modelling of faults
using Cadence Encounter Test. These techniques, based on the coverage calculations
and examples in different situations, are explained in detail.
The build_faultmodel command provides an option of fault rule file where a user can
direct the tool to take specified action on the listed faults. Some of the examples and
utilities where fault rules could be used as required are discussed in details. The
document explains the usage, syntax and application of the fault rule file with examples.

Build Fault Model

The effectiveness of ATPG is measured by the amount of defects modeled (fault
models) and patterns generated. A fault is said to be detected by a test pattern if the
output of that test pattern is not as expected, considering the device has only that one
fault.
The ET ATPG flow starts with building a model of the design/netlist, a testmode and a
fault model. The faultmodel command identifies a list of faults that are to be targeted for
testing during ATPG.
The fault model can include static (stuck-at), dynamic (transition), Iddq, and parametric
(driver/receiver) faults, and other pattern faults defined with fault rules. By default, the
fault model includes static, dynamic, and Iddq faults. Parametric (driver/receiver) faults
are included only if they are explicitly selected.
The only required input for creating a default fault model is an ET Model. If test modes
exist, these are also used as input to build the fault model in determining the active fault
count. Faults are classified as inactive when they cannot be observed due to a
constraint while building the testmode. ATPG works on the active faults only for each of
the testmode.
Example 1: The simplest example of the build_model and build_faultmodel commands

will look like this:
build_model \
workdir=<workDir> \
designsource=<design_netlists.v> \
techlib=<library_files.v>
build_faultmodel \
workdir=<workDir>

Test Modes and the Fault Model
The process of building the fault model is independent of any testmode(s) that might be
created, and, therefore, can be run either before or after defining the testmode(s). The
process of identifying active faults per testmode and initializing the testmode fault status
is done during build_faultmodel for all existing testmodes and during build_testmode for
any testmodes built if the fault model already exists.
One of the advantage of building the testmode first is realized when there are multiple
testmodes to be built, and each of the testmode is built concurrently. When
build_faultmodel is built first, the testmodes can only be built one after another.
Build Fault Model Output
The binary data files are created and stored in the workdir/tbdata directory for use by
the subsequent fault-oriented tasks such as ATPG, fault simulation, and diagnostics.

Controlling the Modelling of Faults

In various scenarios, it is required to control the modeling of faults based on the design.
You may want to model fault for a part of your design, or may want to ignore some of
the faults.
The following topic discusses the various options to control the faults with
build_faultmodel.
Excluding the dynamic faults from fault list
By default, the fault model includes static, dynamic, and Iddq faults. To exclude dynamic
faults from being modeled, the includedynamic=no keyword can be used with the
build_faultmodel.
Build_faultmodel workdir=<directory> includedynamic=no

[The default is to include dynamic faults.]
Fault Rule Files

In ET, the build_faultmodel command provides an option of the fault rule file where you
can direct the tool to take specified action on the listed faults. Some of the examples
and utilities where fault rules could be used are discussed in detail.
The faultrulefile keyword is used during build_faultmodel, to apply these fault rules
defined in the specified fault rule files. The command will look like this:
build_faultmodel
faultrulefile=/dir1/myfaultrule1,/dir1/myfaultrule2,/dir2/myfaul
trule3
If the fault rule files to be applied are based on the file names in the FAULTS attributes,
and are listed under some specific directory, the faultpath keyword is used to specify
the path of directories where these files are expected to be located.
Following is an example of using the FAULT attribute in the design source Verilog file:
(* FAULTS="myfaultrule_1" *) module new_top ( <port

declaration>);
..<statements> ;
endmodule
In this example, the fault rules defined in the myfaultrule_1 file will be included for
each instance of this module. The directory containing this fault rule file will be specified
with the build_faultmodel FAULTPATH keyword.
ET also allows other fault attributes to include or remove certain faults (by default). For
more details on how the FAULTS attribute can be used in Verilog, refer to Modifying
Fault Model/Fault Status of Encounter Test: Guide 4: Faults.
The faultpath keyword lets you specify a set of directories, which is the path for the
fault rule file. The specified directories should be separated with colons. The command
will look like this:
build_faultmodel
faultpath=/dir/faultrule1:/dir/faultrule2:/dir2/faultrule3
The specified directories are searched from left to right for the fault rule files. Hence, if
the same filename exists in more than one of the directories specified in FAULTPATH,
the file found in the first directory will be used.
Note: The build_faultmodel command also accepts the compressed or gzipped

versions of the fault rule files (.z, .gz). Using a compressed fault rule file will actually
help save memory while processing large fault rule files.

Syntax for the Fault Rule File
The fault rule files are used to modify the default fault status. For example, you can no-
fault a particular block.
Predominantly, two keywords, NOFAULT and FAULTONLY, are used within a fault rule
file. These keywords are applicable for the modules or instances to be included or
excluded.
The type of faults to be excluded are static, dynamic, or both. A NOFAULT statement
with no STATIC/DYNAMIC designation excludes both STATIC and DYNAMIC faults.
NOFAULT statements remove faults for the module/instance specified. FAULTONLY

allows the faultmodel to fault only the specified module/instance while the rest of the
logic is nofaulted.
The NOFAULT/FAULTONLY statement can be used as the following syntax:
Cell <Cell_name>
Instance <Instance_name> In Module <Module_name>

NOFAULT/
FAULTONLY Block <Block_name>
Cell <Cell_name>
Module <Module_name>
Figure 1 : Fault rule Syntax
NOFAULT/FAULTONLY statement identifier, which can be specified in mixed case
Instance statement keyword which precedes a specific instance name
Instance_name identifies a specific instance within a cell or module, consistent with

the existing fault rule name parsing. If a name contains special characters, it must be
specified within double quotes
In statement keyword used to indicate the containing cell or module a given block
specification pertains to. This can be specified in mixed case
Module/Cell statement keyword which precedes a module/cell name. This can be

specified in mixed case. Cell is a synonym of Module
Module_name/Cell_name identifies a specific library cell name, consistent with the

existing fault rule name parsing. If a name contains special characters, it must be
Block statement keyword which precedes a fully specified hierarchical block name.
This can be specified in mixed case
Block_name identifies a specific hierarchical block in the ET hierarchical model. This

can be specified in both short and proper form of the block name, consistent with the
existing fault rule name parsing. If a name contains special characters, it must be
Cannot span multiple lines.
Note: To identify certain faults, wildcards can be specified for the BLOCK, Cell or
Module name using asterisk(*).

Use Cases of Fault Rule File
How to NOFAULT or FAULTONLY for a particular module/instance?
Let us take an example to understand the fault rule syntax for NOFAULT and
FAULTONLY techniques, and how to apply these rules.
In this example, we have a top with two modules, mod_A (instance name five_ff) and
mod_B (seven_ff).
Figure 2 : Design Top with default settings
Example 1: With default settings, and without any fault rule file, the
build_faultmodel workdir=<workDir> includedynamic=yes command will include all
the static and dynamic faults.
The build_faultmodel logfile will report Information message (TFM-704) that suggests
the total active and inactive faults and the Maximum Global fault statistics.

INFO (TFM-704): Maximum Global Test Coverage Statistics
Statistics for faults that are not active in any test modes and maximum test coverage
attainable with the current set of test modes:
For the circuit displayed in Figure 2, the fault detail is shown in the following table:
----------------------------------------------------------------
-----
INFO (TFM-704): Maximum Global Test Coverage Statistics:
%Active #Faults #Active #Inactive

Total Static 100.00 210 210 0
Collapsed Static 100.00 210 210 0
Total Dynamic 73.33 210 154 56

Collapsed Dynamic 71.72 198 142 56
----------------------------------------------------------------
-----
Definitions:
#Faults: Number of faults defined (independent of test modes); Total number of static
faults is 210, and total number of dynamic faults is 210
#Active: Number of faults active in at least one mode; Total number of static faults that
are active is 210, and total number of dynamic active faults is 154
#Inactive: Number of Faults Inactive in all modes; Total number of static faults that are
inactive is 0, and total number of dynamic inactive faults is 56
%%Active: #Active/#Faults = Maximum Test Coverage attainable; Thus, the percentage

of max Test coverage that can be achieved for static faults will be 100%, and for
dynamic faults it will be 73.33%.

NOFAULT:
Example 2: Excluding all the faults from a specific module using the fault rule file
Command: build_faultmodel includedynamic=yes

faultrulefile=Myfaultrule1
Faultrule statement that can be used within the Myfaultrule1 file

are:
----------------------------------------------------------------
Nofault Instance mod_A In Module new_top
Or
Nofault Block Block.f.l.new_top.nl.mod_A
Or
Nofault Cell five_ff
Or
Nofault Module five_ff
----------------------------------------------------------------
Figure 3 : Using NOFAULT for mod_A Block
Here, NOFAULT is being used for a block, Block.f.l.new_top.nl.mod_A, which means

that all the faults associated with this BLOCK will now be excluded from the global fault
list.
This example also explains how we can use the various keywords for NOFAULT (also
true to FAULTONLY).

Note: When using the Instance keyword, you also need to specify its module that
consists of the specified Instance. For example, the statement 1 of the fault rules listed
in Example 2. Here, the mod_A instance is within the top module named new_top.
The results are:

----------------------------------------------------------------
-----

Total Static 100.00 132 132 0

----------------------------------------------------------------
-----
Thus, the results show that the total number of static faults is now reduced to 132, and
total number of dynamic faults is also reduced to 132 because all the faults for mod_A
block are excluded from the list.
Example 3: Let us also analyze the results of a similar experiment with NOFAULT for
BLOCK Block.f.l.new_top.nl.mod_B.
As mentioned in Example 2, you can use any of the following Faultrule statement in the
fault rule file:
----------------------------------------------------------------
Nofault Instance mod_B In Module new_top
Or
Nofault Block Block.f.l.new_top.nl.mod_B
Or
Nofault Cell seven_ff
Or
Nofault Module seven_ff
----------------------------------------------------------------

Figure 4 : Using NOFAULT for mod_B Block
Here, you are using NOFAULT for a Block, Block.f.l.new_top.nl.mod_A, which means
that all the faults associated with this BLOCK will now be excluded from the global fault
list.
The results are:

----------------------------------------------------------------
-----

Total Static 100.00 108 108 0

----------------------------------------------------------------
-----
Here, the results shows that the total number of static faults is now 108, and total
number of dynamic faults is also reduced to 108, and these numbers exclude all the
faults from mod_B block.

FAULTONLY:
There can be a requirement to do processing of faults only for a particular BLOCK or

MODULE. In this scenario, FAULTONLY statement is used in the fault rule file. Let us
understand this with an example.
Example 4: If you need to list only the faults associated with mod_B BLOCK, you can
create a fault rule file with any of the following Faultrule statement:
----------------------------------------------------------------
FAULTONLY Instance mod_B In Module new_top
Or
FAULTONLY Block Block.f.l.new_top.nl.mod_B
Or
FAULTONLY Block mod_B
Or
FAULTONLY Cell seven_ff
Or
FAULTONLY Module seven_ff
----------------------------------------------------------------
Figure 5 : Using FAULTONLY for mod_B Block

The results are:

----------------------------------------------------------------
-----

Total Static 100.00 102 102 0

----------------------------------------------------------------
-----
The results show that the total number of static faults is now 102, and the total number
of dynamic faults is also reduced to 102, and these faults are only associated with
mod_B block.
Example 5: Let us see how we can use FAULTONLY to identify faults only for a
particular instance, instead of a complete module.
If you need to process faults only for an instance within a module, you can specify a
FAULTONLY statement in the fault rule file, similar to the following statement:
----------------------------------------------------------------
FAULTONLY Instance q_reg[3] In Module five_ff
----------------------------------------------------------------
After build_faultmodel, this fault rule statement will lead to the following results:
----------------------------------------------------------------
-----

Total Static 100.00 12 12 0

----------------------------------------------------------------
-----
Results suggest that the total number of static faults for the specified instance q_reg[3]
In Module five_ff is 12, and the total number of dynamic faults is also 12.

How to IGNORE few selected faults from the fault list
Apart from NOFAULT/FAULTONLY that exclude/include complete set of faults from a

particular module, the fault rule file can also be used to apply constraints to some
selected faults.
The following example demonstrates moving of some of the faults modeled on a pin to
Ignore category. The ignored faults do not participate in ATPG, and are removed from
the coverage calculation by default. Refer to the topic Fault/Test Coverage
Calculations of Encounter Test: Guide 4: Faults, to see how the ignored faults can
be used in the coverage calculations.
ENTITY: This defines the name of the block (a Verilog module) to which this fault rule
file applies. It is acceptable to have more than one model entity included in the same
fault rule file.
Example:
---------------------------------------------------------------------------------------------
ENTITY = new_top
{
IGNORE {SA0 PIN "Pin.f.l.new_top.nl.mod_A.\q_reg[1].SE"}
IGNORE {SR PIN "Pin.f.l.new_top.nl.mod_A.\q_reg[1].SE"}
}
---------------------------------------------------------------------------------------------
As per the definition:
SA0 : A pin stuck-at-zero fault

SA1 : A pin stuck-at-one fault
SR : A pin slow-to-rise fault
SF : A pin slow-to-fall fault
DRV0 : All drivers drive
DRV1 : All drivers drive 1
RCV0 : All receivers receive
RCV1 : All receivers receive 1
In this example, the SE pin faults are removed from the mentioned instances.
Other than IGNORE, there are options that decide the action for these selected faults:
PTAB: Identifies a fault that is to be marked "Possibly Testable at Best" in the fault
model built with this fault rule

DETECTED: Identifies a fault to be marked "detected" in the fault model to be built with
this fault rule
REDUNDANT: Identifies a fault to be marked "redundant" in the fault model to be built

with this fault rule
OMIT: Identifies the fault that is to be omitted from the fault model. The fault will not
exist, and therefore will not be included in any fault reports or statistics for the fault
model built with this rule
Example 6: To ignore certain specific faults, use the IGNORE statement:
Faultrule Statement:
----------------------------------------------------------------
-----------------------------
ENTITY = new_top
{
IGNORE {SR PIN "Pin.f.l.new_top.nl.mod_A.\q_reg[1].SE"}
}
---------------------------------------------------------------------------------------------
Results: It will ignore the stuck-at-0, stcuck-at-1, and slow-to-rise faults from the SE pin
of q_reg[1] within module mod_A. Here, the ENTITY is new_top, the top-level module
name.
Example 7: You can also combine the NOFAULT and Individual Pattern Fault
Specifications.
The following example shows how to combine user-defined fault specification and
nofault statement for a specific block. Note that the section for Entity=top should have
both the braces, { and } before the nofault statement.
-------------------------------------------------------------------------------------------
Entity=new_top {
IGNORE {SR PIN "Pin.f.l.new_top.nl.mod_A.\q_reg[1].D"}
}
Nofault BLOCK Block Block.f.l.new_top.nl.mod_B
--------------------------------------------------------------------------------------------
With this fault rule, all the faults for mod_B BLOCK will be excluded, and the slow-to-
rise fault from the D pin of q_reg[1] within module mod_A will also be ignored.

EXAMPLE 8: To mark certain faults as IGNORE, DETECTED and REDUNDANT:
---------------------------------------------------------------------------------------------
ENTITY = new_top
{
IGNORE {SR PIN "Pin.f.l.new_top.nl.mod_A.\q_reg[1].D"}
IGNORE {SF PIN "Pin.f.l.new_top.nl.mod_A.\q_reg[1].SI"}
DETECTED {SA0 PIN "Pin.f.l.new_top.nl.mod_B.b3.g2.A" }

DETECTED {SR PIN "Pin.f.l.new_top.nl.mod_B.b3.g2.A" }
REDUNDANT {SR PIN "Pin.f.l.new_top.nl.mod_B.\q_reg[5].D"}

REDUNDANT {SA1 PIN "Pin.f.l.new_top.nl.mod_B.a1.g8.B"}
}
---------------------------------------------------------------------------------------------
Coverage reporting with ignored faults
There are some faults that are untestable because they cannot affect the design
behavior. Hence, ET normally omits such faults. These faults will be termed as ignore
faults.
For example, if the first input of a two-input AND gate is tied to 0, the stuck-at-1 on the
second input will not normally be faulted.
You can specify includeignore=yes to include such faults in the fault list, although they
will still be classified as ignored faults. Hence, including the ignore fault will also impact
your coverage because these fault will be added to the untested faults, and might result
in a reduced coverage.
The default of the includeignore keyword is based on whether the logic model was
built with the build_model option, industrycompatible=yes, to add additional buffers for
faults to be assigned to each pin on a technology cell.
The default is includeignore=yes if the logic model was built with industry compatibility.
The default is includeignore=no if the logic model was built without industry
compatibility.
To reduce the size of an industry compatible fault model, you can override the default
using the includeignore=no keyword.

A similar keyword, ignoredfaultstatistics=no|yes, can also be used with the

build_faultmodel command to specify whether to include the ignored faults in the global
fault coverage. The default for this keyword is no.
How to No-Fault only the pins of a modules

To exclude specific pins of any module/instance, use OMIT in the fault rule file.
OMIT: Identifies the fault that is to be omitted from the fault model. The fault will not
exist and, therefore, will not be included in any fault reports or statistics for the fault
model built with this rule
The difference between using OMIT and IGNORE is the fault classification. When OMIT
is used, the fault is completely removed from the fault database, while using IGNORE
will classify the fault under IGNORE category.
Example 9: The OMIT statement is used to omit certain specific faults:
Faultrule Statement:
---------------------------------------------------------------------------------------------
ENTITY = five_ff
{
OMIT {SA0 PIN q_reg[1].SE}
OMIT {SA1 PIN q_reg[1].SE}
OMIT {SA0 PIN q_reg[1].D}
OMIT {SR PIN q_reg[1].SE}
}
---------------------------------------------------------------------------------------------

How to ignore scan-enable/reset faults during TFT
By default, the dynamic scan enable (SE) and dynamic set/reset faults are considered
as inactive in the transition faultmodel. As mentioned earlier, when faults are marked as
inactive, it does not reflect under the testmode coverage, but will be marked as
untested for global coverage.
In some cases, for the coverage accounting purposes, it is required to have dynamic
SE/set/reset faults out of the global coverage calculations as well. The following method
is used to make these dynamic faults "ignored" instead of inactive":
Use the script Identify_SE_RST_dynfaults.pl to generate the list of these SE and

set/reset faults. Provide this list with build_faultmodel to be removed from the global
fault numbers as well.
The purpose of using the Identify_SE_RST_dynfaults.pl is to identify all the dynamic

faults on the Scan-Enable, Reset/Set. This script will dump a faultrule file marking the
faults to Ignored category. This faultrule rule is used during the build_faultmodel
command.
Command used to execute this script is:
Identify_SE_RST_dynfaults.pl WORKDIR=... TESTMODE=...

setresetpins=pin_name,pin_name > output.txt
Parameters/Options:
WORKDIR =path/directory - location of ET Database

TESTMODE =name - testmode name
Setresetpins =pinname, ppiname - pin names of set/reset pins.
scan_enable =yes/no - default yes - include scan enable faults
set_reset =yes/no - default yes - include set/reset faults
clock = yes/no - default yes - include clock faults
faultrulefile =<filename> - In the existing fault rule file, this will copy and add to the end
of generated file
Use the resulted file from this script to build the fault model:
build_faultmodel faultrulefile=output.txt
Note: All the available extension language scripts can be found in: <ET installation
path>/ etc/tb/contrib.

How to migrate faults from the block level to the top level
In the bottom-up block level flow, there might be cases where the block level fault after
ATPG needs to be migrated to the next higher level in the design.
prepare_detected_faults is a useful command to help in such cases.
This command writes out a faultfile file with all the tested faults. Using this command
with r option writes out a fault rule file with both the tested and redundant faults.
This fault rule file is imported at the TOP for ATPG. The block level faults are marked as
tested/redundant once the TOP level fault model is built using build_faultmodel.
Similar is the case for different testmodes, because if the faults are tested in one
testmode, using prepare_detected_faults will give a fault rule file marking these as
detected faults.
Example 10: Using prepare_detected_faults
Suppose a design has two blocks, A and B, and the build model is done separately.
Testmode1 is testing block A, while B is blackboxed.

Testmode2 is testing block B, while A is blackboxed.
You can use a simple flow:
Step 1: Testing for Block-A with Block-B black box:
Build_model
Build_faultmodel
Build_testmode testmode=blockA
Verify_test_structures
Create_scanchain_tests
Create_logic_tests
Commit_tests
Prepare_detected_faults detected_fault_list_blockA
(This creates a fault rule file with all the detected faults of block A).

Step 2: Testing for Block-B with Block-A black box:
Build_model
Build_faultmodel
Build_testmode testmode=blockB
Verify_test_structures
Create_scanchain_tests
Create_logic_tests
Commit_tests
Prepare_detected_faults detected_fault_list_blockB
(This creates a fault rule file with all the detected faults of block B).
Step 3: Building the model with module-A and module-B
Build_model designsource=blockA,blockB
Build_faultmodel faultrulefile= detected_fault_list_blockA,
detected_fault_list_blockB
Build_testmode (both modules should active)this mode gives
the global coverage numbers
A similar command, prepare_ignore_faults, can be used to generate a fault rule file for
the BLOCK (or a Cell). Later, you can use this fault rule file to identify and ignore these
faults when this BLOCK (or a Cell) is used for a higher level pattern generation.

How to Fault-Only at the pins of an instance
You can also create a faultmodel such that only the faults at the instance pins will be
modeled, nofaulting all the faults inside the instance.
To achieve this, create an editfile that contains attribute FAULT = BOUNDARY for the
targeted module. The targeted module should be defined as a CELL during the
build_model command.
The editfile syntax for setting the attribute is:
ADD ATTRIBUTE FAULTS = BOUNDARY ON INSTANCE <targeted_instance> OF

CELL <cellname_that_consists_targeted_instance>;
Then, to include this attribute, use the editfile=<filename> keyword during the
build_model command.

Example 11: Suppose you want to target only the faults at the pins of mod_B, and
remove all other faults.
Figure 6 : FAULTS only at the BOUNDARY pins of mod_B Block
1. create an editfile (for example: my_editfile ) containing the statement:

ADD ATTRIBUTE FAULTS = BOUNDARY ON INSTANCE mod_B OF CELL
new_top;
OR
ADD ATTRIBUTE FAULTS = BOUNDARY ON CELL seven_ff;
(Here, the instance mod_B (cell name seven_ff) is within new_top.)
2. Use this editfile during build_model command using the

editfile=<filename> keyword.
3. Building the fault model with default keywords will only model faults at the
boundary pins of the instance.
If you want to have only the boundary faults of an instance, you can exclude the
remaining faults. Then, along with the editfile, create a fault rule file with FAULTONLY
for this instance (mod_B), and use it with the build_faultmodel command.

How to ignore faults around blackboxes
During the build_model command, if you do not specify the content of a cell or a block,
the blocks will be defined as blackbox. Such cells will be modeled with only its interface
without any definition as to what it contains.
The blackboxinputfaults=yes keyword with build_model will enable the modeling of

faults for the blackbox inputs and the inputs on cells that are not internally modeled. The
default value of this keyword is same as the i n d u s t r y c o m p a t i b l e keyword.
Similarly, blackboxoutputs=x|z|X|Z|0|1 will specify the value assumed for the outputs
of blackbox cell.
Thus, build_model command with blackboxinputfaults =yes and other default options,
and the faults around the black box (and also for the unconnected inputs/outputs of a
cell) will be counted in the global fault list. These faults are flagged as untestable-X
source (Uxs) so that ATPG does not waste time trying to generate tests for these faults.
However, these will be included in the fault coverage.
Use ignoreblackbox=yes keyword with build_faultmodel to ignore such faults from

the global fault list.
--------------------------------------------------------------------------------------------------------------

Support
Cadence Online Support provides access to support resources, including an extensive
knowledge base, access to software updates for Cadence products, and the ability to
interact with Cadence Customer Support. Visit http://support.cadence.com.
Feedback
Email comments, questions, and suggestions to content_feedback@cadence.com.


Nofault ET

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Nofault ET

Hochgeladen von

Copyright:

Verfügbare Formate

No Faulting Techniques in Encounter

Product Version 15.x

Learn more at Cadence Online Support - http://support.cadence.com

Learn more at Cadence Online Support - http://support.cadence.com

Learn more at Cadence Online Support - http://support.cadence.com

Build Fault Model

Example 1: The simplest example of the build_model and build_faultmodel commands

Learn more at Cadence Online Support - http://support.cadence.com

Test Modes and the Fault Model

Build Fault Model Output

Learn more at Cadence Online Support - http://support.cadence.com

Controlling the Modelling of Faults

Excluding the dynamic faults from fault list

Build_faultmodel workdir=<directory> includedynamic=no

Fault Rule Files

(* FAULTS="myfaultrule_1" *) module new_top ( <port

Note: The build_faultmodel command also accepts the compressed or gzipped

Learn more at Cadence Online Support - http://support.cadence.com

Syntax for the Fault Rule File

NOFAULT statements remove faults for the module/instance specified. FAULTONLY

The NOFAULT/FAULTONLY statement can be used as the following syntax:

Instance <Instance_name> In Module <Module_name>

Figure 1 : Fault rule Syntax

NOFAULT/FAULTONLY statement identifier, which can be specified in mixed case

Instance statement keyword which precedes a specific instance name

Instance_name identifies a specific instance within a cell or module, consistent with

Module/Cell statement keyword which precedes a module/cell name. This can be

Module_name/Cell_name identifies a specific library cell name, consistent with the

Block_name identifies a specific hierarchical block in the ET hierarchical model. This

Cannot span multiple lines.

Learn more at Cadence Online Support - http://support.cadence.com

Use Cases of Fault Rule File

How to NOFAULT or FAULTONLY for a particular module/instance?

Figure 2 : Design Top with default settings

Learn more at Cadence Online Support - http://support.cadence.com

INFO (TFM-704): Maximum Global Test Coverage Statistics

%Active #Faults #Active #Inactive

Total Dynamic 73.33 210 154 56

%%Active: #Active/#Faults = Maximum Test Coverage attainable; Thus, the percentage

Learn more at Cadence Online Support - http://support.cadence.com

Command: build_faultmodel includedynamic=yes

Faultrule statement that can be used within the Myfaultrule1 file

Figure 3 : Using NOFAULT for mod_A Block

Here, NOFAULT is being used for a block, Block.f.l.new_top.nl.mod_A, which means

Learn more at Cadence Online Support - http://support.cadence.com

The results are:

%Active #Faults #Active #Inactive

Total Dynamic 72.73 132 96 36

Learn more at Cadence Online Support - http://support.cadence.com

Figure 4 : Using NOFAULT for mod_B Block

The results are:

%Active #Faults #Active #Inactive

Total Dynamic 74.07 108 80 28

Learn more at Cadence Online Support - http://support.cadence.com

There can be a requirement to do processing of faults only for a particular BLOCK or

Figure 5 : Using FAULTONLY for mod_B Block

Learn more at Cadence Online Support - http://support.cadence.com

The results are:

%Active #Faults #Active #Inactive

Total Dynamic 72.55 102 74 28

%Active #Faults #Active #Inactive

Total Dynamic 66.67 12 8 4

Learn more at Cadence Online Support - http://support.cadence.com

How to IGNORE few selected faults from the fault list