Re: new benchmarks: tristate conflict avoidance

[Scott Davidson <scottdav@hsmpk12a-s1>]

> From: Gary Greenstein <garygr@Synopsys.COM>

> 
>  
> Hello all,
> 
> I wanted to comment further on something mentioned in the last email,
> from Mario Konijnenburg and Hans van der Linden: tristate conflict
> avoidance.  Enclosed are all the snips I could find on the subject,
> from emails sent to this group.
> 
> To clarify: the issue is to avoid conflicts, not just recognize them,
> both during functional operation, and while shifting scan chains
> themselves.  This can be done either through DFT or ATPG; frankly, I'm
> interested in evaluating methods from both approaches.  ATPG has to
> contend with a ratio of many thousands of buses to protect, both
> before and after pulsing clocks, to one measly little fault to detect,
> not to mention vector compaction in the presence of these potential
> conflicts.  DFT has to contend with timing considerations on what is
> often the most timing-sensitive portion of a design.
> 
> So I agree that the new set of benchmarks should have at least one
> design that has thousands of unencoded tristate bus lines, and that
> the ATPG tools should be graded especially on vector compaction
> for that circuit.
> 

I hope you have just a case to donate!

I think test generation time would be another issue.  Identification of tristate 
problems, and the generation of the appropriate vectors that avoid the problems 
can be quite time consuming.  

In custom designs, not just busses but also pass gate muxes can be a problem, so 
let's see an example with a few thousand of them also.

There are circuits for which test generation may be impossible with current 
technology.  Consider the case where a set of flip-flops, without set or clear 
lines, drive a set of tristate enables on a bus.  Unless you force these FFs to 
power up to a safe state, powering up to Xs will force a bus conflict before the 
ATPG can do anything about it.  The ATPGs I know just give up in this situation, 
the good ones identify the source of the problem.  I would not want to see this 
case in the benchmarks, since it is a pathological situation.

Scott

> 
> Thanks.
> 
> 
> Gary Greenstein
> Synopsys Inc.
> garygr@synopsys.com
> (508) 303-5294
> 
> 
> 
> 
>     Circuit features that should be included are (preliminary list from
>     D&T column):
> 
>     o Internal busses - not fully decoded.
> 
>     ------
> 
>     4. One other intersting thing to consider is tristate bus conflicts in the 
ATPG tools
>        we have to understand what to do when there is a bus conflict for a 
given vector,
>        some tools drop the vector , some tools accept the vector and for some 
tools the
>        chioce is programmable. How do we handle this?
> 
>     ------
> 
>     Which companies ignore bus conflicts?  I want to stay away from their 
ASICs!
> 
>     Seriously, most ATPGs can guarantee tests without bus conflicts.  How that 
is
>     done is up to them - DFT is helpful, as well as constraints and other
>     algorithmic tricks.
> 
> 
>     ------
> 
>     On bus-conflict-handling:
>     A tool that cannot handle bus-conflicts simply cannot report realistic 
results
>     on circuits containing buses that can become conflicting/floating.
> 
> 

Scott Davidson
Sun Microsystems
scott.davidson@eng.sun.com