[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exchange of mail on Test benches and benchmark requirements



> 
> > From: Sitaram Yadavalli <syadava@cadev6.intel.com>
> >
> > Before we endorse any circuit as a benchmark we should put in place a
> > ballot process so that we all agree that each of the benchmarks is at least
> > complete, in that it has all the requisite material(s) coming with it. E.g.
> > A minimum standard would require that a benchmark has synthesizable RTL in
> > Verilog AND VHDL, it has the corresponding gate-level descriptions with a
> > standard cell library AND also with structural Verilog primitives. It should
> > have gone through some amount of design verification to ensure that the gate
> > level design corresponds to the RTL. It should have a Verilog Test Bench with
> > non-scan test vectors. The corresponding set can also be provided in a simple
> > format like a table.
> 
> Dear ladies and gentlemen,
> 
> I have some comments and questions on this topic. First, I believe this set
> of benchmarks are for checking out test tools, methodology, and algorithms.
> Why then do we need the benchmarks in synthesizable rtl? We should not be
> checking out efficiencies or the nuances of synthesis. That's a whole
> different area.
> 
> I believe the minimum requirement is a gate-level description with its
> corresponding cell library and with no test structures inserted, scan, bist,
> or whatever. In this case the "language" of the design, be it verilog, VHDL,
> etc. is of little consequence since they can all be easily converted from
> one another. Even if all one can get is a design with scan inserted, it's
> fairly simple to remove the scan circuitry. Also with this approach,
> no test benches are needed.
> 
> So I have pared the minimum requirement down to two items - a gate-level
> netlist and a cell library. Even these may be hard to obtain from commercial
> suppliers. Can we simplify the equation further :-)
> 
> Regards,
> Luis
> 
> -- 
>   ____________________________________________________________
>  |  _______                                                   |
>  |  \____  | Advanced        Luis Basto                       |
>  |  /|   | | Micro           Logic Products Division          |
>  | | |___| | Devices         Voice: (512) 602-6592            |
>  | |____/ \|                 Fax:   (512) 602-7683            |
>  |                           Email: luis.basto@amd.com        |
>  |____________________________________________________________|
> 

Hi guys 

Here are some comments.

Before starting with sample circuits, let us have some things like defining
terms. What do I  mean by that is let us define what coverage means.

The way I understand is the following terms

				# detected faults
	raw coverage = ------------------------------- 
				# total faults


				       # detected faults
	testable coverage = ----------------------------------------
				#total faults - # untestable faults


			     #detected faults + #untestable faults
	fault efficiency = -----------------------------------------------
					#total faults

I have seen other defination terms like possible detects, detectable faults, Oscilating
faults etc. I think we should have the fault list for every circuit published after
some analysis and discussion. Also we should try to map the coverage of any ATPG on 
this fault list (this could be a university project) so that there is a independent 
coverage measure.


1. First of all do all ATPG or Fault list generators generate the same fault list for
   a given circuit? Because any interesting fudge in the fault list can make a 
   difference when coverage numbers reach the high ninties.

2. The one issue is that how do we define untestable faults for every given circuit.
   Is there a universal measure for qualifying a fault as untestable which every tool
   has to agree upon. Or otherwise we have to hilight tools who define the untestable
   differently. 

3. Most ATPGs anf Fault list generators have a way of colapsing faults and the actual 
   coverage is on the colapsed fault list. I have seen different fault list generators 
   generating different colapsed fault list. Does it matter whether we have different
   colapsed fault list?

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?

5. Do we have redundancies in the sample circuits, because a lot of times real 
   synthesis leaves some redundancies which can cause a slow down in the ATPG.


There are a lot of these issues we should discuss along with the debate of what circuits
to use as samples. You may have more of these issues to add to the list. 

-- 
**************************************************************
Prasad Mantri				Phone - 650-933-4331
Scalable Network Servers Division         Fax - 650-932-4331
SILICON GRAPHICS INC.			      mantri@sgi.com
2011 N Shoreline Blvd.
Mountain View CA 94043-1389
**************************************************************