HDTenEightyP/NetNews huggingface dataset:
From: danj@CORONA.AUE.COM (Dan Johnson)
Newsgroups: comp.lsi.cad
Subject: Attention SCMOS Users
Date: 26 Aug 92 21:43:42 GMT

********************************************************************************
                    Attention all SCMOS standard cell users!
********************************************************************************

The ITD Advanced Microelectronics Center (AuE) is conducting a survey of SCMOS 
standard cell users. The AuE SCMOS standard cell library has been released 
under the following version numbers: dlmV1.0, dlmV1.1, dlmV2.0, dlmV2.2, 
dlmV2.2a, and dlmV2.3. The original version of the library, dlmV1.0, was the 
result of a contract with USC-ISI to redesign the CMOS3 standard cell library 
using the MOSIS scalable design rules. The latter versions of the library were 
developed with support from University of California, Berkeley and DARPA. These
cells have also been released through Mississippi State University along with 
the LagerIV Silicon Assembly System.

If you are actively using any of these cell families AuE would like to hear 
from you. In particular we would like the following info:

[a] The name, address, and phone number for your organization

[b] What version of the cell family are you using?

[c] Indicate the number of designs that have been fabricated using these cells.

[d] What CAD tools are being used to assemble your standard cell designs?

[e] If we were to port the SCMOS cells to other CAD tools which ones would you 
    prefer?

[f] Are you using "hard" and "soft" macros?

[g] Are you interested in specialized analog cells? If so please identify
    the cell functions and the performance requirements.

[h] What changes would you like to see in future releases of the library?

In exchange for the effort required to complete this questionaire AuE will
provide you with the information needed to acquire the new dlmV3.0 cell 
library. This libray supports the MOSIS scalable design rules and can be 
scaled from 1.2 microns, up to 2 microns, and down to 0.8 microns. We have 
also completed a new set of I/O cells that are distributed along with the 
SCMOS cells. The layout databases are available in GDSII and MAGIC formats.
A databook is included with the release and is available in FrameMaker
and Postscript formats.

Please E-mail your responses to cells@aue.com or forward them by mail to 
the address given below. Thanks....

      _______
     /       |
====/        |==============================================================
|  /         |  Dan Johnson             Advanced Microelectronics          |
|  /         |  CAD Operations Manager  1080 River Oaks Drive              |
|  \         |  Fax: (601)932-7621      Suite A-250                        |
|   |Jackson |  Phone: (601)932-7620    Jackson, MS                        |
|   /   *    |  danj@AuE.com            39208                              |
===/         |==============================================================
  |______    |
        /    |
        \____|
Newsgroups: comp.lsi.cad,comp.os.ms-windows.apps
From: ronald@opal.cs.tu-berlin.de (Ronald Hindmarsh)
Subject: CIF editor or viewer for MS Windows
Keywords: CIF Editor Viewer
Organization: Techn. University of Berlin, Germany
Date: Wed, 2 Sep 1992 19:28:11 GMT


On our SparcStations we use an old version of KIC, which was adapted
to X11. Is there a PC version around (for MS-DOS/VGA or WINDOWS)?

If not, is there any other CIF reading editor or viewer for PC?

----------------------------------------------------------------------
 Ronald Hindmarsh                      e-mail: ronald@cs.tu-berlin.de
 Institut fuer Technische Informatik
 TU Berlin FR 3-9
 Franklinstr. 29                            Phone: (+49) 30 314-73432
 W-1000 Berlin 10                             Fax: (+49) 30 314-21103
----------------------------------------------------------------------
Newsgroups: comp.lsi.cad
From: aranake@cse.uta.edu (Sandeep Suresh Aranake)
Subject: How to measure regularity in CDFGs ? Help !!
Keywords: High-level Synthesis,allocation etc.
Organization: Computer Science & Engineering, Univ. of Texas at Arlington
Distribution: usa
Date: Tue, 25 Aug 1992 17:33:51 GMT


Can someone suggest a metric to represent the regularity
in digital systems described using CDFGs? 

