HDTenEightyP/NetNews huggingface dataset:
From: ni@galaxie.int-evry.fr (Yang NI)
Newsgroups: comp.lsi.testing
Subject: How to read Group comp.ai.vision
Date: 27 Aug 92 11:52:59 GMT
Organization: INT Evry, France

Hi, everybody
	i am a little troubled by the absence of articles in
comp.ai.vision group. i think this is very active domain, there
must be many articles, but i have never seen any articles inside
	Is it normal?????

-- 
Yang NI
Departement Electronique et Communications
Institut National des Telecommunications
9, rue Charles Fourier
91011 Evry Cedex France
email: ni@galaxie.int-evry.fr
From: strataki@cerberus.csi.forth.gr (Manolis Stratakis)
Newsgroups: comp.lsi.testing
Subject: Conversion of test vectors generated by Silos to TekWaves.
Date: 28 Aug 92 14:36:55 GMT
Organization: FORTH - ICS, P.O.Box 1385, Heraklio, Crete, Greece 71110 
       tel: +30(81)221171, 229302 fax: +30(81)229342,3 tlx: 262389 CCI


	Hello,

	We try to solve a problem concerning the conversion
of test vectors generated by Silos to a format suitable
to be read by TekWaves, and eventualy by the Tektronix 
LV500 verifier.

	We have tried several ways to interface Silos to 
TekWaves: Eurochip has provided us with some scripts to do
the job, but unfortunately they didn't work in our case.
We tried to do the conversion ourselves by writing C 
programs and awk filters, but TekWaves is still not happy.

	If somebody has faced the problem before, please e-mail
me any solutions, ideas, or possible information sources.
	
	Thanks a lot,

	Manolis Stratakis,				(strataki@csi.forth.gr)
	Computer Science Institute,
	Foundation of Research and Technology - Hellas.
	
Newsgroups: comp.lsi.testing
From: praveen@sirius.mcc.com (Praveen Vishakantaiah)
Subject: Re: Rise and shine
Followup-To: Rise and shine
Organization: Microelectronics and Computer Technology Corp.
Date: Mon, 31 Aug 1992 14:51:27 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. 

> 
> Praveen> Well, isn't testing harder than designing ;-). Nobody has proved VLSI 
> Praveen> design to be an NP-complete problem (as far as I know)!
> 

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

I should have specified it more clearly. I meant logic and functional
design. Yes, placement, routing etc. are NP-complete and are part of the
design process. But then I consider testing also to be an essential part of
VLSI design and the whole purpose of comparing design and test is lost. 

Thanks for pointing it out.

> Praveen> After all, the testing problem was NP-complete, is NP-complete 
> Praveen> and will be NP-complete!! 
               ^^^^^^^^^^^^^^^^^^^^

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

Or until the computer scientists/mathematicians give up:-) 

Praveen Vishakantaiah.

------------------------------------------------------------------------------
-- Microelectronics and Computer Technology Corporation, | Ph : (512)338-3736|
-- 3500 W. Balcones Center Drive                         | e-mail :          |
-- Austin, TX 78759.                                     | praveen@mcc.com   |
------------------------------------------------------------------------------
-- ALSO A HARD WORKING MEMBER OF :-)                     |
-- Computer Engineering Research Center,                 | Ph : (512)471-8013|
-- University of Texas, Austin.             e-mail : praveen@cerc.utexas.edu | 
-----------------------------------------------------------------------------

Newsgroups: comp.lsi.testing
From: yooho@ursula.ic.cmc.ca (Yoo Ho Cho)
Subject: Monthly Posting : comp.lsi.testing charter
Organization: Canadian Microelectronics Corporation
Date: Wed, 2 Sep 1992 20:54:08 GMT


This is the monthly posting of the comp.lsi.testing charter.


NAME/GROUP: 
    comp.lsi.testing

STATUS:
    unmoderated 

