HDTenEightyP/NetNews huggingface dataset:
From: mjohnson@netcom.Netcom.COM (Mark Johnson)
Newsgroups: comp.lsi,comp.lsi.cad
Subject: Re: Info on analog behavioral modelling wanted
Date: 18 Aug 92 14:31:58 GMT
Organization: Netcom Online Communications Service

A recent book is mentioned below.  As it costs
about fifty dollars US, I recommend looking it over
carefully before you decide to purchase.


J. A. Connelly and P. Choi, _Macromodeling_with_SPICE_,
_Disk_Included_, Prentice-Hall, Englewood Cliffs,
New Jersey, USA, Copyright 1992.  ISBN 0-13-544941-3

Chapter 4: The Phase Locked Loop Macromodel
Chapter 5: Using SPICE to Design, Analyze, and
              test a PLL System
Chapter 6: Automatic Generation of Macromodels


--MJ
From: richardm@vitsemi.com (Richard Marshall)
Newsgroups: comp.lsi
Subject: REQ: top ASIC companies
Date: 13 Aug 92 20:55:48 GMT
Organization: Vitesse Semiconductor

I would like to know the top ASIC companies in sales in
both gate arrays and standard cells.  I assume that would
include such companies as Toshiba, LSI and perhaps VTI.

Thanks in advance.
-- 
========================================================================
Rich Marshall                          \     email: richardm@vitsemi.com
Vitesse Semiconductor Co.               \    phone: (408) 730-3643
470 Mercury Dr., Sunnyvale, CA 94086     \     fax: (408) 245-9406
From: pakst5@ee.pitt.edu (Paul A. Kwan)
Newsgroups: comp.lsi
Subject: Question on Analog Memory Chip
Date: 15 Aug 92 18:09:44 GMT
Organization: Univ. of Pittsburgh, Electrical Engineering
Originator: pakst5@kona


Does anyone has any information on the cost of analog memory chip ?

Thanks.
paul
pakst5@ee.pitt.edu
From: orpheus@reed.edu (P. Hawthorne)
Newsgroups: comp.lsi
Subject: Re: A Graph Theory Newsgroup, Perhaps?
Date: 19 Aug 92 01:48:42 GMT
Article-I.D.: reed.1992Aug19.014842.20713
Organization: Reed College, Portland, OR


  orpheus@reed.edu (P. Hawthorne) writes:
: I feel that there ought to be a graph theoretic newsgroup, if only for
: the insights that such a multidisciplinary newsgroup could offer.

  jon@alpha.ee.ufl.edu (Jon Mellott) writes:
: The traffic on this newsgroup does not warrant the creation of a spin-off 
: newsgroup. I don't recall ever seeing any discussion of graph theory in 
: this newsgroup (I could be wrong) so I don't see that there is a need. 

  I posted to this newsgroup because I have read much about aspects of
graph theory that are relevant to lsi. It was for similar reasons that I
posted to comp.parallel, comp.object, comp.compilers, and sundry others,
although I have seen explicit mention of graphs on those other groups.

  While graph theory may not be an active enough topic on this newsgroup to
warrant a separate group, graph issues are raised on many other newsgroups
regularly. I have gotten about thirty responses so far today, from people
from very diverse groups. All have been in favor, with the exception of
yours and a fellow from sci.math who had very similar reasons.

  I suggest a graph theory group not to fragment comp.lsi, but to unify
fairly significant elements of many other newsgroups.

  Theus (orpheus@reed.edu)
Newsgroups: comp.lsi.testing
From: Bjorn.B.Larsen@delab.sintef.no (Bjorn B. Larsen)
Subject: Re: Benchmark Circuits for Digital circuit test pattern generation
Reply-To: bjorn.b.larsen@delab.sintef.no
Organization: delab
Date: 21 Aug 92 12:10:09

In article <18341.2a92f106@levels.unisa.edu.au> 8809787l@levels.unisa.edu.au writes:

>In many papers in the field of fault diagnosis and Test generation for digital
>circuits I have seen benchmark circuits used to make comparison between the
>speed and effeciency of various test generation methods.

>I have commonly seen labels such as C880, C5315 or C7552 used to describe or
>mension these benchmark circuits. In many papers on this topic also I have seen
>the following reference to this circuits mensioned:

>(*) F. Brglez and H. Fujiwara, "A neutral netlist of ten combinational
>benchmark circuits and a target translator in FORTRAN," in Proc. IEEE Int.
>Symp. on Circuits and Systems, Kyoto, Japan, June 5-7, 1985