I have allocation program which scans input data-flow graph,
extracts operator-operator interaction and uses this
information during allocation. I want to plot a graph of
some metric representative of regularity in DFG and
the quality of the allocation. I tried few tricks but
none gave me a unique quantity to describe regularity.
Your help and/or pointer to info will be greatly
appreciated.

sandeep
Newsgroups: comp.lsi.cad
Subject: Chip design times
From: news@massey.ac.nz (USENET News System)
Date: Fri, 28 Aug 92 04:37:41 GMT
Reply-To: M.Pearson@massey.ac.nz
Organization: SMIS, Massey University, NZ

I am currently trying to find information on current chip design times verses
complexity.

Thanks in advance

Murray Pearson
Department Of Computer Science
Massey University
Palmerston North
New Zealand
From: pagey@cse.iitb.ernet.in (S Pagey)
Newsgroups: comp.lsi
Subject: cubes and cube covers
Date: 1 Sep 92 12:31:27 GMT
X-Unparsable-Date: Mon, 31 Aug 92 20:50:11 IST


Newsgroups: comp.lsi
From: sridevan@elec.uq.oz.au (Sri Parameswaran)
Subject: E-mail address of Mitchell Mlinar
Keywords: Email address
Organization: Prentice Centre, University of Queensland
Date: Sun, 30 Aug 1992 09:40:15 GMT

Could some one out there provide me with Prof Mitchell J. Mlinar's
email address. I think he is or was attached to the Dept of Electrical
Engineering, University of Southern California.


Thanks
Sri
-------------------------------------------------------------------------
Sri Parameswaran
Dept. of Electrical Engineering, University of Queensland,
St. Lucia, Australia.

Phone: +61-7-365-4190		Fax:   +61-7-365-4999
ACSnet: sridevan@s1.elec.uq.oz	INTERNET: sridevan@s1.elec.uq.oz.au
				UUCP:     uunet!elec.uq.oz.au!sridevan
--

Thanks
Sri
-------------------------------------------------------------------------
Newsgroups: comp.lsi
From: tapas@pooh.engr.mun.ca (Tapas Banerjee)
Subject: Question regarding probe pads
Summary: Same as heading
Keywords: probe pads
Organization: Memorial University of Newfoundland
Date: Fri, 4 Sep 1992 02:20:18 GMT

  Some points about landing probe pads inside a design chip seems to be unclear to me.
Hope some kind soul would be able to help me out.

  Say I want to probe a point in the circuit, which is a point inside a standard cell.
Since standard cells are designed very compact - I have the following question. Is the
standard practice is of landing probe pads inside standard cell, or that of taking a
metal(?) wire out from the point and placing the probe point at a convenient point
outside standard cells. 

  The reason I have this question is - that if you want to put a probe pad inside a
 cell, I believe it is going to be small enough to satisfy various design rules. And
 my personal experience says that for a novice prober, anything less than 50 micron
 square is dangerous. Since a bit of vibration may land you into a serious trouble.

   Any help will be appreciated.

   Thanks in advance.

   -  TAPAS
Newsgroups: comp.lsi
From: mjohnson@netcom.Netcom.COM (Mark Johnson)
Subject: Re: Ultra high-speed analog voltage comparator
Date: Thu, 03 Sep 92 15:20:32 GMT
Organization: Netcom Online Communications Service

In article <1992Sep3.030812.15165@news.iastate.edu> mhbrekke@iastate.edu (Monty H. Brekke) writes:
   I am looking for a very fast (< 1ns) 
   voltage comparator. I don't care what
   technology the thing is implemented in...
   In addition to the high speed, I need an
   input voltage range of +/- 5V.

The bugbear in your requirements is the input voltage
range; not many GHz grade IC technologies can handle
higher than 4-6 volts.  And that's across the supplies
(V+ minus V-): input commonmode range is smaller.

How about a 1:10 attenuator (compensated of course)
followed by an ECL line receiver in the SPECL
(Sony) or ECLiPS (Motorola) families?

