( ESNUG 302 Item 1 ) --------------------------------------------- [10/21/98]
Subject: (ESNUG 300 #3) Comments On The Current State Of The Test World
> Here's my take on the current state of the test world: ...
>
> 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. ...
>
> - Shankar Hemmady
> Guru Technologies Cupertino, CA
From: dchapman@goldmountain.com (Dave Chapman)
Dear John,
Shankar has many good things to say, and I would like to add a little:
1. There have always been two different test requirements: Functional
testing used in development, and go/no-go testing used in production.
It does not seem likely that both needs can be met by the same tools.
2. The one test which confirms whether your design has a chance of working
is this: Set all register bits to 0, then read back; set all register
bits to 1, then read back. Despite much progress over the years, stuck
bits are still the most common type of manufacturing error.
If you cannot perform this test, then I suspect that you cannot test
the device at all.
3. JTAG is the gold standard here. Any proposed testing method should be
(and will be) compared with a comprehensive JTAG solution.
Worst thing about JTAG: It eats silicon like pop corn.
Second worst thing about JTAG: It is not as easy to do right as people
think.
4. BIST is a software concept.
The era of building stuff and hoping that it works is long gone, and the era
of building stuff and hoping that the test guys will figure a way to verify
operation is rapidly fading. TODAY, A TEST STRATEGY MUST BE PART OF THE
INITIAL DESIGN. Everybody already knew that, right?
- Dave Chapman
Goldmountain
---- ---- ---- ---- ---- ---- ----
From: Duncan M. (Hank) Walker <walker@cs.tamu.edu>
John,
Shankar's message was nice, but had one glaring ommission: IBM TestBench.
This is the grandfather of all the other tools, and had the capabilities he
mentioned at earlier dates. It is primarily an internal tool, but IBM does
have quite a few external TestBench customers, they have a booth at ITC,
etc. IBM has also used logic BIST in production. The S/390 processor
chips have about every form of test known.
- Duncan M. (Hank) Walker
Texas A&M University
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
From: rp00280@email.sps.mot.com (Morgan Monks)
> Shankar, Very good comments on the EDA Tools in ESNUG.
>
> I work in a Standard Cell Foundry at Motorola Semi. My team has developed
> a Memory BIST Tool set which inserts Memory BIST into the netlist at the
> Verilog Netlist level. Your comments that BIST should be like scan is what
> my team did. We find this approach is accepted by the customers.
>
> - Morgan Monks
> Motorola Semiconductor Products
From: Shankar Hemmady <hemmady@gurutech.com>
Morgan, My personal opinion is that both the scan tools and the BIST tools
should be avialable at the same level(s). Some have succeeded in doing
this at the RTL level with some limited correlation between extra test logic
and extra coverage. Many have been successful at the netlist level.
Question: don't you find the netlist overwhelmingly large at the netlist
level these days? Do you still prefer to operate at the netlist level for
all forms of testability?
> In a way I would like to see a commerical vendor adopt this approach to
> insert at the netlist level because this would allow other Motorola groups
> to purchase the software. How many embedded memories have you worked with
> in MEMORY BIST ? We are currently doing 6 million plus transistor chips
> with 200+ embedded memories.
My usage of memory BIST is limited to only a couple of multimedia chips
which had a few embedded memories. I know of some people who have used
it in a lot more complex situations. Yours seem to top the list.
Did you share the BIST logic among memories of similar sizes? How did the
team and the management perceive the so-called BIST overhead requirements?
- Shankar Hemmady
Guru Technologies Cupertino, CA
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
Shankar Hemmady <hemmady@professionals.com> writes:
> Question: don't you find the netlist overwhelmingly large at the netlist
> level these days? Do you still prefer to operate at the netlist level for
> all forms of testability?
From: "Morgan Monks (rp00280)" <rp00280@email.sps.mot.com>
Shankar,
Working with the netlist is a large database -- but since I am in a foundry
the customer won't share the RTL files since it's his IP. Also we wanted to
create a system where the BIST logic stays out of the designer's hair as
long as possible.
I use Synopsys Design Compiler to do the "weaving" of the BIST logic
into the Gate level netlist. I also have a couple of tricks which make this
go quickly.
I always stay at the netlist level. It keeps our customer's IP on his site
and I don't change any of the hierarchy in doing the weaving. This approach
also lets me change the BIST and be independent of the customer's design.
This is good since many of my customers will re-use the RTL and if BIST had
been inserted I would have to keep this updated in the field.
Concerning your question of "Did you share the BIST logic among memories of
similar sizes?" -- We have a single controller for all the BIST memories.
Each BIST ram has a "wrapper" or "collar" which contains the BISTregister
and BIST RAM. The customer instiantiates a BIST ram which has all the
BIST inputs tied off so the customer only makes system connections to the
RAM. During the weave the weaving tool removes the ram and inserts a new ram
which has the BISTregister contected to the RAM and new BIST ports. Since
the old RAM wrapper and new are the same port for the customer nothing
changes as far as the customer's logic is concerned.
> How did the team and the management perceive the so-called BIST overhead
> requirements?
My overhead is 5% or less. So far this has been recieved very well. Of
course, as I go to larger number of RAMS the overhead increases since the
BISTregister grows.
I will give a paper on this topic at DesignCon 99 in Feburary 3, in
Santa Clara. (Look at www.designcon.com and search for "schedule".)
- Morgan Monks
Motorola Semiconductor Products
|
|
