HDTenEightyP/NetNews huggingface dataset:
From: hepler@cbmvax.commodore.com (Ed Hepler - LSI Design)
Newsgroups: comp.lsi.cad,comp.lsi
Subject: Symbolic Layout Languages
Date: 8 Sep 92 17:46:32 GMT
Organization: Commodore, West Chester, PA

I am familiar with the procedural layout languages L and Lx from Mentor
Graphics (formerly SCS, or SDL).

What other procedural languages exist for layout (CMOS, others)?
Are there descriptive references to them (User's Manuals) available?
Are they part of a product offering or research from a university?
Are any in the public domain?

Thanks,

Ed Hepler
Commodore
hepler@cbmvax.cbm.com
From: scottb@ogicse.cse.ogi.edu (Scott Baker)
Newsgroups: comp.lsi.cad
Subject: Looking for Schematic Capture Software
Keywords: schematic capture
Date: 9 Sep 92 02:20:53 GMT
Article-I.D.: ogicse.42539
Distribution: na
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

I'm looking for (public-domain) source code for a simple schematic-
capture package.  Anyone have any pointers?

Thanks:
Scott Baker                                      scottb@ogicse.ogi.edu
-----------------------------------------------------------------------
|     A bureaucracy hates simplicity and is terrified of speed.       |
|                               - Roy Barker   Tektronix, GPID        |
-----------------------------------------------------------------------



Xref: sparky comp.lsi:592 comp.lsi.cad:954 comp.lsi.testing:221 comp.arch:9436 biz.comp.hardware:232
From: wyle@synopsys.com (Mitch Wyle)
Newsgroups: comp.lsi,comp.lsi.cad,comp.lsi.testing,comp.arch,biz.comp.hardware
Subject: Synopsys info posted to biz.comp.software
Date: 14 Sep 92 18:43:30 GMT
Organization: Synopsys Inc.

Synopsys press release posted to biz.comp.software:

Subject: (Sept 7) SYNOPSYS INC. ANNOUNCES DESIGNWARE


Requests for press releases or other marketing information can be sent to:

Lois DuBois                    lois@synopsys.com
Synopsys Inc                   (415) 694 4255
700 E. Middlefield Rd.         (415) 965 8637 (fax)
Mountain View, CA  94043-4033  (800) 843 5669 x4255


--
Mitch Wyle                     wyle@synopsys.com
Synopsys Inc                   (415) 694 4076 
700 E. Middlefield Rd.         (415) 965 8637 (fax)
Mountain View, CA  94043-4033  (800) 843 5669 x4076
From: pascal@lorelei.grenoble.hp.com (Pascal REGACHE)
Date: Mon, 14 Sep 1992 06:44:54 GMT
Subject: Re: Help: Looking for 16 BIT A/D-Converter
Organization: Hewlett-Packard, GND
Newsgroups: comp.lsi

Crystal Semiconductor has such a device. It is also a D/A converter,
include Alaw and Ulaw and a bunch of other functions.

pascal
Newsgroups: comp.lsi,comp.lsi.cad
From: sridevan@elec.uq.oz.au (Sri Parameswaran)
Subject: Email address of Richard Andrew
Organization: Prentice Centre, University of Queensland
Date: Mon, 14 Sep 1992 23:26:15 GMT

Could someone out there please help us out with the Email Adress of
Richard Andrew from Cranfield Institute of Technology.



-- 
Sri
Sri Parameswaran Dept. of Electrical & Computer Engineering, 
University of Queensland, Australia. 
Phone:+61-7-365-4190 Fax:+61-7-365-4999 INTERNET: sridevan@s1.elec.uq.oz.au
--
Sri
Sri Parameswaran Dept. of Electrical & Computer Engineering, 
University of Queensland, Australia. 
Phone:+61-7-365-4190 Fax:+61-7-365-4999 INTERNET: sridevan@s1.elec.uq.oz.au
Newsgroups: comp.lsi
From: beerbohm@infko.uni-koblenz.de
Subject: Help: Looking for 16 BIT A/D-Converter
Keywords: 16 Bit ADC 
Organization: University of Koblenz, Germany
Date: Fri, 11 Sep 1992 10:25:29 GMT

Hello,

i am looking for an simple 16 BIT Analog to Digital Converter which
has the following specificationen :
  
  * single, unipolar power consumption. Anywhere between 0..10 V
  * unipolar input signal to convert. Anywhere between 0..10 V 
  * perhaps with some interface logic

Converting time is less interesting, but 100ms .. 250ms should be
the maximum.
Do you have any ideas. Please post it in comp.lsi or email it to
the address below. I will post any summarize if there is any interest.
Thanks in advance

    Dirk

            ---+---                Email : beerbohm@infko.uni-koblenz.de
\______________|_______________/   Fax   : ++49 261 9119-499
              (.)                  Phone : ++49 261 9119-430
Dirk Beerbohm  University of Koblenz  Rheinau 3-4  W-5400 Koblenz  FRG

Newsgroups: comp.lsi
From: eddy@leonardo.et.tudelft.nl (J.G.E. Olk)
Subject: Information on NTL (summary/repost)
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Wed, 09 Sep 1992 19:24:06 GMT


I promised to post a summary of reactions to my request for 
information on Nontreshold (NTL). Unfortunately I didn't get much
reactions (most me too's) so this is at the same time a repost of
my request :-)

So far I have found the following literature discussing NTL in some
way or another:

- H. Mukai, T. Sudo, H.Kindo "NTL-LSI circuit design consideration"
  Rev. Elec. Commun. Lab, 21: 541-546, Sept 1973

- R. Ranfft, H.M. Rein "High-speed bipolar logic circuits with low
  power consumption for LSI - a comparison"
  IEEE J. Solid State Circuits, SC-17: 703-712, August 1982

- M. Suzuki, S. Horiguchi, T. Sudo "A 5K-gate bipolar masterslice LSI
  with a 500 ps loaded gate delay"
  IEEE J. Solid State Circuits, SC-18: 585-592, October 1983

- M. Suzuki, H. Okamoto, S. Horiguchi "Advanced 5K-gate bipolar gate
  array with a 267 ps basic gate delay"
  IEEE J. Solid State Circuits, SC-19: 1038-1040, December 1984

- H. Ichino, M. Suzuki, S. Konaka, E. Yamamoto "A 50-ps 7K-gate
  masterslice using mixed cells consisting of an NTL gate and an LCML
  macrocell"
  IEEE J. Solid State Circuits, SC-22: 202-207, April 1987

- C.Y. Wu, T.S. Wu "A new physical timing model for bipolar NTL circuits"
  Proc. 1988 Bipolar circuits technology meeting, 223-226, sept 1988

- J.S. Wang, C.Y. Wu, M.K. Tsai "CMOS nonthreshold logic (NTL) and
  cascode nontreshold logic (CNTL) for high-speed applications"
  IEEE J. Solid State Circuits, SC-24: 779-786, June 1989

- S. Konaka, et al "A 20-ps bipolar IC using advanced super self-aligned
  process technology with collector ion implantation"
  IEEE trans. on electron devices, ED-36: 1370-1375, July 1989

- C.T. Chuang "NTL with complementary emitter-follower driver: a
  high-speed low-power push-pull logic circuit"
  Dig. Tech. Papers, Symp. VLSI Circuits, 1990, pp. 93-94

- C.T. Chuang "NTL with complementary emitter-follower driver: a
  high-speed low-power push-pull logic circuit"
  IEEE J. Solid State Circuits, SC-26: 661-665, April 1991

- A. Bellouar, M.I. Elmasry "BiCMOS nonthreshold logic for high-speed
  low-power applications"
  IEEE J. Solid State Circuits, SC-26: 1165-1167, August 1991


It seems this is all there is about NTL. Or am I wrong?
If you know of other articles/books/reports discussing NTL, 
please email me.

Thanks,
- Eddy

-- 
\  Eddy Olk                          Section Computer Architecture         \
/  email: eddy@duteca.et.tudelft.nl  Department of Electrical Engineering  /
\  phone: +31-15-785021              Delft University of Technology        \
/                                    The Netherlands                       /
Newsgroups: comp.lsi.testing
From: roy@mcnc.org (Subhash Chandra Roy)
Subject: Re: To Test or Not to Test?
Organization: MCNC Center for Microelectronics, RTP, NC
Date: Wed, 9 Sep 1992 13:32:33 GMT

In article <DON.ALLINGHAM.92Sep3081939@bbking.FtCollins.NCR.COM> Don.Allingham@FtCollinsCO.NCR.COM writes:
|From what I see, the problem is reversed, especially among ASICs.  Maybe
|not for DRAMS, SRAMS, or other stable, long term processes.  In the ASIC
|market, the processes are always on the leading edge.  You have to be,
|or you cannot stay in business.  Everyone wants the leading edge process
|because it is denser (cheaper) and faster.  New processes are always
|less stable than old, mature processes.
|
|--
|Don Allingham           
|NCR Microelectronics 			Don.Allingham@FtCollins.NCR.com
|Ft. Collins, CO.        		uunet!ncrlnk!ncr-mpd!Don.Allingham
|

Just a comment, not everyone wants the leading edge process.  For a majority
of consumer products, the cheapest most mature process is perfect.  This
seems to hold pretty true for medium size multipliers (500k - 1M parts) esp
when the design is pad limited.


Obligatory test statement.
Test issues are growing in complexity because of technological strides and 
an increased emphasis on product quality and reliability. As designs sizes 
increase beyond 40k gates, ad-hoc DFT techniques along with traditional test 
pattern generation methods no longer provide high fault coverage for any 
given design, without the designer or test engineer manually generating a 
majority of tests.  Along with these pressures, the market place is also 
demanding that products are completed faster and with less cost. The goals, 
however, are a trade-off between two seemingly divergent concepts, reduce 
testing costs and increase product reliability.


Subhash
roy@mcnc.org
"Yet another IC designer from MCNC"
From: blade@ccwf.cc.utexas.edu (David Suggs)
Newsgroups: comp.lsi.testing
Subject: Sequential ATPG w/ source needed
Date: 14 Sep 92 18:34:34 GMT
Followup-To: comp.lsi.testing
Organization: The University of Texas at Austin, Austin TX

I am looking for a sequential automatic test generator with source
written in C and/or C++.  I would prefer one with good source
documentation over one that is fast or has fancy features, but
beggars can't be choosers, so I would welcome any suggestions.

Sincerely,
David Suggs (blade@happy.cc.utexas.edu)
From: rsaripa@mercury.cs.clemson.edu (Saripalli Ramakrishna)
Newsgroups: comp.compilers
Subject: Any papers/articles on extracting parallelism?.
Keywords: parallel, optimize, question, comment
Date: 4 Sep 92 17:48:08 GMT
Reply-To: rsaripa@mercury.cs.clemson.edu (Saripalli Ramakrishna)
Organization: Clemson University Computer Science Dept.

I am taking a course on compilers this semester which includes a project.
I am interested in the kind of compiler projects where you extract the
maximum parallelism from a sequential code.

Can someone e-mail me as to whether there are any ftp sources for such
technical papers?.  I am also interested in knowing if there are any books
on these topics (apart from the ubiquitous dragon book)?.

Also, other suitable articles would be those on data-flow analysis,
control-flow analysis etc?.

Any pointers would be appreciated and I can summarize.

						Thanks a lot,
					Saripalli Ramakrishna

e-mail : rsaripa@cs.clemson.edu
[There are several bibliographies in the compilers archive which may have
relevant citations.  See the FAQ for details. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: bruce@harry.ugcs.caltech.edu (Bruce J Bell)
Newsgroups: comp.compilers
Subject: Re: Parsing wars
Keywords: parse, LR(1)
Date: 9 Sep 92 00:46:52 GMT
Reply-To: bruce@harry.ugcs.caltech.edu (Bruce J Bell)
Organization: California Institute of Technology, Pasadena

jar@cheops.HQ.Ileaf.COM (Jim Roskind x5570) writes:

( about a stack-based parser that puts reduced nonterminals back on the input,
  instead of on the stack )

>The conseqeunces of this extension are quite significant, and the
>resulting parser engine provides a much larger class of parsers than LR
>parsers.  Clearly all LR parsers are a subset of the above parsers, as
>doing the above "strange reduce" followed by a "shift" is identical to
>doing a classical LR engine "reduce."

>To see the weirdness of this extension, it can be noted that you can build
>an N pass parser using the above mechanisms.  Certainly parsing is not
>restricted to Left to right, Right most derivation.  ...

If you allow "single-reductions", this parser sounds an awful lot like a
Turing machine, but if you require that all reductions convert more than
one symbol to a nonterminal, you have a parser that is less powerful than
a Turing machine, but still more powerful than an LR parser.  Either way,
I have heard this kind of parser referred to as a "two-stack parser",
since the "strange reduce" treats the input as a stack which is
initialized with the program text on it.

Also, if there are no single-reductions, you are guaranteed that the parse
takes time proportional to the length of the input string, while a 2-stack
parser with single-reductions could conceivably take a great deal of time,
or just enter an infinite loop...

I have looked into this class of parser as possibly being powerful enough
to integrate lexing into the parser.  I doubt it would improve efficiency
much, but the idea of putting the entire front end into a single
conceptual framework has its appeal.

Bruce J. Bell
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: phil@icarus.weber.edu (Phillip Neiswanger)
Newsgroups: comp.compilers
Subject: Register Allocation for Z80000...
Keywords: registers, optimize
Date: 9 Sep 92 03:13:33 GMT
Reply-To: phil@icarus.weber.edu (Phillip Neiswanger)
Organization: Compilers Central

Hi,

I'm interested in determining the affects of the Z80000 register
architecture on compiler register allocation routines.  I read somewhere
that the Z80000 register architecture made it more difficult for register
allocation routines to allocate registers efficiently.  Are there any
people out there who have had experience with the Z80000, or have any
papers concerning register allocation been written about the Z80000.

Thanks for your time.  Email responses would be prefered.

				Phil
				email:	phil@csulx.weber.edu
					phil@icarus.weber.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: drw@euclid.mit.edu (Dale R. Worley)
Subject: Re: Introducing new operators (was: Re: Scientists as Programmers)
Reply-To: drw@euclid.mit.edu (Dale R. Worley)
Organization: MIT Dept. of Tetrapilotomy, Cambridge, MA, USA
Date: Fri, 11 Sep 1992 18:11:33 GMT
Followup-To: comp.compilers
Keywords: parse, design, algol68

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

>If your compiler uses ANY kind of table-driven parsing scheme, it is
>next to impossible to allow programmer-defined operators. ...

   I think that "next to impossible" is perhaps overstating the case a
   little.  If you have a small number of precedence levels (eg. Haskell has
   only 10 or 16 I think), then it is quite possible to code up each of these
   precedences as a production in the grammar.

Yes.  I once wrote an Algol 68 front-end, and the scanner simply
translated all operators into one of 11 tokens (ten tokens for the ten
precedence levels of binary operators and one token for unary operators).
The tricky part was that Algol 68 allows one to use a user-defined
operator before declaring it, so you have to pre-scan the text to build
the part of the symbol table that defines the operator precedences, and
then on a second pass actually parse the expressions.

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: dww@inf.fu-berlin.de
Newsgroups: comp.compilers
Subject: Re: Parsing wars
Keywords: parse, LR(1)
Date: 8 Sep 92 09:17:20 GMT
Reply-To: dww@inf.fu-berlin.de
Organization: Free University of Berlin

jar@cheops.HQ.Ileaf.COM (Jim Roskind x5570) writes [about "strange parsing"]

>The conseqeunces of this extension are quite significant, and the
>resulting parser engine provides a much larger class of parsers than LR
>parsers.  Clearly all LR parsers are a subset of the above parsers, as
>doing the above "strange reduce" followed by a "shift" is identical to
>doing a classical LR engine "reduce."

>To see the weirdness of this extension, it can be noted that you can build
>an N pass parser using the above mechanisms.  Certainly parsing is not
>restricted to Left to right, Right most derivation.  To see how to make an
>N pass (trivial) parser using the above engine, you simply have to note
>that a series of "strange reduces" (re: which put stuff back into the
>input queue) can be used at any point to "back up" into the current stack.
>To be fair about this, you have to provide trivial reductions that have a
>right hand side of length 1, and provided new non-terminal names for the
>"popped" entries on the stack.

Oh yes, with backing up it seems you could parse a lot more languages
like a^n b^n c^n (rough sketch: shift all the "a"'s over, then all the
"b"'s. When we reach a "c", delete it, shovel the "b"'s - or a non-terminal
representing them - back into the input, when an "a" or a non-terminal
representing it turns up on the input, delete it and the "b" that should now
be the first element of the "input". Now shovel the "b"'s back on the stack
until we find another "c" and repeat. If they all are gone, we've recognized
the word. Only a^n b^n c^n will be accepted, because we manage to delete an
"a", a "b" and a "c" together.). You might need productions like
? -> ? to strange-reduce whatever is on the top of the stack to the input,
or you could even have terminal symbols on the left hand side of a production.
The trick would be how to specify all this and produce an appropriate table.

It might be rather difficult :-) to prove the termination of this parsing
algorithm, but it seems to be an interesting idea. Has anyone ever seen
something like this described? Pointers, please!
 
-- 
Debora Weber-Wulff                       dww@inf.fu-berlin.de
Institut fuer Informatik                 +49 30 89691 124
Nestorstr. 8-9
D-W-1000 Berlin 31
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: bburshte@pyramid.com (Boris Burshteyn)
Newsgroups: comp.compilers
Subject: Re: Parsing wars
Keywords: parse
Date: 13 Sep 92 21:16:18 GMT
Reply-To: bburshte@pyramid.com (Boris Burshteyn)
Organization: Compilers Central

jar@cheops.HQ.Ileaf.COM (Jim Roskind x5570) writes [about "strange parsing"]

>The conseqeunces of this extension are quite significant, and the
>resulting parser engine provides a much larger class of parsers than LR
>parsers.  ...

The idea of several passes over the reduction stack has also been
expressed in my paper in SIGPLAN NOTICES V.27 N.1, 1992. 

A parser built upon a modifiable grammar changes the set of available
context-free rules on the fly while parsing the source. If it cannot
continue, it backtracks and tries to reduce tokens (terminals &
nonterminals) from the stack. It may indeed find something to reduce
because of new rules introduced dynamically. Several backtracking attempts
can be made, and the set of rules may be changed while reparsing the
stack. There is also an example of parsing of expressions before
declaration of variables.

Regards - Boris Burshteyn (bburshte@pyramid.com)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1557 comp.human-factors:2217
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.compilers,comp.human-factors
Subject: Re: language design tradeoffs
Keywords: C, macros, design
Date: 14 Sep 92 19:45:12 GMT
Reply-To: tmb@arolla.idiap.ch (Thomas M. Breuel)
Followup-To: comp.compilers
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle Perceptive)

