The DFT Workout

ABSTRACT
This paper provides a Design For Test (DFT) approach that can be used
for ASIC designs. The approach starts with test objectives and
requirements, followed by DFT flow development and test insertion and
ends with DFT results and documentation. The approach assumes early
intervention in the design phase and support from RTL designers. Using
this approach will help meet test coverage goals and reduce overall DFT
effort. This paper does not cover Design Compiler XG mode. Youll need
to reference the DFT Compiler XG Mode User Guides for detailed
information about this mode.

1
 Table of Contents

INTRODUCTION............................................................................................................. 4
THE DFT WORKOUT INTRODUCTION ................................................................ 4
TEST OBJECTIVES AND REQUIREMENTS ........................................................................... 4
What is the Test Strategy?........................................................................................... 5
Does the design need JTAG/boundary scan inserted? ............................................... 5
What are the fault coverage goals? ............................................................................ 5
What is the chain count requirement? ........................................................................ 5
Is the scan style Muxed Flop or LSSD? ...................................................................... 5
DESIGN INFORMATION ..................................................................................................... 5
THE DFT WORKOUT WARM-UP ............................................................................ 6
BASELINE DFTC METHODOLOGY ................................................................................... 6
DRC METHODOLOGY ...................................................................................................... 8
SCAN CHAIN METHODOLOGY .......................................................................................... 9
BSD COMPILER METHODOLOGY .................................................................................... 10
TETRAMAX FLOW ........................................................................................................ 11
THE DFT WORKOUT CARDIO .............................................................................. 12
RTL CODE VERIFICATION ............................................................................................. 12
Preparing your design for RTL TestDRC ................................................................. 12
Running RTL TestDRC ............................................................................................. 14
SYNTHESIS AND INSERT SCAN ....................................................................................... 14
Synthesis and Insert Scan Flow ................................................................................ 14
BOUNDARY SCAN INSERTION......................................................................................... 15
Boundary Scan Insertion Flow ................................................................................. 15
ATPG GENERATION ...................................................................................................... 20
Design Flow Review ................................................................................................. 20
TetraMAX Design Flow ............................................................................................ 20
THE DFT WORKOUT COOL DOWN..................................................................... 23
THE DFT WORKOUT STRETCH AND RELAX .................................................. 23

2
 List of Tables and Figures
Figure 1 RTLTestDRC Typical Design Flow.............................................................. 13
Figure 2 BSD Compiler Flow........................................................................................ 16

3
Introduction
Like any good exercise program, the DFT Workout consists of an introduction, a
warm up, a cardio segment, a cool down, and a final stretch and relaxation
period. During the introduction phase, test objectives and requirements are
determined and agreed upon. Once an agreement has been reached, a DFT
game plan can be formulated during the warm up phase. The hard work occurs
during the cardio segment, which is comprised of scan insertion, and generating
and verifying ATPG vectors. Once the hard work is done, documentation is
finalized, followed by vector delivery (cool down). The final stretch involves a
debriefing to discuss the things that went right and improve on the things that
went wrong. Now that the program has been laid out, lets get started!

The DFT Workout Introduction

The introduction consists of an initial customer meeting. The customer may be
internal or external. In either case, the use of a checklist is valuable. The
checklist is used to determine test objectives and requirements, collect design
information, and provide DFT requirements. The checklist can be used as an
educational aid. While going through the list, the questions that pop up will help
you determine the test knowledge of the customer. By educating the customer
during this phase, confidence is gained, an understanding of why RTL changes
may be required is accepted and the DFT flow is understood. Collecting test
objectives, requirements, and educating the customer reduces schedule,
promotes buy-in for work that needs to be done and generates higher fault
coverage.

Test Objectives and Requirements

Shown below are example questions that can be used to aid in collecting and
understanding the test objectives and requirements.

What is the test strategy?