Also there is a very good chance that the properties
of your input signals will permit true AC coupling.
In part this is because your input signals are required
to have FAST EDGES (otherwise it is, in a practical sense,
foolhardy to insist upon very short propagation delay;
excess delay in the comparator will be indistinguishable
from amplitude error in the input signals).

MJ
Newsgroups: comp.lsi
From: rgupta@sirius.Stanford.EDU (Rajesh K. Gupta)
Subject: Re: Question regarding probe pads
Keywords: probe pads
Reply-To: rgupta@sirius.Stanford.EDU (Rajesh K. Gupta)
Organization: Stanford University
Date: Fri, 4 Sep 92 17:13:06 GMT

>   Some points about landing probe pads inside a design chip seems to
be unclear to me.
> Hope some kind soul would be able to help me out.
> 
>   Say I want to probe a point in the circuit, which is a point inside
a standard cell.
> Since standard cells are designed very compact - I have the following
question. Is the
> standard practice is of landing probe pads inside standard cell, or
that of taking a
> metal(?) wire out from the point and placing the probe point at a
convenient point
> outside standard cells. 
> 


typically a picoprobe can be safely manipulated for
distances in ten's of microns (a 20x20 u pad would be
enough).

However, most common practice today is to use voltage-contrast
enhancement techniques on ebeam reflections. A 5x5 pad in topmost 
metal layer would be sufficient. If surrounded by a ground line, it
would be even better. Of course, the tester would cost more.


Rajesh
725-1776 CSL Modulars I				rgupta@sirius.stanford.edu
From: pagey@cse.iitb.ernet.in (S Pagey)
Newsgroups: comp.lsi
Subject: cubes and cube covers
Date: 1 Sep 92 12:31:27 GMT
Article-I.D.: kailash.9208311521.AA15482
Followup-To: poster
X-Unparsable-Date: Mon, 31 Aug 92 20:51:43 IST

Some time back I had posted this newsitem on the net. But unfortunately some
problem developed in the newsfeed here and no news was coming to us. Because of
this problem I must have lost all the responses to this item. I am posting it
again. Please post your responses again. If, by chance, someone has collected
responses to this item, please mail them to me.

The basic technique used in two level minimization of single output Boolean
functions is to find a cube cover of smallest size. My querry is about the
estimation of the size of the cubes in the cube cover. The querry is,

Given the assignment of 0, 1, and X (don't cares) to the vertices, how to
estimate sizes of cubes in the cube cover, without actually finding the cube
cover? Are any bounds known on the sizes of cubes in cube cover? The cube cover
referred to here is same as the cube cover for two level minimization of
Boolean functions. 

Any references are welcome.
Thanks in advance.
-------------------------------------------------------------------------
Sandeep Pagey,
Dept. of Computer Sc. and Engg.,
IIT Powai,
Bombay 400 076. INDIA.
email : pagey@cse.iitb.ernet.in
-------------------------------------------------------------------------
Xref: sparky comp.lsi:574 comp.lsi.cad:926
From: ronald@opal.cs.tu-berlin.de (Ronald Hindmarsh)
Newsgroups: comp.lsi,comp.lsi.cad
Subject: Netlists with complex gates from high level circuit description?
Keywords: cmos complex gates vlsi netlists
Date: 2 Sep 92 17:36:15 GMT
Organization: Techn. University of Berlin, Germany


Hello net-working users!

I am working on a VLSI module generator, which includes automatic
layout design of static CMOS complex gates. I would like to
know, whether there exists a software solution to break some
high level circuit description into a gate level description, which

a) uses complex gates of a given library,

or

b) 'invents' those complex gates, which leads to a minimal gate count
   of the circuit.

Any experience or pointers?


----------------------------------------------------------------------
 Ronald Hindmarsh                      e-mail: ronald@cs.tu-berlin.de
 Institut fuer Technische Informatik
 TU Berlin FR 3-9
 Franklinstr. 29                            Phone: (+49) 30 314-73432
 W-1000 Berlin 10                             Fax: (+49) 30 314-21103
----------------------------------------------------------------------
Newsgroups: comp.lsi.testing
From: vinoski@apollo.hp.com (Stephen Vinoski)
Subject: VICTORY and CATE
Originator: vinoski@zep_r.ch.apollo.hp.com
Date: Fri, 28 Aug 1992 20:17:48 GMT
Organization: Hewlett-Packard Company, Apollo Division - Chelmsford, MA


Can anybody give me information about Teradyne's VICTORY and/or
Schlumberger's CATE systems?  What are they?  Do they help with scan
testing?  Are they tester-based or stand-alone programs?

thanks,
-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
Newsgroups: comp.lsi.testing
From: raghu@norway.fishkill.ibm.com (Raghu Hudli)
Subject: Re: Rise and shine
Date: Fri, 28 Aug 92 16:28:56 GMT
Reply-To: raghu@vnet.ibm.com
Organization: IBM Corp., E. Fishkill, NY



In article <1992Aug28.143621.1917@mcc.com>, praveen@sirius.mcc.com
(Praveen Vishakantaiah) writes:
>
>
  some stuff deleted....

An interesting posting; however it elicits a couple of comments....

> 
> Holger> I cannot imagine that everyone is interested in design
> Holger> (comp.lang.vhdl, comp.lang.verilog, comp.sys.mentor, comp.lsi*),
> Holger> but nobody in testing of all the stuff produced. 
> 
> Well, isn't testing harder than designing ;-). Nobody has proved VLSI 
> design to be an NP-complete problem (as far as I know)!
> 

  That is not true. There is a mulititude of problems that are NP-complete
in physical design of VLSI, including placement, routing, pin assignment, etc. 

> 
> Rise and shine, all you testing folks. Spend some time posting useful
> discussions pertaining to VLSI testing. Don't work too hard on the testing
> problem [I hope my advisor does not see this:-)]. After all, the testing
> problem was NP-complete, is NP-complete and will be NP-complete!! 
                                               ^^^^^^^^^^^^^^^^^^^^

   ... until the question P = NP ? remains unresolved.


> Praveen Vishakantaiah.

Raghu Hudli
-----------------------------------------------------------------------
Raghu V. Hudli                       Tel:   (914) 892-4188
IBM Corporation                      Fax:   (914) 892-4316 
E. Fishkill, NY                      email: raghu@vnet.ibm.com
------------------------------------------------------------------------
Disclaimer: The opinions/views expressed here are mine and my employer
does not necessarily concur with me.
Newsgroups: comp.lsi.testing
From: karplus@ararat.ucsc.edu (Kevin Karplus)
Newsgroups: comp.lsi.testing
Subject: Re: Rise and shine
Date: 1 Sep 92 22:44:36 GMT
Organization: UC Santa Cruz CIS/CE
NNTP-Posting-Host: ararat.ucsc.edu

Logic minimization is also NP-hard.

In fact, damn near any interesting design or testing teachnique is NP-hard (after all, that
is what makes it interesting).

Kevin
From: jeh@acpub.duke.edu (JUSTIN HARLOW)
Newsgroups: comp.lsi.testing
Subject: Re: Change this Group Name?
Date: 28 Aug 92 09:42:50 GMT
Organization: Duke University; Durham, N.C.

In article <BtnwwM.EBA@metaflow.com> rschnapp@metaflow.com (Russ Schnapp) writes:
>In article <veit.714837724@du9ds3>, veit@du9ds3.uni-duisburg.de (Holger Veit) writes:
>|> In <1992Aug25.183729.27815@venus.ic.cmc.ca> yooho@ursula.ic.cmc.ca (Yoo Ho Cho) writes:
>|> 
>|> >In article <l9ko46INNls@bashful.crhc.uiuc.edu> patel@bashful.crhc.uiuc.edu (Janak H. Patel) writes:
>|> >>I am annoyed at notes posted in this news group which have nothing to
>|> >>do with LSI or VLSI Testing.  It seems lots of news readers are
>|> >>interpreting "testing" to mean just about anything, except what
>|> >>this group was created for!  It seems they ignore the components "comp"
>|> >>and/or "lsi" while  interpreting "testing".
>|> 
>
>You know, the message traffic over the discussion of changing the name of the
>newsgroup has by far exceeded the actual garbage traffic I've seen here in
>the last couple of months.  Does the pain of the disease really justify the
>pain of the cure?  Is this a problem worth fixing?
>
I agree that the group could have a less ambiguous name, but we are
probably stuck with it, given the alternatives. Russ (and others) point
out the central issue: why don't we get any postings? Is the name of
this group the only testing issue left? Come on, Janak: you have lots of
good things going on at UIUC: how about some timely, controversial
postings from you and/or your group? Let's talk about the issues raised
by Don Allingham: why don't undergrad profs incorporate testing ideas in
their earliest classes? 

I'll throw a thought game onto the table: Suppose we had a
manufacturing line whose yield was 100%...  would we then not need to
test products? <Everyone cringes... of COURSE we would test, they cry!>
You could take the position that, in this ideal environment, what we
are actually doing through end-of-line testing was verifying the
function of the design; could we not do that through formal methods as
we designed the device? More generally speaking, how much of what we
call testing is actually a cover for lack of design verification?

Let's see if that stirs the pot....

JEH
-- 
-------------------------------------------------------------------------
Justin E. Harlow III		Office:	harlow@src.org
Vox:	919/541-9464		School: jharlow@egr.duke.edu
Fax: 	919/541-9450		Snail:	SRC, PO Box 12053, RTP, NC 27709
From: Don.Allingham@FtCollins.NCR.COM (Don Allingham)
Newsgroups: comp.lsi.testing
Subject: Design vs. Test (was Re: Change this Group Name?)
Date: 27 Aug 92 06:12:22 GMT
	<veit.714837724@du9ds3>
Reply-To: Don.Allingham@FtCollinsCO.NCR.COM
Organization: /home/bbking/dona/.organization
In-reply-to: veit@du9ds3.uni-duisburg.de's message of 26 Aug 92 14:02:04 GMT


Holger> I cannot imagine that everyone is interested in design
Holger> (comp.lang.vhdl, comp.lang.verilog, comp.sys.mentor, comp.lsi*),
Holger> but nobody in testing of all the stuff produced. 

Unfortunately, this seems to be the view most seem to have.  Many
designers seem to think test is something that can be held off until the
end or "thrown over the wall" to someone else.  *Many* designers do not
think about test at all.  They use no structured test (BIST, scan, JTAG)
and do not even fault grade, but assume that a few functional tests will
ensure that their 30,000 gate circuit works properly.  You can usually
tell who the really experienced designers are.  They are the ones who
are worried about test up front.

I believe that this can be traced back to universities.  I had many
classes dealing with design, from the transistor level to the system
level.  My total exposure to test was a 50 minute lecture that briefly
touched on LSSD.  If I had not been in a cooperative education program,
I would have shared the misconception of many of my classmates who
assumed that every die on a wafer was good.

Hopefully, someday all designers will realize that test needs to be
considered up front, and that no tool exists that will generate 100%
stuck-at fault coverage without modifying their 50,000 gate asynchronous
design. 

Thank you.  I will now step off my soap box.

--
Don Allingham           
NCR Microelectronics 			Don.Allingham@FtCollins.NCR.com
Ft. Collins, CO.        		uunet!ncrlnk!ncr-mpd!Don.Allingham

Newsgroups: comp.lsi.testing
From: kumarv@cricket.asd.sgi.com (Kumar Venkat)
Newsgroups: comp.lsi.testing
Subject: Re: to test or not to test
Date: 1 Sep 92 20:29:51 GMT
Reply-To: kumarv@cricket.asd.sgi.com (Kumar Venkat)
Organization: Silicon Graphics Inc., Mountain View, CA



For those who see the light and decide that testing
is necessary, there are still a number of questions
regarding WHAT to test and HOW MUCH to test. This
is from a design engineer's point of view.

The majority of companies/managers/engineers that
believe in testing simply invest in an ATPG tool
that generates tests for single stuck-at faults. There is usually very
little consideration given to
real defect modes in real chips and how these defects map into various
fault models (stuck-ats,
bridging faults, transistor gate open, etc.). 

It is difficult to know exactly what defect modes
to test for (and what fault models to use in order
to reasonably cover these defects). Even if one
decides on fault models somehow, getting proven ATPG
tools that can cover those faults directly or
indirectly is quite difficult. Even if appropriate
ATPG tools can be found, getting the ASIC vendor
to accept "non-standard" test vectors (such as
delay fault testing using scan, or IDDQ testing)
is a difficult task in general.

Thus, most people settle for some kind of scan
structure (full/partial) and a stuck-at fault
model, because that is the easiest thing to do.
Fault coverage in the high 90's makes people feel
good about what they have done, especially when
they hear from the foundry that 60% of the chips
from a lot didn't pass the scan tests.

Then comes the question of how much to test. Design-
for-test typically comes at a price (area,timing),
but DFT is usually necessary to keep fault coverage
high. How much fault coverage is good enough,
especially when one uses a stuck-at model and does
not know what real defects are being covered ? Note
that process yield is also unknown most of the time.




-Kumar Venkat

 Silicon Graphics, Inc.
 (415) 390-5320
 kumarv@sgi.com
Newsgroups: comp.lsi.testing
From: black@mpd.tandem.com (David C. Black)
Newsgroups: comp.lsi.testing
Subject: Ring oscillators for characterization?
Summary: Are they a good idea? Over voltage/temperature/process?
Keywords: Ring oscillator, High freq., off-chip measurement
Date: 3 Sep 92 11:28:32 GMT
Reply-To: black@auriga.UUCP (David C. Black)
Organization: /etc/organization

In article <tapas.715497268@femto.engr.mun.ca> tapas@pooh.engr.mun.ca
(Tapas Banerjee) writes:

TAPAS> I was wondering, what kind of problems do you face when you want to
TAPAS> take out couple of tens of MHz freq. out of a chip and what kind of
TAPAS> care is to be taken in measurement of those signals (i.e. the signals
TAPAS> out of chip).

Along a similar line, I am interested in others experience with using
on-chip ring-oscillators to gather characterization data.  Local experiences
suggest these are not very easy to use and perhaps useless.  Does anyone
have data on successes?  We are designing with CMOS .8 - 1 micron gate
arrays and standard cell technologies.
-- 
| David C. Black                  Electrical Engineer                    |
| Tandem Computers Incorporated   Guardian: SMTPGATE@AUSTIN(black@tzone) |
| 14231 Tandem Blvd.              Internet: black@mpd.tandem.com         |
|_Austin, Texas 78728-6699________Phone: (512) 244-8321__________________|
Newsgroups: comp.lsi.testing
From: yooho@ursula.ic.cmc.ca (Yoo Ho Cho)
Subject: Re: Change this Group Name?
Summary: Maybe an occaisional charter posting is better ?
Organization: Canadian Microelectronics Corporation
Date: Tue, 25 Aug 1992 18:37:29 GMT

In article <l9ko46INNls@bashful.crhc.uiuc.edu> patel@bashful.crhc.uiuc.edu (Janak H. Patel) writes:
>I am annoyed at notes posted in this news group which have nothing to
>do with LSI or VLSI Testing.  It seems lots of news readers are
>interpreting "testing" to mean just about anything, except what
>this group was created for!  It seems they ignore the components "comp"
>and/or "lsi" while  interpreting "testing".
>
>Here is a suggestion: Change the group name to avoid confusion.
[...]

I am not certain a comp.lsi.defects or comp.lsi.[ testing areas .. ]
would provide the group with sufficient coverage of testing issues. 
Also the incredibly low amount of activity in this group probably doesn't
make the effort worthwhile.

Does anyone have the charter for this group ? Posting the charter once a month
should help keep some of the noise down. If someone will send a copy of the
charter, I'm willing to do a monthly "reminder" posting.

Yoo Ho Cho