raveling@Unify.com (Paul Raveling) writes:

   Actually I like the idea of using EOL rather than ;.  It eliminates a
   cause of several common errors in compilation that need not happen, and it
   need not have particularly adverse side effects.

   Here's one example of a human factors trap in C that wouldn't be there
   without ';'.  The key is C's syntax definition for <statement> -- either
   one simple statement terminated by ';' or a sequence of simple statements
   surrounded by {}'s. [... macro example deleted ...]

This is a misfeature of C that comes about because of a conspiracy between
poorly chosen "if" syntax and poorly chosen macro semantics.  It is not
very much related to how you terminate your statements (in fact, I could
imagine similar problems if you chose EOL as your statement terminator).

In my experience, explicitly terminating statements with something like
";", or even better, explicitly bracketing each statement (as in Lisp), is
the most effective syntax for protecting you from typos and slips.

					Thomas.
-- 
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 (Mark)
Newsgroups: comp.compilers
Subject: Re: LR(0) vs. LALR, and the Great Parsing War
Keywords: parse, LALR
Date: 5 Sep 92 15:43:56 GMT
Reply-To: markh@csd4.csd.uwm.edu (Mark)
Organization: Computing Services Division, University of Wisconsin - Milwaukee

goer@midway.uchicago.edu (Richard L. Goerwitz) writes:
>>Yes and no.  If this were true, then Tomita's algorithm would have a cubic
>>worst-case time factor.  He uses a graph-structured parse forest, though,
>>and claims polynomial time.
>Exponential time factor, I mean.  Not "cubic"!

