🚀 go-pugleaf

In article <398@lehi3b15.UUCP> flash@lehi3b15.UUCP (Stephen Corbesero) writes:
>
>Can anyone tell me if the newest release of the OCT tools is
>available.  I remember a new version was supposed to come out a few
>months ago, and I am wondering if it is actually available.
>
>-- 
Newsgroups: comp.lsi
Subject: OCT Tools Distribution
Message-ID: <8802072153.AA18048@shambhala.berkeley.edu>
Date: 7 Feb 88 21:53:43 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 64

I was forwarded your 'info-vlsi' message requesting
information on our CAD tools.

Our system is called OCT Tools and is distributed by the
industrial liaison office here at Berkeley ($150).

        Cindy Manly
        Industrial Liaison Program
        479 Cory Hall
        University of California
        Berkeley, CA   94720

You will get a 9 track tape and a set of documentation. 

I recommand waiting till after March 9 to order
(we are putting together a new version and it
will not be ready till around then).

The distribution consists of the following:

The framework:

- OCT: a CAD data manager
- VEM: a X-based IC graphics editor supporting
     three editing styles (physical, symbolic, and schematic)
- RPC: a remote procedure call mechanism for allowing CAD tools
   to run as remote procedures from VEM.  A way to extend the
   functionallity of the editor without any source or object
   level changes
   
The tools:
 
Quite a few tools for the following tasks:

- place and route
- logic minimization
- logic synthesis (programming language to logic equations)
- simulation
- plotting (postscript, versatec)
- programming libraries for command data structures
- extraction
- module generation
- conversion to/from cif
- mask modification (grow, shrink, logical operations)


How does it compare to Magic:

Magic was written specifically for mask level CMOS design
and does an excellent job of it.   We are trying to support
a larger set of designers using many technologies (NMOS, CMOS,
GaAs, Bipolar, etc), using many design styles (full custom, gate array,
standard cell, sea-of-gates, etc), and working at different levels of
abstraction (behavioural, logic, schematic, symbolic, physical). 
Our primary interest to date has been on synthesis as oppposed
to hand design.  As far as specifics, we do not support incremental
design rule checking at this point (we use symbolic compaction)
and we represent connectivity explicity.

If you have any questions, feel free to send them to me.

                        Rick Spickelmier
                        ricks@berkeley.edu
                        ...!ucbvax!ricks
~~~~~~~~~~~~~~~~end of forwarded message ~~~~~~~~~~~~~~~~~~~~~~~~
Terry Lalonde
...uunet!helios!lalonde