Does the design need JTAG/boundary scan inserted?
What are the fault coverage goals?
Are there any known ATE limitations?
o Test speed?
o Numbers of scan channels?
o Memory limitations?
o ATE pattern memory depth?
What is the scan chain count requirement?
Are balanced scan chains a requirement?
What is the scan style Muxed Flop or LSSD?

4
What is the Test Strategy?
By definition, full scan indicates that all sequential elements in a design are
converted to scan elements. Partial scan, on the other hand, indicates that there
are some non-scanned sequential parts. The DFT engineer requires this
information to help develop the DFT methodology that will be used on the design.
For example, if PLL devices, BIST logic, or any other logic is not going to be
scanned, DFT script files need to reflect this behavior. Using partial scan may
reduce fault coverage and/or cause additional work to reach a fault coverage
goal. While this in not critical, the information needs to be made public in the
beginning to eliminate any surprises at the end of the program.

Does the design need JTAG/boundary scan inserted?

Some customers prefer to install boundary scan themselves. If this is not the
case, Synopsys BSD Compiler can be used to insert boundary scan and check
for compliance.

What are the fault coverage goals?

Most fault coverage goals are set at 95%. However this should not be assumed.
By bringing the subject up, you can initiate a conversation to discuss what a fault
coverage is, what the risks are associated with meeting the goal, and what steps
will be necessary to reach the required coverage.

What is the chain count requirement?

Does the customer have a scan chain count requirement? Do the chains need to
be balanced? An early accounting of this information, can prevent the need to
rewrite scripts later, and avoid multiple instances of scan chain insertion.

Is the scan style Muxed Flop or LSSD?

There are pros and cons for both Muxed Flop and LSSD scan styles. The DFT
Compiler Scan Synthesis User Guide goes into detail about the difference
between these styles. The scan style should be selected up front. This will aid in
the script development, and provide time to research the selected style.

Design Information
To properly determine the DFT approach, youll need to collect information on the
design. Shown below are example questions that can be used to start the
process of understanding the design.

How many clocks are in the design?

Are there any internally generated asynchronous resets?

5
 Are there any internally generated clocks?
Are there any Rams in the design? If so, how are they going to be tested?
Are there any tri-state buses in the design?
How many bi-directional ports exist in the design?
Will scan pins SI, SO, and Test_en be shared with functional pins?
Is there an external I/O pin to place the PLL's and/or RAMs in bypass
mode?
Can an additional Test Mode pin be used?

The DFT Workout Warm-Up

Now that the objectives and requirements are understood, a methodology needs
to be developed. To aid in this development, baseline methodologies and brief
descriptions of commands are provided in the following sections. The first
methodology presented shows a basic DFT flow that starts with checking the
RTL code and ends with checking inserted scan chains. Next is a discussion on
how to handle DRC warnings/errors and scan chain choices. Potential solutions
and recommendations are provided. The Warm Up section wraps up with basic
flows for BSD Compiler and TetraMAX.

Baseline DFTC Methodology

1. Check HDL Code - Use the RTL Test DRC tool (dft_drc) to get early
warning of testability issues buried in HDL code.
Pre-synthesis checking verifies RTL code. It checks code for
uncontrollable clocks, asynchronous resets and captures violations.
Geared towards HDL-proficient users able to interpret DRC violations and
re-code.
Only flags violating code; it does not advise how to re-code HDL.

2. Prepare Design for Test DRC

For TetraMAX ATPG and DFT_DRC, these variables and commands
need to be set:
o test_default_period 100.00
o test_default_delay 0.00
o test_default_bidir_delay 0.00
o test_default_strobe 40.00
o test_default_strobe_width 1.00
o Define test hold signals using set_test_hold
o Define test clocks using create_test_clock
o Define test attributes using set_scan_configuration and
set_signal_type

6
 o If youre using Design Compiler XG mode then you need to use the
command set_dft_signal. Youll need to reference the DFT
Compiler Scan Replacement User Guide (XG Mode) for detailed
information about this flow.

