( ESNUG 340 Item 4 ) --------------------------------------------- [1/19/00]
From: Tim Wood <tim.wood@amd.com>
Subject: Testing Embedded Macros; Two Users Review Mentor's MacroTest Tool
Hi, John,
We've been using MacroTest, a product from Mentor Graphics, and knowing
how you love "real life" user reviews of EDA tools, we thought we'd tell
you about it. How we found MacroTest was purely by accident. We
happened to stumble across it in some Mentor documentation about 2 years
ago and it seemed to be just the thing we needed to to test some very
difficult-to-test small embedded arrays.
MacroTest is a (separately licensed) feature of Mentor's FastScan ATPG
product. The embedded arrays we were trying to test were implemented as
both full custom blocks and as non-scan standard cell arrays, built out
of the equivalent of non-scan flip-flops (these were the only non-scan
flip-flops in the design). These arrays were too small to justify adding
BIST hardware and they couldn't be fully tested by traditional ATPG. We
also couldn't afford to provide access to each of these arrays through
the normal I/O's.
With small arrays like these, it's usually easy to come up with a set of
patterns if you can apply them to the array directly. It's very difficult,
if not impossible, to do this once the array becomes embedded and you're
restricted to using the I/O's of the part that contains the embedded device.
We were able to write patterns for the embedded arrays using their I/O's,
and used MacroTest to turn these patterns into full-chip scan patterns.
The patterns are written in a tabular format. Each row of a MacroTest
pattern file is converted to a scan test (scan chain load, apply primary
inputs, measure outputs, pulse the clock, scan chain unload). You must
provide both the input stimulus as well as the expected responses for
outputs. MacroTest takes the input stimulus and justifies it back to a
primary input or scannable element. The expected responses are
propagated forward to a primary output or scannable element.
So "what's required to use it?", you ask.
All that we needed to invoke MacroTest was the pattern file and the name of
the instance to apply the patterns to. The setup for MacroTest is the same
as for running normal ATPG patterns using Mentor's FastScan. Instead of
using the "run" command you just invoke MacroTest:
macrotest <instance_name> <pattern_name> [options]
The definition of a macro for MacroTest is a top-level model in the ATPG
library. This model defines the pin direction and the pin order in the
pattern file. The <instance_name> must be an instance of this model as
defined in the library.
The pattern format is the biggest weakness of MacroTest. Everything must
be specified in binary. The patterns quickly become unreadable in this
format when you have lots of I/O or wide busses. To get around this we
normally write patterns in Perl and output them in the format that MacroTest
expects. Alternately, you could set up a block level simulation of your
array in your favorite simulator and sample the stimulus and expected
responses to create the input for MacroTest. Its pattern file does support
comments and a means of specifying the ordering of pins.
Debugging
---------
Sometimes the tests you can write at a block level can't be applied once the
array becomes embedded. If you know these restrictions up front, you can
save yourself some debugging effort. If you don't know much about the
environment the array is embedded in, you'll need to rely on the debug
information that MacroTest provides. This is an area that has seen a lot of
improvement since we first started working with the tool. We're using
version v8.6_4.8, which was just released in December. The default for the
tool is to report all warning and information messages. It's important to
leave this "on" when trying a macro for the first time.
MacroTest starts off trying to justify the input stimulus. If it can't, it
goes through a process of trying to determine what couldn't be satisfied and
why. From what we can tell from error messages we've seen, MacroTest will
let you know if it can successfully justify each input pin individually. If
it can't, it lets you know which pin(s) it's having trouble with. If it can
justify the input stimulus individually it will then try and determine what
combination of inputs is causing the problem. Since MacroTest will
generate patterns that adhere to any ATPG constraints you applied, it will
also try to tell you if the problem is related to the constraints or not.
We've found that MacroTest does a pretty good job of reporting/identifying
problems with the input stimulus. When multiple input pins are in conflict,
you'll occasionally get extraneous pins listed as being part of the problem,
but we don't see this too often. To further debug problems you can use the
"report test stimulus" command.
Once MacroTest can justify all the inputs, it then works on propagating the
outputs such that they can be observed at primary outputs or scan elements.
This is another area that has seen dramatic improvement since we began using
the tool. There are 2 modes/algorithms for propagating the outputs. One is
random the other is deterministic. The random algorithm uses heuristics to
guide the selection of the observe point and is invoked by a switch on the
MacroTest command line. There are some additional switches to control how
many attempts are made at observation before it gives up. If the random
algorithm was not able to observe an output, MacroTest issues a warning that
the output can't be observed and it continues working on other outputs that
can be observed. The deterministic algorithm pre-selects observation points
and uses them for the entire pattern.
The majority of the arrays we test with MacroTest are successful with the
random algorithm. The remaining arrays require the use of another switch
for random mode, which forces it to exhaustively examine the search space
for a solution. The arrays that seem to require the exhaustive search
typically have many observe points and/or have more complex logic to
propagate through.
Testing Multiple Arrays At Once
-------------------------------
MacroTest allows you to apply tests to multiple arrays/instances at once.
You will probably find that there are some arrays that can't be tested in
parallel due to pattern conflicts. We end up doing a couple of MacroTest
runs because we have some arrays that can't be tested in parallel. Being
able to test multiple arrays in parallel is a big test time advantage.
Mentor MacroTest Summary
------------------------
Plusses:
- The diagnostic messages, while imperfect, are fairly sophisticated.
- The scan cells chosen for the application of the pattern can
either be static or can vary dynamically throughout the pattern.
- Honors existing ATPG constraints while generating patterns.
- Allows merging of multiple macro tests.
- Runtime performance is good.
- Can force MacroTest to use specific observation sites if desired.
- Fault simulation capability provided.
Minuses:
- You can't have any scan elements inside the macro itself (ouch!).
- The pattern format is primitive.
- If a transparent latch feeds a black box macro that you're trying
to test, MacroTest won't be able to justify the input back through
the transparent latch. A work-around exists for this situation.
- Doesn't handle bi-directional pins (not an issue for us).
MacroTest is still a first generation tool and there are many improvements
that could be made, but overall we're happy with the results we're getting.
We've been fortunate to be able to work directly with the developer for any
problems we've faced. The response time for bug fixes has been great.
- Tim Wood & Grady Giles
Advanced Micro Devices Austin, TX
|
|