>[ ... ]

>I need to know the following:

>(1) What are these benchmark circuits ?

They are combinational circuits. I think they are parts of, or
complete, real designs. The number of Inputs and Outputs, and the
complexity of the circuits varies.

Usually referred to as ISCAS-85 circuits.

There is a similar set of sequential circuits presented on ISCAS-89, I
think.

>(2) Where can I get these from ?

I think MCNC - Microelectronics Center North Carolina - in the US is
the correct address. I do not have any e-mail or other.

It is an ASCII netlist, based on TEGAS TDL. Easy to transform to
whatever format you need.

They are free available, so if you know somebody with a copy, you may
get a compy from them.

(I may send you what we have, 8 of the 10 (?) circuits.)

>(3) What is the Brglez & Fujiwara reference ( I could not locate it ) ?

It is a tape, distributed to interested participants on the symposium.
(And others later.)

>(4) How can I use the above benchmark netlist to test a test generation method?

 A - Get a copy of the netlist
 B - Transform the netlist to the netlist_of_your_choise
 C - Run your ATPG
 D - Compare your results with other results. These you may find in
     conference proceedings or journals.

>(5) Is there a updated version of this which has come out since 1989 ?

They vere issued in 1985, 1989 was the year of the sequential
circuits, if my memory serves me right.

What is there to update on a netlist? These are supposed to be
standard circuits which anybody may use to get comparable results from
ATPGs or fault simulators. I hope nobody has changed them.

Bj{\o}rn
--
______________________________________________________________________
               s-mail:                 e-mail:
|   |   |      Bjorn B. Larsen         bjorn.b.larsen@delab.sintef.no
|__ |__ |      SINTEF DELAB
|  \|  \|      N-7034 TRONDHEIM        tel: +47-7-592682 / 592600
|__/|__/|_     NORWAY                  fax: +47-7-591039 / 594302
______________________________________________________________________
From: vinoski@apollo.hp.com (Stephen Vinoski)
Newsgroups: comp.lsi.testing
Subject: scan test references needed
Keywords: scan software
Date: 18 Aug 92 14:55:34 GMT
Organization: Hewlett-Packard Company, Apollo Division - Chelmsford, MA
Originator: vinoski@zep_r.ch.apollo.hp.com


I am looking for references to papers, articles, etc. that describe
interactive scan-based testing tools similar to ASSET from Texas
Instruments.  Such tools need not be limited to P1149.1 boundary scan.
In fact, references to any papers discussing control software for scan
would be appreciated.

If you know of any such references, please email them to me directly,
as I don't normally read this newsgroup, and thanks in advance.

-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
From: 8809787l@levels.unisa.edu.au
Newsgroups: comp.lsi.testing
Subject: Benchmark Circuits for Digital circuit test pattern generation
Date: 19 Aug 92 15:40:29 GMT
Organization: University of South Australia

Dear reader

In many papers in the field of fault diagnosis and Test generation for digital
circuits I have seen benchmark circuits used to make comparison between the
speed and effeciency of various test generation methods.

I have commonly seen labels such as C880, C5315 or C7552 used to describe or
mension these benchmark circuits. In many papers on this topic also I have seen
the following reference to this circuits mensioned:

(*) F. Brglez and H. Fujiwara, "A neutral netlist of ten combinational
benchmark circuits and a target translator in FORTRAN," in Proc. IEEE Int.
Symp. on Circuits and Systems, Kyoto, Japan, June 5-7, 1985

One place that I found this reference mensioned was in :

(*) Short Papers "Expremental Evaluation of Testability Measure for Test
Generation" by Chandra & Patel in IEEE trans. on Computer Aided Design Vol. 8,
No. 1 January 1989.

I need to know the following:

(1) What are these benchmark circuits ?

(2) Where can I get these from ?

(3) What is the Brglez & Fujiwara reference ( I could not locate it ) ?

(4) How can I use the above benchmark netlist to test a test generation method?

(5) Is there a updated version of this which has come out since 1989 ?


I would be very greatfull if some one could help me by responding to the
following e-mail address:

		8809787L@LV.LEVELS.UNISA.EDU.AU

Thank you very much, and hope to hear from you soon.


Yours faithfully
Peyam Pourbeik


