Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!ames!ubvax!weitek!sci!kenm
From: kenm@sci.UUCP (Ken McElvain)
Newsgroups: comp.arch
Subject: Re: Testability Features
Summary: Sequential test generation
Message-ID: <31902@sci.UUCP>
Date: 18 Dec 88 00:06:51 GMT
References: <8453@bloom-beacon.MIT.EDU>
Organization: Silicon Compilers Systems Corp. San Jose, Ca
Lines: 91

In article <8453@bloom-beacon.MIT.EDU>, lethin@athena.mit.edu (Richard A Lethin) writes:
> 
> I'm curious about how people designing RISC chips and microprocessors
> test them.  We're designing a small VLSI processor here and would like
> to do it right.
> 
> There seem to be lots of great algorithms for strictly combinational
> circuits, but when state gets added, the answer seems to be "make
> every register shiftable" to allow the circuit to be analyzed 
> as a combinational circuit.

There are a few available programs that can cope with sequential circuit
test generation.   We supply one, and to be fair, Zycad and 
HHB(->Cadnetix->Daisy???)  also have products for sequential test
generation.  Research in this area is much lighter than in
combinational test generation, but the approaches are much more
varied.  Differences in capablity of available programs lie in
the size of the circuits handled, effectiveness in dealing with
sequential behaviour, available modeling primitives (usually gates
and latches, we support tristate and precharge bus drivers and
RAM and ROM primitives.).  I like to believe that mine is the best.

> 
> A RISC chip, with a bunch of on-chip registers, a TLB, pipeline
> registers, a limited number of IO pins, and irregular logic would seem
> to be a testability nightmare.  But gunking up a pipeline register to
> make it shiftable seems drastic.  The state's not regular enough, like
> a DRAM, to just run patterns, so, how is it done?

The way we do it is to turn the test generator loose on the chip
overnight with no design for test.  In the morning we look at what
parts of the chip weren't tested.  We then determine via a combination
of coverage percentages, testablility analysis, and brain power,
what the problem was and then we set up a control file that
tells the test generation program which internal nodes to treat
as external inputs and outputs.  This is far less overhead than
making every latch scanable.  You can usually keep the intrusion
off of the critical path as well.

> 
> How about testing the small, on-chip data cache?  That certainly
> isn't going to be made shiftable...

You should be able to isolate it from the rest of the chip with
a boundry scan path .

> 
> What specific testability features are added to the chip? LSSD?
> OCMS? Special opcodes?  RESET? Special test pins or pads?
> 
> Are test vectors generated by hand?  If so, how long does that take?
> And who does it?  If not, how are they generated?

Generation of test vectors by hand has been known to take longer
than the design.  Especially if you want high test coverage.
Fault simulation time can eat you alive.

> 
> How much coverage do you get?  Is the coverage satisfactory?

One thing to remember is that 99% fault coverage (ignoring the question
of fault models) does not mean that 99% of the chips that pass
your test are working parts.   Chip size and defect density also affect
the answer.  To see this, think of the remaining %1 of the faults
as an area A.  If the defect density D is such that A * D = .1
then 10% of the passing chips will have a fault in the untested
area.  Realisticly then, large chips need to have better fault
coverage than small ones to achieve the same defect rate in 
tested chips.

> 
> How long does it take to run the vectors on the chip?  What hardware
> do you use?
> 
> -- Rich

A couple of references if you are curious.

The basic idea in [1] is to analyize the circuit and derive a partial
state transition table.  [2] is the basis for both Zycad's and HHB's
products.  The idea is to start at the outputs and work back towards
the fault, maintaining a current and previous instance of the circuit.
EBT stands for Extended Back Trace.

[1] Hi-Keung Tony Ma, Srinivas Devadas, A. Richard Newton,
Alberto Sangiovanni-Vincentelli, "Test Generation for Sequential
Circuits," IEEE Trans. Computer-Aided Design, Oct 1988

[2] R. Marlett, "EBT: A comprehensive test generation technique for
highly sequential circuits," in Proc. 15th Design Automation Conference,
June 1978, pp 332-338