3. Compile - Use compile -scan option to tell DFTC to use scan-equivalent flip-
flops from the outset.
Scan flip-flop area, timing and output loading are taken into account during
synthesis.
All unused pins are degenerated: SE - grounded, SI - driven by Q, Q
output pin loaded by SI

4. Create Test Protocol - Use the command create_test_protocol. This

command creates a test protocol for the current design based on your
specifications issued prior to running this command. These specifications are
made using commands such as create_test_clock and set_signal_type.

5. Run Test Design Rule Checking Use the command dft_drc. This
command checks the design against the test design rules of the scan test
implementation specified by the set_scan_configuration command.

6. Preview DFT The preview_dft command generates a scan chain design

that satisfies scan specifications on the current design with out the need to
synthesize.
Allows you to preview scan chains and make changes to your
specifications as necessary.
Checks scan-path consistency
Determines chain count
Allocates and orders scan cells

7. Insert DFT The insert_dft command adds scan circuitry to the current
design.
Insert scan targets the previewed scan-path architecture and performs any
remaining scan replacements.
Ensures that no contention exists
Add disabling/enabling logic to tristate buses.
Conditions the directionality of bi-directional ports
Assembles scan paths
Wires the scan flops into the specified chains
Optimizes the logic, minimizing constraint violations.

8. Write Test Protocol - Use write_test_protocol to generate a protocol file.

Test protocol completely describes the test environment for a design such
as:
o Test timing information

7
 o Initialization sequences used to configure the design for scan
testing
o The test configuration used to select between scan shift and
parallel cycles during pattern application.

9. Run Test Design Rule Checking Use the command dft_drc. This
command checks the design against the test design rules of the scan test
implementation specified by the set_scan_configuration command.

DRC Methodology
1. Check for violations in these environments
Pre-synthesis check of the RTL HDL source code (dft_drc)
Post-synthesis check of block logic using DFT-C (dft_drc).
Pre-ATPG check of chip logic using TetraMax (drc)

2. DRC Rules
State-changing inputs are controllable by ATE from PI's.
POR, PLL and Pulse generators are disabled.
State-changing input never feeds logic cone into flip-flop.
Checks for uncontrollable clocks and resets.

3. Add Test mode pin (ASIC_TEST) - it can bail you out of unforeseen test
problems
A test mode can enable fixes to common DRC violations
One test mode pin can serve multiple on-chip test circuits.
Add to HDL code by declaring extra input port.
Signal is held constant '1' all during scan-based stuck-at fault testing.

4. Methods for Fixing DRC violations

Edit HDL code
Autofix inserts bypass or injection of gate logic
Shadow logic DFT to add control/observe test points
Edit netlist using create_net and related commands

5. Scan shift issues

Gated clocks - Fix with OR gate for no clock skew and use ASIC_TEST
Clock divider - Fix with Mux and ASIC_TEST. Adds clock skew
PLL, digital pulse generators - Use methods above
POR - add mux to bypass POR and use existing RS or PI. Use
ASIC_TEST to control mux.
Uncontrollable resets - add Mux with ASIC_TEST.
Negative edge flops are not a problem for mux-flop scan methodology.
Autofix can be used to correct uncontrollable clocks and resets.

6. Bidirect issues

8
 Bi-directional pins changing direction during scan shift. To fix force bi-
directs to input in RTL code using signal ASIC_TEST.
Contention during capture on bi-directional pins. To fix force bi-directs to
be input during test in RTL code using signal ASIC_TEST.
Insert_dft adds bi-directional disabling logic by default.

7. Capture violations
Caused by clock skew
Clock as data violation

8. Memory DFT Strategies.

Test RAM/ROM for internal faults using direct pin access or BIST
Apply black box model - Casts a low-coverage shadow over nearby
combinational logic.
Inserting test points - Testability of shadow logic can be improved by
automatic insertion of DFT control and observe test points around black-
box RAM/ROM. Use autofix or manually add logic in RTL code.
Write Functional Model - maximum coverage by supplying functional
verilog model

