( ESNUG 300 Item 3 ) ---------------------------------------------- [10/7/98]
From: "Shankar Hemmady" <hemmady@gurutech.com>
Subject: Some Honest Comments On The Current State Of The Test World
John,
I have been a software developer (non-EDA), an EDA tool developer as well
as a chip verification/test engineer. It is very hard for me to take sides
without seeing all the three areas which now get amalgamated in high-level,
IP-based, deep submicron design with an emphasis on time-to-market,
time-to-volume etc. (Did I get all the buzzwords in one sentence?)
Here's my take on the current state of the test world:
Fault Simulation
----------------
In my opinion, stand-alone fault simulators will not stay for too long in
the current chip development process. There are several companies that
use fault simulation as their only manufacturing test tool. For today's
million gate chips, getting a decent (90%+) stuck-at-fault coverage with
functional vectors alone is a rather tedious and clumsy process.
It is almost impossible to think of a future with several embedded cores
(either third party, or legacy blocks within a vertically integrated company)
and tons of memory, FIFOs, control logic, long data paths, mixed-signal
blocks, etc., where functional test vectors will contribute over 60%
coverage. Also, it should be noted that easy to test core logic suddenly
becomes difficult to test when it is embedded within a larger system-chip.
My recommendation for Fault simulation tools is use them frugally. Use them
only when you have no other choices -- where your cost, speed or other
constraints force you to have a non-scan, non-BIST, non-testable design. Or
you have legacy blocks which you do not want to touch for pragmatic reasons
such as not messing them up and missing the market window. Or you have
simple chips where it is easier to get a good grip on the manufacturing
coverage without using any DFT techniques. (Other than large memory chips
and certain programmable logic, I can't think of many such chips.) Even in
such cases, try to see if you can make some use of other DFT tools, as
little as you may want to use them, to alleviate some of the major test
bottlenecks you will face with functional test alone.
Which tools should you use for Fault Simulation? Use the ones that are
easiest to use with your current functional test development environment.
If you use Verilog, try to go for Verilog-based tools. If you use VHDL in
a particular flavor, see if your simulation vendor also has a fault
simulation solution. The speeds of FS vary significantly depending on the
algorithms they use. But more often, the problem of setting up the FS is
harder than the raw speed of FS. Therefore, it is important to ensure that
you can fault simulate your vectors as easily as you can create them. I do
not worry about "full-timing" fault simulation and other esoteric
capabilities. In my experience, it does not contribute a whole lot except
good press. Most of the folks I know really use them for stuck-at fault
testing, and generally use them on synchronous or almost-fully-synchronous
logic. Even those that buy full-timing, mixed-level fault simulators end
up using them at the gate-level (possibly with RTL or testbench wrappers)
in the functional test mode.
I won't recommend any vendor names for FS tools since companies that seem to
make money on these tools seldom last for a long time, and seem to drop out
of the business over time. If you intend to use substantial amount of scan
or other DFT logic, you may want to consider using the Fault Simulators in
the DFT environment. You may have to work exclusively in a gate-level,
non-timing environment. But it may be worth the effort if your scan logic
is substantial.
Scan-Based Test & DFT Tools
---------------------------
These are currently the most popular type of manufacturing test tools. One
of the earliest successful set of "Test Synthesis" and ATPG tools was sold
by Synopsys -- Test Compiler. Although much complained about, for a
disinterested design team and an equally disinterested test/product
engineering team, IMHO, Synopsys Test Compiler tools did a reasonably good
job while using full scan. They have had their problems in more complex
chip test schemes such as dealing with designs using low levels of scan.
Historically, Sunrise became the first tool in this area which was able to
market the idea of "partial scan and 100% coverage for dummies". After a
while, the story was prudently changed to "almost full scan that works really
well". Having been a part of the engineering team and applications team at
Sunrise in my past life, I am quite happy to say that the tool has worked
quite well in most chip design/test configurations and has withstood the
most esoteric demands of design engineers.
But it has never been an easy to use tool. In many cases, I found that the
Synopsys Test Compiler was easier to use if all that I wanted was full scan
in a "testable" design enviroment (little asynchronous logic, plenty of
controllability and observability hooks etc). But like a good old pickup,
Sunrise has a lot of raw power, which if harnessed properly could deliver
good coverage. The first time around with Sunrise has usually been support
intensive for most customers. Personally, I have used Sunrise tools the
most and being conversant with many of the idiosyncracies of partial scan
and the tricks you can use with Sunrise helps a lot.
Mentor's Fast Scan and Flex test tools, in my experience, seem to need less
support than the Sunrise tools. Online documentation and tool maturity
with some of the larger chips has made these tool quite a bit robust and
easy to use. My experience with Mentor's tools is limited. But I certainly
like to use them and they do a good job.
I have never participated in a competitive benchmark of any of the above
test tools. To a large extent, it surprises me to see some customers worry
about the raw speed of running the tools and getting a high coverage with
minimal test logic. There are several competing criteria that a customer
*should* worry about:
* What are your test goals? High stuck-at-fault coverage? Some IddQ
coverage? Any speed testing requirements? What kind of tests do your
customers want/require? What can your semiconductor vendor do for you?
Can you get support from a third-party test vendor or a test expert?
* What are your design and market constraints? Time to market?
Manufacturing cost? Quality, reliability, fault-tolerance? Leveraging
existing designs to create larger more complex chips? Is this just
a sample production run or is it a high-volume production run? Would
your customers rather have an expensive/slower but reliable chip,
or are they simply looking for "cheaper, better, faster" chips? Who is
paying for bad chips? You or your customer ;-)
* What are your test constraints? What kind of testers do you want to use?
Will they have scan features? Who will do the testing -- you or your
semiconductor vendor? What kind of board testing will be employed on
this chip?
* What kind of test methodology do you think is suitable for your chips?
Can you afford to use scan in most of your blocks? How much test
overhead can you live with? Do you intend to use BIST for your regular
structures? Have you looked at BIST for any embedded legacy blocks? Have
you thought about how you will take care of your mixed signal/analog
blocks? Do you have a good handle on some of your logic simply by
leveraging your functional vectors? Do you have the time to use your
functional vectors well? Do you intend to use test logic for easing
board test issues -- such as boundary scan?
* How test savvy are you? Do you have the time, the money and the interest
in learning all about the test problems you face currently and you are
likely to face in the future? How much support can you expect from your
EDA vendor, semiconductor vendor? How is your current test methodology
going to affect any future spins of the chip? Are your current chips
likely to shrink to cores or reusable blocks of embedded logic in a
future design?
The reason I pose these questions is, more often than not, the speed of the
tool is secondary to the design/test environment that you are faced with.
You must give more importance to these points and ask your EDA vendor,
semiconductor vendor, test/tester vendor relevant questions before jumping
to conclusions based on some numerical benchmarks. You *must* perform your
own evaluations and/or look for other chip design/test teams that use
methodologies akin to yours (most often other groups within your own
company, or other companies in your segment of the market).
BIST tools
----------
This area is still maturing. Many large customers seem to have begun using
memory BIST for large embedded memories. Most semi-vendors seem to have a
BIST solution for memories as well. Worries over BIST overhead should become
fewer as the sizes of the memories and their usage in difficult to test
areas within larger system chips increases.
Logic BIST and BIST for analog blocks seems to be in its very early stage of
real usage. Although I have heard of success stories from a couple of
vendors, I am yet to hear anything independently from design/test groups.
IMHO, BIST will become very important over time. It is another story whether
you will need to buy expensive tools to do it. Many of the tools insert BIST
logic at the RTL level (unlike scan tools which usually operate at the
gate-level or during the synthesis process). It is very likely that hard and
soft core vendors will provide testable logic over time using some amount
of scan and some BIST logic. At this time, much of the IP/core business
has many other problems to tackle such as legal, business and verification/
design methodology issues. It is my feeling that manufacturing test issues
will pop up over time as one of the impediments to the proliferation of
leverageable blocks of logic, therefore making it essential to add some
high-level testability early on.
Among BIST vendors, Logic Vision and Mentor seem to be the leaders, along
with half a dozen or so smaller players.
Boundary scan tools
-------------------
These are often sold in conjunction with scan tools or BIST tools. You
should certainly consider your board test environment and/or your customer's
test requirements before using boundary scan. I would simply look for any
specific JTAG or BSDL compatibility issues you may be concerned about.
There are other test tools such as test vector translation tools (TSSI);
virtual test or test environment emulation tools (IMS, Teradyne), mixed
signal test tools. I could spend some time discussing their strengths
and deficiencies. But it may not be useful to most ESNUG subscribers.
What do you think?
- Shankar Hemmady
Guru Technologies Cupertino, CA
|
|
