Re: Exchange of mail on Test benches and benchmark requireme

[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.

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.

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