Scan Chain Methodology

1. Scan Chain Length
Support as many scan chains as available pins allow.
Share SI and SO with functional pins as necessary.
Scan chain count does not affect how many patterns are generated.
Tester time per pattern increases directly with the longest scan path.
Default behavior is to minimize the number of scan chains consistent with
risk free scan requirements. Requirements can include clock mixing and
re-balancing options.

2. Scan Chain Balancing

Default Behavior
o Tries to safely balance paths but won't use more than one clock in
a single chain.
o Will not break up existing scan-chain segments.
Clock Mixing
o You can allow use of multiple clocks in a single chain
o You can use multiple clock edges in a single chain.
User-specified Re-balancing
o Can break up existing scan chain segments as needed.

3. SI and SO ports

9
 By default DFTC looks for a flip-flop that directly drives output port for SO.
By default DFTC always synthesizes a dedicated SI port.

4. Pattern Memory
Tester memory depth
Use multiple scan paths with balance lengths. This minimizes tester time
and utilizes memory efficiently.
Use fewer scan chains if pin limited and ATE has deep memory.

5. Clocks - Using both edges

Using both edges of clock causes two clock domains.
Violates rule that all scan flops clock in new data at the same time.
If using both edges place all negative edge flops together followed by all
positive edge flops for a RTZ test clock this is the default behavior if
mix_edges is specified.

6. Mixing Clocks
Risky for Mux flop scan methodology.
By default no clock mixing along scan path is allowed
Default chain count is one path per clock.
If clock mixing is going to be allowed, use lock up latches.

BSD compiler Methodology

1. Preview BSD - preview_bsd
Reports information on test data registers, boundary scan registers and
instructions.
Displays the characteristics of the boundary-scan circuitry that would be
synthesized if you were to invoke the insert_bsd command.
2. Insert Boundary scan cells - insert_bsd
This command synthesizes ANSI/IEEE Std 1149.1 compliant boundary
scan circuitry using DesignWare macro cells.
3. Synthesize - compile
BSD compiler synthesizes boundary scan logic based on users JTAG
specification.
Once design is mapped, BSD compiler optimizes the boundary scan
architecture by selecting boundary cells to meet top-level area and timing
constraints.
Synthesizes using DesignWare JTAG components.
DesignWare tap controller is configurable to accommodate individual
designs.
4. High level BSD optimize - optimize_bsd
5. Check BSD compliance - check_bsd
6. Write BSDL - write-bsdl

10
 Generates BSDL file

7. Create patterns - Create_bsd_patterns

Generates functional vectors
Generates DC parametric vectors

TetraMAX Flow
1. Read Netlist and Libraries
Reads Verilog, VHDL or EDIF structural netlist
Netlist may be either flat or hierarchical
Netlist may exist as a single file or multiple files

2. Build Model
The build process is used to choose the top-level module and to build
in-memory design image necessary for the ATPG algorithm.

3. Perform DRC
Scan chains are checked for working order during shift model and that
the scan input to output path is logically connected.
Clocks and asynchronous set/reset ports connected to scan flops are
checked to see that they are controlled only by primary inputs.
Clocks/sets/resets are checked for off state when switching from
normal mode to scan mode and back again.
Multi-drive nets are checked for contention.

4. Run ATPG
Populate a fault list and generate ATPG patterns

5. Review Coverage

6. Save Patterns
STIL, Verilog, WGL, VHDL or proprietary binary outputs
Compression choices - none, GZIP
Serial vs. Parallel form (Verilog). Serial only VHDL
Compaction or not STIL
ATPG patterns - chain, test patterns, setup or combos.

7. Simulate Patterns
VCS verilog simulator

11
The DFT Workout Cardio
This is the phase of the workout in which the huffing and puffing begins. To get
the heart beating faster, the RTL code will be examined for test violations and
corrected. Compile and insert scan will elevate the heart rate to its maximum
rate. Boundary-scan insertion and ATPG generation will maintain the rate for the
maximum cardio benefit.

RTL Code Verification

RTL TestDRC can be used if youre lucky enough to start on a program during
RTL development. This provides early warnings for test-related issues. Early
feedback is crucial because it provides an opportunity to correct the RTL code
before the compile phase of the design flow. Correcting these problems during
this stage can reduce time-consuming iterations. The DFT Compiler RTL Test
Design Rule Checking User Guide is a great reference and should be reviewed
for detailed information about RTL Test DRC.

Preparing your design for RTL TestDRC

A typical RTL TestDRC design flow is shown below.

12
 dc_shell

Set Variables Fix RTL Manually

ReadHDL Source

Set ScanStyle

DefineTest
Protocol

Run RTL TestDRC

Violation
Report Violations

Review Report

No Violations

Finishedw ith
RTL TestDRC

Figure 1 RTLTestDRC Typical Design Flow

Variables need to be set before executing RTL TestDRC. The variable

hdlin_enable_dft_drc_info should be set to true. This variable causes HDL
compiler to save additional information that is used by TestDRC to report file
names and line numbers associated with testability violations. Make sure
link_library is defined. In addition, variable test_dft_drc_latch_check_style can
be set too transparent (default) or scan depending on how you desire TestDRC
to examine latches.

Next, read in the source code followed by selecting the scan style. The scan
style setting affects the messages generated by RTL TestDRC. Examples of how
to read in the source code and set the scan style are shown below:

dc_shell> read format verilog file_name.v

13
dc_shell> set_scan_configuration style scan_style

Typical scan styles are Muxed Flop or LSSD. Refer to the DFT Compiler Scan
Synthesis User Guide for additional information on setting scan style.

Finally, define the test protocol. To define the test protocol, all test clocks need to
be identified. Use the create_test_clock command to identify the clocks. All
asynchronous resets, presets and scan_enables need to be flagged. Use the
set_signal_type to flag these signals. TestDRC recognizes the following signal
types:
test_asynch
test_asynch_inverted
test_scan_enable
test_scan_enable_inverted

The constant logic value of the test mode needs to be described. Use the
set_test_hold command to describe the constant logic value. If your design
needs to be initialized for test then define the test mode initialization
requirements using set_test_isolate and set_test_assume.

Now that your heart rate is on the rise you are ready to run TestDRC.

Running RTL TestDRC

Before running TestDRC make sure the variable test_enable_dft_drc is set to
true. To run TestDRC use the following command

dc_shell> dft_drc

Review and manually fix any violations found in the report files. Once a clean run
is produced, design compilation and scan insertion are next.

Synthesis and Insert Scan

Once the RTL code has been verified, it is time to synthesize and insert scan.
The following sections describe the flow.

Synthesis and Insert Scan Flow

DFT Compiler requires a scan style to perform scan synthesis. The scan style
dictates the appropriate scan cells to insert during optimization. The test protocol
configures your design for scan testing. Commands to use for selecting scan
style and defining test protocol are defined in the Warm-Up section of this
document. If youre using Design Compiler XG mode you need to reference the
DFT Compiler Scan Replacement User Guide (XG Mode) for detailed information
about this flow.

14
Dont forget to breathe in this exercise! Now that the scan style has been
selected and the test protocol defined, it is time to read in the entire design and
uniquify any multiple design references.

Scan replacement can begin after the attributes and constraints are applied to
the top level synthesis. The following commands will compile and insert scan:

dc_shell> compile scan

The scan replacement process inserts scan cells into your design by replacing
non-scan sequential cells with their scan equivalents. Scan synthesis considers
the design constraints and the impact of both the scan cells themselves and the
additional loading due to the scan chain routing to minimize the impact of the
scan structures on the design.

Create a test protocol, check for test errors, and preview the scan chains.
Previewing the scan chains allows you to see if the results are desirable. The
following commands can be used to accomplish this. If controllability problems
are found, the Autofix feature may be used.

