HDTenEightyP/NetNews huggingface dataset:
From: osyjm@cs.montana.edu (Jaye Mathisen)
Newsgroups: comp.lsi,comp.lsi.cad
Subject: Re: problems with OCTTOOLS
Date: 14 Apr 92 13:35:00 GMT
Organization: Montana State University, College of Engineering, Bozeman MT, 59717

In article <728sis-b@massey.ac.nz> M.Pearson@massey.ac.nz writes:
>
>I am hoping to have a chip fabricated that has been designed using
>OCTTOOLS in the near future. I have recently found out there are a
>number of potental problems with octtools including:
>
>     - The MOSIS pads provided with version 5.0 do not work
>     - The cif generated is not necessarily correct
>
>Has anybody out there managed to sucessfully fabricate a chip using
>octtools to produce the design. If so what path was used and where was
>the chip fabricated? 

The EE department here has fabricated several chips using OCT.

1) "BTPX"  a 16bit RISCish CPU, with lots of cool stuff, done as a 4 week
	assignment for an architecture class. This chip is fairly good
	sized, 1600-1800 cells for the core. (I did this one, along with
	2 other EE people).  The chip works fine, except the address
	logic was shorted out for some reason, although the design and
	layout looked fine, and simulated fine.  This was with Oct 4.0

2) "DLX"  The next years arch class built a mini-DLX from the architecture
	description in the Hennessy-Patterson book.  It's back from fab, and
	works, except MOSIS used an old release that didn't have a clock
	driver on the chip, and hence has some problems with skew or 
	somesuch.  But all the individual instructions work fine, and the
	chips runs about 1MHZ.

3) A whole slew of tinychips.  Every EE VLSI class had about 10 group
	projects, with all kinds of variety that all had to fit in the
	MOSIS "tinychip" category.  Dozens of these are back from 
	fab.

4) One of the grad students here (Grant Beagles, ieeg0010@amin.ee.montana.edu),
	developed and fab'd a neural-net chip that he presented a paper on
	at some recent conference.


Notes:

Oct 5.1 is the current release, and is MUCH improved over 5.0, although I
don't remember pads being one of the things addressed in the new release.

Kel Winters is the EE professor responsible for these classes, however, he's
turned traitor (Hi kel!) and moved from academia to the private sector.  He
can be reached as 'kel@aha.com'.  You can contact him for more detail if
you want...

You're welcome to ask me specific questions, but I don't know all the 
answers, I just built the first big chip ever fab'd with the OCTTOOLS.  At
the time, from conversations with the people at Berkeley, it was the
largest and most complex.
-- 
 Jaye Mathisen, COE Systems Manager                (406) 994-4780
 410 Roberts Hall,Dept. of Computer Science
 Montana State University,Bozeman MT 59717	osyjm@{cs,coe}.montana.edu
Xref: sparky comp.lsi:311 comp.lsi.cad:493
From: jtw@duke.cs.duke.edu (James Thomas Wilkes)
Newsgroups: comp.lsi,comp.lsi.cad
Subject: Request for circuit examples
Keywords: DC operating point, Slow Convergence, CAzM
Date: 6 Apr 92 21:40:34 GMT
Followup-To: poster
Organization: Duke University Computer Science Dept.; Durham, N.C.

The research work I am doing involves the application of 
a new method for solving nonlinear systems of equations 
that arise in circuit simulation (cazm level of simulation).

To study this method I obviously need example circuits.  In 
particular I am looking for circuits that give you convergence
problems when using a spice-like simulator in either transient
simulation or when finding DC operating points.  If you have 
experience with any such circuits and can send me the circuit
description, I would greatly appreciate it.  The size of the 
circuit doesn't matter; I think I can handle circuit descriptions 
from magic and for any of you cazm users out there, I'll certainly
take cazm format circuit files (I am using cazm as my platform for
studying this new method).  Also, if you have command files for the
circuits I can use those as well.

Currently I'm especially interested in circuits that give DC operating
point problems, but I eventually will get to the transient problems if
you send them too.

Thanks for your time and your circuits,

<x James Wilkes
   jtw@cs.duke.edu
From: rvutukur@uceng.UC.EDU (Raghunath Vutukuru)
Newsgroups: comp.lsi
Subject: BSDL
Date: 7 Apr 92 13:44:36 GMT
Organization: College of Engineering, University of Cincinnati

Hi,
  
We are developing boundary scan structure synthesis and test vector 
generation tools as part of high-level synthesis system for multi-chip 
module design. 
  
We are looking into BSDL( Boundary Scan Description Language) to use it
as a means of specifying the various options in boundary scan structures
that should be synthesized automatically. Also the same description in BSDL
is intended be used by the test generation tool. 
  