This is what I understand to be the case:

The later (1992) reference made a couple enhancements to the algorithm
that gives it cubic worst case performance in both space and time.  That
means that every possible parse, even if there is an infinite number of
them, is accepted within those space and time limits.

And it is still linear on LR(1) grammars.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: masticol@cadenza.rutgers.edu (Steve Masticola)
Newsgroups: comp.compilers
Subject: Re: Abstract Interpretation Query
Keywords: functional, logic
Date: 6 Sep 92 14:22:09 GMT
Reply-To: masticol@cadenza.rutgers.edu (Steve Masticola)
Organization: Rutgers Univ., New Brunswick, N.J.

vugranam@pike.ee.mcgill.ca (Vugranam Chakravarthy Sreedhar) writes:
>AI, although nice, is expensive in terms of time and space. I doubt if the
>concept is being used in any production compilers.

I don't believe that this generalization holds. As I understand it,
abstract interpretation (please forgive me if I don't use the prejudicial
term "AI" :-) is a theoretical framework for connecting a program to an
abstraction of that program, or for generating the abstraction given some
particular information you'd like to estimate.  The abstraction is
supposed to have properties that make it nice for data flow analysis
(monotonic edge functions, etc.)  

Standard problems like reaching definitions can be cast in an abstract
interpretation framework, and it costs nothing in terms of analysis time
to do so.

If anyone knows differently, please jump in...

- Steve Masticola (masticol@cs.rutgers.edu).
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1537 comp.human-factors:2172
From: nr@dynastar.Princeton.EDU (Norman Ramsey)
Newsgroups: comp.compilers,comp.human-factors
Subject: Re: language design tradeoffs
Keywords: design
Date: 9 Sep 92 19:24:10 GMT
Reply-To: nr@dynastar.Princeton.EDU (Norman Ramsey)
Organization: Princeton University, Dept. of Computer Science

You might want to consider using John Ousterhout's tcl language, which was
designed for just the kind of application you describe, and which comes
with an implementation.  I'm not saying that tcl is the world's most
wonderful language, but it's decent enough, and you can spend your time
doing real work :-).
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.