dc_shell> create_test_protocol
dc_shell> dft_drc
dc_shell> preview_dft

Now insert the scan using the following command.

dc_shell> insert_dft

Write out the test protocol and verilog netlist to export to your ATPG tool.

dc_shell> write_test_protocol -o post_dft.spf

Verify the resulting scan chains to make sure the completed scan chains operate
properly.

dc_shell> dft_drc

Boundary Scan Insertion

Hang in there just two more sections until cool down! The BSD Compiler Users
Guide goes into detail the steps required for boundary scan insertion. The
highlights are featured here.

Boundary Scan Insertion Flow

Shown below is a block diagram showing the Boundary Scan Insertion Flow.

15
 Finished w ith Synthesis
and scan insertion

dc_shell
Read RTL Net list
And Pin Map File

SetBoundary-Scan
Requirements

Preview Boundary-Scan

Insert Boundary Scan

Synthesizing and Optimizing

Boundary Scan Design

Optimize Boundary Scan

Design

Verify IEEE Std. 1149.1

Compilance

Write BSDL file and Test

Vectors

Write gate-level netlist

Figure 2 BSD Compiler Flow

16
To begin the BSD Compiler flow, you need to read in the RTL netlist and pin map
file. The RTL netlist can be a Verilog, VHDL, or DB format. The top-level must
have the following three characteristics.

The interface between the core and boundary logic must be defined
The top-level design must have I/O pad cells for all functional ports. The pad
cells must be linked to the core design pins.
The design might or might not have scan inserted but all scan ports must be
defined.

To read the netlist and remove core logic you can use something like:

dc_shell> read f verilog design.v

dc_shell> current_design core
dc_shell> remove_net all
dc_shell> remove_cell all
dc_shell> current_design top

Keeping the core the script will be similar to the following:

dc_shell> read f verilog design.v

dc_shell> current_design core
dc_shell> set_dont_touch core
dc_shell> current_design top

After loading the top-level design description youre ready to read in the port-to-
pin mapping file. If a pin mapping file is not used the tool automatically arranges
the pins in alphanumeric order. This file can be read using the following
command:

dc_shell> read_pin_map file_name

The pin-to-map file includes a mapping of logical ports to physical package pins.
It serves two purposes. First it provides BSD compiler with information regarding
the relative order of the ports for boundary-scan synthesis. Second, it provides
BSD compiler with the naming relationship between ports and pins for BSDL file
generation.

The next step is to specify the boundary-scan requirements. The requirements

that you need to focus on are listed below:

Define the IEEE Std 1149.1 Test access ports.

Identify the compliance enable pattern
Identify the linkage bits
Identify the clock signals

17
 Configure the device identification register
Select the boundary-scan configuration
Define the custom boundary-scan components
Customize the boundary scan register.
Implement instruction

You can use the command set_bsd_signal signal_type port to ensure the
mandatory TAP ports are defined. The TAP ports are test clock (tck), test data in
(tdi), test data out (tdo), test mode select (tms), and test reset (trst). The test
reset (trst) pin is optional.

For better optimization you should specify clock ports. Clock ports need to be
observe-only ports. The create_clock command can be used to define the clocks.

You must define the device identification register information to be used in your
boundary scan design if you intend to use the standard instruction IDCODE. You
can set the ID code by setting the following variables:

test_bsd_version_number
test_bsd_part_number
test_bsd_manufacturer_id

By defining these variables you enable the implementation of the device

identification register. The variable set_bsd_instruction IDCODE also needs to be
defined for the above variables to take effect.

The set_bsd_configuration command can be used to select the boundary scan

instruction encoding, the reset configuration of you TAP and the pin-map
package you intend to use. For information on the options available with this
command see the BSD user guide or the man page in DC.

If you have a requirement to use custom boundary scan components or need to

customize the boundary scan register, you can use the following commands:

set_bsd_bsr_element
set_bsd_tap_element
set_bsd_control_cell
set_bsd_data_cell
set_bsd_instructions

BSD Compiler implements the standard set of IEEE Std. 1149.1 instructions, and
also allows you to implement user-defined instructions. You specify boundary
scan instructions using the command set_bsd_instruction

Whew, boundary scan requirements specification is finally done! Lets preview to

see what we have.

18
dc_shell> preview_bsd

This command generates a preview of the boundary-scan design that satisfies

your specifications and it reports information about test data registers, boundary-
scan registers and instructions.

Let the fun begin by generating a boundary scan design. You do this by using the
insert_bsd command.

dc_shell> insert_bsd

This command has no arguments. The insert_bsd command synthesizes IEEE

1149.1 compliant boundary scan circuitry by using DesignWare macro cells.

It is now time to synthesize and optimize the boundary scan design. The three
components that need to be present to synthesize the entire design are pad
cells, core logic, and boundary-scan logic. A sample bottom-up compile strategy
script is shown below:

dc_shell> current_design DW_bc_1_design

dc_shell> compile
dc_shell> current_design DW_bc_2_design
dc_shell> compile
dc_shell> current_design DW_bc_4_design
dc_shell> compile
dc_shell> current_design DW_bc_7_design
dc_shell> compile
dc_shell> current_design TOP_BSR_top_inst_design
dc_shell> set_dont_touch {DW_bc_1_design, DW_bc_2_design, \
DW_bc_4_design, DW_bc_7_design}
dc_shell> compile
dc_shell> remove_attribute {DW_bc_1_design, DW_bc_2_design, \
DW_bc_4_design, DW_bc_7_design} dont_touch
dc_shell> current_design TOP
dc_shell> set_dont_touch { TOP_BSR_top_inst_design}
dc_shell> compile
dc_shell> remove_attribute { TOP_BSR_top_inst_design} dont_touch

With synthesis done, the boundary scan design can be optimized. For
optimization to take place constraints must be set. You perform the optimization
using the optimize_bsd command. Optimization occurs in the following steps:

BSR cells are merged

The design is optimized to comply with timing constraints.
The design is optimized to comply with area constraints

19
The check_bsd command can be used to verify the compliance of your logic with
IEEE Std. 1149.1. This command analyzes the boundary-scan logic, verifying its
behavior and assuring that it complies with IEEE Std. 1149.1.

Last but not least, a BSDL file and test vectors need to be written. To generate a
BSDL File the write_bsdl command can be used. The syntax is shown below:

Write_bsdl [-naming_check VHDL | BSDL | none] [-output file_name]

BSD Compiler can be used to generate vectors to test your boundary-scan logic.
The vectors typically generated are functional vectors and are based on the
structure of your boundary-scan logic. The vectors also allow DC parametric
testing enabling you to characterize your circuits ports. To generate vectors use
create_bsd_patterns command. The syntax is shown below:

Create_bsd_patterns [-output test_program_name] [-effort low | medium | high] [-

type all | functional | dc_parametric | tap_controller | tdr | bsr | reset]

ATPG Generation
Dont fade now, were on the homeward stretch! For purposes of this document,
the Verilog netlist and STIL file generated for the core design will be used in
TetraMAX. The TetraMAX ATPG User Guide is an excellent document and
should be reference more additional information.

Design Flow Review

Before getting into the TetraMAX design flow, lets review where weve been.
Starting with the HDL netlist, we ran a test ready compilation that integrates logic
optimization and scan replacement. The compile scan command maps all
sequential cells to their scan equivalents. You can use the dft_drc and
preview_dft commands to verify that none of the sequential cells have violations
and to observe the scan chains. Next, scan is inserted using insert_dft and
checked using dft_drc. Finally, a design netlist and STIL protocol file are written.
The following diagram summarizes the review.

TetraMAX Design Flow

A basic TetraMAX design flow block diagram is shown below. Each of the steps
will be briefly described.

20
 TetraMAX
