REASON
Workpackage WP3
Testing and Design for Testability of SOC
Contents
I. Tools for defect oriented testing .............................................................................. 2
1. TTU_DOFSIM - Defect-Oriented Functional Fault Simulation tool ............. 3
2. TTU_MAFFAD - Mapping Functional Faults to Defects tool ......................... 4
3. TTU_DOFGEN - Defect-Oriented Test Generation tool ................................. 5
II. Tools for Built-In Self-Test analysis ...................................................................... 6
1. TTU_SIMBIST - Simulation of Built-In Self-Test tool .................................... 7
2. TTU_HYBCAN - Hybrid BIST Cost Analysis tool (script) ............................. 9
III. Tools for design error diagnosis ......................................................................... 10
1. TTU_DERRIN - Design Error Insertion tool .................................................. 11
2. TTU_PREDIA - Prediagnostic tool .................................................................. 12
3. TTU_TVECIN - Test Vector Insertion tool..................................................... 13
4. TTU_ECRDCR - Encryption/Decryption tool ................................................ 14
5. TTU_COMLIB - Common Library ................................................................. 15
IV. Tools for high level test generation .................................................................... 16
1. Software tools for VHDL Design and Test Flow (CR3-TTU) ........................ 16
2. TTU_VHDLDD – VHDL to DD Converter for hierarchical test generation
.................................................................................................................................. 17
I. Tools for defect oriented testing
The new tools are extensions to the Turbo-Tester (TT) diagnostic tool set developed by TTU
in the frame of previous EC COPERNICUS projects SYTIC and VILAB. The TT tools are
handling logic level SAF faults. The new tools give the TT a new functionality to handle also
physical defects.
All the tools developed by TTU in WP3 use the formats and libraries of TT. Therefore this
deliverable does not embrace all the information and documentation necessary for running
these tools. The details are available at the Turbo Tester home page in the Web:
http://www.pld.ttu.ee/tt.
2
1. TTU_DOFSIM - Defect-Oriented Functional Fault Simulation tool
Tool acronym:
TTU_DOFSIM
Tool destination:
The goal of the tool is to simulate functional faults for logic level
variables and to create the functional fault table.
Tool description:
The working principle of the tool is based on using a new functional
fault model which is a new concept for uniform description of
arbitrary logic faults, and also physical defects by a combination of
stuck-at fault and additional logic condition for activating a defect to
cause the given SAF. The inputs of the tool are the logic description
of circuit in the form of structurally synthesized BDDs (SSBDD). All
the functional faults to be simulated are extracted from the SSBDD
model. The result of the simulation is the fault table.
Tool platform:
OS platforms: Windows/NT, Linux and Solaris
Program. language:
ANSI C language using Microsoft Visual C++, SUN workshop and
GNU CC compilers
Command:
var_analyze
Input:
SSBDD model file (.agm), test pattern file (.tst)
Output:
test patterns including fault analysis result for each low level block
(.tst).
Syntax:
var_analyze <design>
design:
Name of the design file without .agm extension.
3
2. TTU_MAFFAD - Mapping Functional Faults to Defects tool
Tool acronym:
TTU_MAFFAD
Tool destination:
The tool reads the fault table of functional faults of the circuit and the
defect tables of components of the circuit and calculates the defect
coverage (both, probabilistic and enumerative).
Tool description:
The inputs of the program are the fault table of functional faults
created as the result of the functional fault simulation tool
TTU_DOFSIM, and the defect table of components. The defect
tables should be pregenerated. In this project the pregeneration of
defect tables will be done by the partner CO1-WUT for a given set of
selected complex gates or components. The defect tables are stored
as library components. For each component the very costly analysis
of physical defects to create the defect table will be done only once.
The pregenerated results (the library defect table) will be used by the
tool TTU_MAFFAD each time where a component should be
analyzed. Such a hierarchical approach allows tremendously increase
the efficiency of simulation. In fact the complexity of the defect
simulation will be reduced to the complexity of the SAF simulation.
Tool platform:
OS platforms: Windows/NT, Linux and Solaris
Program. language:
ANSI C language using Microsoft Visual C++, SUN workshop and
GNU CC compilers
Command:
deforient
Input:
SSBDD model file (.agm), test pattern file (.tst), defect tables for the
low-level blocks.
Output:
Enumerative and probabilistic defect coverage report (.prb).
Syntax:
deforient <design>
design:
Name of the design file without .agm extension.
4
3. TTU_DOFGEN - Defect-Oriented Test Generation tool
Tool acronym:
TTU_DOFGEN
Tool destination:
The tool generates test patterns for all the physical defects of the
circuit described in the pregenerated library defect tables.
Tool description:
The test generation is carried out in a hierarchical way and is based
on the random test generation algorithm. The patterns are generated
randomly and simulated for functional faults. The detected functional
faults are mapped into the defect space by using the defect tables of
components.
Tool platform:
OS platforms: Windows/NT, Linux and Solaris
Program. language:
ANSI C language using Microsoft Visual C++, SUN workshop and
GNU CC compilers
Command:
randomgen
Input:
SSBDD model file (.agm)
Output:
test pattern file (.tst)
Syntax:
randomgen [options] <design>
design:
Name of the design file without .agm extension.
options:
-length <x>
Generate x test patterns
5
II. Tools for Built-In Self-Test analysis
Due to the high cost of external testers and of inefficiency of testing in real speed by external
testers the Built-In Self-Test (BIST) is the emerging testing concept in VLSI testing and,
particularly, in the System on Chip field. BIST is the capability of a circuit to test itself. BIST
is usually based either on generating on-line pseudorandom patterns by so called LinearFeedback-Shift-Registers (LFSR) or on using functional test patterns. In both cases it is
difficult to reach high-fault coverage because of existing hard-to-detect faults which can be
detected only by a single or very few test patterns. To reach high fault coverage, the HWbased generated pseudorandom (or functional) test patterns can be complemented by
deterministically pregenerated and stored test patterns. This combination is called – hybrid
BIST. The problem here is to find out the best and cost-effective combination of on-line and
stored test patterns.
The low cost tools for simulating different architectures of BIST (or hybrid BIST) and for
analyzing the quality of BIST are missing. To support the lecture courses on BIST to be
developed in WP3 by laboratory works and research training the creation of the following
low-cost tools was planned.
6
1. TTU_SIMBIST - Simulation of Built-In Self-Test tool
Tool acronym:
TTU_SIMBIST
Tool destination:
The tool emulates the given BIST architecture, simulates given
circuit for a given sequence of pseudorandom test patterns, calculates
the signatures and fault coverage.
Tool description:
Different Logic BIST architectures can be emulated: BILBO, CSTP.
One of the two LFSR types can be used : standard or modular. The
structures of LFSRs for test generation and signature analysis are
optional and can be selected by specifying the corresponding polynomials. By emulating the BIST architecture a sequence of pseudorandom patterns will be generated, fault simulated and the final
signature will be calculated. The best settings of the LFSR registers
can be selected by repetitive simulation and by using genetic
algorithms.
Tool platform:
OS platforms: Windows/NT, Linux and Solaris
Program. language:
ANSI C language using Microsoft Visual C++, SUN workshop and
GNU CC compilers
Command:
bist
Input:
SSBDD model file (.agm)
Output:
test pattern file (.tst)
Syntax:
bist –rand –glen <generator_length>
alen <analyzer_length>] [options] <design>
[-
or
bist –gpoly <generator_poly> -ginit <generator_init> [–
apoly <analyzer_poly> -ainit <analyzer_init>] [options]
<design>
design:
Name of the design file without .agm extension.
generator_length:
Length of the generator LFSR in bits.
(Use only with –rand option!).
Length of the analyzer LFSR in bits.
(Use only with –rand and –simul bilbo options!).
Feedback polynomial of the generator LFSR in binary
digits. (Do not use with –rand option!).
Initial value of the generator LFSR in binary digits.
(Do not use with –rand option!).
Feedback polynomial of the analyzr LFSR in binary digits.
(Do not use with –rand and -simul cstp option!).
Initial value of the analyzer LFSR in binary digits.
(Do not use with –rand and -simul cstp option!).
analyzer_length:
generator_poly:
generator_init:
analyzer_poly:
analyzer_init:
options:
-rand
Generate random LFSR feedback polynomials and initial
states.
7
-aliasing
With this option selected, exact fault coverage values will
be reported. BIST emulation will be slower but it will take
into account possible fault aliasing in the analyzer LFSR.
-simul <bilbo|cstp> Choses between BILBO and CSTP architectures. (Default
is BILBO).
-count <cycles>
The length of the test in clock cycles. Default is 1000.
-optimize
Dismiss test patterns at the end of the test sequence that do
not detect any additional faults.
-lsb
Design outputs are connected to the side of less significant
bits of the analyzer LFSR. (Default is the side of more
significant bits).
-run <num>
Run simulation <num> times, sort results and store best
one. Makes sense when -rand option is being used
-oext <extension>
output file with given extension (default '.tst')
-generate
generate test patterns only, don't perform any simulation
-modular
use modular LFSR instead of standard one
8
2. TTU_HYBCAN - Hybrid BIST Cost Analysis tool (script)
Tool acronym:
TTU_HYBCAN
Tool destination:
The tool emulates the given BIST architecture, fault simulates the
given circuit for the given sequence of pseudorandom test patterns,
calculates the fault coverage and total costs of hybrid BIST for the
given breakpoints of the test sequence.
Tool description:
In hybrid BIST, the length of the pseudorandom test is an important
parameter, which determines the behavior of the whole test process.
A shorter pseudorandom test implies a larger deterministic test. This
however requires additional memory space, but at the same time,
shortens the overall test process. A longer pseudorandom test, on the
other hand, will lead to longer test application time with reduced
memory requirements. Therefore it is crucial to determine the
optimal length of pseudorandom test in order to minimize the total
testing cost.
The inputs of the tool are the settings of the BIST architecture, and
the circuit to be fault simulated. First, the BIST will be emulated, and
the fault coverage for the given breakpoints of the test sequence will
be calculated. The number of clocks generated up to the breakpoint
determines the cost of pseudorandom test. For each breakpoint the
needed additional test patterns are generated to reach 100% fault
coverage. The number of needed deterministic patterns determines
the cost of the stored test. As the result of this procedure two
functions will be created: the functions of the costs of pseudorandom
test and of the stored test. The sum of these functions gives the
function of the total cost. The minimum of this cost determines the
breakpoint to be found.
Tool platform:
OS platforms: Linux, Solaris or any other UNIX-like OS able to run
shell scripts. In Windows environment Cygwin (UNIX-like
environment running atop Windows) installation is required.
Program. language:
Bourne Again Shell (bash) scripting
Command:
hybcost.sh
Input:
two test pattern files (.tst) from BIST emulator and deterministic
generator and SSBDD model file (.agm)
Output:
Location (index) of breakpoints and number of additional vectors for
completing 100% test. Results are saved into <design>.res file.
Syntax:
hybcost.sh <inp1> <inp2> <design>
design:
inp1:
inp2:
Name of the design file without .agm extension.
Test pattern file (.tst) from deterministic generator.
Test pattern file (.tst) from BIST emulator (SIMBIST).
9
III. Tools for design error diagnosis
Design errors stand for the mistakes or faults introduced by a designer or a CAD system
during the design process. Such errors usually manifest themselves during design validation
and verification stage. If the specification and the implementation of a design do not match a
design error has been introduced. An example of a design error could be a gate substitution
error. For example, an AND gate is replaced by OR gate in the implementation. It could be
also a bad or missing connection between gates. Extra or missing inverters are also examples
of a design error.
Design error diagnosis is an illustrative area for teaching diagnosis. It shows both the essential
principles of fault diagnosis and the existence of alternative fault models other than stuck-at
faults. The latter is important because the stuck-at fault model is widely accepted and taught
over the world. Therefore students know usually very little about the existence of different
fault models and different diagnostic problems.
The software package for manual design error diagnosis contains following tools.
10
1. TTU_DERRIN - Design Error Insertion tool
Tool acronym:
TTU_DERRIN
Tool destination:
This program creates a pair of specification and implementation,
which are not functionally equal. The specification will be then taken
as correct and the implementation as wrong
Tool description:
This tool is based on the EDIF format converter from the Turbo
Tester package. The input of the converter is the design description in
EDIF format. The output is the internal Turbo Tester format – a
special kind of decision diagrams. TTU_DERRIN tool is an add-on
to the EDIF converter. It analyzes the structure of the design and
inserts a single design error into. The output of TTU_DERRIN tool is
two files. The first one is the correct design while the second is the
design which contains an error.
Tool platform:
OS platforms: Windows/NT, Linux and Solaris
Program. language:
ANSI C language using Microsoft Visual C++, SUN workshop and
GNU CC compilers
Command:
xtimport
Input:
EDIF or ISCAS’89 netlist file
Output:
specification (.spec), implementation (.agm), gate-level paths (.gat),
gate names and types (.pat).
Syntax:
xtimport [options] <EDIF file> <library file>
options:
-paths
-spec
-read_iscas89
-gate_level
-tool <application>
-gnd <gnd name>
-vdd <vdd name>
Preserve information about gate-level signal paths.
Create a specification (insert a design error).
Read ISCAS’89 format.
Generate gate-level SSBDD model. Default output is
macro-level SSBDD.
Options for application are orcad and cadence.
gnd name is the name of the GND net.
vdd name is the name of the VDD net.
11
2. TTU_PREDIA - Prediagnostic tool
Tool acronym:
TTU_PREDIA
Tool destination:
This automated tool allows reducing the suspected faulty area in
larger circuits for subsequent application of manual diagnosis
performed by the student.
Tool description:
In order to have larger variety of tasks for students as well as to have
less restrictions on the circuits used for practicing we propose the
following tool. The tool implements a special design error diagnosis
technique to reduce the area of analysis for larger circuits. The area is
to be kept within certain boundaries, which define the minimum and
the maximum number of gates considered to be under suspicion.
Tool platform:
OS platforms: Windows/NT, Linux and Solaris
Program. language:
ANSI C language using Microsoft Visual C++, SUN workshop and
GNU CC compilers
Command:
prediag
Input:
specification (.spec), implementation (.agm), gate-level paths (.gat),
gate names and types (.pat), test pattern (.tst).
Output:
report file (.rep).
Syntax:
prediag [options] <design>
design:
Name of the design file without .agm extension.
options:
-f
-n
-g
-v <extension>
-s <extension>
-o <extension>
-scr
Show failing outputs.
Do not show suspected nodes.
Do not show suspected gates.
extension is the file name extension of the input test pattern
file. Default extension is tst.
extension is the file name extension of the specification
model file. Default extension is spec.
extension is the file name extension of the output file.
Default extension is rep.
Print everything on the screen only.
12
3. TTU_TVECIN - Test Vector Insertion tool
Tool acronym:
TTU_TVECIN
Tool destination:
It is an interactive tool for manual insertion, deletion or update of
input test vectors in a test pattern file.
Tool description:
The Turbo Tester system has a special format the test vectors are kept
in. Automatic test pattern generation tools from Turbo Tester
package use this format to store generated tests in files. However, it
is inconvenient to manually compose from scratch these test vectors
files using this format. Therefore for manual test vector generation a
special user-friendly tool is needed to create the interface between the
user and the Turbo Tester. The proposed vector manager tool
includes also some simple test manipulation possibilities, like fault
simulation, logic simulation, random test vectors creation, etc. It can
work in an interactive as well as in a command line modes. In
interactive mode (usage: vecmanager) the program asks for the name
of the design, the name of the test pattern file, and finally gives the
following menu:
S. Show existing test patterns
N. Insert completely New test
A. Add vectors
D. Remove some vectors
R. Automatically generate some Random sequence
F. Perform Fault simulation
X. Save patterns and eXit
In the command line mode you can add only a single test vector.
Tool platform:
OS platforms: Windows/NT, Linux and Solaris
Program. language:
ANSI C language using Microsoft Visual C++, SUN workshop and
GNU CC compilers
Command:
vecmanager
Input:
SSBDD model file (.agm), test pattern file (.tst).
Output:
test pattern file (.tst).
Syntax:
vecmanager [options] [<design>]
design:
Name of the design file without .agm extension.
options:
-new
-add <vector>
-i <extension>
-o <extension>
-ftable
Create completely new test set.
Add test pattern vector.
extension is the file name extension of the input file.
Default extension is tst.
extension is the file name extension of the output file.
Default extension is tst.
Perform fault simulation.
13
4. TTU_ECRDCR - Encryption/Decryption tool
Tool acronym:
TTU_ECRDCR
Tool destination:
The encryption part of the tool encrypts the information about the
design error, which includes the type of inserted error and its precise
location. The decryption part of the tool allows teacher to decrypt the
information about the design error and therefore to verify the
correctness of the diagnosis performed by the student.
Tool description:
The encryption part of the tool must be implemented as a part of the
Design Error Insertion tool - TTU-DERRIN. The decryption part of
the tool is implemented as a separate program (checkgate).
Tool platform:
OS platforms: Windows/NT, Linux and Solaris
Program. language:
ANSI C language using Microsoft Visual C++, SUN workshop and
GNU CC compilers
Command:
checkgate
Input:
encrypted name and type of the erroneous gate (can be read from file
<design>.rep).
Output:
decrypted name and type of the erroneous gate.
Syntax:
checkgate [options] [ -f <InFile>| -m <message>]
InFile:
File containing the encrypted message.
message:
String of printable ASCII characters (encrypted message).
options:
-o <file>
-s
file is the output file.
Print output also on the screen.
(default: if -f specified - don't, otherwise - yes).
14
5. TTU_COMLIB - Common Library
Tool acronym:
TTU_COMLIB
Tool destination:
This component is to be created to bind the diagnostic programs
together as well as to implement some minor functions used
throughout the package.
Tool description:
Some functions for reading and writing of common formats are to be
implemented as well as the functions to append the common log file
from all the diagnostic package components.
Tool platform:
OS platforms: Windows/NT, Linux and Solaris
Program. language:
ANSI C language using Microsoft Visual C++, SUN workshop and
GNU CC compilers
15
IV. Tools for high level test generation
1. Software tools for VHDL Design and Test Flow (CR3-TTU)
As the degree of integration in VLSI designs has been growing, so has the need for
automation of different design tasks. Design automation helps to shorten the time-to-market
cycle and improves significantly designer’s productivity. The automation was first introduced
on the lower levels of design tasks, like placement and routing, and together with the growth
of design complexities, moved gradually to higher levels, e.g. logic synthesis, high-level
synthesis (HLS) and hardware/software co-design. Nowadays the goal is to automate the
entire design cycle from conceptualization to generation of silicon layout.
During recent years, more-and-more commercial and university high-level synthesis tools
have become available. These tools are applied for automatically generating a registertransfer level (RTL) description from a behavioral description of the circuit. In the RTL
descriptions the design has been partitioned into a control part, i.e. a finite state machine, and
a datapath part containing a network of interconnected functional units (FU). Usually the HLS
tools take into account several constraints, as speed, area, or testability, and allow the
designer to quickly compare the trade-offs between alternative RTL implementations.
The circuit design flow continues by synthesizing the RTL descriptions to the logic level.
Subsequently, the logic gates are placed to the chip layout and connections between them are
routed. Finally, the chip is manufactured in a silicon foundry and tested.
We propose a hierarchical test generation fitting into the circuit synthesis flow described
above. The environment consists of a hierarchical test generator and dedicated high- and lowlevel Decision Diagram (DD) model interfaces. From RT-level VHDL descriptions, highlevel DD interface generates RTL DD models, which are applied as the high-level input for
the test generator. Low-Level DD (LLDD) representations are required when generating
local, structural level tests for the functional units (FU) of the design. For that purpose, an
EDIF to LLDD interface has been implemented. The system includes also a low-level
sequential circuit fault simulator, which is needed to measure the stuck-at fault coverage of
the tests generated by the hierarchical ATPG.
The VHDL Design and Test Flow includes the following steps and tools (printed in italics).
- The user describes a design at behavioral level using VHDL.
- A high-level synthesis tool xTractor (a tool developed at TTU) synthesizes the
description into RT-level VHDL.
- VHDL interface (VHDL to DD Converter) is used to generate High-Level Decision
Diagram (HLDD) models from the RTL VHDL. This tool is to be developed in the
REASON project.
- Synopsys Design Compiler is run in order to synthesize the RTL VHDL into logic
level netlist in EDIF format.
- Low-Level Decision Diagrams (LLDD) are generated from the EDIF description by
EDIF importing tool. This tool is developed at TTU.
- The generated HLDD and LLDD models are used in hierarchical test generation by
DECIDER tool and in hierarchical fault simulation. The DECIDER tool is developed
at TTU.
- Exact fault coverage of the tests are measured using the logic level fault simulator.
This tool is developed at TTU and belongs to the tool-set Turbo-Tester
Specification of the tool developed in this project:
16
2. TTU_VHDLDD – VHDL to DD Converter for hierarchical test generation
Tool acronym:
TTU_VHDLDD
Tool destination:
The tool is used to generate High-Level Decision Diagram (HLDD)
models from the RTL VHDL to create a link between high-level
synthesis flow and hierarchical test generation flow.
Tool description:
VHDL2DD tool translates behavioral register transfer level (RTL)
VHDL to high-level decision diagram representation format suitable
for simulation and test generation programs. Supported source RTL
level VHDL should describe both Data and Control path of the
digital device; description should contain the control states and
possible data operations in each state. Generated structural VHDL
code is one level lower in abstraction than RTL level VHDL code.
Control and data paths are separated and each operation in source
VHDL is replaced with proper functional element, multiplexers
introduced in order to commutate data. There is one-to-one mapping
between generated high level DD-s and generated structural VHDL
Tool platform:
OS platforms: Solaris
Program. language:
ANSI C language using SUN workshop and GNU CC compilers
Command:
vhdl2dd
Input:
Behavioral RTL VHDL (*.vhdl)
Output:
High-Level Decision Diagram, corresponding structural vhdl
(result_file_name)
Syntax:
or
vhdl2dd < source_file_name (results displayed on screen)
vhdl2dd < source_file_name >! result_file_name (results into
file)
source_file_name:
substitute with your input file name
result_file_name:
substitute with your output file name
17