CHARTER:
    This newsgroup is intended to cover all aspects of the testing of
    electronic circuits such as (but not restricted to)
      *  Testing of Digital and Analog Devices
      *  Automatic Test Pattern Generation
      *  Fault Modeling and Fault Simulation
      *  Design for Testability
      *  Scan Design and Built-in Self Test
      *  PCB-Test and Boundary Scan
      *  Design Verification
      *  ATE

    Important topics are (again not restricted to)
      * Announcements (conferences, workshops, special issues)
      * Books on testing
      * Standards
      * Benchmarks
      * Questions and answers
      * Discussions concerning technical or algorithmic problems
      * Available commercial and public domain tools

    PLEASE: DO NOT USE THIS GROUP FOR "test" POSTINGS TO CHECK YOUR
    MAILER OR NEWS SYSTEM. THERE ARE OTHER SPECIAL GROUPS FOR THIS
    PURPOSE, such as "alt.test", "news.test", "local.test" ETC.

WHY THIS GROUP:
    The ever increasing number of publications on testing shows a
    vivid and growing interest in that subject. A newsgroup on 
    testing will stimulate and accelerate the exchange of related 
    information among interested network users. It makes it easier 
    to recognize current trends in testing, especially for novices. 
    
    The discussion period showed a general agreement on the theme.
    Our first proposal for the name of the group was comp.lsi.cat,
    which is similiar to comp.lsi.cad. A number of contributors 
    remarked that this name is not generally understandable or 
    misleading. Among the proposed alternatives were:
    comp.lsi.test, comp.lsi.testing, comp.lsi.ate, comp.lsi.ft (fault 
    tolerance). Taking into account that ".test" may sound like
    "alt.test", "news.test" which have a specific function within the
    USENET hierarchy, the proposed name "comp.lsi.testing" should be
    the most understandable and general one. 

    Some authors commented that there are existing groups like comp.lsi
    which do not have an extreme news flow to date. Splitting therefore
    should not be necessary. We have never intended to split any group
    due to "net bandwidth", comp.lsi.testing is a new thread. A closer
    look at comp.lsi[.cad] shows that these groups are mostly design oriented,
    and this probably raises the level for participation of non-designers.
From: thomae@eos.ncsu.edu (DOUGLAS ALAN THOMAE)
Subject: Re: Change this Group Name?
Originator: thomae@boomer.csl.ncsu.edu
Reply-To: thomae@eos.ncsu.edu
Organization: North Carolina State University
Date: Tue, 25 Aug 1992 18:28:33 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
[...]
|>An alternate group name that doesn't contain the word "testing" would
|>be better.  My suggestions are:
|>
|>2. comp.lsi.defects
|>or
|>3. comp.lsi.faults
|>

...or eliminate comp.lsi.testing entirely.  comp.lsi dosen't
get that much traffic anyway, and as you've observed merely
having a seperate newsgroup dosen't do much to cut down
on posts that testing people are not interested in.

Newsgroups: comp.lsi.testing
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: Change this Group Name?
Organization: Metaflow Technologies Inc.
Date: Thu, 27 Aug 1992 21:55:34 GMT

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?

-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, CA  92037     Unless otw specified, I`m speaking only for myself!
From: mjohnson@netcom.Netcom.COM (Mark Johnson)
Newsgroups: comp.lsi.testing
Subject: Re: Ring oscillators for characterization?
Date: 3 Sep 92 16:05:01 GMT
Organization: Netcom Online Communications Service

In my experience, ring oscillators are among the BEST
vehicles for process monitoring.  Generally the
most useful ones are a series of _loaded_ oscillators:

   (i)   Oscillator with long thin fingers of N+ diffusion
         loading down every node.  Monitors effect of
         N+ junction perimeter capacitace

   (ii)  Oscillator with fat rectangular boxes of N+
         diffusion loading down every node.  Monitors
         effect of N+ junction perimeter capacitace

   (iii) Oscillator with long meander track of minwidth
         metal-1 loading down every node.  Monitors
         effect of metal-1 capacitance.

   (iv)  Oscillator with a 3-input mux in series between
         each inverting stage.  Monitors effect of
         mux delay (mosfet "R" & "C", junction C).

   (v)   Oscillators made of NAND gates, inverters,
         NOR gates.  Shows effect of PMOS stacks,
         NMOS stacks.

etc.

Admittedly the measurements you get are indirect
indicators of process deviations.  However they are
DIRECT indicatiors of product performance.

The tough part is getting the automatic tester to
do the measurements.  About the best arrangement
I've seen for this was at Vitesse (GaAs vendor).
They do it simply: the oscillators are always
located in the same location in the scribe lane,
so they have dedicated probecard pins for the
oscs.  These go to a GPIB-interfaced frequency
counter.  The frequency counter does the
measurement and presents its result to the tester
over GPIB.  Costs a couple hundred bux.

MJ
Newsgroups: comp.lsi.testing
From: thalli@piis10.joanneum.ac.at (Georg Thallinger (IIS))
Subject: Help on Magic / gds data format
Keywords: Magic gds
Organization: Joanneum Research (IIS)
Date: Wed, 26 Aug 92 12:52:19 GMT


Hi net people,

  We have installed magic (ver 6.3) on our DECSTATION 5000 running BSD.
Compiling went well, but the problems begun thereafter.

  On most of our commands the response is :
>>>>> Point to a window first.    <<<<<<<
We tried to click in a window , issued setpoint commands even tried to part te userinterface over two machines ( graphicswindow one one , term one another) but didn't get any sucess :-(.

  So anybody out there who has any hints ??

Another question :  Are there any viewers for data-files in gds II-format ?

Thanks again.

IMPORTANT : please reply only by mail to  gruberw@pbox.joanneum.ac.at !!!!!

Georg

-- 
Georg THALLINGER                      | e-mail: thalli@piis10.joanneum.ac.at
Institute for Information Systems     |         thallinger@joanneum.ada.at
JOANNEUM RESEARCH GRAZ /  AUSTRIA     | phone:  (++43/316) 8020-243
Newsgroups: comp.lsi
From: mhbrekke@iastate.edu (Monty H. Brekke)
Subject: Ultra high-speed analog voltage comparator
Organization: Iowa State University, Ames, IA
Date: Thu, 3 Sep 1992 03:08:12 GMT

I apologize if this is the wrong group to post to, but I can't
find any other groups that seem suitable.

As the subject implies, I am looking for a very fast (< 1ns) 
voltage comparator. I don't care what technology the thing
is implemented in, but it will probably need to be ECL. 
In addition to the high speed, I need an input voltage range
of +/- 5V. I would prefer a device which has several of these
beasts on a single IC, but could use individual components if
necessary.

If anyone knows who builds a device like this (if anyone does),
please email your responses. I will post a summary if anyone is
interested.

-Monty Brekke

-- 
Internet : mhbrekke@iastate.edu
Xref: sparky comp.lsi:581 comp.lsi.testing:216
From: jcooley@seqp4.sequoia.com (John Cooley)
Newsgroups: comp.lsi,comp.lsi.testing
Subject: ESNUG goes on Vacation
Date: 4 Sep 92 15:41:39 GMT
Organization: Sequoia Systems Inc., Marlboro, Mass.



  This message is directed to the subscribers of the E-mail Synopsys Users
  Group (ESNUG) who may have missed the latest mailing:

  E-mail at my company is going to be messed up for the next two weeks because 
  we're moving to another building.  As a consequence, ESNUG will be down for 
  9 days from Monday, Sept. 7 to Wednesday, Sept. 16.

						- John Cooley

 ===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how others dealt
 with it ?  Join the E-Mail Synopsys Users Group!  To join, E-mail me today! 
 ===========================================================================
      !!!     "It's not a BUG,    |           jcooley@sequoia.com
     /o o\  /  it's a FEATURE!"   |         jcooley@sds.sequoia.com
    (  >  )                       |        "Yes, We make trees here!"
     \ - /       |
     _] [_       |        "This here ain't no one's opinion 'cept my own."
From: ae24@iamk4516.mathematik.uni-karlsruhe.de (Peter Januschke)
Newsgroups: comp.compilers
Subject: Re: IEEE Floating-Point Package?
Keywords: arithmetic
Date: 2 Sep 92 14:41:28 GMT
Reply-To: ae24@iamk4516.mathematik.uni-karlsruhe.de (Peter Januschke)
Organization: University of Karlsruhe, Germany

I received several messages concerning the IEEE floating point package.
To reduce responding time, I would like to answer some of the often
asked questions here :

 1.) The floating point package is a part of the PASCAL-XSC system
     which is traded by Numerik Software Gmbh. Therefore :

 2.) The package is not free, i.e. you can not get it and distribute
     it to other people as you like. If you want to do so
     nevertheless, you have to come to an arrangement with
     Numerik Software GmbH.

 3.) If you want to test the IEEE-arithmetic, directed roundings and
     so on, you should be a little patient.
     We are going to upload a demo version of the PASCAL-XSC system
     for MS-DOS computers at the SIMTEL20 archive.
     To run the demo system you must have a BORLAND C++ system
     version 2.0 ( or higher ) available.

  Dipl.-Math. Peter Januschke
  Institute for Applied Mathematics
  University of Karlsruhe, Germany
  e-mail :   ae24@iamk4516.mathematik.uni-karlsruhe.de  (129.13.129.16)
-- 
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: Parsing wars
Keywords: parse, LR(1), question, comment
Date: 31 Aug 92 16:13:40 GMT
Reply-To: dww@inf.fu-berlin.de
Organization: Free University of Berlin

I have encountered a parsing method that I do not understand. Perhaps it's
just some sort of fancy technique, maybe I overlooked something.  If
someone can either tell me how this works or else state <rtfm,book,topic>
I would be grateful.

The parsing is called shift-reduce parsing, and I thought I had understood
that. What happens on a reduction though is, instead of pushing the
nonterminal of the lhs of the reduced production onto a symbol stack and
digging through the goto table for the appropriate state to push onto the
state stack, the nonterminal is *prepended* to the input sequence of
tokens and parsing resumes as normal. The other actions, shift, accept and
error are as expected, an action shiftreduce combines the normal shift and
the strange reduce.

My question: how and why does this work? What does it buy me? (Is it
extremely efficient? Use compact tables? Wrong?)

Thanks for any clues!
-- 
Debora Weber-Wulff                       dww@inf.fu-berlin.de
Institut fuer Informatik                 +49 30 89691 124
Nestorstr. 8-9, D-W-1000 Berlin 31
[It sounds to me like a way to combine the shift and goto tables, since
pushing the nonterminal and then shifting it would be equivalent to a
goto.  -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: paist@maxine.WPI.EDU (David Paist)
Newsgroups: comp.compilers
Subject: OOL & RISC references?
Keywords: OOP, question
Date: 31 Aug 92 21:58:29 GMT
Reply-To: paist@maxine.WPI.EDU (David Paist)
Organization: Compilers Central

This is a request for references.

I'm undertaking a master's thesis with a goal of compiling an object-
oriented language and generating RISC code.  From previous course work, I
have a compiler that adequately handles the more traditional issues, and a
few of the simpler OO cases.  The work to be done includes the write-up
and implementation of the following:

        Multiple inheritance
        Polymorphism
        Persistence
        Specialization of methods
        RISC instruction sequencing
        Register windows

Articles that define and discuss the use of OOP concepts haven't been hard
to find.  Now I'm looking for implementation details.  References such as
the Goldberg & Robson book, "Smalltalk-80: The Language and its
Implementation," have provided some ideas.  However, I'm trying to find
more literature that is specific to compiled language, perhaps going into
greater detail.

I would also be interested in references on RISC code generation.  By the
way, besides Sparc, is there any (commercial) RISC processor that provides
register windows?

Help in these areas would be greatly appreciated.

                                        Dave Paist
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: wendt@CS.ColoState.EDU (alan l wendt)
Newsgroups: comp.compilers
Subject: Seeking book "A Compiler Generator"
Keywords: books, question
Date: 31 Aug 92 21:03:28 GMT
Reply-To: wendt@CS.ColoState.EDU (alan l wendt)
Distribution: usa
Organization: Colorado State University, Computer Science Department

Does anyone have a copy (new or used) of McKeeman, Horning, & Wortman
"A Compiler Generator" that they are willing to sell.  I missed getting
this great book when it was in print.

Alan Wendt
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1480 comp.compression:3136
From: graham@maths.su.oz.au (Graham Matthews)
Newsgroups: comp.compilers,comp.compression
Subject: Re: Representing unions of Cartesian products
Keywords: theory, design
Date: 30 Aug 92 04:05:26 GMT
Reply-To: graham@maths.su.oz.au (Graham Matthews)
Organization: School of Mathematics and Statistics, University of Sydney

(Mark-Jan Nederhof) writes:
>I am looking for an efficient way to store and manipulate unions of
>Cartesian products. 
...
>At this moment I am using a representation where a union of Cartesian
>products is transformed into another such that the Cartesian products do
>no longer overlap (i.e. they have no tuples in common).  If possible I
>merge two Cartesian products into one.  These transformations are however
>rather expensive.  Does anyone have a better suggestion? references to
>papers?

I may be off the mark here but one way to do this is to represent your
cartesian products as predicates. Then the union of two cartesian products
C1 and C2 is the logical or of their respective predicates, the
intersection is the logical and of their respective predicates, etc.

This scheme allows for fast membership testing of a tuple in a cartesian
product, and allows maintains enumerability. If C1 and C2 are enumerable
then so is C1 union C2, C1 intersect C2, etc.

Efficiency is a bit of an issue here, but given that you don't want to
represent cartesian products explicitly, you don't appear to have much
choice but to sacrifice efficiency.

graham
--
Graham Matthews
Pure Math, Uni.Sydney, Oz
graham@maths.su.oz.au
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Subject: ASF+SDF (Was: Online Bibliography for Macro Processors ...
Reply-To: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Organization: The Johns Hopkins University CS Department
Date: Sun, 30 Aug 1992 02:04:29 GMT
Keywords: macros, specification

Paul.Klint@cwi.nl (Paul Klint) writes:
>The resulting formalism (ASF+SDF) has the complete expressive power of
>conditional rewrite rules with additional benefits of user-defined syntax.
>We use it to define the formal syntax and semantics of "formal languages" ...

	You forgot to mention that the ASF+SDF formalism has been
implemented and is available as part of the Centaur set of language tools
available from INRIA.  Contact centaur@mirsa.inria.fr for techical info,
and centaur-request@mirsa.inria.fr for ordering and administrivia.
Remember, the Centaur system is NOT free; get somebody else to buy it for
you!  It makes a great Christmas gift!  :-)
--
Jack Eifrig (eifrig@cs.jhu.edu)       The Johns Hopkins University, C.S. Dept.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: preston@dawn.cs.rice.edu (Preston Briggs)
Newsgroups: comp.compilers
Subject: Re: interaction between loop scheduling and register allocation
Keywords: registers, optimize, bibliography
Date: 28 Aug 92 18:06:54 GMT
Reply-To: preston@dawn.cs.rice.edu (Preston Briggs)
Organization: Rice University, Houston

wang@minos.inria.fr writes:
>Is [there] any published paper about the interaction between
>loop scheduling and register allocation and the algorithms for combining 
>these two parts?

Try this one, from the SIGPLAN '92 Conference on Programming Languages
and Design.  The proceedings are published in SIGPLAN Notices.

@article{rau:92,
  title="Register Allocation for Software Pipelined Loops",
  author="B. R. Rau and M. Lee and P. P. Tirumalai and M. S. Schlansker",
  pages="283--299",
  journal=sigplan,
  year=1992,
  month=july,
  volume=27,
  number=7,
  note=pldi92
}
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.