Read Net list and Library
Models

Build the Model

Perform Test Design Rule

Checking (DRC)

Preparte to run ATPG

Run ATPG

Review TestCoverage

Save Test Patterns

Figure 3 TetraMAX Design Flow

The following command can be used to read in the netlist and library files. If you
have multiple files use as many read netlist commands as needed.

Build> read netlist filename

Build> read netlist libfile

The process of building the ATPG design model takes those parts of the design
that are to be part of the ATPG process, removes the hierarchy, and puts them
into an in-memory image that TetraMAX can use. The syntax to build the model
is shown below:

Build> run build_model top_module_name

DRC checks the following:

21
 Whether the scan chains inputs and outputs are logically connected
Whether all the clocks and asynchronous set/reset pins connected to scan
chain flip-flops are controlled only by primary input ports
Whether the clocks/sets/resets are off when you switch from normal mode to
scan shift mode and again when you switch back to normal mode.
Whether any internal multiple-driver nets can be in contention

In order to run DRC, you must provide information about clocks, ports, scan
chains, and other controls by means of a STIL protocol file. The STIL file is
generated from DFT compiler. To run DRC type at the build prompt:

Build> run drc my_stil_file.spf

After completing a successful DRC run, you can start preparing for ATPG. The
list of things to do to prepare are: initialize the faultlist, select the pattern source,
choose settings for bus contention checking, and specify the pattern generation
effort. At this point, you might want to write out a test vector that examines the
scan chains. Here is the command to write out the chain test:

Test> write patterns <filename.v> -internal format verilog_tables replace

serial last 0

If the chain test passes simulation great! If not, research and find out why.

To generate a new faultlist that includes all possible fault sites use the add faults
command as shown below:

Test> add faults all

TetraMAX can read and write patterns. By default TetraMAX generates new
internal patterns. If an external pattern is required, the set patterns command will
allow you to change the default.

Test> set patterns External <filename>

There are several options associated with the set patterns command. The user
guides or on-line TetraMAX on-line help provides information on the options.

If a pattern can potentially cause contention it is discarded and additional

patterns are generated to avoid the contention. The set contention command and
its options can be used to match your unique requirements.

Test> set contention [Bidi | NOBIdi] [bus | nobus] [dff dlat | nodff nodlat]

22
It is now time to run ATPG. Before doing so the set atpg command can be used
to customize for your specifications. The on-line documentation explains all of
the options available. To run ATPG use the following command.

Test> run atpg -auto

By default, TetraMAX performs Basic-Scan ATPG first, followed by Fast-

Sequential ATPG (if enabled), and Full Sequential (if enabled). When run ATPG
is done, the report summaries command will display the test coverage.

Finally, if you have achieved the required test coverage, you can save and write
patterns. The write patterns command is used to write out the patterns.
Commonly used write patterns command variations are shown below:

Test> write patterns <filename.v> -internal format verilog_tables replace

serial last 0
Test> write patterns patterns.bin format binary replace
Test> write patterns patterns.stil format stil replace
Test> write patterns patterns.v format verilog parallel 1 -replace

The test vectors should be simulated using VCS to ensure correct operation. If
the entire vectors pass and the coverage are acceptable, then congratulations -
youre done with ATPG and the Cardio portion of this workout!

The DFT Workout Cool Down

The cool down consists of vector delivery and final documentation. The actual
delivered components depend on the customer requirements. Here is a list of
candidates for delivery.
All Vectors
Write up on flow used for engagement
Generate a list of coverage, vector count, simulation results, etc.
Lessons learned from engagement positive and negative. Include work
around for problems.

The DFT Workout Stretch and Relax

You have finally reached the end of your workout. It is time to stretch, relax, and
think about the positive outcomes of the DFT engagement and jot down your
thoughts. Reflect on the things that could be improved on for next time. Set up a
time with your peers and discuss your notes so that during your next
engagement youll be stronger and better equipped for your next DFT Workout!!

23