School of Electronic Engineering
University of South Australia ( Levels campus )
Adelaide, South Australia, Australia
Newsgroups: comp.lsi.testing
From: vmarsch@adobe.com (Vonn Marsch)
Subject: Automated Testing of X Applications
Organization: Adobe Systems Incorporated
Date: Wed, 19 Aug 1992 18:04:31 GMT


Dear Friends,

I need advice, caveats, recommendations, and anecdotes concerning automated
testing of X applications.  Specifically, has anyone had any experience
(or know someone who has had experience) with XRunner or Ferret?

Many thanks in advance,

Vonn Marsch
Adobe Systems, Inc.
vmarsch@adobe.com
Newsgroups: comp.lsi.testing
Newsgroups: comp.lsi.testing

	Hi,

	We're looking for a PD netlist translator that can map a hierarchical
    structural Verilog netlist into TEGAS. Any pointer is much appreciated.

----
Hai  Vo-Ba                              (303)229-3874
ESL  MS55              			hai@hpeshai.fc.hp.com
Hewlett Packard Co.
3404 E. Harmony Rd.
Fort Collins, Colorado 80525-9599
From: inyup@python.icsl.ucla.edu (Ian Knight)
Newsgroups: comp.lsi
Subject: DELAY LINE?
Date: 18 Aug 92 22:34:40 GMT
Organization: UCLA Integrated Circuits & Systems Laboratory


Hi, folks.

Is there anybody who designed a delay line(DL, continuous time, digital) 
using CMOS ?

Its specifications are as follows:

1. the output is delayed version of input.
2. it's desirable to have the symmetric delay
   (that is, rising propagation delay == falling propagation delay)
