( ESNUG 320 Item 10 ) --------------------------------------------- [6/2/99]

Subject: ( ESNUG 316 #3 ) Transmission Gates In Libs Ruin Fault Coverage !!!

> We're facing a Design-For-Test problem.
>
> In our library we have some MUXes made of transmission gates.  We manually
> instantiate these cells in our datapath for fast timing.  For example, we
> have a cell DSEL4, which has 4 i/ps, 4 selects and 1 output.  We always
> have a decoder in front of such MUXes for the select lines.  (Actually in
> our design, the selects for the MUXes are not decoded.  So using a
> decoder, we generate fully decoded selects which drive the pass gate
> selects.)
>
> So we assure that, ONE & ONLY ONE of the selects is ON at any given time.
>
> Now my problem is the stuck-at faults at the select pins of these pass
> gates are untestable.  So, can I do something to make them testable???
> I would also like to know the best way to model them in Synopsys.  Right
> now they're modelled as bufif.
>
> We have many such cells in the design and the fault coverage reduction is
> required is huge.  So, we can't neglect them.
>
> Please, help!!!
>
>     - Nukala Ravikanth
>       Meridian semiconductor


From: Hannes Froehlich <hannes@elaborate-designs.com>

John,

This designer could add an XOR-tree (testpoints) and a register (add to
scan chain) to observe the select lines (given you can live with some
additional gates).

    - Hannes Froehlich
      Elaborate Designs

PS: John, this should count as one point (against tri-states) in the long
    lasting battle on whether to use tri-states or logic gates for muxing.


> Now my problem is the stuck-at faults at the select pins of these pass
> gates are untestable.  So, can I do something to make them testable???
> I would also like to know the best way to model them in Synopsys.  Right
> now they're modelled as bufif.


From: gsp@enigma.mlb.semi.harris.com (Gary Porter)

I recommend replacing the entire mux model with a model of the cell that
only uses ands, ors and inv's. Completely ignoring the internal structure.
And suppress faults inside the cell.  The "stuck-at" model is still
valid at the pins of the cell.

    - Gary Porter
      Harris Semiconductor

         ----    ----    ----    ----    ----    ----   ----

From: Nukala Ravikanth  <ravikanth@msemi.com>

Hi John,

I think that Gary's solution won't work with pass gates.

Right now I have a solution but dont know whether it is the best or not.

The solution is 2 fold, one for Stuckat1 faults and another for SA0
faults.  I added a pullup cell(to test SA0 faults) at the o/p of each such
passgate mux.  The pullup is an active one which i will switch off during
normal operation as I don't want my fall times to be affected.  Also, I
had to add some control points (NOR gates) to the selects of the muxes,
to enable the ATPG tool to force all zeroes at the selects of the
passgate mux.  The main problem is, as selects are driven by decoders, we
cant have all zero combination at the selects.  This combination (all
zeroes means all pass gates are off) is needed to test the SA1 faults at
the select pins.

This solution gives 100% coverage but in case select lines are timing
critical, we can't add control points to the selects.  So for those select
paths which are timing critical, we need to have a compromise over
the fault coverage.

    - Nukala Ravikanth 
      Meridian Semiconductor

         ----    ----    ----    ----    ----    ----   ----

From: [ A Former Sunrise/Synopsys Test CAE/Consultant ]

As a former Sunrise/Synopsys Test CAE/Consultant, this issue is fairly
common on custom designs that use fully-decoded N-input muxes.  Modeling
these with bufif1 primitives is fine for TestCompiler or TestGen.  The issue
is more fundamental to the stuck-at fault model and this type of circuit.

First, consider a single pattern test to detect a S-A-0 fault on a bufif1
enable (mux select pin.)  This test will have to sensitize this pin to a
1, which implies that all the other mux select pins are a 0.  If this pin
has a S-A-0 fault, the faulty machine bufif1 will produce a Z and the mux
will output an X.  At best this can only lead to a potential detect.  Now
TestCompiler will give credit to half the potential detects in the final
fault coverage.  And TestGen provides an option to re-classify a potential
detect as a hard detect once a specified detection count for that fault is
reached.  So some creative accounting can make the fault coverage look a
bit higher.

If the mux were to contain a bus holder or charge storage, TestGen
sequential ATPG would create a two pattern test to detect the S-A-0 fault
on the bufif1 enable.  The first pattern selects data through another mux
input and stores this value in the mux.  Then the second pattern selects
the opposite data through the target input.  In the presence of a S-A-0
fault, the previous data will be retained rather than overwritten.

S-A-1 faults on the bufif1 enable can never be hard detected because any
test will have to sensitize this pin to a 0, which implies that one of the
other mux select pins is 1.  If this pin has a S-A-1 fault, opposite data
on the selected input will create a tristate contention which produces an
X on the mux output.  Like the S-A-0 faults, giving credit to potential
detects may help

If the decoder and mux combination can be re-modeled as a single, encoded
mux cell, a complete set of patterns will be generated and a full coverage
will be reported.

    - [ A Former Sunrise/Synopsys Test CAE/Consultant ]