We would appreciate any feedback on the usage of BSDL and its completeness
in describing the architecture for the purpose of synthesis and test vector
generation. We would also like to get in touch with people who are using
BSDL. Please send your mail to
   
         rvutukur@thor.ece.uc.edu
  
Thanks
  
Raghu Vutukuru and Prasad Subbarao

-- 
Raghunath Vutukuru   email : rvutukur@uceng.uc.edu 
Electrical and Computer Engineering, University Of Cincinnati, Cincinnati.
From: farhad@tamaru.kuee.kyoto-u.ac.jp (Farhad F. Islam)
Newsgroups: comp.lsi
Subject: help conference schedule
Date: 11 Apr 92 03:21:53 GMT
Organization: Dept. of Elec. Eng., Kyoto Univ., Japan


        I would like to know about ``Asilomar Conference on Signals, Systems
and Computers" to be held in 1992. I need to know:
	1. The dead line for submission of manuscript.
	2. The date of conference.
and     3. Whom to contact about the conference.
	
	Could anyone please help me with these informations?

					--- Farhad F. Islam
					    Graduate student
				            Electronic Engg. Dept.
					    Kyoto University, Japan.

				     E-mail: farhad@tamaru.kuee.kyoto-u.ac.jp
Xref: sparky comp.lsi:323 comp.lsi.cad:516
From: paul@eros.Berkeley.EDU (Paul Cohen)
Newsgroups: comp.lsi,comp.lsi.cad
Subject: Re: problems with OCTTOOLS
Date: 15 Apr 1992 05:33:43 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: eros.berkeley.edu

In article <1992Apr14.133500.16848@coe.montana.edu> osyjm@cs.montana.edu (Jaye Mathisen) writes:
>In article <728sis-b@massey.ac.nz> M.Pearson@massey.ac.nz writes:
>>
>>I am hoping to have a chip fabricated that has been designed using
>>OCTTOOLS in the near future. I have recently found out there are a
>>number of potental problems with octtools including:
>
>The EE department here has fabricated several chips using OCT.
>
>1) "BTPX"  a 16bit RISCish CPU, with lots of cool stuff, done as a 4 week
>2) "DLX"  The next years arch class built a mini-DLX from the architecture
>3) A whole slew of tinychips.  Every EE VLSI class had about 10 group
>4) One of the grad students here (Grant Beagles, ieeg0010@amin.ee.montana.edu),
>
>Oct 5.1 is the current release, and is MUCH improved over 5.0, although I
>don't remember pads being one of the things addressed in the new release.

> Jaye Mathisen, COE Systems Manager                (406) 994-4780
> 410 Roberts Hall,Dept. of Computer Science

Thanks, Jaye, I couldn't have summed it up much better, except to add
that some of the problems you are referring to (I'm sure you read MUG
18), are related to trying to do "illegal" things with the MOSIS pads,
which must be alternately mirrored and non-mirrored to avoid Vdd/GND
shorts, (I'm not happy with the way this is implemented, but the
"correct" method caused some problems for the tools) and tryng to fab
NWELL pads in a Pwell technology. Read the README file, and check what
you've done carefully.

As part of the testing for the past few Octtools releases, I've fabbed
chips (through the Massachusetts Microelectronics Center) and tested
them (all worked) prior to releasing the rev of the tools.

In general, Octtools support questions can be sent to
octtools@ic.berkeley.edu. For more information reagding the octtocif
conversion scripts or the MOSIS pads, feel free to contact me
directly.

Paul Cohen

paul@aha.com, paul@ic.berkeley.edu

===============================================================================
Opinions expressed here are mine, and mine alone.

Paul Cohen				| paul@aha.com
Advanced Hardware Architectures		| (208) 883-8000 (voice)
P.O Box 9669				| (208) 883-8001 (FAX)
Moscow, ID 83843			|
Xref: sparky comp.lsi:315 comp.lsi.cad:500
From: bouldin@cs.utk.edu (Don Bouldin)
Newsgroups: comp.lsi,comp.lsi.cad
Subject: MOSIS Users' Group Design Files, CAD Software & Newsletters
Date: 7 Apr 92 02:42:03 GMT
Organization: University of Tennessee, Knoxville - CS Department
NNTP-Posting-Host: alphard.cs.utk.edu
Originator: bouldin@alphard.cs.utk.edu

A variety of design files and CAD  tools   contributed   by   the
members  of  the  MOSIS  Users' Group (MUG) are now available via
anonymous ftp from "venera.isi.edu"   (128.9.0.32)  in  directory
"pub/mug".  The  files  "readme"  and "index" should be retrieved
first.  These files are provided "as  is",  but  may  prove  very
helpful  to  those using the MOSIS integrated circuit prototyping
service.

The files include the following:

   a pad frame generator program,
   a 66-bit Manchester carry-skip adder,
   a tile file for MPLA using MOSIS Rev 6 rules,
   a netlist convertor (Futurenet to OCT/bdnet),
   an analog neural network library of cells,
   a new version of the switch-level simulator ESIM
       that can handle CMOS transmission gates,
   an analog op amp,
   a static ram fabricated at 2-micron,
   several complete TinyChip projects,
   a plotter utility for Spice,
   programs for checking wells in MAGIC files, and
   copies of previously broadcast MUG newsletters.

If you do not have ftp capability or would like to  subscribe  to
the  MUG  newsletter  at no charge, send a text message via elec-
tronic mail to bouldin@sun1.engr.utk.edu.

Prof. Don Bouldin
Electrical & Computer Engineering
420 Ferris Hall
1508 Middle Drive
University of Tennessee
Knoxville, TN 37996-2100
Tel:    (615)-974-5444/3461
FAX:    (615)-974-5492
Email:  bouldin@sun1.engr.utk.edu
Newsgroups: comp.lsi
From: dataram@tigger.jvnc.net (Dataram Corp. PO Box 7528)
Subject: FPGA -> Gate Array
Originator: dataram@tigger.jvnc.net
Organization: JvNCnet, Princeton University, NJ
Distribution: usa
Date: Tue, 7 Apr 1992 18:40:35 GMT

We are looking at converting a Xlinx design into a NEC gate array. So 
far we have found a software package that is suppose to do this from
a company called Exemplar Logic. If you have been this route using
Exemplar or some other source, please send me e-mail or post here.
I will compile a summary reply if there is enough interest.
                             Chuck Staatse

-- 
Michael DeMeis     Dataram Corp.
                   609-799-0071 x229
michaeld@dataram.jvnc.net

Xref: sparky comp.lsi:314 comp.lsi.cad:499
From: cmg996@cck.coventry.ac.uk (Martin-Martin Nike)
Newsgroups: comp.compilers
Subject: Re: Book "Writing Compilers & Interpreters"
Keywords: books
Date: 3 Apr 92 11:22:13 GMT
Reply-To: cmg996@cck.coventry.ac.uk (Martin-Martin Nike)
Organization: abUSENET, Coventry Polytechnic, Coventry, UK

>>I was wondering if anyone has the book "Writing Compilers and Interpreters"
>>by Ronald L. Mak and if it's worth buying.
>[or how it compares to Fisher & LeBlanc]

If you want a book which gives the construction of a compiler, try Allen
Holub's excellent 'compiler design in C'. The book starts off with a
section on lexical analysis, then follows up with sections on grammar and
then includes the actual source of two parser's and a lexical analyser,
explained step by step.

Also included is a complete C compiler, broken down and explained
thoroughly.

I used this book to write a compiler for my honours project, and apart
from a lot of errors and a few bugs, it gives superb insight in how a
compiler works, how values are manipulated and is written in a friendly
and untheoretical manner.

I'd recommend this book to anyone who wants to learn about compiler design.
-- 
/\/\artin-/\/\artin Nike, Coventry Polytechnic, England.
JANET:cmg996@uk.ac.coventry	               
INET:cmg996%coventry.ac.uk@nsfnet-relay.ac.uk
[Holub's book has been discussed at length in the past here.  It gives the
complete annotated source code for a working compiler, the only book I know
of that does so.  Early printings suffered from a phenomenal number of
editing and printing errors, but errata sheets are available (see message
90-06-081) and recent printings fix most of them. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: taihou@iss.nus.sg (Tng Tai Hou)
Newsgroups: comp.compilers
Subject: binary-compiler from Apple?
Keywords: assembler, translator
Date: 7 Apr 92 00:17:19 GMT
Reply-To: taihou@iss.nus.sg (Tng Tai Hou)
Organization: Institute of Systems Science, NUS, Singapore

Apple is doing a binary-compiler for its new line of PowerPC Macs. It
takes in existing 680x0 code and translate opcodes for the PowerPC chip.

Can anyone tell me if this is logical, or right approach?  Seems to be a
great idea. Why hasn't anyone thought of it before?

Tai Hou
Singapore
[So long as the underlying datatypes are the same, this can be a very
effective technique.  HP apparently uses it to run HP 3000 binaries on the
new Spectrum RISC machines, IBM used it to simulate the RT PC on 370s, and
several packages use it to run IBM PC binaries on workstations. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: smk@dcs.edinburgh.ac.uk
Newsgroups: comp.compilers
Subject: Include files and yacc grammars
Keywords: design
Date: 16 Apr 92 14:18:25 GMT
Reply-To: smk@dcs.edinburgh.ac.uk
Organization: Compilers Central

JOSEPH OSWALD writes:
[how to do include files in yacc given the possible one-token lookahead]
I had once a similar problem and solved it as follows:

The includes were done by the lexer itself, but with some support by the
parser. The idea is that you use lexer's states.

  statement : ... /* usual stuff */
            | INCLUDE '(' statement ')' ';'
            | ...

This doesn't mean that there is a statement in the parentheses,
it is just the expanded file.

The lexer changes its state, so you have something like:

<INITIAL>"include"	{ BEGIN EXPECTPAR; return INCLUDE;}
<EXPECTPAR>"("		{ BEGIN INCLFILE; return '('; }
<INCLFILE>{string}	{ BEGIN INITIAL; files++; yyin=fopen(yytext,"r"); }

Notice that the <INCLFILE> line has no return-statement, i.e. lexer and
parser go on as if nothing has happened, except that the input now comes
from the include file -- its content is parsed by the parser as usual; if
EOF is reached, yywrap is called and here you can check the variable
`files' to distinguish between EOF of stdin and EOF of an include-file.

You might have some more sophisticated actions, e.g.  to apply some
function to yytext to get its meaning, to support error messages talking
about the file they occur, to allow includes in includes, etc.  You also
might want a special state rather than INITIAL to scan an include file,...

One disadvantage of treating INCLUDE in the lexer is that you cannot
(easily) write

	include(f(x));

where f is a function that has to compute the filename yet.  This does not
make much sense in compilers (languages that are supposed to be compiled),
but in interpreters there is no principle problem with it. The most
logical way to treat it seems to be a separate parser to parse the
argument of include (and to evaluate it wrt.  the actual symbol table), at
least this sledgehammer method solves any lookahead problems.
--
Stefan M. Kahrs	                   JANET:    smk@uk.ac.ed.dcs
LFCS, Dept. of Computer Science    Internet: smk@dcs.ed.ac.uk
University of Edinburgh            UUCP:     ..!mcvax!ukc!lfcs!smk
Edinburgh EH9 3JZ                  ARPA:   smk%dcs.ed.ac.uk@nsfnet-relay.ac.uk
SCOTLAND                           Tel:      044-31-650-5139
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: worstell@eecs.ucdavis.edu (Glen Worstell)
Subject: GMD on NeXT
Keywords: tools, question
Reply-To: worstell@eecs.ucdavis.edu (Glen Worstell)
Organization: Compilers Central
Date: Wed, 8 Apr 1992 16:40:19 GMT

Has anyone ported the GMD compiler toolset to the NeXT?
Is the toolset available via ftp from a North American site?

Thanks...
Glen.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: jxyb@crystal.lanl.gov (Jeffery S Brown)
Newsgroups: comp.compilers
Subject: Re: Debugging Strategy Survey
Keywords: debug
Date: 2 Apr 92 19:29:01 GMT
Article-I.D.: comp.92-04-021
Reply-To: jxyb@crystal.lanl.gov (Jeffery S Brown)
Organization: Los Alamos National Laboratory

We employ software watchpoints as follows:

Our debugger developed at Los Alamos (ldb) has a "watch" command that
instruments the attached user process (at the line/label level) with
checks for a condition specified in the "watch" command.  An instrumented
program stops when the condition is satisfied.  If the scope of the
"watch" command was the entire program, then the program stops when the
memory is corrupted.  The checks are done "on the fly" in the attached
user process so as not to degrade performance of the instrumented code.

Other debuggers have similar features but check the "watch" condition in
the debugger causing considerable performance problems.

Hardware support helps here too, such as an set of registers that can be
set such that an signal is generated if memory is written to that is
bracketed by these registers (available on the C90).

lbd runs on CRI hardware under unicos

	Jeff Brown, LANL 
[I added watchpoints to GDB, using the hardware support on the 386, they
are indeed very useful. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers,comp.lang.ada
From: rod@minster.york.ac.uk (Rod Chapman)
Subject: Re: Implementing packages for Ada compiler
Reply-To: rod@minster.york.ac.uk (Rod Chapman)
Organization: Department of Computer Science, University of York, England
Date: Wed, 8 Apr 1992 09:55:49 GMT

I suggest you take a look in either of the following books

1) Methods and Tools for Compiler Construction, Edited by B. Lorho,
   Cambridge University press, 1984.
   This has a chapter by Jean Claude Heliard of Alsys on how their
   separate compilation works.

2) The Rationale for the Design of Ada by Ichbiah & co. (published
   recently in the Ada Companion Series.)  This is more general, but
   does mention some of the work needed in a compiler to support
   separate compilation of packages and so on.

Hope these help,
  Rod Chapman,
  Department of Computer Science,
  University of York,
  York YO1 5DD, England.
  email: rod@minster.york.ac.uk
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: verkist.pad@sni.de
Subject: Wanted: C Library Functions Test Suite
Posted-Date: Thu, 9 Apr 92 04:46:11 -0400
Keywords: testing, ACK
Reply-To: verkist.pad@sni.de
Organization: Compilers Central
Date: Thu, 9 Apr 1992 08:46:11 GMT

I am developing a UNIX C-Cross compiler named cc6x based on the ACK
(Amsterdam Compiler Kit) which produces Assembler Code for our proprietary
Nixdorf 886x/BNC Computer System.

I just finished writing the C-Library string operations and memory
subroutines as described in the XOpen Portability Guide, Chapter 3,
Subroutines and Libaries.

Most subroutines were written in 886x-Assembler, a few of them were
implemented in C and then compiled afterwards using cc6x.

Now I'm looking for (extensive) test cases covering the above mentioned
subroutines. If anybody knows existing archives of test cases, please
let me know.

Thanks a lot in advance.

Bruno Verkist, c/o Siemens-Nixdorf Informationssysteme AG
STO-NC 332, Riemekestrasse 160, W-4790 Paderborn, Germany
EMail:   USA: verkist.pad@sni-usa.com   |  Phone: (+49) 5251 835365
       EUNet: verkist.pad@sni.de        |  Fax  : (+49) 5251 835353
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: samuel@nada.kth.se (Samuel Cederlund)
Newsgroups: comp.compilers
Subject: Re: Wanted: a program that calulates the maximal stack depth
Keywords: code, storage
Date: 11 Apr 92 16:31:08 GMT
Article-I.D.: comp.92-04-051
Reply-To: samuel@nada.kth.se (Samuel Cederlund)
Organization: Compilers Central

Thank you all who have answered my question.  Perhaps I should have given
you all a little more background on the problem, so that you wouldn't have
had to guess what it would be used for. This is what I'm trying to do: a
very small operating system built on threads and synchronous message
passing. I think it might provide an interesting environment for solving
some problems. As an example, consider this piece of code:

port f()
{
    port p = new_port();
    fork_thread(q, p, USED_STACK(q));
    return p;
}

q(port p)
{
    int i;
    while (true) {
        if (receive(p, &i) == no_sender_error)
    	    return;
        compute;
    	send(p, i);
    }
}

This is, in my opinion, almost like a closure in C. But why do all this
when there already are OSes that have IPC and light-weight processes?  For
one thing, if you want to keep things small and in the same time fork
numerous threads, the notion of infinite stack can be a rather costly
issue. But this way those threads that would need an infinite stack could
be given one and the others could have a fixed-size stack of their
theoretical maximum.

The needed tool would then: 1 Get the theoretical maximal stack depth, 2
Be as machine independent as possible and 3 Process the code before
compilation. Or else you would have to patch the information into the
executable.
                                             Sam

    Samuel Cederlund, programming assistant  samuel@nada.kth.se
    Interaction and Presentation lab
    Department of Computer Science	     Royal Institute of Technology
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:774 comp.lang.c++:6686
From: kelley@cs.dal.ca (Dan Kelley)
Newsgroups: comp.compilers,comp.lang.c++
Subject: Wanted: indent pgm for C++
Keywords: C++,question,tools
Date: 11 Apr 92 15:21:30 GMT
Article-I.D.: comp.92-04-050
Reply-To: kelley@cs.dal.ca (Dan Kelley)
Organization: Math, Stats & CS, Dalhousie University, Halifax, NS, Canada

Is there a (preferably public domain) indent program for C++ code? I
started hacking a shell script that used sed before and after a normal
indent program, but realized that it was more complicated than I thought,
and that someone else had probably done it before.

(PS: this is a bit of a hint to the FSF people that their indent program
would be even better if it handled C++)

Thanks for any (email) hints that come my way.  I'll post a summary if
there is any interest.

Dan
-- 
Dan Kelley, Oceanography Department   |  kelley@cs.dal.ca
Dalhousie University                  |  {uunet watmath}!dalcs!kelley
Halifax, Nova Scotia, CANADA, B3H 4J1 |  (902) 494-1694
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.