3. the delay must be controllable from "0.5ns" to "10ns"
   using only circuit parameter(let's say, using gate cap. or ratio...)
4. the total area of the DL must be minimal.
   (it can be included inside the usual Digital VLSI,
	in quantity of 10 or more)
....

I think somebody in the DRAM business might be using DL 
as a control signal for the RAS/CAS,
my application is totally different, though.

Any hints really will be appreciated.


- Ian Knight
From: jch@rdg.dec.com (John Haxby)
Newsgroups: comp.compilers,comp.lang.basic
Subject: Re: Why is compiled basic slower than C? (Basic is the future)
Keywords: Basic, C, performance
Date: 12 Aug 92 08:43:32 GMT
Reply-To: jch@rdg.dec.com (John Haxby)
Organization: Digital Equipment Corporation

Glenn_Johansson@f313.n203.z2.fidonet.cd.chalmers.se writes:
|> [How much slower is compiled Basic than C, and why?]

There has been a lot of work put into optimizing C compilers: the efforts
of FSF, Sun and MIPSCO to mention but three.  There hasn't been a great
deal of work put into optimizing BASIC compilers, at least not that I know
of.

There seems to be a more general problem though: compilers of high-level
languages tends to produce optimal machine code, whereas compilers of
low-level languages tend to produce sub-optimal machine code.

Some time ago, code produced by an Algol68S compiler was compared to code
produced by an optimizing Fortran compiler on an ICL1906.  The program
compiled from Algol68 ran 30% faster than that produced from the Fortran
compiler.  The reason for this seems to be that the high-level language
compiler has a better idea of what the programmer is trying to do and can
make appropriate optimizations-- such optimizations frequently show up as
doing nothing at all where another programming language would require code
to be executed, or use a single machine instruction for coping where (C
for example), would use a loop.  This form of optimization, of course, is
largely wasted on RISC machines, although the compiler can still exercise
the right to copy, say, 4 bytes at a time whereas the C program forces a
byte by byte copy.

-- 
John Haxby
Digital				<jch@rdg.dec.com>
Reading, England		<...!uknet!wessex!jch>
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: steveh@psg.com (Steve Hampson)
Newsgroups: comp.compilers
Subject: Re: A Non-LALR(1) Parser Generator
Keywords: parse, LR(1)
Date: 22 Aug 92 05:06:00 GMT
Article-I.D.: comp.92-08-140
Reply-To: steveh@psg.com (Steve Hampson)
Organization: Compilers Central

bromage@mullauna.cs.mu.OZ.AU (Andrew Bromage) writes:
>Does anybody know if LR is sitting on a server somewhere?

In about 1982 LR was available for a nominal fee from the National Energy
Software Center located at Argone National Laboratory.  I used a copy to
write my masters thesis.

The system is described in:

	Wetherall, Charles and Alfred Shannon, "LR - Automatic Parser
	Generator and LR(1) Parser," IEEE Transactions on Software
	Engineering SE-7, 3, 274-278, May 1981.

The tables are meant to be transportable, so they are not packed at all.
I spent some time packing the tables and extending the grammar so that it
would be tolerable to use.

I have a copy somewhere on a 9-track tape in DEC-10 backup format, but
since I have neither a DEC-10, a 9-track tape drive nor any desire to look
for it, please don't ask.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: kandt@ai-titania.Jpl.Nasa.Gov (kirk kandt)
Newsgroups: comp.compilers
Subject: Re: Large-space GC
Keywords: GC, storage, design
Date: 21 Aug 92 15:38:37 GMT
Article-I.D.: comp.92-08-135
Reply-To: kandt@ai-titania.Jpl.Nasa.Gov (kirk kandt)
Organization: NASA/JPL

Jon L. White (from MIT) had a paper in (I believe) the first Lisp and
Functional Programming Language Conference in either 1979 or 1980.  The
issue has also been adressed in the Proceedings of the Hawaii Inter. Conf.
on System Sciences, 1992.  There is also a workshop going on right now in
Canada on Distributed Object Management Systems.  A compilation is
supposed to be published by Morgan-Kaufman titled Distributed Object
Management edited by Ozsu.
-- 
Kirk Kandt
M/S 525-3660
Jet Propulsion Laboratory
4800 Oak Grove Drive
Pasadena, CA 91109
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: steele@vlsi.cs.caltech.edu (Craig Steele)
Subject: IEEE Floating-Point Package?
Reply-To: steele@vlsi.cs.caltech.edu (Craig Steele)
Organization: California Institute of Technology
Date: Fri, 14 Aug 1992 22:53:33 GMT
Keywords: arithmetic, question

Can anyone point me to a readily available software implementation
package of IEEE floating-point arithmetic?  C or Pascal source
would be ideal, but assembly language would do.  Thanks.

Craig Steele, steele@vlsi.caltech.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: markh@csd4.csd.uwm.edu (Hunk)
Newsgroups: comp.compilers
Subject: Re: constant folding at parse time
Keywords: parse, attribute
Date: 17 Aug 92 17:28:49 GMT
Reply-To: markh@csd4.csd.uwm.edu (Hunk)
Organization: Computing Services Division, University of Wisconsin - Milwaukee

wjw@eb.ele.tue.nl (Willem Jan Withagen) writes:
>Well just a little nit pick here. I do not consider this part of a
>parser. Determining wether an expression is constant or not is part of
>constant folding, which is usually not done while parsing. But the
>taken approach could be made to work.

A expression evaluation routine I wrote for an expression parser in a
recently released assembler (C-expression syntax is handled) is set up in
such a way that all constant subexpressions will be reduced to leaf nodes
during parsing.  The question about whether a given expression is constant
or not doesn't even arise because it's already been handled by the parser.
Basically, if the expression tree returned by the parser is a leaf node
then it's a constant, otherwise it's not.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: kelvin@kickapoo.cs.iastate.edu (Kelvin Don Nilsen)
Subject: Re: Adding garbage collection to C++
Reply-To: kelvin@kickapoo.cs.iastate.edu (Kelvin Don Nilsen)
Organization: Iowa State University, Ames IA
Date: Thu, 13 Aug 1992 10:26:37 GMT
Keywords: C++, GC

>[I'd be interested how you trace through unions containing pointers. -John]

We have implemented copying garbage collection for the C++ language
standard, making only a few minor restrictions on normal C++ usage.  We
are able, for example, to compile Gnu groff by fixing fewer than five
"sloppy" programming tricks.  We handle unions that may contain either
pointers or raw seething bits by adding an explicit tag to distinguish
between the two.  Each assignment to one of these unions incurs the cost
of updating the tag.  We do not check the tag on reads.  Further, we do
not update the tag if the union is known always to contain pointers, or
always to contain raw seething bits.

Kelvin Nilsen/Dept. of Computer Science/Iowa State University/Ames, IA  50011 
 (515) 294-2259   kelvin@cs.iastate.edu  uunet!kelvin@cs.iastate.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: brannon@stun4s.cs.caltech.edu (Terrence M. Brannon)
Subject: Re: Shared memory design, was garbage collection
Reply-To: brannon@stun4s.cs.caltech.edu (Terrence M. Brannon)
Organization: Caltech Yoga Qi Gong Tai Chi
Date: Wed, 12 Aug 1992 15:05:43 GMT
Keywords: storage, architecture

>>(2) The UNIX process model is a good one, and should be preserved.  In
>>particular, this means that (a) processes shouldn't be able to crash each
>>other or (b) view each other's data.

>No. There are a lot of ways processes can view "each other's" data. One of
>them, which is to map a common file, is very useful. I insist that
>processes _should_ be able to do this, mainly by not buying versions of
>UNIX where this is not possible.

-*- Another way, that I will be working on this morning is to force all
other languages to be inferior process of Emacs. Emacs will serve as a
global cache for Python, Tcl, and Perl interpreters. 

This is the first step. The next step is to let Emacs be the virtual
shared memory for interpreters across the internet. For example let's say
your local machine is A and you have remote machines R1 and R2.  Using
only Python as an example, we spawn a Python interpreter on A.  This
Python interpreter does the following:

import emacs

r1_pointer = emacs.spawn("tbrannon@R1:~/python-directory")
r2_pointer = emacs.spawn("tbrannon@R2:~/python-directory")

r1_pointer.('import fibonacci')
r2_pointer.('import fibonacci')

sum1 = r1_pointer.('fibonacci.generate(1000,2000)')
sum2 = r2_pointer.('fibonacci.generate(2001,3000)')

local_sum = sum1 + sum2


-*- Another point: BUY unix ? Wait until the GNU Hurd comes out and you
wont have to buy another unix for two reasons: (1) no company will be able
to outperform the GNU Hurd (2) free is always cheaper than any higher
amount of money.
--
Terrence Brannon       (brannon@jove.cs.caltech.edu)  
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: tmb@idiap.ch
Newsgroups: comp.compilers
Subject: Re: Adding garbage collection to C++
Keywords: C, GC
Date: 17 Aug 92 15:57:49 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)

fjh@cs.mu.OZ.AU (Fergus Henderson) writes:

>[C lets you hide pointers in inconvenient ways, e.g. writing them to
>files or scrambling bytes in unions.]

All the locations where a pointer is converted to an integer (via casts,
unions, or memcpy) are detectable by the compiler. For any pointer that
has ever been (mis-)treated in such a way, the corresponding memory can
simply be exempted from garbage collection (e.g., by recording the pointer
in some global table searched by the garbage collector).

					Thomas.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Newsgroups: comp.compilers
Subject: Code Generation by Coagulation?
Summary: Has anyone used Code Generation by Coagulation?
Keywords: code, optimize
Date: 12 Aug 92 09:27:45 GMT
Article-I.D.: comp.92-08-051
Reply-To: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Organization: Softway Pty Ltd

I've been looking through the paper "Code Generation by Coagualtion" by
Michael Karr, published in 1984.  In it, a code generation algorithm is
describes that does instruction selection simultaneously with register
allocation.  The code generator has access to runtime flow statistics, and
it generates code for most critical blocks first to least critical last.
It also generates linkage code between them so that most common flow paths
have optimial interfaces.

It all looks quite interesting, but the conclusion says that none of the
ideas has been implemented, so whether it is a good idea is entirely
hypothetical.  I'm wondering if this work has been followed up or further
investigated.  I'm looking for papers, actual code etc..

Thanks,
	J

--
jeremy@softway.sw.oz.au ph:+61 2 698 2322-x122 fax:+61 2 699 9174
[Someone asked a similar question in 1987 but there weren't any answers.
-John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1367 comp.os.msdos.programmer:8526
From: ejy@hrmsc.att.com (Eugene Yurek)
Newsgroups: comp.compilers,comp.os.msdos.programmer
Subject: Re: 8086 object code
Keywords: linker
Date: 13 Aug 92 17:34:42 GMT
Reply-To: ejy@hrmsc.att.com (Eugene Yurek)
Organization: AT&T

bromage@mullauna.cs.mu.OZ.AU (Andrew Bromage):
>[Where can I get documentation for Intel 8086 object formats?]

Have you tried Intel yet ?  I got a copy of the object file format
document 3 or 4 years ago from them.  It also included a library format
section, however, at least Microsoft (probably others) like to break
things in their compilers and fix them in the linker and librarian (read:
the object and library formats are augmented by them with additional
record types that are NOT defined in the Intel document), so I'm not
exactly sure how useful the Intel document is going to be unless you don't
care about generic compatibility with other compiler vendors.

Gene Yurek
ejy@hrmsg.att.com	AT&T Bell Laboratories, Middletown NJ
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers