From: meier@ee.umanitoba.ca (Martin Meier)
Subject: Re: Why universities shouldn't write IC CAD tools
Organization: Elect & Comp Engineering, U of Manitoba, Winnipeg, Manitoba,Canada
Date: Tue, 13 Oct 1992 16:42:09 GMT



I have waited several days so that I could collect all responses to my article
and respond to them in one shot.

When I first decided to post this article I knew that there are many readers
who make CAD tools there prime area of research. I expected that this article
might start a discussion on the subject. Unfortunately many respondents see my
posting as a personal attack. Responses have not been on specific points but
to the general notion of the article.

Also, respondents think I have specifically attacked the better tools. I did
not make the all encompassing statement the ALL tools are junk. 

------------------------

>
>From: lazzaro@boom.CS.Berkeley.EDU (John Lazzaro)
>Message-ID: <1b2bdoINNheq@agate.berkeley.edu>
>
>
>In article <1992Oct8.190248.20655@ccu.umanitoba.ca> meier@ee.umanitoba.ca (Martin Meier) writes:
>>           Why universities shouldn't write IC CAD tools:
>>      [long set of arguments deleted, posted in comp.lsi.cad]
>
>CAD tool users tend to vote with their feet, in my experience. I'm
>primarily a chip designer who also does minimal maintainence on a
>academic-born ECAD toolset that is available via ftp, and if no one
>uses the tools, then why is my mailbox filled daily with messages asking
>for support, new features, and sending me bug fixes? If there wasn't a
>place for these tools in the world, no one would send any mail; they
>would set up the tools, decide they suck, and delete them for disk
>space, leaving me alone to read usenet in my spare time instead of fix
>bugs :-).
>

It sounds like you are stuck holding the bag on ECAD. I assume you are not
getting paid for your services, and that your doing it out of the kindness
of you heart. If you got fed up one day, and decided not to give support,
who would take your place? 

If a CAD tool doesn't have support, which most university tools only have
limited to no support, then that tool might as well not exist. Why is it
that many IC houses use commercial tools?  Support. No IC house can afford
to be hindered by thier tools, and not get a fix. Of course, the bigger
you are, the more support you can expect.

>And the tools I maintain have a pretty small audience compared with
>something like Magic or IRSIM ...
>
>

--------------------

>From: robert@csustan.csustan.edu (Robert Zeff)
>Message-ID: <1992Oct9.025320.25381@csustan.csustan.edu>
>
>
>I find that Spice 3e2 is VERY useful.  I think that, given a pc environment,
>many students / engineers could find it satisfactory for 99% of their needs.
>
>In fact, I have re-written nutmeg and ported spice 3e2 for Windows NT / 
>Win32 with a GUI that works very well.  I intend to release it to the internet
>as shareware in just a few days.
>

Spice is the favorite counter example. SPICE itself is popular because it is not
limited to IC design, but covers all of the Electrical Engineering field in 
one way or another. SPICE is used more than any other university developed
tool, and is atypical of what general comes out of university labs.

People like to hold up Spice as the typical university tool. While this
a good tool, and there are several usable tools for university, a vast majority
of university tools never reach the renowned of SPICE. One only has to
look in the DAC proceedings to find that about a 1/3 of all papers deal with 
CAD tools to this or that. How many of the tools published about in DAC will be
used by

  - a vast majority of people in the field the tool covers
  - a fair number
  - a small following
  
most will never be used outside the institution they where created, if they
are used at all. 

>-Robert
>robert@csustan.csustan.edu
>
>-- 
>robert@csustan.csustan.edu
>Cserve 70323,1251
>fax (209) 577-8548
>voice (209) 577-4268 X101
>

-------------------------

>From: gld@cunixb.cc.columbia.edu (Gary L Dare)
>Message-ID: <1992Oct9.030530.3749@news.columbia.edu>
>
>
>A lot of ideas created in the course of Master's and Ph.D. theses
>cannot be developed on a stand-alone basis, and many university VLSI
>CAD tools have served as testbeds for these new ideas.  Magic is now
>in its 6th version, with numerous changes and new stuff, for example.
>I can't think of any other way to demo a layout tool technology other
>than doing VLSI layout ... (-;
>
>Octtools, while I've only read its documentation (we haven't installed
>it at our site), contains a few extra dozen little tools each time it
>comes out ... if you want to give it a spin, that's great; if you want
>to add a tool and try it out, you don't have to build a framework from
>scratch around it and all the better if there are predecessor and
>successor modules available so you don't have to do any extra crap.
>
>Maybe some tools are good enough, and elegantly simple in their
>implementation, that there is no need for recoding if a commercial
>site wants to use them.  However, these University tools don't come
>with a warranty for a good reason ... they are basically testbeds.
>                                               ^^^^^^^^^^^^^^^^^^^^

Which brings me to my point: Do you want to design an IC on a test bed. I
agree that test beds are necessary for the research, but almost useless
to IC designers.

>                                           
>But analogous to Unix and other software platforms, some testbeds do
>end up in the field.  The only way to get commercial-quality code is
>    ^^^^^^^^^^^^^^^

