Re: Exchange of mail on Test benches and benchmark requireme

[Scott Davidson <scottdav@hsmpk12a-s1>]

> From: Brion Keller <kellerbl@us.ibm.com>

> 
> Scott,
> 
> Since there will be a lot of variability to the DFT applied to an RTL design, 
I
> would suggest that for all RTL designs we have a specific gate-level design
> with DFT already applied (i.e. scan of some sort has been inserted).  This 
will
> allow comparison of the back-end tools.  It will also be a good basis on which
> to compare other DFT results.  Those that want to compare DFT results can,
> while those who prefer to focus on the ATPG and/or fault simulation results 
can
> do so as well.
> 

I hope that we can get someone to volunteer to run test generation on full scan 
versions of all of these circuits.  However, I hope that no one puts a lot of 
academic research effort into better full scan!  Advances in this are 
incremental, at best, and there are plenty of industrial tools you can buy if 
you want to do full scan (including yours :) ).  Some people might want to 
insert DFT at the gate level, and we want to allow this.  The shipped circuits 
should not have DFT, and I hope there is a wide range of techniques about which 
people can write good ITC papers.

> Regarding a desire to see RT level ATPG/Fault Simulation, this may conflict
> with also trying to model real defects which will very likely depend upon the
> cell library that is used to map the design.  Faulting cell library members'
> I/O pins seems to be a typical approach used in the industry, but it doesn't
> work well with larger cells.  It took us many years to finally model latches
> with a single primitive in IBM because we would lose the ability to fault the
> inside of the latches (feed-back loops and special port designs).  There is
> still the possibility of using a combination of high-level (RTL) design data 
in
> combination with gate-level to allow more realistic fault models along with
> higher performance.
> 

Alas, you are quite correct.  I don't expect to see much in the way of fault 
model advances  coming out of this (except mapping RTL -> gate level.)
It might be nice to manufacture these designs some day so such experiments could 
be done, but I'm not even thinking about that now.  Fortunately, we've got 
excellent work such as the Sematech experiment and the Stanford Murphy 
experiment to teach us about real defects and fault modeling.

Scott

> Brion Keller
> Sr. Software Engineer
> TestBench Architecture
> ph: (607) 755-8231 IBM tie-line 855
> Fax: (607) 755-5608
> 
> 
> 
> Scott.Davidson@Eng.Sun.COM on 05/26/98 03:34:42 PM
> Please respond to Scott.Davidson@Eng.Sun.COM
> To: Gordon_Robinson@credence.com, Scott.Davidson@Eng.Sun.COM
> cc: dftbench@voyager2.Eng.Sun.COM
> Subject: Re: Exchange of mail on Test benches and benchmark requireme
> 
> 
> Perhaps everyone submitting a circuit could also submit a form like this:
> 
> 
>            RTL            |  Netlist               |  Library
> --------------------------------------------------------------------------
> Design    VHDL | Verilog  | Verilog | EDIF | VHDL  | Verilog | Bench | Prop.
> 
> 
> With checkmarks if the circuit were available in the particular format.
> As time goes on, we could get more boxes filled in, as we got people to do
> translations, as Gordon suggests.  I definitely agree that for the first pass
> we
> do not need all the boxes checked.
> 
> I've seen some comments suggesting that we don't want EDIF as an option.  Any
> comments?
> 
> As for libraries, Verilog means all libraries experessed in terms of Verilog
> primitives, for portability, Bench means a basic set of primitives which we
> will
> define, and which all benchmark circuits should be expressed in terms of, and
> Prop. means a proprietary library.
> 
> We'll need another table to describe the features of each circuit - how many
> state elements, if there are memories, what DFT any is included, etc.
> 
> Any additions?  I will put up a table in HTML when I set up the web site.
> 
> Suppliers: Can you fill in at least a few of these boxes for your designs?
> 
> Users:  Are these okay?  Which boxes do you want to see checked?
> 
> Scott
> 
> 
> > Date: Tue, 26 May 1998 07:36:37 -0700
> > From: Gordon Robinson <Gordon_Robinson@credence.com>
> >
> >
> > I think that we have to be realistic about what formats and materials
> > we can obtain from willing suppliers. If we insist on too much,
> > then we will end up with no benchmarks.
> >
> > Maybe we should look at two phases of getting varied formats.
> > In the first phase, circuits are donated. In the second phase
> > the work of removing existing DFT structures and of language
> > conversion is done.
> >
> > There are several ways that may work for the conversions. Some
> > companies have tools that convert Verilog to VHDL or vice-versa:
> > maybe they will allow those tools to be used to perform the
> > conversion. (Hmmm, interesting experiment: take a circuit in Verilog,
> > run tools, convert to VHDL, convert that back to Verilog, run tools
> > again, see how different they could be.) Another method could
> > be to get universities to perform the conversion with grad students,
> > so as to produce a "natural" version on the second language.
> >
> > --
> > Gordon D Robinson
> > Credence Systems Corporation
> > 215 Fourier Ave
> > Fremont CA 94539
> >
> > Tel: (510) 623-5139
> > Fax: (510) 623-2549
> > Email: Gordon_Robinson@credence.com
> > ITC: http://www.itctestweek.org/
> 
> Scott Davidson
> Sun Microsystems
> scott.davidson@eng.sun.com
> 
> 
> 
> 
> 
> 

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