[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