And only(hopefully) after the have be thoroughly tested and debugged. As I
stated before, debugging is not a publishable activity, and a tool
researcher will try to keep this activity down to do more testing on the 
algorithms performance(which is publishable). An academic lives and dies
by the number of publication cranked out each year. A commercial producer will 
have more incentive to actually test and debug a product.

>
>to write a piece of commercial-quality code based on the concepts
>pioneered in the university tool, with suitable hooks to suit your
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>

As I said in the second part of my article. Spend more time on the method
and algorithm, and not on coding the tool for the tools sake.

>
>installation's needs, using the latest in software engineering
>principles ... heck, even SPICE was redone at AT&T Bell Labs by
>Lawrence Nagel when he joined them (it's called ADVICE).
>
>gld
>--
>~~~~~~~~~~~~~~~~~~~~~~~~ Je me souviens ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Gary L. Dare				
>> gld@cunixB.cc.columbia.EDU		Oct 26/92: Just say "OUI!"
>> gld@cunixc.BITNET			(Let's worry about the economy!)
>
>

-----------------------------------


>From: brian@vuse.vanderbilt.edu (Brian Antao)
>Message-ID: <Bvu8p3.4F7@vuse.vanderbilt.edu>
>
>[Long rethoric on the subject deleted ]
>
>	Well if that is the case than, no software engineering/computer
>engineering should be done at a university ;-) .
>
>Universities afford the luxury of experimenting with new methodologies,
>concepts and algorithms without having to justify immediate return in
>terms of corporate profit margins. The University CAD tools are prototype 
>implementations to demonstrate the feasibility of the proposed concept. 
>

But don't try to compete head-to-head with commercial vendors once the
concept is proven. It is a waste of time and money. University and industry
are meant to complement each other.

>
>
>These fundamental developments are then adapted by industry to make a 
>commercially viable and robust product. You cannot expect an acedemic researcher
>perform the same software development cycle -- such as alpha, beta testing etc..
>that's what separates academia from industry. 
>

Exactly what I would say.

>
>This is the case with most university research in the engineering field,
>that's why there usually is a technology transfer process, where the
>basic research is transfered to industry -- in this case a CAD house
>Take the classic case of SPICE -- which was originally Larry Nagel's
>Ph.D. thesis. Most of the industry SPICE versions are robust adaptations
>of the original, with more bells and whistles added. The reason why
>a distribution fee is charged is to cover the nominal cost of the
>distribution media -- somebody has to pay for the tape and documentation.
>                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
                                      
I would not expect to get a free tape. But it should be possible to get it
via ftp. Would the number of people ftp'ing this program cause problems 
for the site. I would say not. Look at X Windows, it's ftp'able.

NOTE: please do not use the argument that X Windows is an example of a 
      university designed program. It is not an IC CAD tool, and has a much
      larger audience than any CAD tool could possibly hope to have.


Of all the tools ever created and published about by universities, what
percentage make it to the same level as SPICE. I from all the journals and
proceedings I have read, I would say few.

>
>The rest of the discussion in the original posting is rethoric anyway ...
>
>	-- Brian Antao
	
It seems that you are personally offended by my article. I am not attacking or
trying to discredit any one in particular, just the way research work is done
in this area. I know may people working in this area read this group, and it
was not an accident that I choose this group to post to. 

>
>-- 
>Brian Antao,  			     |INET: brian@vuse.vanderbilt.edu
>Dept. of Electrical Engg.,     	     |Office: Room 283, New Engineering Bldg.
>Vanderbilt University, 		     |Tele: (615)-343-6191(O) (615)-292-6308 (H)
>Nashville, TN 37235 	     	     |Fax: (615)-343-6449
>

----------------------------------

>From: eddieb@ERC.MsState.Edu (Eddie Brown)
>Message-ID: <EDDIEB.92Oct12122159@cliff.ERC.MsState.Edu>
>
>
>>From jscott@ERC.MsState.Edu Mon Oct 12 12:10:03 1992
>
>
>           Why CAD companies shouldn't write IC CAD tools:
>
>1.  Most tools don't work as advertised. Usually features written about in
>    publications don't work properly, or the tool works only with other
>    tools from the same company that don't work as advertised, with features 
>    in publications that don't work properly, et. al.
>
>2.  These tools usually have limited usefulness. They try to cover the
>    entire gambit of the problem representing their customer datbase,
>    which to most CAD companies is everyone with a workstations, ending
>    up with a tool that doesn't a little bit of everything maybe fairly
>    well.
>

People don't buy weak tools, or they won't stay with them for long. As
John Lazzaro says "CAD tool users tend to vote with their feet, ...".
Think of it as a process of natural selection.


>3.  Although CAD Company designed tools are maintained, it is usually
>    at great expense with the most popular support being a toll-free
>    number where you reach a dial-an-answer-to-your-problem answering
>    machine where the choices are:
>
>           a) It will be fixed in our next release (When? the next
>              DAC, of course).
>           b) What bug?
>           c) That is a problem with a company that we just purchased
>              and all the support people quit because the stock options
>              we gave them sucked.
>           d) We no longer support that software. Didn't you know?
>
>     In addition, CAD company designed CAD tools are difficult to
>     maintain, for several reasons:
>
>     Code is always documented but written by people who either haven't
>     the slightest idea of how the software works or some who writes
>     manuals like he writes code:
>
>     started(getting);
>         {
>         FILE *assume_idiot_user;
>         /* so you want to use our tool /*
>         .;
>         .;
>         .;
>
>      The tool is usually created by some well meaning garage shop 
>      CAD engineers that make a really nice point solution to a CAD
>      problem. They make a lot of money when their tool is bought
>      by a huge CAD company. Then all the good algorithms and especialy
>      the look-and-feel are dumped because the company who bought them
>      has a competing tool in a group which uses the NIH approach to
>      engineer. Net effect -> dead tool.
>
>4.  Most tools are written in CAD-company ways. Then the large CAD 
>    companies form consortiums to come up with standard-ways of doing
>    things. Then they realize that although this will benefit the user,
>    it will hurt their business by allowing the garage shop people
>    (like, uhhhhhhh? university types) back into the game after they
>    have just spent a fortune buying them out of the game.
>

If you pay for a tool, maintenance is not your problem. You pay someone else
to fix it. If you don't like the service, you can switch to a competitor.
Can you do this with a university tool? Should universities compete
with each other by writing tools? As an IC designer, do you really want
to debug code? I would answer NO to all 3.

Unlike a university, a company writing and selling tools has to deal with
all of these problems, or they won't be in business much longer. If a 
university doesn't deal with these problems, they will still get research 
money. 


>
>5.  Source code is always kept 'secret'. This is to stop others from 
>   finding out that the tool doesn't work as stated.
>

Unlimited access to code as you suggest would encourage software piracy, both
by end users and competing companies. Think how easy it would be to hack out
the license check from source code. Commercial companies spend private funds
for code, universities spend public money for code. Who has the right
to secrecy.

You do realise that some companies will offer source licence for a hefty
fee. While this may not be what you want, it is possible to get code. 

As a counter example to code ALWAYS being 'secret', I would point to the
IC layout tool Electric by Electric Editor. While this is a comerical tool,
universities which are part of the CMC can sign a non-disclosure agreement
and get the code, for no charge.

>
>6.  I am tried of typing, I haven't run out of points.....
>
>--

Too bad. I would have like to see some more arguments that would strengthen
your case. I sounds like you got screwed by some company. Care to name it
for the benift of others.

>
>***********************************************************************
>            Eddie Brown			Email: eddieb@erc.msstate.edu
>      CAD/Systems Administrator        USmail: P. O. Box 6176
> Microsystem Prototyping Laboratory	       Miss. State, MS 39762
>    Mississippi State University  	Phone: 601-325-1607
>					  Fax: 601-325-3626
>***********************************************************************
>"Starkville, MS - The SPONTANEOUS CONFUSION (tm) Capital of the World!"

--------------------------

>From: arrigo@cube.sublink.org (Arrigo Benedetti)
>Message-ID: <1992Oct10.182750.574@cube.sublink.org>
>
>In article <1992Oct8.190248.20655@ccu.umanitoba.ca> meier@ee.umanitoba.ca  
(Martin Meier) writes:
>> 
>>            Why universities shouldn't write IC CAD tools:
>>  
>> 
>>[a lot stuff deleted]
>
>This is not true, Universities must keep writing IC CAD tools.
>Let me tell you a story. A couple of years ago I took a course on VLSI
>design at the University of Bologna. In a semester I designed a fully
>functional 4-bit microprocessor from scratch with the Octools. This was
>possible because some smart people at UC Berkeley decided to write this
>package and give it for a nominal fee. Of course my University would have
>never afforded to buy enough Cadence site licenses for a student lab,
>and I would have never been exposed to IC design.
>

But if you had read the contents of my article you would have seen the point
about university discounts. I would agree that before you would have had to
pay a hefty fee for commercial tools, but these companies will now offer their
product at deep discounts, mostly so the get university people trained on their
tools. If you can't afford this fee(and it seems quite
small to me), I can't understand how you could afford to implement a design.

>You say that code written by EE student is not terse. This is right
>in some cases, but not always. IC CAD tools design has evolved rapidly
>in the last years, and so did teams writing cad tools. I remember someone
>telling me that people in the cad group at Berkeley are more computer
>literate than many people doing research in computer science.
>

Again, the Octools is held up as the typical tool. Very few tools reach this
this level. I remember one circuit tool that was ftp and compiled by a friend.
The editor was in one large 500k C file. I see this writer knew about 
modularity. ;)


>Arrigo Benedetti
>
>P.S. flames to /dev/null
>-- 
>Arrigo Benedetti             e-mail: arrigo@cube.sublink.org (preferred)
>University of Bologna                benedett@deis01.cineca.it
>undergraduate student (EECS)         
>Via S. Agata, 11               Tel:  (home)   +39 59 224929
>41100 Modena - Italy                 (office) +39 59 216688 (fax) +39 59 220727
>


Newsgroups: comp.lsi.cad