Professional Documents
Culture Documents
Training Workbook
February 2004
This document contains information that is proprietary to Mentor Graphics Corporation. The original
recipient of this document may duplicate this document in whole or in part for internal business purposes
only, provided that this entire notice appears in all copies. In duplicating any part of this document, the
recipient agrees to make every reasonable effort to prevent the unauthorized use and distribution of the
proprietary information.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OR MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS CORPORATION HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
U.S. Government Restricted Rights. The SOFTWARE and documentation have been developed
entirely at private expense and are commercial computer software provided with restricted rights. Use,
duplication or disclosure by the U.S. Government or a U.S. Government subcontractor is subject to the
restrictions set forth in the license agreement provided with the software pursuant to DFARS 227.7202-
3(a) or as set forth in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted
Rights clause at FAR 52.227-19, as applicable.
Contractor/manufacturer is:
Mentor Graphics Corporation
8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777.
Table of Contents
About This Training Workbook............................................................................ix
Introduction............................................................................................................ix
Audience .................................................................................................................x
Primary Audience.................................................................................................x
Secondary Audience.............................................................................................x
Course Timeline.....................................................................................................xi
Course Overview ..................................................................................................xii
Prerequisite Knowledge.......................................................................................xiii
Acronyms Used in This Workbook .....................................................................xiii
Customer Support Information ............................................................................xiv
Module 1
Memory BIST Concepts .....................................................................................1-1
Objectives ............................................................................................................1-1
Embedded Memories ...........................................................................................1-2
Typical Architecture with Embedded Memories.................................................1-4
Types of Memories ..............................................................................................1-5
Types of Testing ..................................................................................................1-7
Functional Testing ...............................................................................................1-8
Direct Access Testing ..........................................................................................1-9
Memory BIST Testing .......................................................................................1-10
When Should You Use Memory BIST? ............................................................1-11
Advantages of Adding BIST .............................................................................1-13
Disadvantages of Adding BIST .........................................................................1-14
Inserting BIST Circuitry ....................................................................................1-16
Memory Testing and Fault Types......................................................................1-17
Stuck-at Faults ...................................................................................................1-19
Stuck-at Faults ..................................................................................................1-20
Transition Faults ................................................................................................1-21
Transition Faults (Continued) ...........................................................................1-22
Coupling Faults..................................................................................................1-23
Neighborhood Pattern Sensitive Faults .............................................................1-26
Testing for Cell Array Faults ............................................................................1-28
Memory BIST Algorithms.................................................................................1-30
Module 2
Generating a Memory BIST...............................................................................2-1
Objectives ............................................................................................................2-1
Typical Memory BIST Flow ...............................................................................2-2
MBISTArchitect Inputs and Outputs...................................................................2-4
Graphical User Interface......................................................................................2-6
MBISTArchitect GUI Overview .........................................................................2-7
Role of the Test Bench ........................................................................................2-8
Memory BIST Documentation ............................................................................2-9
Module 2 Lab Exercises ....................................................................................2-10
Module 2: Lab Exercises ...................................................................................2-11
Getting Started ...................................................................................................2-11
Software Versions ...........................................................................................2-11
Training Files ..................................................................................................2-12
Installing the Training Data Files....................................................................2-12
Exercise 1: Creating a Basic Memory BIST Collar ...................................... 2-14
Exercise 2: Verifying the BIST Circuitry ..................................................... 2-20
Module 3
Common BIST Variations ...................................................................................3-1
Objectives ............................................................................................................3-1
Configuring Memory BIST Circuitry ..................................................................3-2
Support for Multi-port Memories ........................................................................3-5
Generate a Comparator Functional Test ..............................................................3-6
Inserting BIST for Multiple Memories................................................................3-8
MBISTArchitect Controller Options .................................................................3-10
How the BIST Controller Works .......................................................................3-11
Read/Write Operations on Synchronous Memories ..........................................3-12
Full-Speed Overview .........................................................................................3-14
Full-speed design with pipeline circuitry ..........................................................3-16
Pipelining Read/Write Operations .....................................................................3-17
Module 4
Memory BIST-In-Place ........................................................................................4-1
Objectives ............................................................................................................4-1
Memory BIST-In-Place Flow ..............................................................................4-2
Memory BIST-In-Place Flow Overview .............................................................4-3
Creating BIST Structures.....................................................................................4-5
Model Creation ....................................................................................................4-6
Memory Model Example .....................................................................................4-7
Creating BIST Structures Invocation...................................................................4-8
Basic Command Flow..........................................................................................4-9
Module 5
Memory Modeling for
MBISTArchitect ...................................................................................................5-1
Objectives ............................................................................................................5-1
A Memory Model: ...............................................................................................5-2
Memory Model Syntax .......................................................................................5-3
Introduction
This course is designed to be a one-day, self-paced training class. The student will
use this workbook and run exercises to become familiar with memory Built-In-
Self-Test (BIST) concepts. The following are the top level course goals:
Audience
Primary Audience
The target student profile is the Electronic Design Engineer using synthesis tools
to develop synchronous digital designs. It is assumed that students will be using
MBISTArchitect, and optionally, Memory BIST-In-Place tools. This type of
student will comprise about 80% of the course attendees and will have the
following characteristics:
They have some limited familiarity with DFT terminology and concepts.
They are interested in learning how to add memory BIST to their designs.
As they work with these DFT tools, these engineers want to know what is
this tool doing to my design (or my design flow) and how do I control
what the tool is doing to my design?
These engineers want to be well grounded in the basic tool process flow and
be able to respond appropriately when the tools report problems.
Secondary Audience
About 20% of the students will be test engineers. These engineers are typically
members of a manufacturing test group or an internal CAD group that provides
support for design engineers. Test engineers are typically well grounded in their
understanding of DFT terms and concepts, but may not have had much experience
with DFT tools.
Course Timeline
8:30
Memory BIST Concepts
9:30
LAB 1: Creating a Basic Memory BIST Collar
LAB 2: Verifying the BIST Circuitry
11:00
Configuring Memory BIST Circuitry
12:00
Lunch
1:00
LAB 3: Changing the BIST Algorithm
LAB 4: Changing the Data Background
LAB 5: Inserting BIST for Multiple Memories
LAB 6: Adding BIST with a Compressor
LAB 7: Full-Speed Exercise
LAB 8: Adding BIST for Bidirectional Memories
LAB 9: Adding BIST for ROMs
2:30
Memory BIST-In-Place
3:00
LAB 10: Setting Up MBIST Architect Outputs
LAB 11: Inserting BIST Controllers using MBIST-In-Place
LAB 12: Translating BIST Patterns
5:00
Course Overview
The course is divided into the following five parts:
The first module introduces various types of memories, memory BIST concepts,
memory testing and fault types.
This module introduces you to the typical memory BIST flow, inputs and outputs
to MBISTArchitect, and the role of the test bench. It also introduces you to the
MBISTArchitect graphical user interface (GUI) and user documentation for
memory BIST tools. The lab exercises will give you practice generating a BIST
collar and verifying the circuit.
This module highlights a variety of options you can use to customize the memory
BIST circuitry to your design. The lab exercises cover tasks you may use when
adding memory BIST to your design such as inserting BIST for multiple
memories or adding BIST when you have a compressor, ROM, or bidirectional
memories. A number of lab exercises are included here to give you a variety of
choices. Generally, you will not be expected to complete them all.
This module gives you a basic understanding of how to create, connect, and
integrate BIST structures using the Mentor Graphics Memory BIST-In-Place tool.
The lab exercises at the end of this module will give you experience in running
through the process flow of Memory BIST-In-Place.
This module explains how memory devices are modeled inside MBISTArchitect.
The lab exercises are designed to give you practice creating a memory model in
case your company does not already have the model you are looking for. It also
introduces you to the Mentor Graphics User Defined Algorithm function that
can be used to generate your own March-type algorithms.
Prerequisite Knowledge
Prerequisite knowledge in DFT fundamentals is required. The purpose of
requiring prerequisites is to (1) reduce learning overload which can happen
early in the course and (2) help the students move quickly toward learning tool
concepts and best practices for getting results.
Generic DFT concepts and terminology can be learned from sources outside
Mentor Graphics.
When you complete this module, you should have a basic understanding of
memory testing and memory BIST concepts.
Objectives
Upon completion of this module, you will be able to:
Embedded Memories
Embedded Memories
Memory Built-In-Self-Test (MBIST) has been used successfully
for years to solve the test issues for embedded memories.
Most of todays designs contain embedded
memoriesfeatures associated with memories:
Memory can consume a large design portion
Memories are dense, resulting in high defect rates
Embedded memory quality is critical to whole chip quality
Memories can have high operating speeds
Embedded memories can be difficult to exercise efficiently
with functional testing
Most of todays designs contain embedded memories. Here are some common
side effects of using embedded memories in chips today:
Memory can consume a large design portion and result in high defect
rates
In many designs today, memories may take up a large portion of the design.
See Typical Architecture with Embedded Memories on page 1-4 for more
information on architecture and test options.
Types of Memories
Types of Memories
General Memory types
Different depth and width
Synchronous and asynchronous
Multi-port
SRAM
DRAM
EPROM & EEPROM
(Flash)
ROM
The memories listed in the slide above are common, your memory BIST circuit
will be different depending upon the model selected. In general, SRAM and
ROMs commonly use memory BIST to solve the test problems.
SRAM
The most commonly used in our industry is an ASIC type of flow. We do
most of our work in this tutorial on variations of an SRAM.
DRAM
A DRAM is not as common as an SRAM, a special process is sometimes
required to accommodate DRAMs.
ROM
ROM memories are very common and generally use a slightly different
implementation for memory BIST. Well talk about BIST architectures in
Lesson 3.
Types of Testing
Types of Testing
Functional testing
Functional Testing
Functional Testing
Pattern generation can be very difficult
No functional impacts
Previously, ATPG functional testing was the only way to test embedded
memories.Because memory faults differ from random logic faults and memories
reside within larger designs, ATPG does not provide an adequate memory testing
solution. Functional testing is inadequate because pattern generation is difficult,
verification is time-consuming and it is difficult to determine quality.
Memory BIST testing addresses memory testing problems. Memory BIST adds a
layer of test circuitry around the memory. This circuitry becomes the interface
between the high-level system and the memory. This interface minimizes the
controllability and observability challenges of testing embedded memories. And
the built-in, finite-state machine that provides the test stimulus for the memory
greatly reduces the need for an external test set for memory testing.
BIST provides a memory test solution without sacrificing test quality. In many
cases, BIST structures can eliminate or minimize the need for external test pattern
generation (and thus, tester pattern memory) and tester application time. In
addition, a designer can exercise BIST circuitry within a design, running tests at
speed due to the proximity of the BIST circuitry to the memory under test. A
designer can also run a memory BIST process from within higher levels of the
design. See Advantages of Adding BIST on page 1-13 for more detailed
information on the advantages of using memory BIST.
1-10 M BISTA rchitect: M BIST C oncepts Copyright 2002 M entor G raphics Corporation
Self-testing provides a number of benefits. First, placing the test circuitry on the
chip itself reduces external tester time and expense. Second, it minimizes the
difficulty of testing embedded circuitry by providing system-level control signals
that run and report status of the test operation. Third, because the circuitry itself
generates test stimulus, this eliminates or reduces expensive test pattern
generation time. Likewise, it eliminates or reduces the amount of required external
test data storage.
BIST blends both the design and test disciplines. Merging test into the design
process far earlier in the flow reduces the product development cycle.
However, these tests are being hard-wired into the controller. After they
are designed in, they cannot be changed. If you have direct access, you can
change your test pattern supplied by the tester and rerun. It is also possible
to design a re-configurable controller but this takes additional work and
overhead.
M UX
System System
Pattern G enerator I0 M em ory
I1
Start Ctrl
BIST Controller
Response Analyzer
Fail?
A built-in self-test (BIST) solution can alleviate many of these classic problems
by embedding the pattern generator within the silicon. This approach can be
automated using MBISTArchitect, which creates the RTL description in either
Verilog or VHDL, that tests the memory without external stimulus or access.
BIST Circuitry
Ce ll
A rray
Da ta Reg is te rs
S en se A m plif ie rs
A dd res s
D e co de r R e ad /Write
C on tro l C irc uitry
The basic types of memory faults include stuck-at, transition, coupling, and
neighborhood pattern sensitive. The next several slides discuss each of these fault
types in more detail.
Stuck-at Faults
Stuck-at Faults
Applies to Control signals and m em ory cells
Behavior: Value stuck at either 0 or 1 indefinitely (signal/cells
acts as though tied to power or ground)
VDD
Stuck-at Faults
Stuck-at Faults (C ontinued)
w1
w0 w1
S S
0 1
w0
G ood Cell State D iagram
w0 w0
S S
0 1
w1 w1
A memory fails if one of its control signals or memory cells remains stuck at a
particular value. Stuck-at faults model this behavior, where a signal or cell
appears to be indefinitely tied to power (stuck-at-1) or ground (stuck-at-0).
Transition Faults
Transition Faults
A pplies to: Signal or cell
1
1
0 0
w1
w0 w1
S S
0 1
w0
Good Cell State Diagram
w0
w1
w0
S S
0 1
w1
A memory fails if one of its control signals or memory cells cannot make the
transition from either 0 to 1 or 1 to 0. The inability to change from 0 to 1 is called
an up transition fault. The inability to change from a 1 to a 0 is called a down
transition fault.
As the example shows, a cell may behave normally when a test writes and then
reads a 1 value. And it may even transition properly from 1 to 0. However, when
undergoing a 0->1 transition, the cell could remain at the 0 stateexhibiting
stuck-at-0 behavior from this point on. However, a stuck-at-0 test might not detect
this fault if the cell was at the 1 state originally.
Thus, to ensure the cell can transition normally, a test must write a 1, write a 0,
and then read the cell contents, as well as write a 0, write a 1, and then read the
cell contents.
Coupling Faults
C o u p lin g F a u lts
A p p lie s to : M e m o r y c e lls
A A C C
C e ll_ n C e ll_ m
change change
A B C C
Cell_n Cell_m
change change
1-21 M BISTA rchitect: M BIST C oncepts C opyright 2002 M entor G raphics C orporation
Memories fail when memory cells do not attain the proper state.This can happen
in a number of different ways. In one case, a write operation in one cell can
influence the value in another cell. Coupling faults model this behavior.
Coupling faults fall into several categories: inversion, idempotent, bridging, and
state.
Inversion coupling faults, commonly referred to as CFins, occur when one cells
transition causes inversion of another cells value. For example, a 0->1 transition
in cell i causes the value in cell j to go from 0 to 1.
Idempotent coupling faults, commonly referred to as CFids, occur when one cells
transition forces a particular value onto another cell. For example, a 0->1
transition in cell i causes the value of cell j to be 0.
Bridge coupling faults, abbreviated as BFs, occur when a short, or bridge, exists
between two or more cells or signals. Instead of transition operation, a logic value
triggers the faulty behavior. Bridging faults fall into either the AND bridging fault
(ABF) or OR bridging fault (OBF) subcategories. ABFs exhibit AND gate
behavior: that is, the bridge has a 1 value only when all the connected cells or
signals have a 1 value. OBFs exhibit OR gate behavior: that is, the bridge has a 1
value when any of the connected cells or signals have a 1 value.
State coupling faults, abbreviated as SCFs, occur when a certain state in one cell
causes another specific state in another cell. For example, a 0 value in cell i causes
a 1 value in cell j.
1-2 3 M B IS T A rch ite ct: M B IS T C on cep ts C o pyrig ht 20 02 M e nto r G ra ph ics C o rp ora tion
Another way in which memory cells can fail involves a write operation on a group
of surrounding cells affecting the values of one or more neighboring cells.
Neighborhood pattern sensitive faults model this behavior. Neighborhood pattern
sensitive faults break down into three categories: active, passive, and static.
An active fault occurs when, given a certain pattern of neighboring cells, one cell
value change causes another cell value to change. A passive fault occurs when a
certain pattern of neighboring cells cause one cell value to remain fixed.
A static fault occurs when a certain pattern of neighboring cells forces another cell
to a certain state.
Because of the complexity and vast number of ways in which these faults can
occur, testing for neighborhood pattern sensitive faults remains a very difficult
task.
D ifficu lt to d ete ct an d re q uire d iffe ren t pro ced u re s for d iffe ren t typ es
o f the se fau lts.
1-2 4 M B IS TA rch ite ct: M B IS T C on cep ts C o pyrig ht 20 02 M e nto r G ra ph ics C o rp ora tion
To detect stuck-at faults, you must place the value opposite the stuck-at fault at the
fault location. To detect all stuck-at-1 faults, you must place 0s at all fault
locations. To detect all stuck-at-0 faults, you must place 1s at all fault locations.
In order to detect all transition faults in the memory array, a test must transition
each cell from 0->1 and then immediately read it. The test must then repeat this
process for the 1->0 transition.
Coupling faults involve cells affecting adjacent cells. Thus, to sensitize and detect
coupling faults, you must perform a write operation on one cell (j) and later read
cell (i). The write/read operation performed in ascending order assumes coupling
of a memory cell to any number of cells with lower addresses. Likewise, the
write/read operation performed in descending order assumes coupling of a
memory cell to any of the cells with higher addresses.
neighborhood pattern sensitive fault detection require much area overhead and
produce very long test sets. Some test algorithms, in conjunction with manual
circuit manipulation, can produce test sets for this fault type. However, currently
no commercially-available tool alone does an adequate testing job for this
memory fault type.
1-25 M BIST A rc hitect: M BIST C onc epts C opyright 2002 M entor G raphics C orporation
The test industry has generated many different algorithms for memory testing.
The following list gives a brief description of some of the more popular ones:
March A and March B
The March A and March B algorithms cover some linked faults, such as
idempotent linked faults, transition faults linked with idempotent coupling
faults, and inverting faults coupled with idempotent coupling faults.
Other Algorithms
Other common algorithms include: March C, March C-, March3, Column
March, Unique Address, Checkerboard, ROM Test, the Port Interaction
Test, and the User Defined Algorithm. For more detailed information on
these algorithms, see Chapter 3 in the Built-In Self-Test Process Guide.
For example, the March C- algorithm has a complexity of 10n, where n is the
number of locations in the memory. That is, if you count the number of operations
(see the slide depicting the algorithm operations for March C-), you can see that it
requires 10 operations at each location to complete its test. In this comparison, the
March C- algorithm took 1.0 seconds to complete testing of a 1 M RAM.
While more robust in its fault detection, the GALPAT algorithm, on the other
hand, has an order n2complexity. A walking target cell and revisiting of this target
cell after each read greatly increases this algorithms complexity. This results in
the following equation that describes the complexity of the GALPAT algorithm:
2(2N + 2n2), where N is the number of address lines and n is the number of cells in
the memory. Because of its complexity, in this comparison, the GALPAT
algorithm would take 5.1 days to complete testing of a 1 M RAM. The MATS
algorithm is a modification of the Algorithm Test Sequence (ATS). MATS
provides the shortest march test for unlinked stuck-at faults, it detected address
and stuck-at faults in .42 seconds.
Selecting one or more algorithms for your BIST design depends on the type of
memory you are testing, your test goals, your overall test strategy, and the advice
you may receive from in-house memory-test experts or ASIC vendors.
As you can see, as the size of the target memory grows, the complexity of the
algorithm plays a very big role in the required test execution time. So, you need to
consider the trade-off between robust fault coverage and test execution time when
determining which algorithms to use.
March C+ (March 2)
M arch C + (M arch 2)
D efault A lgorithm for M B IS TA rchitect
Ex tra R e ad s
Write 0s (to initialize) to detec t
at sp ee d fau lts
Read 0s, Write 1s, Read 1s
Read 1s, Write 0s, Read 0s
March C+ (March 2)
M arch C+ (M arch 2) Continued
Detects the sam e faults as M arch C, PLUS som e stuck-open
faults, and som e tim ing faults if you test at-speed (due to the
read im m ediately after the write)
When you complete this module, you should have a basic understanding of
memory testing inputs and outputs, how to launch MBISTArchitect, and how to
access documentation for MBISTArchitect. The accompanying lab exercises give
you hands-on experience generating and verifying a BIST collar for a simple
memory device.
Objectives
Upon completion of this module, you will be able to:
Logic Synthesis
Gate level
Netlist
Add internal scan
Timing Closure
(Optional)
Run Diagnostics
2-2 MBISTArchitect:Generating a Memory BIST (optional) Copyright 2002 Mentor Graphics Corporation
Here a typical Memory BIST flow. It contains all the basic steps that are used in
an ASIC type flow.
The MBISTArchitect Control Panel gives you a graphic means to setup and
generate the memory BIST circuitry. As shown in the slide, the output is a set of
three HDL files:
3. Test Bench (ram4x4_tb.v) You can use this test bench to verify the proper
working of the memory BIST generated circuit before you include the
circuit in your design.
You or your ASIC vendor must supply the memory simulation model. In this case,
assume that your simulation model file is named ram4x4.v.
DFT products use two similar graphical user interfaces (GUI): one for BIST
products and one for ATPG products. The BIST graphical user interface supports
MBISTArchitect, LBISTArchitect, BIST Controller Synthesis, BIST-In-Place,
and BSDArchitect.
The slide shows a representation of the GUI elements that are common to both
user interfaces. Notice that the graphical user interfaces consist of two windows:
the Command Line window and the Control Panel window.
Buttons used for common tasks such as loading memory models, setting the
report environment, and obtaining help.
You will be using the tool in the GUI mode in the first exercise.
MB IS T C ircu itry RA M1
sys_ a dd r
n sys_ ad d r
di
n di
0 0 0 0
Pattern Generator
Algorithm-Based
wen
we n
rst 0 0 0 0 n do
clk 0 0 0 0
h old _l
0 0 0 0
co m p
Comparator
t est _h
fa il_ h
The testbench instantiates and provides stimulus to the connected memory BIST
model. A high value on the tst_done signal indicates the BIST test has
successfully completed. The fail_h signal value goes high the first time the BIST
controller encounters a miscompare.
Use the following documentation for information on BIST concepts and how to
use the MBISTArchitect and Memory BIST-In-Place tools:
Click the Help and Turn on Query Help buttons to obtain online information and
links to this documentation. You will need a PDF viewer to view documentation.
Exercise 1: Creating a Basic Memory BIST CollarYou will create a basic BIST
collar for a simple 4x4 RAM model, then save the BIST circuit as a Verilog file
set.
Exercise 2: Verifying the BIST CircuitryYou will use ModelSim to verify the
memory BIST circuit using an MBISTArchitect-generated test bench.
Getting Started
This section lists the software versions and versions of the training data you will
need. It also provides instructions on how to install the training data so that you
can run the labs.
Software Versions
This version of the training data and materials (V8.2002_1) should be used with
the V8.2002_1 release of all BIST products to ensure that the lab exercises run
successfully:
MBISTArchitect v8.2002_1
Memory BIST-In-Place v8.2002_1
Acrobat Reader v4.0 (install from MGC CD)
ModelSim EE/Plus 5.5f or newer, including both VHDL
and Verilog libraries
Training Files
Training files have been provided for this course. Use the files in this directory to
access the training data:
2. The design data for the lab exercises is named mbist896nwp. It is located in
the directory named:
$MGC_HOME/shared/training/mbist896nwp
Before you can perform the lab exercises, this training data directory must
be installed in your Mentor Graphics tree. To check whether the training
data is installed, list the contents of the $MGC_HOME/shared/training
directory by issuing the following operating system command:
/bin/ls $MGC_HOME/shared/training
If mbist896nwp does not appear in the displayed list, then either you or
your system administrator must install the training package.
3. Before attempting to copy the training directory, ensure you have at least 20
MB of disk space. The uncompressed tar file is approximately 10 MB and
the design data is about 10 MB.
4. Copy the training package data from the MGC_Home tree to the training
directory on your workstation. Specify the pathname where you want your
local copy. The pathname that you specify in this step is referred to as
your_path.
The ram4x4.atpg file is a library file contains a single 4x4 RAM model.
The ram4x4.v file is the corresponding Verilog simulation model.
4. Invoke MBISTArchitect.
shell> mbistarchitect
This step invokes the MBISTArchitect graphical user interface (GUI). You
will be using various aspects of the GUI to create your memory BIST
model.
This adds the model to the memory models for BIST insertion.
d. Click OK.
The tool displays a list of commands similar to those shown on the next page.
You want to see the models in the library, so use the -Library switch.
This is the memory model around which you want to generate BIST
circuitry.
3. From the command line interface, report more information on the current
memory model by issuing the following command:
MBISTA> report memory models -model ram4x4
Model ram4x4
data_out DO3, DO2, DO1, DO0;
data_in DI3, DI2, DI1, DI0;
address A1, A0;
write_enable WEN low;
Vendor: sample
Technology: sample1
Version: 1.0
Additional info: 4x4 RAM, ports = 1rw
Number of Words: 4
This RAM has one read/write port and contains four words. It has four data
input bits, two address bits, and four data output bits.
4. Click Run.
Name Type
------------------------------------------------
ram4x4_bist Memory Bist
This action brings up the File Viewer window which allows you to view the
contents of each of the output files. MBISTArchitect generated the
following three Verilog files for the ram4x4 model:
Examine the top-level signals coming out of and going into the BIST
controller. Scroll down through the file and notice that the default BIST
circuitry includes a comparator.
There are also three new BIST inputs; clk and rst_l drive the new BIST
state machine. test_h is a level-sensitive signal that tells the BIST
controller to run the test.
tst_done tells your design that the test is finished and has run
successfully;
fail_h tells your design that the memory test has failed.
Examine the top-level signals coming out of this model. Examine the
testing that the testbench performs on the ram4x4_bist_con.v model.
3. Compile the memory simulation model, all BIST models, and the
testbench.
d. Run a little more to capture the complete pattern for the tst_done
signal.
VSIM 3> run 50
5. Examine the saved list file. Use whatever editor you prefer to view the
trace.log.m2 file you saved.
The signals that comprise the columns in this file include (from left to
right, fail_h, tst_done, the address, the write enable, the data input
values, and the data output values).
At time 2250ns, with the address set back to space 0, the algorithm
reads 0, writes 1, and reads 1. The address space increases to 1, and the
algorithm then reads 0, writes 1, and reads 1. This process repeats for
addresses 2 and 3.
At time 4650ns, with the address set back to space 0, the algorithm
reads 1, writes 0, and reads 0. This repeats for addresses 1, 2, and 3.
At time 7050ns, the algorithm begins the test in reverse address order,
reading 0s, writing 1s, and reading 1s.
At time 9450ns, the algorithm again performs the test in reverse address
order, this time reading 1s, writing 0s, and reading 0s.
At time 12750ns, the tst_done flag goes high indicating the BIST
testing is complete.
When you complete this module, you should have a basic understanding of how to
configure memory BIST circuitry, use one BIST controller for multiple memories,
add diagnostics, add pipeline registers, use compressors and comparators, use
clock constraints, and run MBISTArchitect at full-speed.
Objectives
Upon completion of this module, you will be able to:
Decreases interconnections
You can add to or change the default algorithms. For example, if you are adding
BIST circuitry to a multiple-port memory model, you may not want to execute the
March C+ test on every write port. You may instead want to use the Unique
Address algorithm to test just the address and control circuitry for all but the first
port.
Another common variation includes using a single BIST controller for multiple
memory models. You can add a BIST collar around an individual model or you
can create a single BIST controller that controls and tests a number of different
compatible memory models.
One common variation includes using a compressor for signature analysis instead
of a built-in comparator for direct memory output comparison. You also have less
capability to diagnose what failure occurred.
You can add a system-level hold signal that can stop the testing process. You can
also define multiple input busses connecting to the memory model to provide
further system control.
Generate Using:
MBIST> setup observation scheme -compare
set comparator test -on
The MBISTArchitect tool provides the ability to test the comparator before
running the BIST. This is achieved by adding three states to the controllers finite
state machine that inject faulty data into the memory at the beginning of the test.
The two states are comp_test_write and comp_test_read_fail.
The comparator test first uses the comp_test_write state to write known data
(background 1) to address zero of all the memories. Then, comp_test_read
performs a read/compare expecting a mismatch which should raise the fail_h flag.
Next, comp_test_read performs a second read/compare expecting a match,
thereby resetting the fail_h flag. When you enable the comparator test, it always
precedes all other tests.
To generate the comparator test, use the Setup Observation Scheme command
with the -Compare switch. To test the comparator, use the Set Comparator Test
command with the -on switch as follows:
In this case, the controller repeats the comparator test for each memory prior to the
application of any other tests. Thus, testing the fail flag of each memory
independently.
You can load multiple memory models with the Add Memory
Model command
B IST C ir cu itry
n ad d r Pattern Generator
Algorithm-Based
n di
n di
wen
n ad dr
M e m ory
rst M o d el
c lk w en R A M 4 X 4_ 1
h ol d_ l
te st_h
co m p
Comparator
te st_ d on e
fail_flag_0
fa il_ fla g_ 1
You can create a single BIST controller that runs BIST on multiple memory
models. This can only occur with compatible memory modelsthose that share
the same vendor and technology and have compatible read and write cycle
definitions.
You can specify multiple memories using one or more Add Memory Models
commands. MBISTArchitect generates BIST circuitry that runs the testing on all
memories in parallel.
MBISTArchitect contains options that let the designer or tester determine how
they want to test the memory and how fast the MBIST controller performs
memory testing. Using MBISTArchitect options, the designer can match the
memory BIST controller speed and hardware required to their own unique needs.
See How the BIST Controller Works on page 3-11 for information on how the
BIST controller typically works. See Full-Speed Overview on page 3-14 for an
overview of MBISTArchitect full-speed implementation.
FAIL
Compare Capture
F Reference Data
COMP
S C D A
O A D
M N T D
T A R
R E
O S
L S
MEMORY
LOGIC
LOGIC
In a typical design with memory BIST, the BIST controller performs two primary
functions to the memories under test: 1) it provides the test stimulus, 2) it checks
the response. The slide shows that there is one memory tested by one BIST
controller. In reality, the BIST controller is much smaller than the memories.
The BIST controller itself is a finite-state machine. The clock controlling its state
transitions can be from either an internal clock generator or an external source. To
avoid clock synchronization problems during the BIST operation, normally the
same clock source controls both the BIST controller and the memories it tests. In
this example, we assume all memories are synchronous memories.
CLOCK
CLOCK
COMPARE COMPARE
CIRCUITRY
CIRCUIT FAIL/PASS
OUTPUT
To properly perform read or write operations for synchronous memories, the BIST
controller must first generate read/write setup signals before the memory clock is
active. For simplicity, the examples presented in this section assume:
In addition, memory BIST controllers typically use comparators to verify the data
read out from the memories. Since memory outputs are not ready until the edge of
the second clock, the result of the comparator will be captured at the third clock
cycle. Therefore, a BIST controller requires:
Full-Speed Overview
Full-Speed Approach
Because memories are getting larger and denser, design and test engineers need to
ensure higher memory test quality to ensure overall chip quality. Besides static
functional tests, timing and stress tests are necessary to detect system operation
problems. At-speed BIST operation generally means BIST operation is capable of
exercising the memories at system clock frequency. However, at-speed operation
is not sufficient to detect all timing faults. Even if a BIST controller design is
operated in system clock frequency, its data latency prevents testing whether the
memory can change the address and read out different data from different
addresses at every cycle. Without this limitation, the BIST operation may not
ensure adequate memory quality.
read/write operations require 5 clock cycles which can be done in 2 clock cycles
with full-speed BIST operation.
Full-speed testing reduces testing times. Full-speed can locate defects that will not
be detected at slower speeds, thus providing increased fault detection. Full-speed
provides the additional benefit of testing whether a memory can change an
address and read data from different addresses at every cycle. It enables timing
and stress testing as part of the BIST operation because it can launch a read/write
operation on each active clock edge.
stage1
stage2
Compare Capture
FAIL
stage1
S C D A
O A D
M N T D
T A R
R E
O S
L S
MEMORY
LOGIC
LOGIC
Since there is data latency in memory BIST controllers, the BIST controller must
be pipelined to enable full-speed read/write operation. The pipeline is used to
temporally separate the needed action at each cycle of read/write operations. With
pipelining, you can model the memory as only taking one clock cycle and then use
the pipelining to tear the comparison out of the first cycle and the capture of the
comparison result, which happens at the end of the pipeline.
CLO CK
W RIT E WRITE 1
The slide shows the pipelined design for full-speed memory BIST operation.
A 3-stage pipeline can be used to compress the three cycle read operation into
single cycle read. In this case, the first stage does the read setupwhich may
include read address change, read enable activation, and output enable activation.
The second stage activates the read clock and provides the reference data for read
data output comparison. The third stage captures the comparison result. Inside the
BIST controllers, all signals needed for read operation are generated at the rising
edge of the same clock. The following pipelines are also needed:
In addition, a 2-state pipeline can compress the two cycle write operation shown
earlier, into a single cycle write. The first stage does the write setup which may
include write address change, write data change, and write enable activation. The
second stage activates the write clock. Similarly, inside the BIST controllers, all
signals needed for write operation are generated at the rising edge of the same
clock. Here, only the memory clock needs to be delayed one cycle to achieve full-
speed operation. As explained earlier, a memory clock is repeated every cycle, the
pipeline register to create one-cycle memory clock delay is not needed.
As part of this module, you can perform a Full-Speed exercise to see the results of
full-speed testing. See Running BIST at Full-Speed on page 3-61.
The -Sequential contiguous switch causes the controller to apply all the test
algorithms to all the ports of a memory before proceeding to the next memory
(this is the system default). Using the -Sequential interleaved switch instructs the
MBISTArchitect tool to interleave algorithm steps between memories.
Since the controller tests the memories independently of one another during
sequential memory testing, the memorys read/write cycles need no longer be
compatible. However, the current MBISTArchitect implementation of sequential
memory test does not have this capability.
Additionally, you can generate individual fail flags for multiple memories by
using the Setup Memory Test and Setup Comparator Failflag commands as
follows:
setup memory test -sequential
setup comparator failflag -separate
This specifies separate fail flags for multiple memory tests. This is especially
useful in identifying which memory has failed when you specify the sequential
memory test option (-Sequential). The default is Common; output a single fail bit
regardless of the number of memories.
Adding Diagnostics
Adding Diagnostics
Extracts failing data for fault diagnosis process
MBISTArchitect can give the BIST controller the ability to download the failing
data on every occurrence of a miscompare. And, the failing data can be scanned
out with a minimal impact on silicon area and routing overhead. You can switch
on a diagnostic clock and a diagnostic clock pin named diag_clock is added to the
controller pin list. The diag_clock pin is toggled at half BIST clock during the test
bench. The BIST controller operates in one of two modes controlled by debugz.
The modes and operation of the fail_h and scan_out ports is as follows:
In order to synthesize the diagnostic functionality into the BIST controller, the
following conditions must be met.
You can also set a slow clock to scan out diagnostic data. The cycle time of the
diagnostic clock is two times slower than a BIST clock with a default of 200ns.
Use the Setup Diagnostic Clock -Diag_clock command in conjunction with the
Setup Controller Naming -Diag_clk diag_clk command to set up a diagnostic
clock.
setup diagnostic clock diag_clock
setup controller naming -diag_clk diag_clk
Clock Synchronization
There are two clock domains for the diagnostic process in the Memory BIST
controller. One clock controls the diagnostic clock domain that scans out
diagnostic data to the Automatic Test Equipment (ATE). This clock domain is
usually relatively slow. A second clock domain is run by the bist clock that
operates everything except the diagnostic data scan-out and operates at a faster
clock speed. In default operation, MBISTArchitect operates with these clocks in a
non-synchronized relationship. When you turn synchronization on, these clocks
become synchronized by passing information between the domains. For more
information, see the Synchronization between BIST Clock and Diagnostic
Clock section in Chapter 3 of the Built-In-Self-Test Process Guide.
However, a comparator has the capability of stopping on the first fail or in the case
of debug mode, stopping on every failure and scanning out the data. These
features result in good diagnostic capability by providing precise information
about failure location.
Since the contents of a ROM are predetermined and cannot be changed by the
BIST controller, the expected reference data for a comparator would have to be
provided through the duplication of ROM contents. In general, this results in a
large area overhead and is unacceptable. Thus, using a compressor for analyzing
the ROMs output response is the only viable alternative.
Use Setup MBist Compressor -scan to scan out the final signature and compare
it with the tester. Use Setup MBist Compressor -localcomparator to generate a
signature comparator in the memory BIST collar (locally).
sys_address n
1 n
test_address n 0 ROM
BIST Memory
Controller
test_read_enable 1 m
data_out
read_enabl e 0
test_h
m
rst_l
cl k sys_clk
test_capture 0
1
mi sr_data_out
fail_h l
tclk MISR
trst_l m isr_scan_out
tst_done
si
m isr_hold-l
se
For example, the following set of commands generates the compressor shown:
shell> $MGC_HOME/bin/mbistarchitect -library dft.lib
Pattern Generator
Algorithm-Based
0
Register
Register
sys_ wen
test_di
rst_ l 1 Mem ory
n do
clk M o del
m addr
hold_ l
ctl*
te st_h clk
tst_d one
ct l* = might in clud e m
w en, ce n, or oen
O u tp u t
P ipeline Register s
In some designs, pipeline registers are inserted along the address/data lines to
synchronize the data flow activity between the memory and a system-level device.
MBISTArchitect can model this pre-determined pipeline delay by allowing you to
insert pipeline registers into the generated connection model.
The Setup Controller Pipeline command specifies the controller pipeline register
settings, the number of pipeline registers to be placed between the controller and
the memory, the position of the comparator in the pipeline, and the number of
pipeline delay stages to be placed between memory and the comparator. For
different configurations you can also specify the respective pipeline stages for the
memory address input, data input, control input, and/or output pipelines. Refer to
the Setup Controller Pipeline command section of the MBISTArchitect
Reference Manual for information on specific switches.
Pipelining is useful for several situations, such as when timing is critical or when
you want to control where MBISTArchitect samples and compares the data. With
this command and its options, you can manage time delays and meet timing
constraints. By specifying the comparators position, you can control from which
pipeline stage you want to take data for comparison.
The -Control switch specifies that the memory clock should be gated. The default
is -System. When the -Control switch is used, the test mode clock is connected to
the clock control signals created by the BIST controller.
The -Test Noinvert switch lets you specify whether the controller is synchronous
with the rising edge or falling edge (inverted) of the clock. The default is to not
invert.
Allows high fault coverage for scan and logic BIST designs
with embedded memories
bis t_ co n
ra m 4X 4 _ b lo ck
a0
a1
d i0 M em o ry d o0 do 0
BIST d i1 M o d el d o1 do 1
Co n tro lle r d i2 (ra m 4 X4 ) d o2 do 2
d i3 d o3 do 3
wen
ra m 4X 4 _ by pa ss
b p_ c lk N o n -S c an C on tr ol
te st_ m o de ce lls MUX s
Where:
You can direct MBISTArchitect to configure scan logic to bypass the memory
during scan mode. This is done by XORing all the address lines and all the data
input lines to generate a specified number of compressed signals. Each of these
compressed signals are captured in scan or non-scan cells. These cells are clocked
using a new signal line named bp_clk. If you choose to specify scan cells,
MBISTArchitect generates three additional signal lines: scan_enable, scan_in,
and scan_out.
The default -Control option is provided to multiplex the scan/non-scan cell output
to the memory data output. This is helpful in testing logic on the output side of the
memory during scan test. MBISTArchitect inserts one multiplexer for each data
output. It connects one input of the multiplexer to memory data output and the
other input to the newly inserted scan/non-scan cells. The multiplexer is
controlled by the test_mode signal.
The bypass logic created by this command is placed in a hierarchical block called
memory_name_bypass. Also, a new level of hierarchy called
memory_name_block is created if it doesnt already exist. This
memory_name_block is created or modified to contain both the memory and the
memory_name_bypass blocks. The description of the memory_name_bypass and
memory_name_block are in the same file as the BIST Controller.
To help with testing the logic that surrounds your memory design,
MBISTArchitect allows you to add memory bypass circuitry using the Set Scan
Logic command. This bypass circuitry compresses the address and data input lines
through XOR logic and either scan or non-scan cells into a specified number of
output signals. By using the commands default -Control switch, these output
signals are multiplexed with the memory data output lines. The multiplexers are
controlled by test_mode. When test_mode is asserted high for testing the
surrounding logic, the memory is bypassed and the compressed address and data
input signals are presented to the data output lines. This allows you control over
the downstream logic during testing.
MBISTArchitect can write a basic synthesis script, targeted for Synopsys Design
Compiler tools.You can use this script as a template for synthesizing and
optimizing the BIST models MBISTArchitect produces.
While you can change the models name using Setup File Naming, by default
MBISTArchitect names this model <design>_dcscript (for Synopsys Design
Compiler).
The Design Compiler can save the BIST controller and BIST block in a single file
for Verilog. For VHDL, the BIST controller and BIST block can be saved to
separate files.
/* ----------------------------------------------------------
// File Type: Logic Synthesis Script File
// Date Created: Wed Feb 6 21:02:00 2002
// Tool Version: v8.9_6.02 Wed Feb 6 15:31:55 PST 2002
// ----------------------------------------------------------
*/
sh mkdir work
define_design_lib work -path "./work"
read -format verilog top_after.v
current_design cti_sab
uniquify
compile
write -format verilog -hierarchy -output "cti_sab_gate.v"
current_design ram4x4_multi_bist
uniquify
compile
write -format verilog -hierarchy -output
"ram4x4_multi_bist_gate.v"
current_design ram4x4_multi_bist_ram4x4_block_0
uniquify
compile
write -format verilog -hierarchy -output
"ram4x4_multi_bist_ram4x4_block_0_gate.v"
current_design ram4x4_multi_bist_ram4x4_block_1
uniquify
compile
write -format verilog -hierarchy -output
"ram4x4_multi_bist_ram4x4_block_1_gate.v"
current_design ram4x4_multi_bist_ram4x4_block_2
uniquify
compile
write -format verilog -hierarchy -output
"ram4x4_multi_bist_ram4x4_block_2_gate.v"
exit
E xam ple:
Cl ock _P er io d=1 00
c re ate _c lo ck -pe ri od CL OC K_ PER IO D RC LK
s et d ont _t ou ch _ne tw or k R CL K
c re at e_c lo ck -p eri od C LOC K_ PE RIO D BI ST _CL K
s et d ont _t ou ch _ne tw or k B IS T_ CLK
The MBISTArchitect Design Compiler script has been modified to let you define
clock constraints. This script uses the currently defined clock width and add clock
constraints for the BIST controller clock and any other memory model defined
clock signals, where clock gating is disabled.
capture and write the output values of the memory itself. You specify this
information using the Setup Mbist Patterns command.
While you can change the models name using Setup File Naming, by default
MBISTArchitect names this output <design>_bist.pat.
sys_address n
0 n
test_address n 1
BIST Memory
Controller
test_h sys_data_in m
0 m
test_data_in m
rst_l 1
cl k test_wri te_enable
0
sys_w rite_enable
1
sys_clk
data_out
m
tst_done
fai l_h
Library Enhancement
A BIST-mode signal is used to select either BIST signals or system signals. This
signal is necessary and is used as follows:.
Exercise 3: Changing the BIST AlgorithmIn this exercise, you will generate a
new memory BIST collar that uses the March 1 rather than the default March 2
algorithm to reduce test time.
Exercise 4: Changing the Data BackgroundIn this exercise, you will improve
the test coverage of the March 1 BIST Controller by adding three different data
pattern backgrounds.
Exercise 5: Inserting BIST for Multiple Memories In this exercise, you will
save area and overhead by sharing a BIST controller for multiple memories.
Exercise 6: Adding BIST with a Compressor In this exercise, you will add a
Compressor instead of a Comparator. A Compressor may be used to improve
area-overhead or optimize routing.
Exercise 7: Running BIST at Full-SpeedIn this exercise, you run BIST at full-
speed meaning it will run at the system clock speed to test the memory at the full
speed at which the system will run.
Exercise 8: Adding BIST for Bidirectional MemoriesIn this exercise, you add
BIST for bidirectional memories.
Exercise 9: Adding BIST for ROMsIn this exercise, you add BIST for ROMs.
A ROM requires the use of a compressor.
Selecting one or more algorithms for your BIST design depends on the type of
memory you are testing, your test goals, your overall test strategy, and the advice
you may receive from in-house memory-test experts and ASIC vendors.
In this exercise, you will direct MBISTArchitect to use the March 1 algorithm
when you generate a BIST collar for the ram4x4 memory. Remember that you can
add new algorithms as well as change algorithms. You will gain experience
adding algorithms in later exercises.
Do the following:
3. Add the ram4x4 model to the list of memory models for BIST insertion.
4. Select the Controller block to access the Setup Mbist Controller dialog
box.
5. Select the Test Algorithms tab, select March 1, then click OK.
7. Save the default outputs by clicking Save BIST. After verifying the format
and destination directory, click OK.
Click No in the Question dialog box, then Cancel the Save Bist Results
dialog box.
In Exercise 1, you saved outputs with the same default filenames. Instead of
replacing these files, you can give them custom names.
8. Click on the Output Files Names button in the Control Panel Window. In
the Setup Output File Naming dialog box, change the filenames to the
following, then click OK:
The System command lets you issue an operating system command. The ls
command shows the contents of the working directory. You should see:
b. Compile the memory simulation model, all BIST models, and the
testbench.
d. Run a little more to capture the complete pattern for the tst_done signal.
VSIM 4> run 50
This exercise repeats the steps you performed in the last exercisewith one
exception. In this exercise, instead of having the March 2 test write words of 0s
and 1s, you will tell MBISTArchitect to create a March2 pattern generator that
uses 1010, 0010, and 0100 as the data backgrounds.
2. Invoke MBISTArchitect.
3. Load the ram4x4.atpg library from the ../design directory, (but do not add
the model to the memory list).
4. Add the ram4x4 model to the list of memory models for BIST insertion.
MBISTA> add me m ram4x4
10. Compile the outputs and simulate the testbench. Create a new work
directory called work_m2db for the compilation and simulation results.
You can use the ../design/vsim_setup_db.do file to setup the simulation.
Name the trace file trace.log.m2db. If you need assistance with this
process, refer back to Exercise 2: Verifying the BIST Circuitry.
11. Observe from the List Window that the background patterns you specified
are written to and read from the memory.
Now that you have become more acquainted with the GUI features, you will be
able to utilize the command line to take advantage of minimum typing and other
features.
1. Change directories.
shell> cd $MBISTNWP/mbist2/multi_ram_dwp/results
This is where you will do your work and save your results.
2. Invoke MBISTArchitect.
shell> mbistarchitect
3. Load the appropriate libraries (you can load only one library at a time):
MBISTA>load library ../design/ram4x4.atpg
MBISTA>loa li ../design/ram8x4.atpg
4. Add both the ram4x4 and ram8x4 models to the list of memory models for
BIST insertion:
MBISTA> add me m ram4x4 ram8x4
Note that when you generate a BIST controller for multiple memories,
MBISTArchitect names the saved outputs <first_memory>_multi_bist.vhd,
<first_memory>_multi_bist_con.vhd, and <first_memory>_multi_tb.vhd,
by default. In this case, you added ram4x4 first with the Add Memory
Models command, so ram4x4 becomes the prefix for each saved file.
8. Examine the generated outputs using the View Saved Design Files button
in the Control Panel window.
b. Compile the core logic, all BIST models, and the testbench.
You use vlog for compiling Verilog (the original memory models)
and vcom for compiling VHDL (the MBISTArchitect-generated
Note outputs). In this exercise, you perform mixed Verilog/VHDL
simulation using ModelSim after compiling the models.
d. Run a little more to capture the complete pattern for the tst_done signal.
VSIM 3> run 50
The BIST controller runs testing on the RAM4x4 and RAM8x4 memories in
parallel, first running the March 2 algorithm on port 1 of each memory, followed
by running the Unique Address algorithm on port 2 of RAM8x4.
The Unique Address algorithm places the address value in the address
location. For example, the algorithm places address value 0000 in location
0, address value 0001 in location 1, address value 0010 in location 2, and so
on. If the address and data widths do not match, the algorithm concatenates
the MSB values of the address and places them as the LSB of the data word,
to pad the data word to the appropriate size.
In this exercise, the address bus has three bits while the data width has four.
So the algorithm pads the data word by duplicating the most significant
address bit as the least significant data word bit to increase the word size to
four bits. For example, in this case the algorithm places the value 0000 at
location 0, 0010 at location 1, 0100 at location 2,..., 1011 at location 5, and
so on. Note that you see the data values in reverse bit order (LSB->MSB)
during simulation.
Table 3-1 provides a breakdown of the testbench simulation, and thus, the
memory BIST controller operation.
This exercise demonstrates how to generate BIST circuitry that uses a compressor
instead of a comparator. Since you have invoked MBISTArchitect and generated
BIST circuitry several times in previous exercises, this exercise does not provide
as much detail as the previous exercises. If you need assistance, refer to
Exercise 1: Creating a Basic Memory BIST Collar.
This exercise again uses the RAM4x4 modelfor the sake of both simplicity and
comparison to the architectures generated by earlier exercises.
3. Add the ram4x4 model to the list of memory models for BIST insertion.
4. Specify that the BIST controller should not include a comparator in the
architecture.
MBISTA> setup observation scheme -compress
8. Save the default outputs, with the customized names, in Verilog format.
MBISTA> save bist -r
10. Reset the state of MBISTArchitect and make some changes within the
session.
Assume you examined the files and decided you want to implement a
hold_l signal. This signal lets you pause BIST testing with a low value on
the hold_l signal, retaining the state of the BIST test process. When the
hold_l signal returns to a high state, the BIST test continues. The hold_l
signal, among other purposes, enables you to perform data retention testing.
If you pause testing between a write and a read, the read performed after
testing should display the expected values from the write operation. If not,
the memory could have a data retention problem.
13. Compile the outputs and run the simulation using the following script.
Verify that the final signature is 8482e23a.
shell> runsim
15. If you have time, and want to explore more of the available algorithms for
the compressor architecture, repeat this exercise specifying one of the other
algorithmssuch as Diagonal or Checkerboardinstead of the default
March 2 algorithm.
shell> cd $MBISTNWP/full_speed/design
shell> ls -ltr *
4. Invoke MBISTArchitect:
shell> mbistarchitect
5. Click on the Memory block in the Control Panel graphic pane. This will
start the process to load the Full speed memory model.
d. Click OK.
Now you can modify the specific settings to enable the generation of
the FULL SPEED memory BIST controller.You should now see the
Setup Mbist Controller panel.
a. Select the Controller Options tab at the top right of the Setup MBIST
Controller panel.
b. Make sure that the System Clock is selected in the Type of Memory
Clock.
c. Select the Setup Pipelining... button at the bottom left of the Setup
MBIST Controller panel.
You should now see the Setup Pipeline Staging panel come up.
7. Click Run in the Control Panel. This will generate the BIST circuitry.
8. Click Save BIST and click OK. This will generate the BIST circuitry and
add to the BIST model.
Next, look at the files you just generated. You should see three new
files.(Full_speed_bist.v, Full_speed_bist_con.v, Full_speed_tb.v). Look at
the *_bist.v file and try to identify the new pipeline registers.
10. What makes the memory model different in AT Speed vs. FULL Speed?
Look at the memory models and compare them.
shell> cd $MBISTNWP/mbist/full_speed/design
b. Use your text editor to chose and view the library file.
shell> vi lab13.atpg
You will see two RAM model definitions in this library file. The first is
called At_speed and the second is called Full_speed.
Try and identify all the differences between these two models.
11. Next, we will verify the BIST logic works properly. Use the BIST
Controller you just generated with the Verilog model of the memory and
resimulate to see if everything works.
shell> cd $MBISTNWP/mbist/full_speed/results
shell> runsim
b. A window displays with the message Are you sure you want to
finish? Click No.
Separated by time cursors are 3 cycles of interest for the first back-to-
back RWR operation for address 0.
Extra Credit
To do additional speed comparisons go through steps 1 - 11 again but
this time select the At_speed model in steps 5b and 5c. Skip step 6.
Compare the verilog of the *_bist.v files. What are the differences and
why?
Compare the Verilog expected data and the number of cycles in the 2
testbench file. What are the differences and why?
Lab Summary
You should now be able to take a memory that can perform back-to-back
read/write cycle and generate a memory BIST circuit to do Full Speed testing of
that memory.
This exercise demonstrates BIST insertion for a RAM with a bidirectional data
bus. In this exercise, you will duplicate the default run you performed in another
exercise, then examine the generated outputs to understand the circuitry that
MBISTArchitect creates.
4. Invoke MBISTArchitect.
6. Add the bram4x4 model to the list of memory models for BIST insertion.
10. Compile the outputs and the memory model (../designs/bram4x4.v) then
simulate the testbench. Create a new work directory called work for the
compilation and simulation results. You can use the ../design/vsim_setup.do
file to setup the simulation and format the transcript. Name the trace file
trace.log. If you need assistance with this process, refer back to
Exercise 2: Verifying the BIST Circuitry.
In this exercise, you will use a dofile to add BIST circuitry to test a ROM. This
exercise uses a ROM64x16 model.
This dofile sets up for ROM BIST circuitry generation, runs the insertion,
and saves the default outputs with the default names to the current
directory.
rom64x16_bist.v rom64x16_bist_con.v
Compressor_lib.v rom64x16_tb.v
5. Run the simulation using the following script and examine the results.
shell> runsim
This module will give you a basic understanding of how to create, connect, and
integrate BIST structures using the Memory BIST-In-Place tool. The lab exercises
at the end of this module will give you experience in running through the process
flow of Memory BIST-In-Place.
Objectives
Upon completion of this module, you will be able to:
MBIST Controller
CTDL for MBIST BIST collars
CORE INTEGRATOR
Controllers (Library models)
SoC Netlist
RTL Synthesis
Phase
Test Access
Description
Logic Synthesis
Gate-Level
Netlist, Library
INTEGRATION PHASE
MBIST Vectors
(WGL)
DRC
MBIST Vector
Translation
SoC MBIST
Patterns (WGL
or Verilog)
4-2 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
pattern translation
The BIST controllers and memory collars are generated from the standalone
Mentor Graphics Memory BIST tool, MBISTArchitect.
Integrate BIST
DRC and Pattern Conversion
Patterns
input: Gate level Verilog design, ATPG library,
CTDF, CTAF
Gate-Level
output: Design level pattern (WGL/Verilog)
Simulation
4-3 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
RTL Simulation
Run the Mentor Graphics ModelSim tool to simulate the design. You can
also run a gate-level simulation later in the process.
Synthesis
Run the bisted design through a synthesis tool.
Gate-Level Simulation
Run the Mentor Graphics ModelSim tool to simulate the design.
Uses MBISTArchitect
Requires Memory BIST models for input
Creates RTL BIST models
BIST controller
BIST collar
4-4 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
Model Creation
Creating BIST Structures
Model Creation
4-5 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
NOTES:
4-7 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-8 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-9 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
endspecify
4-10 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
Timeplate definition
timeplate TP0 period 400ns
4-11 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
vector(+, TP0) := [ 1 1 1 X X ];
vector(+, TP0) := [ 1 1 0 X X ];
BIST Initialization
Pattern
loop 450
vector(+, TP0) := [ 1 1 1 0 0 ];
end
loop 16
vector(+, TP0) := [ 1 1 1 X 0 ]; BIST Test Pattern
end
vector(+, TP0) := [ 1 1 1 1 0 ];
end
end
4-12 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
end;
4 -13 M e m ory B IS T T ra inin g W o rkbo ok: M B IS T In-P la ce C op yrigh t 20 02 M e ntor G ra ph ics C orpo ra tion
NOTES:
NOTES:
NOTES:
C o n n e c tin g B IS T S tru c tu re s
U s e s M e m o ry B IS T -In -P la c e S y n th e s is m o d e
R e q u ire s
R T L o r g ate -lev e l d e s ig n (V H D L o r V e rilo g )
V H D L o r V e rilo g lib ra ry
B IS T d e sig n o b je c ts c rea te d e a rlie r in flo w
C T D F c rea te d e a rlie r in flo w
In s e rts /c o n n e c ts B IS T s tru c tu re s w ith in h ie ra rc h y a n d to
c h ip -le v e l I/O
4-1 6 M em ory B IS T T raining W o rkb ook: M B IS T In-P la ce C op yrig ht 2 002 M en to r G raph ics C o rporatio n
NOTES:
4-17 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-18 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-19 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
Run
in s e rt a c c e s s lo g ic
W rite o u t R T L a c c e s s lo g ic a n d p h a s e d e c o d e r
s a v e d e s ig n file _ n a m e -re p la c e
W rite o u t C T A F file
s a v e c o re a c c e s s file _ n a m e -re p la c e
W rite d riv e r file s fo r D e s ig n C o m p ile r a n d M e m o ry B IS T -In -
P la c e in te g ra tio n m o d e
s a v e d riv e r file s -lo g ic _ s y n th e s is file _ n a m e -in te g ra tio n
file _ n a m e
E x it
e x it
NOTES:
4-21 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-22 Memory BIST Training W orkbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-23 M em o ry B IS T T rainin g W o rkboo k: M B IS T In-P la ce C opyright 2 002 M e nto r G raphics C orp oration
NOTES:
NOTES:
4-25 M emory BIST Training W orkbook: M BIST In-Place Copyright 2002 M entor G raphics Corporation
NOTES:
4-26 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-27 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-28 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-29 Memory BIST Training Workbook: M BIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-30 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
Verification
RTL Simulation
You can run simulation to
verify at two different points Connect BIST
in BIST-in-Place flow Structures
After BIST creation
After pattern integration
Labs cover verification Synthesis
Integrate BIST
Patterns
Gate-Level
Simulation
4-31 Memory BIST Training W orkbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
I/O Pads
Issues/Caveats
I/O Pads
Designs with I/O pads attributes need to be added in Verilog
library
4-32 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
Memory collar
Design U1 Bypass block
Bp_clk
Port1
Port2 Test_mode
U2
4-33 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
4-34 Memory BIST Training Workbook: MBIST In-Place Copyright 2002 Mentor Graphics Corporation
NOTES:
Exercise 12: Translating BIST Patterns to the SoC Level As the final step in
the Memory BIST-In-Place process flow, you will translate the BIST patterns to
the chip-level.
Exercise 13: Full Flow Exercise You will run through the entire process again
using a different design. To make things faster, you will run through various
scripts which take you through the process.
Now that you are familiar with the MBISTArchitect GUI and its command line
interface, we will invoke MBISTArchitect through Memory BIST-In-Place. The
Memory BIST-In-Place GUI provides a task flow manager that makes creating
BIST structures easier. For every command that the flow guide executes, do the
following:
The BIST Structures Creating Flow Guide opens to the first step.
4. Load the mbist.lib design library. Click Click Here to Set Up... to set up
the Load Libraries information. In the new window, select the mbist.lib
library and click Load. Close this window.
5. Click Next >>> to move to the Add Memories step, then set up the Add
Memories information as shown. You will be adding one 8x4 RAM and
three 4x4 RAMs for BIST insertion. This shares multiple RAMs with one
BIST controller.
1. Select
2. Click
3. Select
4. Click 3 times
5. Click
6. Continue to the next step in the flow guide. Since you will be using the
default algorithm setting, there is no need to set up any information for this
step.
7. Continue to the next step in the flow guide. You are now at the Specify
Controller Options step. For this exercise, you will create multiplexers
outside of the controller, in the BIST collar block, and create the necessary
output files for use with Memory BIST-In-Place.
1. Select
2. Deselect
3. Click
8. From this point on, you will want to use the default settings. Click
Next >>> until you get to the Generate BIST Logic step.
10. Click Next >>> until you get to the Save Results step. Set this up to
generate BIST-In-Place files, then click OK.
12. From the MBISTArchitect command line window, list the generated
outputs.
MBISTA> system ls ram8x4*
16. Compile the model outputs and simulate the testbench to verify the BIST
structure using the given script.
shell> runmsim
Memory BIST-In-Place has two modes upon which you can invoke the
tool: synthesis and integration. Here we invoked in synthesis mode in order
to replace a RAM with the BISTed RAM generated in the previous
exercise. This mode also creates access logic to a BIST controller and a
connection to an SoC. All outputs in this mode are at the RTL level.
The -lverilog switch specifies the Verilog RAM library used in the design
file.
4. Schedule the insertion of the BIST controller into the SoC design. Actual
insertion does not take place until you transition the tool into the Synthesis
mode.
SETUP> add mbist controller core_b/mbistc ram8x4_multi_bist \
mem_a -c ram8x4_multi_bist_ram8x4_block_0 \
core_b/mem_b -c ram8x4_multi_bist_ram4x4_block_1 \
core_c/mem_c -c ram8x4_multi_bist_ram4x4_block_2 \
core_c/core_e/mem_d -c ram8x4_multi_bist_ram4x4_block_3
You can also run the add_mbist.do dofile to keep from having to type the
whole thing.
This file contains information on how to test and isolate a BIST controller.
The Insert Access Logic command initiates all the actions specified during
the setup mode. These include:
a. Save the RTL level access logic to core1_rtl.v and modified SoC netlist
to BIP_cti.v
BISTINPLACE> save design core1_rtl.v -all -replace
b. Save the CTAF file which includes information on how to access the
BIST controller from the SoC level.
BISTINPLACE> save access file core1_rtl.access -replace
10. At this point, you will synthesize the RTL design using a logic synthesis
tool such as Design Compiler. Since we cannot run Design Compiler here,
examine the runDC and dc.do scripts provided in this directory.
After defining the designs clocks (clock=clkp and reset=rstp), you set the
system mode to cti or integration mode. This initiates a set of design rules
checks. Then you tell the tool to translate all patterns (Note: If you have
multiple memories and/or multiple controllers, you could translate patterns
for only a subset of these), and then run, which creates chip-level vectors to
control the BIST operation. You then save patterns in both Verilog (for
simulation/verification) and WGL (for test program) formats.
4. Scroll back through the transcript to see the results of the steps described
previously.
Answer No to the question about finishing. You should see the comment
No error between simulated and expected patterns.
2. Invoke MBISTArchitect.
The next step is to Add Memories. This means you are choosing the
memory models you want to BIST from the library that you just loaded.
Select picdram from Available Models and click >> Add >>. You should
see this model description listed under Added Models. If you click on
picdram, you can view model information in the Model Information area.
4. Specify algorithms.
Click on the line between the Controller and RAM blocks in the Control
Panel. Here you can see the list of all available algorithms the tool supports.
The March2 algorithm, which is the default (shown on the Controller
block), is the algorithm well be using in this lab. It is already selected by
default, so you can just Cancel out of this dialog.
In this case, we want to put multiplexors under the Memory collar block (as
opposed to putting them in the controller block), since there is only one
memory being BISTed. Therefore, unselect the option to create a
configuration that has Multiplexors Located Inside Controller.
We also want to turn clock gating off so make sure you unselect the option
Clock Gating (the system clock is used for the memory).
Also, we want to insert BIST-in-place in the design, so check the option for
BIST-in-Place information. Click OK when you are finished.
We are now ready to perform a Memory BIST generation. You need only
click the Run button to generate the BIST logic. Notice how the
compressor block disappears from the Control Panel. That is because we
did not choose to use a compressor, but instead are using a comparator to
determine whether the memory passes the BIST process.
The last step is to save all results. Click on the Save BIST button. When
the Save BIST Results dialog appears, check all the boxes to select all the
options. Then click OK.
The tool writes out a total of six files, which you can see in the transcript
area:
You have just created BIST structures for your memory model - so you now
have a BISTed memory. In other words, you have a memory model with
a BIST collar, a BIST controller to control the BIST operation for this
memory, as well as other files (testbench, core test definition, DC synthesis
script, and WGL pattern file) that will be used downstream.
You are now ready to insert these BIST structures into the chip-level
design. For this process we will run a series of scripts.
You are now going to run a simulation of the RTL BIST model you created.
To do this, execute the following command:
shell> runsim1
This script compiles the BIST design objects and runs the generated
testbench on the model.
Notice the march2 algorithm as its shown in the Wave window. Expand the
Wave window. You can Zoom > Zoom Full to see the whole BIST
process, or zoom into various parts by clicking your middle mouse button
and drawing a box around a particular area. You may also need to expand
the leftmost area where the signals are displayed to see their full names.
Basically what you are seeing is the test clock (clk), the reset signal (rst_l),
the test signal (test_h), the test_done signal (tst_done), the fail flag (fail_h),
followed by the clock, address, we, din, and dout of the memory model.
Notice the read/write operations and the address incrementing up and down
the address space, as occurs during the march test. The tst_done signal goes
high when the BIST operation completes.
Use File > Quit from the ModelSim EE window to close Modelsim, and
this time enter Yes, that you want to quit.
The next step is to insert the BISTed memory and controller into the design.
We will do this via a script that runs the Memory BIST-in-Place tool in
synthesis mode. The end result is that we will have an RTL design that
includes the inserted memory model with BIST collar, BIST controller,
access logic, phase decoder, and all the appropriate connections. To
perform this operation, execute the following command:
shell> runsyn
The design file (mbip_rtl.v) now needs to undergo synthesis, as the next
phase of BIST-in-place, integration mode, requires a gate-level design.
Integration mode also uses the access file (mbip.access) as described in the
next step.
In a normal design flow, you would synthesize the RTL design created
during BIST-in-Place synthesis (mbip_rtl.v) to gates. However, due to time
constraints, we will use a design that has already been synthesized.
Therefore, the final step is to perform rules checking on the gate-level
design to ensure safe testing when the access path is sensitized and then
create chip-level patterns to initiate the memory BIST operation. This is all
done in the integration phase of BIST-in-Place.
To view the steps the tool will perform, view the integration script, runint.
It should look as follows:
After defining the designs clocks (clock=ramclk1 and reset=clk2), you set
the system mode to cti or integration mode. This initiates a set of design
rules checks. Then you tell the tool to translate all patterns (Note: If you
have multiple memories and/or multiple controllers, you could translate
patterns for only a subset of these), and then run, which creates chip-level
vectors to control the BIST operation. You then save patterns in both
Verilog (for simulation/verification) and WGL (for test program) formats.
You should see the comment No error between simulated and expected
patterns.
This module gives you a basic understanding of how to create, load and verify
MBISTArchitect memory models. The lab exercises at the end of this module also
give you experience creating, verifying and troubleshooting a variety of memory
model types.
Objectives
Upon completion of this module, you will be able to:
A Memory Model:
A M em ory M odel:
Is an abstract data m odel that defines the m em ory ports and
the read/w rite protocol of each port
Is the only design input to M BISTArchitect
Is not a sim ulation m odel
3-2 M BISTArchitect: Com m on BIST Variations Copyright 2002 M entor Graphics C orporation
The MBISTArchitect tool uses an abstract data model that defines the memory
ports and read/write protocol of each port. This model adds its own constructs to
support BIST insertion. The memory model is the only input to MBISTArchitect.
See the next slide for an example of a memory model and a description of memory
model syntax.
You can add or change memory models using the Memory Model Editor in the
MBISTArchitect Control Panel. See Memory Model Editor on page 5-4 for a
sample of the Memory Model Editor.
model model_name(list_of_pins)(
bist_definition (
address <name> (list_of_pins);
data_in <name> (list_of_pins);
data_out <name> (list_of_pins);
data_inout <name> (list_of_pins);
clock <pin> <active_state>;
write_enable <pin> <active_state>;
read_enable <pin> <active_state>;
In p u t/O u tp u t D e fin itio n s
output_enable <pin> <active_state>;
chip_enable <pin> <active_state>;
control <pin> <active_state>;
dont_touch <name> <active_state> <dir>;
tech = <tech_name>;
vendor = <vendor_name>;
version = number; M e m o ry Id e n tific a tio n
message = message_text;
address_size = <number>;
min_address = <lowest address>;
max_address = <highest address>;
data_size = <data_bus_bits>;
M e m o ry S iz e In fo rm a tio n
addr_inc = <number>
write_port (
write_cycle ( ... ))
read_port ( R e a d a n d W rite C y c le s
read_cycle ( ... ))
) // end bist_definition
) // end model description
The MBISTArchitect tool shares the library format used by the DFT/ATPG tools
FastScan, FlexTest, and DFTAdvisor. You need only to add the special
bist_definition section if you have an existing memory model in the DFT library
format. MBISTArchitect does not use the gate-level simulation primitive
information found in the primitive construct. The other DFT/ATPG tools use this
information, but MBISTArchitect simply ignores it.
The term pin in this context refers to the individual inputs and outputs of the
memory at the cell boundary. A pin can be defined as a scalar bit or an array. An
array represents a bus and is sometimes referred to as a wide pin. The pin name
must exactly match the port names specified in the associated Verilog or VHDL
simulation model (both in name and case).
See Loading Library Files and Models on page 5-5 for instructions on how to
load the library file, add a memory model, and run MBISTArchitect to generate
memory BIST logic.
3-4 MBISTArchitect: Common BIST Variations Copyright 2002 Mentor Graphics Corporation
You can add or change memory models using the Memory Model Editor in the
MBISTArchitect Control Panel. For more information on how to use the Memory
Model Editor, refer to Using the Memory Model Editor in Chapter 3 of the
MBISTArchitect Reference Manual.
3-5 MBISTArchitect: Common BIST Variations Copyright 2002 Mentor Graphics Corporation
Follow these steps to invoke, set up, and run the MBISTArchitect tool using the
minimum set of commands needed to generate memory BIST logic.
1. Invoke MBISTArchitect.
shell> $MGC_HOME/bin/mbistarchitect
2. Load a Library.
After tool invocation, you must load a DFT library that contains the
memory model(s) for which to add BIST logic. To load a DFT library
interactively during the session, enter:
MBISTA> load library dft.lib
Where dft.lib is the name of the library. You can also load a library at
invocation by using the -Lib switch.
The next step is to add a memory model from the loaded library to the BIST
configuration. For example:
MBISTA> add memory models ram4x4
Where ram4x4 is the name of the memory model for which you want to add
BIST logic.
4. Run MBISTArchitect.
After you have loaded a library and added a memory model, you can run
MBISTArchitect to generate default BIST logic:
MBISTA> run
Defining Inputs/Outputs
D e f in in g In p u t s /O u t p u t s
Address A d d res s b u s
data_in D a t a in p u t b u s
data_out D a ta o u tp u t b u s
data_inout D a t a b u s ( b id ir e c t io n a l)
Clock M e m o r y c lo c k ( s )
write_enable C o n t r o l s ig n a ls
read_enable
output_enable
chip_enable
control A d d it io n a l c o n t r o l s ig n a ls if r e s e r v e d
k e y w o r d s in s u f f ic ie n t
dont_touch P in s t h a t a r e n o t c o n t r o lle d o r
o b s e r v e d b y t h e B IS T c o n t r o lle r
Defining Buses You should define the address and data buses in the same manner
as the simulation model for the memory. If a bus in your simulation model is
declared as an array, then declare the same bus in your memory model header as
an array. Consider the following memory model header segment:
When MBISTArchitect reads this model, it assumes the address and data ports on
the HDL model are declared as arrays and will use the STD_LOGIC_VECTOR as
the data type when generating the matching bus in the BIST controller. You can
change the signal type to STD_CLOGIC_VECTOR to specify it at the end of each
statement.
model ram4x4 (DO3, DO2, DO1, DO0, A1, A0, WEN, DI3, DI2, DI1,
DI0)
( bist_definition (
data_out d_o(DO3, DO2, DO1, DO0);
data_in di(DI3, DI2, DI1, DI0);
address addr(A1, A0);
...
Each bus element in the model header is declared as an individual scalar bit, the
same as the simulation model. Notice that the bist_definition segment allows you
to collect the individual bit under a single bus name and the ordering is
significant. MBISTArchitect assumes that the bit order is from most significant
(MSB) to least significant (LSB). MBISTArchitect uses this pin ordering when it
connects the BIST controller to the RAM model. Thus, mismatches between the
specified library pin ordering and the HDL model pin ordering can result in an
improperly-connected BIST controller.
Memory Clocks You can define one or more memory clocks for synchronous
memories.
Control Signals The active state can be either high (default) or low. During the
read and write cycles, control signals always remain at the value opposite this
state except when explicitly asserted. The following example declares an active
low write enable named wrt:
If the control signal operates a bidirectional data bus, the active state required to
control tri-state buffers for the data bus follows the signals active state. You must
specify either tri_l or tri_h to define this tri-state output buffer control state.
When you define a model with a bidirectional data bus, you must specify a tri-
state output control state for at least one of the defined control signals.
T h e D o n t_ to u c h K e y w o r d
M e m o r y p in s n o t c o n n e c te d to th e B IS T c o n tr o lle r
E x a m p le s : s u p p ly p in s , s ta tu s o u tp u t p in s
ramvdd oectram
B IS T
sys_addr
addr dout
sys_din
A s y n c h ro n o u s
sys_wen S ta te data RAM
sys_rst_l M a c h in e
wen
sys_hold_l
sys_test_h
test_clk fail_h
clk
test_done
The dont_touch keyword allows you to specify pins that have no need to be
controlled by the BIST controller. The syntax for specifying dont_touch ports is as
follows:
The assert state is either high (default) or low and defines the pins active state.
Dont_touch pins always remain at the value opposite their assert state. The
direction is either input or output.
The default is input for all vector types except data_out and data_inout. The
following example declares two dont_touch ports an active low input port
named clr and an active high output port named refcntso:
U n d e rs ta n d in g C lo c k in g S c h e m e s
A s y n c h ro n o u s M e m o ry
N o m e m o ry c lo c k in p u t
A c h a n g e in in p u ts s ta rts a re a d o r w rite c y c le
G a te d M e m o ry C lo c k
In s y s te m m o d e , th e m e m o ry c lo c k c o n n e c ts th ro u g h a m u x to
th e s y s te m c lo c k
In te s t m o d e , th e m e m o ry c lo c k c o n n e c ts to a c o n tro lle r-
re la te d c lo c k s ig n a l
N o n -G a te d M e m o ry C lo c k
M e m o ry c lo c k (m e m _ c lk ) c o n n e c ts to th e s y s te m m e m o ry
c lo c k
Your job in creating a memory model is to define a read and write cycle that meets
the minimum timing constraints as specified by the manufacturer, but at the same
time runs at the fastest test speed. Introducing just one extra test clock cycle in a
read operation, for example, can increase the total test time for a March2
algorithm by 50%.
There are different clocks that you need to reference when defining the read and
write cycles for a memory model. This discussion refers to the BIST clock as
the primary input clock to the BIST controller. This clock is named clk by
default and is used to advance the BIST state machine to the next state. As the
state machine enters each state, memory control signals are asserted or de-asserted
and memory bus values can be changed. The term memory clock (mem_clk)
refers to the clock input to a synchronous memory. A memory can have one or
more clock inputs. Asynchronous memories dont have a clock input. During
testing, a test clock is also generated as described next.
N o n -G a te d C lo c k
G a te d C lo c k
Ctr l Mem
Te st_ h
B IS T C lo ck C trl
Gated There is a MUX (gate) attached to the clock input of the memory.
During system use, the MUX is set so the memory clock is driven by a
system clock. During test mode, the MUX is set so that the memory is
driven by a BIST related clock. There are three important variations of this
described in the following clocking diagrams.
The key advantage of the Non-Gated approach is that it greatly simplifies getting
clock timing correct for normal system use. Depending on the clock-tree
generation process and the severity of the minimal skew requirements, using the
Non-Gated approach can be almost mandatory. It is the default mode.
The major disadvantage to this approach is that the tester must be set up to drive
the system clock input and the bist clock input with the same signal. There are
potential skew issues with this due to tester limitations. However, these are often
mitigated by the tester clock being much slower than the expected system clock.
Clock Connections
C lo c k C o n n e c tio n
Te s t_ h C tr l C tr l
Ctr l Te s t_ h
Ctr l
Mem
Mem
B IS T C lo c k
B IS T C lo c k
1
System Clock 0 1
System Clock 0
G a te d C lo c k T e s t [n o in v e rt]
G a te d C lo c k T e s t In v e rt
C lo c k C o n n e c tio n (C o n tin u e d )
C tr l
T e s t_ h
C tr l
Logic
Mem
B I S T C lo c k
System Clock
C o n tr o lle r
N o te : F a s t e s t p o s s i b l e c l o c k o u t o f c trl i s 1 /2 ra te o f th e B IS T c lo c k o r e v e n
s low er
When Memory clocking is set to anything other than -System, there will be a
MUX instantiated which will select between a system clock and a BIST-related
signal. This MUX will be very obvious when you use commands that place MUX
related RTL in the collar. Otherwise, it may be buried in the BIST controller RTL.
When the SETup MEmory Clocking -Test command is specified, the BIST
clock will be sent to the BIST controller and directly to the MUX.
There is a separate command: SET COntroller Clock [-positive | negative] that can
be used in conjunction with the clock connection command to deal with memories
that lock their inputs on falling edges rather than rising edges. Also, the two
commands can be used to effect half-cycle phase shift which can overcome timing
violation issues. This is discussed later in this workbook.
No Memory Clock
N o M e m o ry C lo c k
A s y n c h ro n o u s m e m o ry
te s t_ c lk d riv e s th e B IS T s ta te m a c h in e
W rite C y c le
B IS T
addr
te s t_ c lk
din addr dout
A s yn c h ro n o u s
wen
S ta te din
addr
RAM
rst_l M a c h in e wen
hold_l
test_h
d in
test_clk fail_h
clk wen
test_done
C hange L a tc h W rite
In p u ts A d d re s s In p u t D a ta
W rite Cycle
test_clk
BIST
sys_mem_clk
mem_clk m em _clk
test_done
Change
Inputs
Latch W rite
A ddress Input Data
3-12 M BISTArchitect: Comm on BIST Variations Copyright 2002 M entor Graphics Corporation
A N o n -G a te d M e m o ry C lo c k
N o n -g a te d m e m _ c lk is in p h a s e w ith te s t_ c lk
Setup Memory Clock -System (default)
W rite C y c le
mem_clk te s t_ c lk
B IS T
m e m _ c lk
addr S y n c h ro n o u s
addr RAM dout
data
wen S ta te din
addr N e w A d d re s s
rst_l M a c h in e wen
hold_l
d in V a lid D a ta
test_h
fail_h
test_clk
clk w en
test_done
Change
In p u ts
L a tc h W rite
A d d re s s In p u t D a ta
A n Inverted B IS T C lock
mem_clk test_clk
sys_mem_clk
BIST
m em _clk
Synchronous Invert of
addr Test_clk
addr R AM dout
data
wen State din addr N ew A ddress
rst_l M achine w en
hold_l
din V alid D ata
test_h
test_clk fail_h
clk w en
test_done
Change
Inputs
Latch W rite
A ddress Input D ata
You can use a setup command in MBISTArchitect to tell the BIST state machine
to respond to the falling edge of the clock. In this case, the falling edge of the
clock input to the state machine causes the memory input buses and control lines
to change. One half cycle later, the rising edge of the clock input to the
synchronous memory captures the input data. This scheme reduces the write cycle
from four cycles to two, and thus cuts the write cycle test time in half.
Test Clock
A T e s t C lo c k
M e m o ry c lo c k is c o n n e c te d to a m u x . In te s t m o d e , th e c lo c k is
d riv e n fro m a s ig n a l g e n e ra te d b y th e B IS T c o n tro lle r.
Setup Memory Clock -Test
T e s t C lo c k
C tr l Mem C trl M em
-in v e rt -n o in v e rt
3-1 5 M B IS T A rch ite ct: C o m m o n B IS T V aria tio ns C o p yrigh t 2 00 2 M e n tor G ra p h ics C o rpo ra tio n
When using the test clock scheme, the memory clock connects to a mux. In
system mode, the clock is driven from the system memory clock. In test mode, the
clock is driven from a signal generated by the BIST controller. This signal is a
reassignment of the BIST controller clock. The generated RTL will be modified
for the controller assigned test clock scheme to include the controller assignment
of the clock and the clock mux.
Two types of test clock connection are supported, -noinvert and -invert.
C o n tro l R e te n tio n T e s t D e la y
RAM 1 R W
te st_ re su m e
tst_ d o ne
3-1 6 M B IS T A rch ite ct: C o m m on B IS T V a riatio ns C o pyrig ht 20 02 M e nto r G ra ph ics C o rp ora tion
MBISTArchitect lets you control the delay value used in the WGL and simulation
test bench when waiting to assert the resume signal. This is used to continue the
BIST session following a retention test synchronization delay.
You can specify the delay value, as a multiple of the number of controller clock
cycles. The default value is 100 cycles. The report environment reports the delay
value.
The diagnostics capability is added by using the Setup Retention Cycles command
followed by a value defining the delay in cycles. For example, to set a delay value
of 50 cycles, enter:
setup retention cycles 50
Memory Ports
M e m o ry P o rts
R ead B _addr
P o rt B _ re n
B _dout R e a d p o rt
R e a d o p e ra tio n o n ly
1 re a d , 1 w rite
R e a d /W rite p o rt
R e a d /W rite A _addr
A _ d in A _dout
P o rt A _w en
B o th re a d a n d w rite
B _addr
R e a d /W rite B _ d in
o p e ra tio n s
B _dout
P o rt B _w en
2 re a d /w rite
3-1 7 M B IS T A rch ite ct: C o m m on B IS T V a riatio ns C o pyrig ht 20 02 M e nto r G ra ph ics C o rp ora tion
A memory component can have any number of read ports, write ports, or
read/write ports. The memory model syntax can match the port scheme of any
memory component.
D e fin in g M e m o ry P o rts
re a d _ p o rt (
re a d _ c y c le (
W rite P o rt
)
) C o n ta in s w rite c y c le o n ly
w rite _ p o rt (
w rite _ c y c le (
R e a d P o rt
)
C o n ta in s re a d c y c le o n ly
)
R e a d /W rite P o rt
re a d _ w rite _ p o rt (
re a d _ c y c le ( C o n ta in s b o th a re a d c y c le a n d w rite
) c y c le
w rite _ c y c le (
)
)
3-1 8 M B IS T A rch ite ct: C o m m on B IS T V a riatio ns C o pyrig ht 20 02 M e nto r G ra ph ics C o rp ora tion
Each unique port requires its own port definition and the definitions are not
explicitly labeled. MBISTArchitect identifies a port by the signals controlled
within the read/write cycles. Only the write port is identified as a port for the add
mbist algorithm command.
The first port that is defined within the bist_definition is referred to as port #1 and
the MBISTArchitect Model Editor will enter a comment identifying it as such.
The second port defined in the model will be referred to as port #2, and so on.
P o rt D e fin itio n E x a m p le 1
E x a m p le : 1 re a d , 1 w rite m e m o ry
w rite _ p o rt (
w rite _ c y c le (
change A_addr;
change A_din;
W rite A _addr wait;
A _ d in
P o rt A _w en
assert A_wen;
wait;
)
R ead B _addr )
B _d out
P o rt B _ re n
re a d _ p o rt (
1 re a d , 1 w rite re a d _ c y c le (
change B_addr;
wait;
assert B_ren;
wait;
expect B_dout;
wait;
)
)
3-1 9 M B IS T A rch ite ct: C o m m o n B IS T V aria tio ns C o p yrigh t 2 00 2 M e n tor G ra p h ics C o rpo ra tio n
NOTES:
P o rt D e fin itio n E x a m p le 2
re a d _ w rite _ p o rt (
re a d _ c y c le (
E x a m p le : 2 re a d /w rite m e m o ry change
wait;
A_addr;
expect A_dout;
wait;
)
w rite _ c y c le (
change A_addr;
R e a d /W rite A _addr change A_din;
A _ d in A _d out wait;
P o rt A _w en assert A_wen;
wait;
B _addr )
R e a d /W rite B _ d in )
B _do ut
P o rt B _w en re a d _ w rite _ p o rt (
re a d _ c y c le (
change B_addr;
2 re a d /w rite wait;
expect B_dout;
wait;
)
w rite _ c y c le (
change B_addr;
change B_din;
wait;
assert B_wen;
wait;
)
)
3-2 0 M B IS T A rch ite ct: C o m m o n B IS T V aria tio ns C o p yrigh t 2 00 2 M e n tor G ra p h ics C o rpo ra tio n
NOTES:
R e a d /W rite C y c le S y n ta x
3-2 1 M B IS T A rch ite ct: C o m m on B IS T V a riatio ns C o pyrig ht 20 02 M e nto r G ra ph ics C o rp ora tion
You use event statements to describe the action of the inputs and outputs during a
read and write cycle. You use the change statement to assign the next scheduled
value on the address bus and data buses.
You use the assert statement to force a control signal to its active state during that
test clock cycle. The control signal returns to its inactive state on the leading edge
of the next test clock cycle, unless asserted again with another assert statement.
The expect statement tells the BIST controller that the data on the specified bus is
valid, starting with the leading edge of that test clock cycle. This tells the BIST
controller that it can read the data for use with the comparator or MISR.
Inserting a wait statement is like inserting the leading edge of the next test clock
cycle (the clock that drives the BIST state machine). Any signals described in the
change, assert, or expect statements that follow the wait statement become active
or are valid on the leading edge of that clock cycle.
T h e R e a d C y c le
re a d _ c y c le (
im p lie d c lo c k e d g e (w a it)
c h a n g e A _ a d d r;
w a it;
e x p e c t A _ d o u t (m o v e );
w a it;
)
te s t_ c lk
dont care
A_addr
A _dout
T p d a d d r-d o u t M e a s u re
A_dout
3-2 2 M B IS T A rch ite ct: C o m m on B IS T V a riatio ns C o pyrig ht 20 02 M e nto r G ra ph ics C o rp ora tion
A read or write cycle often starts with a memory input becoming active, such as an
address bus or a chip enable line. This change occurs on the rising edge of the
clock that is advancing the state of the BIST controller. You can also think of a
wait statement as a rising edge of the reference clock and a read or write cycle as
starting with an implied wait statement, even though the wait statement is not
explicitly written into the model. You should place an explicit wait statement at
the end of a read or write cycle to mark the end of the cycle.
T h e W rite C y c le
w rite _ c y c le (
im p lie d c lo c k e d g e (w a it)
c h a n g e A _ a d d r;
c h a n g e A _ d in ;
w a it;
a s s e rt A _ w e n ;
w a it;
)
te st_ c lk
dont care
A _addr
A _ d in
A _w en
3 -23 M B IS T A rc hite ct: C o m m o n B IS T V a ria tio ns C o p yrig ht 20 0 2 M e n to r G rap h ics C o rp ora tio n
In this asynchronous write cycle, the change in address occurs on the rising edge
of the test_clk and marks the beginning of an asynchronous write cycle. The new
input data is also changed at this time, although typically, the change could occur
later in the cycle without violating the timing constraints. The next wait statement
marks the next rising edge of the test_clk. A_wen goes active low, which latches
the address into the memory. On the next clock edge (wait statement), A_wen is
released because it is not explicitly activated in the memory model. This action
writes the data to memory and ends the write cycle.
An expect statement can include an optional move modifier that specifies when
an event executes. The move modifier means that the MBISTArchitect tool can
move this event to a later clock cycle when optimizing the BIST structure. The
move option usually applies to data outputs. The MBISTArchitect tool uses the
move option only when it is trying to optimize circuitry while combining read and
write cycles together to form read/write/read cycles or other large cycles.
In te rp re tin g D a ta s h e e ts
R e a d a n d W rite c y c le s c a n b e d e te rm in e d fro m d a ta s h e e ts
D e p e n d e n t tim in g c o n s tra in ts a re h a n d le d w ith w a it
s ta te m e n ts
S e tu p a n d h o ld c o n s tra in ts
S e q u e n tia l b e h a v io r
3-2 4 M B IS T A rc hite ct: C om m o n B IS T V a ria tion s C op yrig ht 20 02 M en tor G rap h ics C o rpo ration
NOTES:
A S y n c h ro n o u s R A M E x a m p le
d ou t v a lid
9 12
R e a d c y c le tim in g d ia g ra m
NOTES:
d in v a lid
1 2 4
3
csb
5 6
m e m _ c lk m em _ clk
addr a dd r v a lid
7 8
d in
rw b
rw b dout 9 10
oe b
oeb 13 12
csb d ou t d in
11 14
NOTES:
m o d e l ra m _ 1 rw (a d d r, d in , rw b , o e b , c s b , m e m _ c lk ,
d o u t)( m e m _ c lk
b is t_ d e fin itio n (
a d d re s s a d d r (a rra y = 4 :0 ;); addr
d a ta _ in d in (a rra y = 3 :0 ;);
d a ta _ o u t d o u t (a rra y = 3 :0 ;); d in
o u tp u t_ e n a b le o e b lo w ; dout
w rite _ e n a b le rw b lo w ; rw b
c h ip _ e n a b le c s b lo w ;
oeb
c lo c k m e m _ c lk h ig h ;
csb
te c h = te c h n o lo g y _ 1 ;
ve n d o r = a cm e _ silic o n ;
ve rsio n = 1 .0 ;
m e s s a g e = S y n c h ro n o u s S R A M , 1 rw ;
a d d re s s_ s ize = 5 ;
m in _ a d d re s s = 0 ;
m a x _ a d d re s s = 3 1 ;
d a ta _ s ize = 4 ;
NOTES:
In te rp re tin g th e R e a d C y c le T im in g
1 2 R ea d cy c le is s yn c h ro n ize d
csb b y m e m _ c lo c k ris in g e d g e
3 4
m em _ clk
L o o k fo r d ep e n d e n cie s
c s b s e tu p b e fo re m e m _ c lk
a d dr v a lid a d d r s e tu p b e fo re m e m _ c lk
5 6
rw b
T p d o e b to d o u t
7 8
T p d m e m _ c lk to d o u t
oeb
10 11
c s b h o ld a fte r m e m _ c lk
d o ut v a lid a d d r h o ld a fte r m e m _ c lk
9 12
rw b s e tu p a n d h o ld ? ? ?
1 c s b s e tu p 5 a dd r s etu p 9 o eb tri -> ac tiv e N o - rw b is in a ctive
2 c s b h old 6 a dd r ho ld 10 r ea d a c c ess
3
4
pr ec h ar ge
m e m _c l k a ctiv e
7
8
rw b s etu p
rw b ho ld
11
12
o eb ac tiv e -> tr i
r ea d d ea c ces s
N o o th e r d ep e n d e n cie s
R e a d c y cle tim in g d ia g ra m
3-28 M B IS T A rch ite ct: C om m on B IS T V ariatio ns C o pyright 2 002 M en to r G raph ics C o rp oratio n
NOTES:
D e fin in g th e R e a d C y c le
R e a d d e p e n d e n c ie s
te s t_ c lo c k c s b s e tu p b e fo re m e m _ c lk
a d d r s e tu p b e fo re m e m _ c lk
addr
T p d o e b to d o u t
rw b re m a in s in a c tiv e
dout
dont care
T p d m e m _ c lk to d o u t
c s b h o ld a fte r m e m _ c lk
rw b
csb
Set memory clock
oeb Set controller clock
S tro b e d _ o u t
3 -2 9 M B IS T A rch itect: C o m m o n B IS T V a riation s C op yrig h t 2 0 02 M en to r G ra p hics C o rp ora tio n
NOTES:
D e fin in g th e R e a d C y c le (C o n tin u e d )
te st_ c lo c k
re a d _ c yc le (
ad d r ch a n g e a d d r;
a s se rt c s b ;
a s se rt o e b ;
dout
dont care
w a it;
a s se rt c s b ;
rw b a s se rt o e b ;
w a it;
c sb e x p e c t d o u t;
w a it;
o eb )
S tro b e d _ o u t
3-30 M B IS T A rch ite ct: C om m on B IS T V ariatio ns C o pyright 2 002 M en to r G raph ics C o rp oratio n
NOTES:
din va lid
1 2 4 W rite cycle is synchron ized
csb
3 b y m em _clock risin g ed ge
5 6 L oo k for d ep en den cies
m em _ clk
csb setup befo re m em _clk
a ddr va lid add r setup before m em _clk
7 8
rw b setup befo re m em _clk
rw b
9 10 T pd m em _clk to d ata valid
oe b csb hold after m em _clk
13 12
dout
add r hold after m em _clk
d in
11 14 rw b hold after m em _clk
1 d in se tup 6 m em _clk a ctive 11 oe b tri - > a ctive
o eb setu p and hold ?
2 d in h ol d 7 a d dr se tup 12 oe b a ctive -> tri N o - oeb is for observe only
3 csb se tup 8 a d dr h ol d 13 re ad acce ss
4 csb h o ld 9 r w b se tup 14 re ad de acce ss oeb can be asserted
5 p re cha rg e 10 r w b h ol d
N o other d ep end en cies
W rite cycle tim in g diagram
3-31 M B IS TA rch ite ct: C om m on B IS T V ariations C opyright 20 02 M en tor G raphics C o rpo ra tio n
NOTES:
D e fin in g th e W rite C y c le
W rite d e p e n d e n c ie s
te s t_ clo c k c s b s e tu p b e fo re m e m _ c lk
a d d r s e tu p b e fo re m e m _ c lk
addr
d in s e tu p b e fo re m e m _ c lk
rw b s e tu p b e fo re m e m _ c lk
d in
dont care
T p d o e b to d o u t
T p d m e m _ c lk to d a ta v a lid
rw b c s b h o ld a fte r m e m _ c lk
csb a d d r h o ld a fte r m e m _ c lk
rw b h o ld a fte r m e m _ c lk
oeb
3-32 M B IS T A rch itect: C om m o n B IS T V a ria tion s C op yrigh t 2 00 2 M en tor G ra ph ics C o rpo ratio n
NOTES:
te s t_ c lo c k
w rite _ c y c le (
addr c h a n g e a d d r;
c h a n g e d in ;
a s s e rt c s b ;
d in
dont care
a s s e rt rw b ;
a s s e rt o e b ;
rw b w a it;
a s s e rt m e m _ c lk ;
csb a s s e rt c s b ;
a s s e rt rw b
oeb a s s e rt o e b ;
w a it;
)
NOTES:
3-34 M BISTArchitect: Com m on BIST V ariations Copyright 2002 M entor G raphics Corporation
NOTES:
read_cycle ( write_cycle (
change addr; change addr;
wait; change din;
assert m em _clk; assert rwb;
wait; wait;
expect dout; assert m em _clk;
wait; assert rwb
) wait;
)
3-35 M BISTArchitect: Comm on BIST Variations Copyright 2002 Mentor G raphics Corporation
NOTES:
L o g ic a l to P h y s ic a l M a p p in g
E x a m p le : 6 4 -b it R A M
1 6 w o rd s , 4 b its p e r w o rd L o g ic a l A d d re s s in g
1 6 p h y s ic a l c o lu m n s b y 4 p h y s ic a l ro w s 15
4 w o rd s p e r ro w
0
P h y s ic a l A d d re s s in g 0 1 2 3
12 15
8 11
4 7
0 3
0 1 2 3 3 2 1 0 0 1 2 3 3 2 1 0
3-3 6 M B IS T A rch ite ct: C o m m o n B IS T V a riatio n s C op yrig ht 20 0 2 M e ntor G ra ph ics C o rpo ration
Externally, the memory illustrated may appear to consist of sixteen 4-bit words.
The internal physical layout of a memory is organized in a two-dimensional
matrix, in this case a common word per row configuration. Memory designers use
different physical configurations in an effort to reduce cell space, reduce power
consumption, increase yield (by including spare rows and columns), and
accommodate mapping to standard chip pin assignments. In this example, there
are four words per row.
T h e E ffe c t o f P h y s ic a l T o p o lo g y
A p p ly c h e c k e rb o a rd a lg o rith m
S h o u ld e n s u re in v e rs io n b e tw e e n e v e ry b it
P h y s ic a l to p o lo g y c o m p ro m is e s a lg o rith m e ffe c tiv e n e s s
12 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 0 15
A dd res s 8 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 0 11
4 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 0 7
0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 0 3
D a ta 0 1 2 3 3 2 1 0 0 1 2 3 3 2 1 0
bits
N o in v e rs io n s
3-3 7 M B IS T A rc hite ct: C om m o n B IS T V a ria tion s C op yrig ht 20 02 M en tor G rap h ics C o rpo ration
A llo w in g fo r P h y s ic a l T o p o lo g y
S o lu tio n
A d ju s t th e d a ta p a ttern to fit th e p h y s ic a l to p o lo g y
D a ta in v e rte d a t a d d re s s e s 1 , 3 , 4 , 6 , 9 , 1 1, 1 2 , 1 4
12 1
0 0
1 1
0 0
1 1 0 1 0 1
0 0
1 1
0 0
1 1 0 1 0 15
A dd re ss 8 0 1 0 1 0
1 1
0 0
1 1
0 0 1 0 1 0
1 1
0 0
1 1
0 11
4 1
0 0
1 1
0 0
1 1 0 1 0 1
0 0
1 1
0 0
1 1 0 1 0 7
0 0 1 0 1 1
0 0
1 1
0 0
1 0 1 0 1 1
0 0
1 1
0 0
1 3
D a ta 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
b its
NOTES:
T h e C h e c k e rb o a rd A lg o rith m
S u p p o rts b a s ic c o lu m n s p e r ro w a rc h ite c tu re s
L ib ra ry k e y w o rd s d e fin e to p o lo g y
to p _ c o lu m n = n u m b e r c o lu m n s (w o rd s ) p e r ro w
to p _ w o rd d e fin e s m u x in g o n a d d re s s d e c o d e r
S e le c t a lg o rith m w ith th e fo llo w in g c o m m a n d :
A d d M b is t A lg o rith m s C h e c k e rb o a rd
to p _ c o lu m n = 4 ;
to p _ w o rd = 0 ;
The Checkerboard algorithm reads the physical topology information from the
memory model and adjusts the output patterns to create the proper checkerboard
pattern among physically adjacent cells. When you are creating the memory
model, you must include the physical topology information by placing the
following lines within the memory model bist_definition. Often this information
is not found in a standard memory data book and you must request it from the
manufacturer. top_column=<value> tells the algorithm the number of words per
row. The <value> can be any integer greater than 0. The algorithm uses this value
to ensure that the first word of each row is different than the first word of the
previous row, thus creating a checkerboard pattern. top_word=<value> tells if
multiplexers in the column address decoder. A multiplexer is used to select
between the bits of two words that are interleaved. If this is the case, then writing
all 1s to one word and all 0s to the other creates a checkerboard pattern. 1
indicates there are multiplexers, 0 indicates there are not.
You must use the Setup Observation Scheme -Compare command when you
use the Checkerboard algorithm to compare algorithms. In addition, multiple
memories of different topologies can share the same controller. It is only
necessary that each memory model contain its own top_column and top_word
statements.
Descrambling Functions
D e s c ra m b lin g F u n c tio n s
D e s c ra m b lin g p ro v id e s m o s t fle x ib le to p o lo g ic a l m a p p in g
U s e d fo r m o re c o m p le x to p o lo g ic a l m a p p in g
D e fin e s w h e re d a ta is in v e rte d
A d d re s s e s c a n a ls o b e d e s c ra m b le d
M u s t u s e S e tu p M u x lo c a tio n -c o n tro lle r
The address subsection defines the descrambling for the address bus and the
data_in subsection defines the descrambling for the data input bus. For each
address/data line of the memory there must be a line in the corresponding
subsection. For example, if the width of the address bus is 4, there must be four
lines in the address subsection of the descrambling definition section of the
memory model. Similarly, if the width of the data bus is 8, there must be eight
lines in the data section of the descrambling definition section of the memory
model. The names of the descrambled address/data lines are arbitrary but the order
of the statements in each section is important.
The first statement corresponds to the LSB and the last to the MSB. The supported
Boolean operators are BUF, INV, AND, NAND, OR, NOR, XOR, XNOR.
Finally, you must define BOTH address and data_in subsections, regardless of
whether or not scrambling information exists for both.
V a lid a tin g a M e m o ry M o d e l
R un M e m o ry m o d e l e rro rs
M B IS T A rchite ct
w ill re s u lt in in c o rre c t
B IS T c o n tro lle r
C o m pile & ru n
testbe nch C o rrect
sim ulatio n pro blem
S u ccess
3-41 M B IS T A rch ite ct: C om m on B IS T V ariatio ns C o pyright 2 002 M en to r G raph ics C o rp oratio n
NOTES:
0 0 0 0 0 1.W rite a ll 0 e xc e pt ba s e ce ll
0 0 0 0 0 2.R e ad first ce ll
3.R e ad b ase cell
0 0 0 1 0
4. R e pe a t 2 -3 for all ce lls
0 0 0 0 0
3-42 M B IS T A rch ite ct: C om m on B IS T V ariatio ns C o pyright 2 002 M en to r G raph ics C o rp oratio n
Prior to inclusion of the Mentor Graphics User Defined Algorithm function, all
of the test algorithms available in the MBISTArchitect tool were precoded into the
tool. Adding a new algorithm required engineering work at the factory to support
the new algorithm. The User Defined Algorithm functionality removes the pre-
coded test algorithms and replaces them with algorithm definitions, loaded from
files, which you can modify prior to BIST generation. All of the algorithms pre-
configured as part of the MBISTArchitect tool, except the comparator test and
port interaction tests, are defined within the software using this facility.
You can use User Defined Algorithms to define a class of simple March-type
algorithms. This capability lets you define algorithms that perform a single
memory access operation or more complex activity formed from read and write
operations, at each address of a range of memory addresses.
When the memory BIST kernel is active, you can use User Defined Algorithm
commands to load algorithms into the tool and change the set of available
algorithms. The UDA algorithms use the UDA language that follows a Verilog-
like style. Algorithms are composed of these parts:
Tests
Repetitions
Steps
Use these commands when working with User Defined Algorithms: Load
Algorithms, Delete Algorithms, and Report Algorithms.
User Defined Algorithm Exercises are available at the end of this module so that
you can get experience using this MBISTArchitect feature.
T ro u b le s h o o tin g a M e m o ry M o d e l
T h re e m a jo r c a u s e s o f m is m a tc h e s
In c o rre c t m e m o ry m o d e l d e s c rip tio n
R e -e x a m in e d a tas h e et a n d m e m o ry m o d e l
A d d itio n a l M B IS T A rc h ite c t c o m m a n d s re q u ire d
S o m e m e m o rie s w ill re q u ire s o m e se tu p in
M B IS T A rc h ite c t
In c o rre c t s im u la tio n m o d e l o r in a c c u ra te d a ta s h e e t
In ten d ed b e h a v io r c o rre c t, b u t s till g e ttin g p ro b lem s
3-43 M B IS T A rch ite ct: C om m on B IS T V ariatio ns C o pyright 2 002 M en to r G raph ics C o rp oratio n
NOTES:
NOTES:
Exercise 15: Reviewing a User Defined Algorithm You will review a User
Defined Algorithm (UDA) that has been modified to change the March1
algorithm.
Exercise 16: Running a User Defined Algorithm FileYou will run the User
Defined Algorithm reviewed in the previous exercise and simulate a memory
model which uses the algorithm.
The Model Editor works on selected objects. Therefore, in most cases, you
must first select an object before you modify or replace that object.
The Model Editor allows you to save to multiple models to one file.
Therefore, during a save operation, only a model with exactly the same
name is overwritten in that file. If you save a model by a different name,
that model will be appended to the existing models in the file.
RAM4x16
1-Port Asynchronous RAM with 4 words by 16 bits
Technology: Newest
Version: 1.00
Date: 4/29/96
Inputs/Outputs
a1:0 - Address lines.
d15:0 - Data inputs.
q15:0 - data outputs (tri-state).
oe - Output Enable - active low.
wrt - Write control line. A high state enables writing, a low state enables reading.
Miscellaneous Info: Input and Output buses are defined as wide-pins (arrays) on
the simulation model.
3. Click the Model Editor button, then follow the directions below to select a
template:
1. Click
2. Select
3. Click
1. Enter
2. Click
3. Click
The File Viewer window should appear with the template displayed. At this
point, only the model name has changed.
BEST PRACTICE:Keep the File Viewer window open and off to the side, so
you can examine the updated status of the file after you execute each Save
Model... command.
1. Bring the Model Editor window to the front, then click on Change Above
Information.
4. Click OK.
Toh
Toz Toe
oe
Trc - read cycle time - minimum 6.0ns
Taa - address access time - maximum 6.0ns
Toh - output hold time from address change - minimum 3.7ns
Toz - output disable time - maximum 0.9ns
Toe - output enable time - minimum 1.0ns
Read Cycle Description - An address change initiates the read sequence. Data from
the previous read is valid for a minimum of 3.7ns. Output data for the new address is valid
6.0ns after the address change. If the output_enable goes inactive low, output data
remains valid for.9ns, then goes to hi-Z. Output data is valid 1.0ns after output_enable
goes active high.
Test
Clock
a1:0
q7:0 valid data previous address data not valid valid data
Assumptions:
1. An address change occurs on the rising edge of the test clock.
2. The test clock will not violate setup and hold times.
3. New data will be valid after one test clock cycle
4.Output_enable will not be tested by the BIST circuitry.
2. Verify that the Read Cycle for Port #1 is selected for editing. If not, select
1 Read/Write (Read), then click Edit the Selected Cycle.
3. Click Define Cycle Pins, then select the Address definition on the right
side of the form.
4. Change the Name from addr to a, click >> Add >>, then click Change
Selected.
6. Add an Output_Enable signal called oe. Since you will not be testing this
signal, define it as active low even though it is active high. This causes the
BIST controller to hold it in what it thinks is the inactive state (high), when
in fact it is the active state (for example, output always enabled).
In the Write Cycle editing session that follows, you will define the
write_enable wrt signal as active high. You can assume this
Note signal is low during the read cycle, therefore you dont have to
define it as part of the read- cycle protocol.
8. Look at the Cycle Editor timing diagram. The output data should be valid
one test clock cycle after a valid address change, so click on the q signal
line where shown in Step 1 below. Also, the read cycle is complete within
two test clock cycles, so you should shorten the Read Cycle by one test
clock cycle, as shown in Step 2 below:
2. Click
1. Click
In the following sequence, you will learn how to Import a signal definition from
the Read Cycle to the Write Cycle.
Twc
a1:0 valid write address
Taw
Tasw
we Twp
Tdw Tdh
valid data to write
di7:0
we going high (true) initiates the Write sequence.
Twc - write cycle time - minimum 5.5ns
Taw - address valid to end of write - minimum 5.5ns
Tasw - Address setup to we high - minimum 2.6ns
Twp - write minimum pulse - maximum 2.9ns
Tdw - data valid to end of write - minimum 3.7ns
Tdh - data hold time - minimum 3.7ns
Write Cycle Description - With the address stable, Write Enable (we) initiates
the write sequence. The address is latched into memory on the rising edge of we.
Data on the data input bus is written into memory on the falling edge of we.
Test
Clock
latch address
wrt
read data
Assumptions:
1. Address and data changes on the rising edge of the test clock.
2. The test clock will not violate setup and hold times.
3. Address is latched on the rising edge of wrt (next test clock cycle).
4. Input data is written into memory on the falling edge of wrt (next test clock cycle).
5. Output_enable will not be tested by the BIST circuitry.
3. Click Define Cycle Pins, select the Address definition, then click Import
Pin...
4. Select the Address definition, click OK, click >> Add >>, then click
Change Selected.
6. Change the Write_Enable input to an active high wrt signal, then click
OK.
7. Look at the Cycle Editor timing diagram and make it conform to the
illustration below:
8. End the Modeling Editing session by clicking on Save Model..., then click
OK.
9. Examine the updated status of the Read and Write Cycle in the File Viewer
window. Verify that it corresponds with your understanding of what the
syntax should be.
Summary
In this exercise, we will show you an example of a user defined algorithm. The
next exercise shows you how to load a dofile that references this algorithm and to
run the dofile in MBISTArchitect.
2. The file named marchA.dsc is an algorithm file that has been created to
modify the existing March 1 algorithm. Use your favorite text editor or vi to
open this file.
Definition
Steps
Algorithm repetition
The Definition section contains the test name, a summary of the test, and size.
This is followed by an algorithm definition that defines the actions to be taken in
the algorithm. In this example, it defines the read and write operations performed
during the up and down memory test.
Definition Section
marchA
Summary:
test example for a marching algorithm named marchA
10n
Algorithm:
up - write 0
up - read 0, write 1
up - read 1, write 0
down - read 0, write 1
down - read 1, write 0
down - read 0
The Steps section declares the basic activity across the address space of the
memory ports. The step includes the following:
addr
The address clause defines what happens to the address register during the
step of the algorithm.
data
A string that defines what data values will be used by the operation applied
at each address visited by the algorithm step.
operation
A string that defines the activity, such as a read or write, that is performed
at each address visited by the algorithm step.
Steps Section
step wSeedUp;
addr min, max, up, 1;
data seed;
operation w;
step rwInvSeedUp;
addr min, max, up, 1;
data invSeed;
operation rw;
step rwSeedUp;
addr min, max, up, 1;
data seed;
operation rw;
step rwInvSeedDown;
addr min, max, down, 1;
data invSeed;
operation rw;
step rwSeedDown;
addr min, max, down, 1;
data seed;
operation rw;
step rSeedDown;
addr min, max, down, 1;
data seed;
operation r;
The Repetition section defines the action that will be taken in the algorithm. It
includes the following:
seed
A string that specifies a common default value to be used by all the steps in
the repetition.
Repetition Section
repetition marchA;
seed 0;
begin
step wSeedUp;
step rwInvSeedUp;
step rwSeedUp;
step rwInvSeedDown;
step rwSeedDown;
step rSeedDown;
end
test marchA;
repetition marchA;
Once you have finished reviewing the sample algorithm, close the text editor. In
the next exercise, you will load a dofile that references the MarchA algorithm and
run the dofile in MBISTArchitect.
2. Use your favorite text editor or vi to open the ram4x4.do file. This file
contains commands required to load the design, memory model and the
MarchA algorithm.
ram4x4.do sample
loa li ../design/ram4x4.atpg
add me m ram4x4
load algorithm marchA.dsc
add mbis alg 1 marchA
run
save bist -replace
exit
3. Once you have finished reviewing the sample algorithm, close the text
editor.
4. You are now ready to run MBISTArchitect and load this dofile. Change to
the results directory.
shell> cd $MBISTNWP/mbist3/uda/results
Type the following command to launch MBISTArchitect and run the dofile:
shell > mbistarchitect -nogui -dofile ../design/ram4x4.do
ram4x4_bist.v
ram4x4_bist_con.v
ram4x4_tb.v
Next, you will use the MBISTArchitect-generated testbench to verify the memory
BIST circuitry created by running the dofile.
3. Compile the memory simulation model, all BIST models, and the
testbench.
b. This file sets the parameters for the simulation to stop due to tst_done
or fail_h going high. It also sets up a List window so you can examine
pertinent signals.
7. Examine the saved list file. Use whatever editor you prefer to view the
trace.log.uda file you saved.
The signals that comprise the columns in this file include (from left to
right): tst_done, fail_h, the address, the write enable, the data input values,
and the data output values.
TM-69
Third-Party Trademarks
The following names are trademarks, registered trademarks, and service marks of other companies that appear in Mentor
Graphics product publications:
Adobe, the Adobe logo, Acrobat, the Acrobat logo, Exchange, FrameMaker, FrameViewer, and PostScript are registered trademarks of Adobe Systems
Incorporated.
Altera is a registered trademark of Altera Corp.
AM188, AMD, AMD-K6, and AMD Athlon Processor are trademarks of Advanced Micro Devices, Inc.
Apple and Laserwriter are registered trademarks of Apple Computer, Inc.
ARIES is a registered trademark of Aries Technology.
AMBA, ARM, ARMulator, ARM7TDMI, ARM7TDMI-S, ARM9TDMI, ARM9E-S, ARM946E-S, ARM966E-S, EmbeddedICE, StrongARM, TDMI, and
Thumb are trademarks or registered trademarks of ARM Limited.
ASAP, Aspire, C-FAS, CMPI, Eldo-FAS, EldoHDL, Eldo-Opt, Eldo-UDM, EldoVHDL, Eldo-XL, Elga, Elib, Elib-Plus, ESim, Fidel, Fideldo, GENIE,
GENLIB, HDL-A, MDT, MGS-MEMT, MixVHDL, Model Generator Series (MGS), Opsim, SimLink, SimPilot, SpecEditor, Success, SystemEldo,
VHDeLDO and Xelga are registered trademarks of ANACAD Electrical Engineering Software, a unit of Mentor Graphics Corporation.
Avant! and Star-Hspice are trademarks of Avant! Corporation.
AVR is a registered trademark of Atmel Corporation.
Cadence, Affirma signalscan, Allegro, Analog Artist, Composer, Concept, Design Planner, Dracula, GDSII, GED, HLD Systems, Leapfrog, Logic DP, NC-
Verilog, OCEAN, Physical DP, Pillar, Silicon Ensemble, Spectre, Verilog, Verilog XL, Veritime, and Virtuoso are trademarks or registered trademarks of
Cadence Design Systems, Inc.
CAE+Plus and ArchGen are registered trademarks of Cynergy System Design.
CalComp is a registered trademark of CalComp, Inc.
Canon is a registered trademark of Canon, Inc. BJ-130, BJ-130e, BJ-330, and Bubble Jet are trademarks of Canon, Inc.
Centronics is a registered trademark of Centronics Data Computer Corporation.
ColdFire and M-Core are registered trademarks of Motorola, Inc.
Ethernet is a registered trademark of Xerox Corporation.
Foresight and Foresight Co-Designer are trademarks of Nu Thena Systems, Inc.
FLEXlm is a trademark of Globetrotter Software, Inc.
GenCAD is a trademark of Teradyne Inc.
Hewlett-Packard (HP), LaserJet, MDS, HP-UX, PA-RISC, APOLLO, DOMAIN and HPare registered trademarks of Hewlett-Packard Company.
HCL-eXceed and HCL-eXceed/W are registered trademark of Hummingbird Communications. Ltd.
HyperHelp is a trademark of Bristol Technology Inc.
Installshield is a registered trademark and service mark of InstallShield Corporation.
IBM, PowerPC, and RISC Systems/6000 are trademarks of International Business Machines Corporation.
I-DEAS and UG/Wiring are registered trademarks of Electronic Data Systems Corporation.
IKON is a trademark of Tahoma Technology.
IKOS and Voyager are registered trademarks of IKOS Systems, Inc.
Imagen, QMS, QMS-PS 820, Innovator, and Real Time Rasterization are registered trademarks of MINOLTA-QMS Inc. imPRESS and UltraScript are
trademarks of MINOLTA-QMS Inc.
ImageGear is a registered trademark of AccuSoft Corporation.
Infineon, TriCore, and C165 are trademarks of Infineon Technologies AG.
Intel, i960, i386, and i486 are registered trademarks of Intel Corporation.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc.
Linux is a registered trademark of Linus Torvalds.
MemoryModeler MemMaker are trademarks of Denali Software, Inc.
MIPS is a trademark of MIPS Technologies, Inc.
MS-DOS, Windows 95, Windows 98, Windows 2000, and Windows NT are registered trademarks of Microsoft Corporation.
MULTI is a registered trademark of Green Hills Software, Inc.
NEC and NEC EWS4800 are trademarks of NEC Corp.
Netscape is a trademark of Netscape Communications Corporation.
Novas, Debussy, and nWave are trademarks or registered trademarks of Novas Software, Inc.
OakDSPCore is a registered trademark for DSP Group, Inc.
Oracle, Oracle8i, and SQL*Plus are trademarks or registered trademarks of Oracle Corporation.
PKZIP is a registered trademark of PKWARE, Inc.
Pro/CABLING and HARNESSDESIGN are trademarks or registered trademarks of Parametric Technology Corporation.
Quantic is a registered trademark of Quantic EMC Inc.
QUASAR is a trademark of ASM Lithography Holding N.V.
Red Hat is a registered trademark of Red Hat Software, Inc.
TM-70
SCO and the SCO logo are trademarks or registered trademarks of Caldera International, Inc.
Sneak Circuit Analysis Tool (SCAT) is a registered trademark of SoHaR Incorporated.
SPARC is a registered trademark, and SPARCstation is a trademark, of SPARC International, Inc.
Sun Microsystems, Sun Workstation, and NeWS are registered trademarks of Sun Microsystems, Inc. Sun, Sun-2, Sun-3, Sun-4, OpenWindows, SunOS,
SunView, NFS, and NSE are trademarks of Sun Microsystems, Inc.
SuperH is a trademark of Hitachi, Ltd.
Synopsys, Design Compiler, DesignWare, Library Compiler, LM-family, PrimeTime, SmartModel, Speed-Model, Speed Modeling, SimWave, and Chronologic
VCS are trademarks or registered trademark of Synopsys, Inc.
TASKING is a registered trademark of Altium Limited.
Teamwork is a registered trademark of Computer Associates International, Inc.
Tensilica and Xtensa are registered trademarks of Tensilica, Inc.
Times and Helvetica are registered trademarks of Linotype AG.
TimingDesigner and QuickBench are registered trademarks of Forte Design Systems
Tri-State, Tri-State Logic, tri-state, and tri-state logic are registered trademarks of National Semiconductor Corporation.
UNIX, Motif, and OSF/1 are registered trademarks of The Open Group in the United States and other countries.
Versatec is a trademark of Xerox Engineering Systems, Inc.
ViewDraw, Powerview, Motive, and PADS-Perform are registered trademarks of Innoveda, Inc. Crosstalk Toolkit (XTK), Crosstalk Field Solver (XFX), Pre-
Route Delay Quantifier (PDQ), and Mentor Graphics Board Station Translator (MBX) are trademarks of Innoveda, Inc.
Visula is a registered trademark of Zuken-Redac.
VxSim, VxWorks and Wind River Systems are trademarks or registered trademarks of Wind River Systems, Inc.
XVision is a registered trademark of Tarantella, Inc.
X Window System is a trademark of MIT (Massachusetts Institute of Technology).
Z80 is a registered trademark of Zilog, Inc.
ZSP and ZSP400 are trademarks of LSI Logic Corporation.
Other brand or product names that appear in Mentor Graphics product publications are trademarks or registered trademarks of
their respective holders.
Updated 2/13/02
TM-71
TM-72
End-User License Agreement
IMPORTANT - USE OF THIS SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS CAREFULLY
READ THIS LICENSE AGREEMENT BEFORE USING THE SOFTWARE
This license is a legal "Agreement" concerning the use of Software between you, the end-user, either individually or as
an authorized representative of the company purchasing the license, and Mentor Graphics Corporation, Mentor
Graphics (Ireland) Limited, Mentor Graphics (Singapore) Private Limited, and their majority-owned subsidiaries
("Mentor Graphics"). USE OF SOFTWARE INDICATES YOUR COMPLETE AND UNCONDITIONAL
ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT. If you do not agree to
these terms and conditions, promptly return or, if received electronically, certify destruction of Software and all
accompanying items within 10 days after receipt of Software and receive a full refund of any license fee paid
1. GRANT OF LICENSE. The software programs you are installing, downloading, or have acquired with
this Agreement, including any updates, modifications, revisions, copies, and documentation ("Software")
are copyrighted, trade secret and confidential information of Mentor Graphics or its licensors who
maintain exclusive title to all Software and retain all rights not expressly granted by this Agreement.
Mentor Graphics or its authorized distributor grants to you, subject to payment of appropriate license fees,
a nontransferable, nonexclusive license to use Software solely: (a) (in machine-readable, object-code
form; (b) for your internal business purposes; and (c) on the computer hardware or at the site for which an
applicable license fee is paid, or as authorized by Mentor Graphics. A site is restricted to a one-half mile
(800 meter) radius. Mentor Graphics then-current standard policies, which vary depending on Software,
license fees paid or service plan purchased, apply to the following and are subject to change: (a) relocation
of Software; (b) use of Software, which may be limited, for example, to execution of a single session by a
single user on the authorized hardware or for a restricted period of time (such limitations may be
communicated and technically implemented through the use of authorization codes or similar devices); (c)
eligibility to receive updates, modifications, and revisions; and (d) support services provided. Current
standard policies are available upon request.
2. ESD SOFTWARE. If you purchased a license to use embedded software development (ESD) Software,
Mentor Graphics or its authorized distributor grants to you a nontransferable, nonexclusive license to
reproduce and distribute executable files created using ESD compilers, including the ESD run-time
libraries distributed with ESD C and C++ compiler Software that are linked into a composite program as
an integral part of your compiled computer program, provided that you distribute these files only in
conjunction with your compiled computer program. Mentor Graphics does NOT grant you any right to
duplicate or incorporate copies of Mentor Graphics real-time operating systems or other ESD Software,
except those explicitly granted in this section, into your products without first signing a separate
agreement with Mentor Graphics for such purpose.
3. BETA CODE
3.1. Portions or all of certain Software may contain code for experimental testing and evaluation ("Beta
Code"), which may not be used without Mentor Graphics explicit authorization. Upon Mentor
Graphics authorization, Mentor Graphics grants to you a temporary, nontransferable, nonexclusive
license for experimental use to test and evaluate the Beta Code without charge for a limited period of
time specified by Mentor Graphics. This grant and your use of the Beta Code shall not be construed
as marketing or offering to sell a license to the Beta Code, which Mentor Graphics may choose not
to release commercially in any form.
3.2. If Mentor Graphics authorizes you to use the Beta Code, you agree to evaluate and test the Beta
Code under normal conditions as directed by Mentor Graphics. You will contact Mentor Graphics
periodically during your use of the Beta Code to discuss any malfunctions or suggested
improvements. Upon completion of your evaluation and testing, you will send to Mentor Graphics a
written evaluation of the Beta Code, including its strengths, weaknesses and recommended
improvements.
3.3. You agree that any written evaluations and all inventions, product improvements, modifications or
developments that Mentor Graphics conceives or makes during or subsequent to this Agreement,
including those based partly or wholly on your feedback, will be the exclusive property of Mentor
Graphics. Mentor Graphics will have exclusive rights, title and interest in all such property. The
provisions of this subsection shall survive termination or expiration of this Agreement.
4. RESTRICTIONS ON USE. You may copy Software only as reasonably necessary to support the
authorized use. Each copy must include all notices and legends embedded in Software and affixed to its
medium and container as received from Mentor Graphics. All copies shall remain the property of Mentor
Graphics or its licensors. You shall maintain a record of the number and primary location of all copies of
Software, including copies merged with other software, and shall make those records available to Mentor
Graphics upon request. You shall not make Software available in any form to any person other than your
employers employees and contractors, excluding Mentor Graphics competitors, whose job performance
requires access. You shall take appropriate action to protect the confidentiality of Software and ensure that
any person permitted access to Software does not disclose it or use it except as permitted by this
Agreement. Except as otherwise permitted for purposes of interoperability as specified by the European
Union Software Directive or local law, you shall not reverse-assemble, reverse-compile, reverse-engineer
or in any way derive from Software any source code. You may not sublicense, assign or otherwise transfer
Software, this Agreement or the rights under it without Mentor Graphics prior written consent. The
provisions of this section shall survive the termination or expiration of this Agreement.
5. LIMITED WARRANTY
5.1. Mentor Graphics warrants that during the warranty period Software, when properly installed, will
substantially conform to the functional specifications set forth in the applicable user manual. Mentor
Graphics does not warrant that Software will meet your requirements or that operation of Software
will be uninterrupted or error free. The warranty period is 90 days starting on the 15th day after
delivery or upon installation, whichever first occurs. You must notify Mentor Graphics in writing of
any nonconformity within the warranty period. This warranty shall not be valid if Software has been
subject to misuse, unauthorized modification or installation. MENTOR GRAPHICS ENTIRE
LIABILITY AND YOUR EXCLUSIVE REMEDY SHALL BE, AT MENTOR GRAPHICS
OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF SOFTWARE TO
MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF SOFTWARE THAT
DOES NOT MEET THIS LIMITED WARRANTY, PROVIDED YOU HAVE OTHERWISE
COMPLIED WITH THIS AGREEMENT. MENTOR GRAPHICS MAKES NO WARRANTIES
WITH RESPECT TO: (A) SERVICES; (B) SOFTWARE WHICH IS LOANED TO YOU FOR A
LIMITED TERM OR AT NO COST; OR (C) EXPERIMENTAL BETA CODE; ALL OF WHICH
ARE PROVIDED "AS IS."
5.2. THE WARRANTIES SET FORTH IN THIS SECTION 5 ARE EXCLUSIVE. NEITHER
MENTOR GRAPHICS NOR ITS LICENSORS MAKE ANY OTHER WARRANTIES, EXPRESS
OR IMPLIED, WITH RESPECT TO SOFTWARE OR OTHER MATERIAL PROVIDED UNDER
THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE.
8. INFRINGEMENT
8.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against you
alleging that Software infringes a patent or copyright in the United States, Canada, Japan,
Switzerland, Norway, Israel, Egypt, or the European Union. Mentor Graphics will pay any costs and
damages finally awarded against you that are attributable to the claim, provided that you: (a) notify
Mentor Graphics promptly in writing of the action; (b) provide Mentor Graphics all reasonable
information and assistance to settle or defend the claim; and (c) grant Mentor Graphics sole authority
and control of the defense or settlement of the claim.
8.2. If an infringement claim is made, Mentor Graphics may, at its option and expense, either (a) replace
or modify Software so that it becomes noninfringing, or (b) procure for you the right to continue
using Software. If Mentor Graphics determines that neither of those alternatives is financially
practical or otherwise reasonably available, Mentor Graphics may require the return of Software and
refund to you any license fee paid, less a reasonable allowance for use.
8.3. Mentor Graphics has no liability to you if the alleged infringement is based upon: (a) the
combination of Software with any product not furnished by Mentor Graphics; (b) the modification of
Software other than by Mentor Graphics; (c) the use of other than a current unaltered release of
Software; (d) the use of Software as part of an infringing process; (e) a product that you design or
market; (f) any Beta Code contained in Software; or (g) any Software provided by Mentor Graphics
licensors which do not provide such indemnification to Mentor Graphics customers.
8.4. THIS SECTION 8 STATES THE ENTIRE LIABILITY OF MENTOR GRAPHICS AND ITS
LICENSORS AND YOUR SOLE AND EXCLUSIVE REMEDY WITH RESPECT TO ANY
ALLEGED PATENT OR COPYRIGHT INFRINGEMENT BY ANY SOFTWARE LICENSED
UNDER THIS AGREEMENT.
9. TERM. This Agreement remains effective until expiration or termination. This Agreement will
automatically terminate if you fail to comply with any term or condition of this Agreement or if you fail to
pay for the license when due and such failure to pay continues for a period of 30 days after written notice
from Mentor Graphics. If Software was provided for limited term use, this Agreement will automatically
expire at the end of the authorized term. Upon any termination or expiration, you agree to cease all use of
Software and return it to Mentor Graphics or certify deletion and destruction of Software, including all
copies, to Mentor Graphics reasonable satisfaction.
10. EXPORT. Software is subject to regulation by local laws and United States government agencies, which
prohibit export or diversion of certain products, information about the products, and direct products of the
products to certain countries and certain persons. You agree that you will not export in any manner any
Software or direct product of Software, without first obtaining all necessary approval from appropriate
local and United States government agencies.
11. RESTRICTED RIGHTS NOTICE. Software has been developed entirely at private expense and is
commercial computer software provided with RESTRICTED RIGHTS. Use, duplication or disclosure by
the U.S. Government or a U.S. Government subcontractor is subject to the restrictions set forth in the
license agreement under which Software was obtained pursuant to DFARS 227.7202-3(a) or as set forth in
subparagraphs (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clause at FAR
52.227-19, as applicable. Contractor/manufacturer is Mentor Graphics Corporation, 8005 Boeckman
Road, Wilsonville, Oregon 97070-7777 USA.
12. THIRD PARTY BENEFICIARY. For any Software under this Agreement licensed by Mentor Graphics
from Microsoft or other licensors, Microsoft or the applicable licensor is a third party beneficiary of this
Agreement with the right to enforce the obligations set forth in this Agreement.
13. CONTROLLING LAW. This Agreement shall be governed by and construed under the laws of Ireland
if the Software is licensed for use in Israel, Egypt, Switzerland, Norway, South Africa, or the European
Union, the laws of Japan if the Software is licensed for use in Japan, the laws of Singapore if the Software
is licensed for use in Singapore, Peoples Republic of China, Republic of China, India, or Korea, and the
laws of the state of Oregon if the Software is licensed for use in the United States of America, Canada,
Mexico, South America or anywhere else worldwide not provided for in this section
14. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be
void, invalid, unenforceable or illegal, such provision shall be severed from this Agreement and the
remaining provisions will remain in full force and effect.
15. MISCELLANEOUS. This Agreement contains the entire understanding between the parties relating to
its subject matter and supersedes all prior or contemporaneous agreements, including but not limited to
any purchase order terms and conditions, except valid license agreements related to the subject matter of
this Agreement which are physically signed by you and an authorized agent of Mentor Graphics. This
Agreement may only be modified by a physically signed writing between you and an authorized agent of
Mentor Graphics. Waiver of terms or excuse of breach must be in writing and shall not constitute
subsequent consent, waiver or excuse. The prevailing party in any legal action regarding the subject
matter of this Agreement shall be entitled to recover, in addition to other relief, reasonable attorneys fees
and expenses.
(10/99 rev B)