Re: test (was: Re: [f-cpu] No latches, please !)

[Kim Enkovaara <embo@mpoli.fi>]

> Testing is also required in another situation : during fabrication,
> just before the dies are packaged. As Kim mentions, it's a cost-sensitive
> place because each second the test equipment is used must be paid
> (i don't remember the prices however). Given a wafer whith 100 dies

I doubt that you have heard the excact figures. These figures are almost
as sensitive as real yeild figures. FABs don't want to give the customer
too much information about their financial parameters of the process. Of
course the testing time can be seen in the chip costs, but usually they
are embedded to the total cost. And when memory testing is usually the
dominating factor some maximum times can be calculated.

> and if the tester uses 1 second to move from one dies to another,
> it is already 1 minute and 40 seconds to pay. correct me if i'm wrong.

Also tester reloads are expensive if the vectorset doesn't fit into the
tester memory. But that is a problem for very complex and huge chips. For
that vector packing is used.

> Scan chains are simple and easy means to test a circuits but
>  - the FF cells are larger

Not very much fortunately. Bigger problem is the extra routing needed, but
current processes have enough metal layers and this is not so big problem.

>  - the testing time is somewhere near O(n^2) for n FF
>  (the testing time for a N I/O circuit is roughly proportional to N
>   and a scan chain requires N cycles to be replaced)

Actually the time is not that big. First trick is to cut the scan chains
to many parts, usually 8-16 chains are supported in the testers. Also the
vectors can be optimized, not all combinations need to be tested. Scan
chains are used for chips that have millions of gates and testing time is
still reasonable (in order of seconds).

> So it is only good for specific parts of the circuit where other
> means to bring data and verify it do not exist. Whenever there
> is a simple and fast way to test a part of the circuit, it must be used,
> particularly because generating the "vectors" of the scan chain
> is complicated and these vectors must be stored somewhere (more surface).

The vectors are usually in the testers. Chip testing is part of the whole
manufacturing process, the vendor does this part of testing. If you start
to store vectors to chip that is LogicBIST already.

> If the scan vectors can't be stored onchip, the external tester
> must provide them and the test can't work at full circuit speed
> (there is a risk that high-frequency specific errors [such as
> those due to crosstalk] can't be detected).

These are problems that are not detected, but they should be attacked
during design. Crosstalk can be minimised with special tools and that is
part of the layout process. The manufacturer can check process goodness
with their own proprietary structures in the chip. In processor business
after the first test for manufacturing fauls the chips are run at
different speeds and separated to different lots. But this part might not
be supported by the fabs, they are only interested that manufacturing was
correct and minimum requirements were met.

> Using LFSR is another possibility for faster testing. It still requires
> modified FF for initialising the state and switching between test/functioning
> mode and the fault coverage is high with no vector ROM. However it's not

Actually LFSR style LogicBIST is good for fullspeed testing of the chip.
But it is not good for manufacturing test that needs good coverage.
LogicBIST is usually used to test chip integrity by running it in
redundant parts over night in missin critical solutions. Actually this is
what vendor of LogicBIST tools said :)

> Testing time however can take a similar time as a simple scan chain
> because the LFSR must explore enough states (goes as 2^N). The problem is

The problem is bigger with LFSR because the vector space can't be
optimized. You just use random vectors and hope that they catch errors.
The coverage can be simulated but that is quite slov job.

> to know when enough states are explored, how many cycles are necessary until
> 100% coverage is reached. Once again, correct me if i'm wrong.

100% coverage is not usually possible because of monetary reasons. That
would take too much tester time. Usually >95% coverage is adequate, in
huge volume chips this figure might be >97%.

> The other advantage is that because the test "vectors" are internally
> generated, there is no need to provide them through an external test interface
> and the freqency can be the real operating frequency, thus catching errors
> that could not be detected at lower frequencies.

The external interface is usually muxed to existing IO. You just have few
test pins that change the I/O functionality.

> The previous means are used for logic stages. For example, a 16-bit LFSR
> can be used to test the opcode part of the instruction decoder and a signature
> is collected with another (much larger) LFSR at the other end. When the
> signature does not match, there is an error which is forwarded to the tester
> or the rest of the circuit which does not boot.

How have you tought to change this information to test coverage.
Manufacturers won't manufacture a chip if they doubt that the test
coverage is not good enough. There are tools to simulate test coverage,
but again they are quite expensive stuff.

> * For the memory arrays, another method is useful, which i used already.
> The vectors are very easy to generate and scales well with the cell number
> (O(log2 N)) but we are limited by the bus width so a multicycle unit is necessary.
> For the register set, for example, we need 2*(63*Log2(63*64)+1)=1512 R+W cycles
> per write and read port. This can be reduced by not sending identical/duplicate vectors
> because since the access bus is not 4032 bits wide, it would send duplicate data.
> Remark that this method catches ALL coupling between any wire, on top of the
> usual stuck at 0 or 1. The same method can be applied to the caches.
> Another remark is that the result of a read, instead of being sent back
> to the BIST unit, can be chained with other units before the usual verification
> in a MISR.

For memory testing there are huge pile of algorithms to choose how the
memory is tested. Memories have quite often faults that come from the
neighbouring cells and simple tests wont detect those. Good book about
memory testing is Van de Goor: Testing Semiconductor Memories. In short
good algorithm for memory testing is some form of the March algorithms. I
guess that google search rteturns quite much about this. Also IEEE library
has good papers about memory testing.

> Remember that i have designed a testing equipment for Mentor Graphics ;-)

Hmm.. I tought that those were just simulation accelerators that are made
in France. Isn't FastScan, LogicBIST, MemBIST etc. US products. And as far
as I know Mentor doesn't do manufacturing testers :)

> And i currently have testing courses and practice in the university.
> i know it's not directly related but the methods i will integrate in the
> BIST unit are a sophisticated version of the "logarithmic" test method
> that is used for routing equipment : exhaustive, simple and fast.

Actually what I learned at university about testing was something from the
80s, unfortunately, I hope you have better lectureres. Most of what I know
comes from matrial by Ben Bennets (http://www.dft.co.uk/).

> When it's ok (half a second), the circuit must verify that it can access
> the outside pins, so the tester starts to communicate with the circuit,

Functional vectors are not so common in testing, but of course they can be
used. In normal testflows they are fed in after normal ATPG tests to make
few additional checks.

> One thing to keep in mind is that the tester, for cost reasons, might
> not provide as many pins as there are on the chip and the tester speed
> is probably lower than what the tested circuit can run. For example an
> old, second-hand or cheap tester can provide only 64 I/O pins
> and work at 10MHz while the chip could run at 100MHz (just an example,

Actually that is not usually the case. When you select packages etc. for
the chip the manufacturer has to allocate tester for manufacturing of the
chip (decide what manufacturing and tester lines are used and if they are
free). If there is no such tester manufacturer is forced to get a new one.
That is part of NREs and testing costs of the chip. Of course this is
different if some chip is very low volume, then long testing times are not
so hughe problem.

> Usually, when the number of pads is larger than what the tester
> can do, several passes are done on different sections of the circuit.

This is possible, but I doubt that this is very common.

--Kim
ps. I'm not an testing expert, I have just seen few ASICs done :)

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/