[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exchange of mail on Test benches and benchmark requirements
> Date: Thu, 28 May 1998 14:23:36 +0200
> From: Mario Konijnenburg <mario@ettin.et.tudelft.nl>
Thank you, Mario, for this very useful mail, and for volunteering.
I'm snipping most of it, (all of which sounds great) and expanding on a point or
two.
>
<snip>
> We have our own gate-level format, next to iscas '85 and iscas '89 'formats'
> etc. support, and convert other gate-level circuits (such as structural level
> verilog (i.e., hierarchical/gate-level)) to these formats in a variety of
> manners.
>
> So we feel that a set of circuits is required in Verilog or VHDL, on RTL, and
> perhaps higher levels, depending on what is available (a benchmark collection
> effort of a few years ago did not get off the ground due to lack of
> cooperation by the companies), and at least a gate-level synthesised version,
> for those who lack high level input AND for having an identical gate-level
> version anyway. This could be structural verilog. Separate versions with and
> w/o scan and with and w/o bist etc, would be useful, but at least a 'bare'
> version seems to be required.
>
> In addition a set of converters has to be written, to (and perhaps from) the
> various other (popular) structural/gate-level formats. It might be useful to
> somehow poll, and make an indexation of which formats are required/useful to
> facilitate an as large as possible portion of the interested parties. Then,
> by contributions, writing, etc, a set of converters, preferably at source-code
> level so people with obscure format-needs may adapt an existing converter,
> should be made centrally available, and circuits need not be offered in a
> variety of formats.
>
We wrote many converters when we were using the proprietary AT&T format.
The biggest problem we ran into was signal renaming in Verilog, which was
not supported by our proprietary format.
Does anyone out there have converters they can make available? Perhaps we could
make the tool available at the web site.
<snip>
> Thus, it seems that explicit target-fault-lists need not be made
> available, as far as SAFs are concerned. For realistic BFs, PDFs, etc, it
> might be useful or even necessary, to indeed provide target-fault-lists,
> esp. as most university groups will not be able to extract the realistic BFs
> etc. Also the realistic BFs depend on synthesis, so having the same
target-list
> together with same gate-level description, is the only way for real comparison
> in those cases.
>
BFs will depend on layout and synthesis, PDFs on timing. I agree, we will make
some set of bridging faults available.
If those people donating implemented designs with layouts can make such a list
available, that would be helpful. Not all BFs are required. For PDFs, a list
that includes false paths will be fine - since identifying false paths quickly
is certainly a good research topic. A few hundred paths would seem to be
adequate.
<snip>
> On Scott's request for volunteers:
> We volunteer to do full-scan ATPG for candidate-benchmarks, if we can get
> them at structural/gate-level. We can handle tristate busconflicts, as well as
> 'fixed-unknown' inputs etc. resulting from 'removed' embedded/adjacent
ROM/RAM/
> analog blocks, etc.
>
> regards, Mario Konijnenburg and Hans van der Linden
>
Thanks!
> P.S. Scott, will you please also put linden@nand.et.tudelft.nl in the mailing
> list.
>
Done.
Scott
>
> --
> ==============================================================================
> | Mario Konijnenburg P.O. Box 5031 |
> | Delft University of Technology 2600 GA Delft |
> | Faculty of Information Technology and Systems The Netherlands |
> | Section of Computer Architecture and Digital Technique (Test Group) |
> | phone(work):+31(0)152786177 fax: +31(0)152784898 |
> | email: M.H.Konijnenburg@et.tudelft.nl |
> | www: http://einstein.et.tudelft.nl/~mario/ |
> ==============================================================================
Scott Davidson
Sun Microsystems
scott.davidson@eng.sun.com