[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exchange of mail on Test benches and benchmark requirements
I have been short on bandwidth for the last few weeks and apologize if I am
repeating any of the suggestions below:
-- it would be useful to have a web-based archival site of all such
correspondence. An example of how such a site (with a search engine) and
threaded index may look like, see (and try out) under
http://www.cbl.ncsu.edu/DiscussionGroups/A-GuestUser-Test-Forum/
If there is interest and perceived need, CBL can set up such a site for
'dftbench' (protected, if this is desired). If you are like me, you can't
respond to each mail on each day, so some place that archives suggestions
and responses can be useful.
-- there may be still time to set up a meeting at DAC -- I am away from
e-mail next week, but Scott may come up with something .... see me at
Univ-Booth 11-1pm each day, the 6-university team project (as per 1998 June
IEEE spectrum article gives some hints of things to be seen) -- for foils
under construction, see
http://www.cbl.ncsu.edu/publications_misc/1998--Talk-DACdemo/
-- as to fault models, I'd advocate ALSO fault models derived from a layout
or at least from a placement file -- after DAC, I'll present examples of
cases where cell OUTPUT pins may replicated, one sourcing the net in one
channel, the other sorcing the net in another channel -- in effect
"splitting the fanout node to feed another fanout node", something not
visible under nominal netlist description. The wire connecting two "fanout
nodes" may be untested or untestable. Further, the placement file alone
also gives the lower bound on the wire crossing of nets connecting the cell
pins -- and hence can be used to "induce" placement-specific "bridging
faults" .... for an example of evaluations of crossing numbers, critical
path crossing numbers, and other "placement parameters", see
http://www.cbl.ncsu.edu/publications/1998--Talk-01-Kapur/1998--Talk-01-Kapur-HTM
L/MS-Kapur11.html
http://www.cbl.ncsu.edu/publications/1998--Talk-01-Kapur/1998--Talk-01-Kapur-HTM
L/MS-Kapur12.html
and for more details, see
http://www.cbl.ncsu.edu/publications/1998-Thesis-MS-Kapur/
For examples of "hard data" and summaries such as
Table Name: TOCO_F@CBL-WD-C1355.table
Column Population Mean Sample Sample Sample
Sample
Parameter (95% conf. interval) Mean Std. Dev. Min.
Max.
--------------------------------------------------------------------------------
TWL [8.1401e+03, 8.3225e+03] 8.2313e+03 4.5605e+02 7.3865e+03
9.1955e+03
CWL [2.4601e+02, 2.5315e+02] 2.4958e+02 1.7873e+01 2.1100e+02
3.0000e+02
TWC [2.9343e+03, 3.0837e+03] 3.0090e+03 3.7345e+02 2.2930e+03
4.3780e+03
CWC [2.7916e+02, 2.9340e+02] 2.8628e+02 3.5586e+01 1.9900e+02
3.9700e+02
AWD [1.1723e+01, 1.2015e+01] 1.1869e+01 7.2919e-01 1.0568e+01
1.3841e+01
Width [2.7990e+02, 2.8632e+02] 2.8311e+02 1.6042e+01 2.5450e+02
3.2650e+02
Height [3.5266e+01, 3.5466e+01] 3.5366e+01 5.0055e-01 3.4100e+01
3.6700e+01
Area [9.8931e+03, 1.0135e+04] 1.0014e+04 6.0436e+02 9.0602e+03
1.1638e+04
--------------------------------------------------------------------------------
see
http://www.cbl.ncsu.edu/experiments/00_Illustrative_Experiments/Physical_Design/
layout-uniform_grid/outputdata/WSI_mutants/C1355/TOCO@CBL/TOCO_F@CBL-WD-C1355.su
m1
Here we see that TWC (total wire crossing) in 100 instances of ISOMORHIC
circuit c1355, can vary -- when placed by the same tool -- from 2293 to
4378!!
You should expect similar variations in "test length" when you give the
tool 100 identical netlists and fault lists in different order!!! For more
details on the "design of experiments", see my draft tutorial report,
entitled "Design of Experiments to Evaluate CAD Algorithms: Which
Improvements Are Due to Improved Heuristic and Which Are Merely Due to
Chance?", accessible under
http://www.cbl.ncsu.edu/publications/#1998-TR@CBL-04-Brglez
At 12:10 PM -0700 6/3/98, Scott Davidson wrote:
>> From: Rainer Dorsch <rainer@rainer.informatik.uni-stuttgart.de>
>>
>> > 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.
>> >
>>
>> As a user, I need to read one of the file formats and build a graph-like
>>data
>> structures in RAM. From my point of view, it would be much easier to use a
>> library which already can read one of these formats and build this data
>> structure (except I need a very special structure for my algorithm to work
>> efficient).
>>
>> If such a library would be provided, I guess 80% of the tools would
>>build on
>> this data structure and linking two tools together would be much easier.
>>It is
>> somewhat offtopic, but if filters are created, this would be only little
>>more
>> work and the tools would be much more comparable and _compatible_.
>>
>> Maybe there is already something like this and I do not know it.
>>
>
>I perhaps was not clear on the definition of library. I mean a library
>giving the
>definition of the primitives used in the design - basically a cell
>library. It sounds
>like you are describing a design database/framework. I quite agree that
>it would be
>nice to have compatible tools, but I don't even hear anything about the
>CAD Framework
>Initiative anymore.
>
>Given that you will need to write a translator/filter, which of the
>commerically
>available formats works best for you?
>
>Thanks,
>
>Scott
>
>>
>> --
>> Rainer Dorsch
>> Abt. Rechnerarchitektur e-mail:rainer.dorsch@informatik.uni-stuttgart.de
>> Uni Stuttgart Tel.: 0711-7816-215
>>
>>
>
>Scott Davidson
>Sun Microsystems
>scott.davidson@eng.sun.com