From: meier@ee.umanitoba.ca (Martin Meier)
Subject: Why universities shouldn't write IC CAD tools
Organization: Elect & Comp Engineering, U of Manitoba, Winnipeg, Manitoba,Canada
Date: Thu, 8 Oct 1992 19:02:48 GMT

           Why universities 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 within a narrow
   scope.
   
2. These tools usually have limited usefulness. They cover a small part of a
   general problem or are limited to specific cases. The given publication will
   often say something to the effect:
   A program that will do X in a Y in the case of Z

3. University designed CAD tools are often not maintained.  When the student
   who wrote the tool leaves, no one will want to maintain it.  No one 
   starting a thesis wants to just maintain a tool, because work will look
   unoriginal.  Also, no funding body like NSERC would pay for maintaining
   tools.  In addition, university designed CAD tools are difficult to
   maintain, for several reasons:
  
   Code is usually not documented, making maintenance difficult. Proper
   documentation of a program will not get the author credit in a
   thesis or publication. 
   
   Usually the tools are poorly coded since most students are Electrical
   Engineers with little experience coding significant projects.

   Debugging these programs becomes difficult. It is hard to find errors in
   poorly documented code and/or poorly written code. Sometimes a program
   will not work as expected because the underlying concept is unsound.
    
   When a tool is created, the researcher will only try to get the program to
   a point where useful test data can be produced. There is usually no testing
   stage or beta testing. The robustness of the program is never considered,
   since this is not a point which can be mentioned in a publication.   
  
   This leaves debugging for the end user of the program. Even if code is
   available, most users don't want to bother hunting for bugs in 10k's of
   code. They want to implement their IC, not debug other peoples tools.

4. Most tools end up being non-standard in many ways, usually just for the
   sake of being different. Most of these tools can't interface with other
   tools.

   Strange input and output formats abound in these tools. The author may be
   making a tool which covers new ground, and this would end up being a
   necessity. But in a lot of cases differences from standard formats exist
   solely to make coding easier. All of this makes it difficult to interface
   these programs with existing tools.
   
   Sometimes programs are written in uncommon languages like LISP or PROLOG.
   This is usually done so that the student can learn the language for own
   personal interest while doing the research. These programs then require
   the proper interpreter to be run, and in some cases may be a proprietary
   version which would then have to be bought before the tool could be used.
   
   Usually if someone has covered this ground before, the new author has to
   point out how their tool is different. This is usually done by adding
   features or requirements that would not be useful in general use. 

5. Source code is usually kept 'secret'. This is to stop others from stealing 
   ideas and publish papers on same subject. This would also stop readers of the
   paper from finding out that the tool doesn't work as stated. Secrecy is
   especially true for people from industry. The company which they are
   working for does not want anything released to their competition.
   
6. If you're thinking that CAD tools from universities will create an 
   abundance of free software, remember that all reasonably useful software 
   from universities is not necessarily free. Octtools, for example, needs a 
   license and fee before it can be used. SPICE needs a fee for tape copy. 
   These tools, while useful, are nevertheless outdated by today's 
   standards(Mentor, Cadence, HSpice).

   Better quality tools are siphoned off to industry. A good example of this  
   is SPECTOR. Also if a lot have work has been done on a tool, and the tool
   could be useful for many designers, there is a great temptation to start
   selling the program.
   
7. The IC design market is too small for a GNU type project. GNU's C compiler,
   GCC, has 10000's of users, and each of these a C programer. IC design is a
   small group by comparison. GNU type projects get many 'power programers'
   that do this for a useful product, not as a publishing vehicle.
 
8. The scope of IC design is too large for a comprehensive project by a
   university. The many stages of IC design (high level description, layout,
   testing, timing, design rules checking, etc) make it a nearly impossible
   task to create a set of tools for IC design. Cadence tools(binaries & files)
   are ~200Meg and still many useful tools and feature missing. This
   company employs many 1000's of programs and takes many years to complete
   projects. A university with a handful of grad students could not hope to
   even keep up. Even in a single area of IC design such as layout would be
   beyond the capabilities of most Universities. 
 
THEREFORE:

1. No large, general purpose tools should be written for general use by a
   university.

2. Code written should only be for 'proof of concept'. Some researchers don't
   make the mistake of designing a tool. Instead they follow the correct
   research path and attempt to prove that their algorithm is correct.

3. Industry offers Universities a 'good' deal for IC tools (Mentor aprox.
   $1500/10 seats per year).  While not free, its a small sum for a 
   QUALITY tool.
   
4. Groups like the CMC (Canadian Microelectronics Corporation) offer tools
   at no cost.

COROLLARY: If a U wants to make IC cad tools successfully, all above issues 
           must be addressed.


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

Some general points about IC CAD tool publications:

When a researcher writes about an IC CAD tool, there is usually no
consideration given to the software life cycle. Concept and coding are the
only stages which are performed. Testing and maintenance is ignored.

A common thread in many publications is how performance of a new tool is
better than existing tools and algorithms. However these performance estimates
are usually done in an ad hoc fashion.

  - sometimes only one performance test is done(ie. a single ALU is analyzed).
    While this will always show the tool is better than what is it compared
    against, it is not show better performance in the general case.
   
  - sometimes a new tool or algorithm is compared against existing University
    or commercial tool. Some researchers take commercial tools as a performance
    acme. In many cases this is the only other tool to which the researcher has
    access, and is not necessarily the true best algorithm.
    
    While all researchers will(hopefully) do the comparison on the same
    computer, they often do not consider other factors. These include what
    algorithm is used in the comparison tool, what language the comparison
    tool is written in, if the compiler used had optimization capabilities,
    and if the algorithm was implemented efficiently. Often this information
    is not know to the researcher, but an empirical comparison is done anyways.
  
  - In many new algorithms put forward, the research fails to formally prove
   that the new algorithm is correct.  In many cases a formal proof might be
   impossible to do. Many times in cases like these, only a few items are
   tested in the new algorithm, and the method is assumed correct from then on.
   The most useful publications in an area are ones which can formally prove a
   method correct and be formally proved to be quicker(lower order of
   complexity) than an existing method which is commonly used. 

Newsgroups: comp.lsi.cad