jimmc@sci.UUCP (Jim McBeath) (07/13/87)
On May 19, Bob Mayo (mayo@mustard.berkeley) suggested that we
define what a silicon compiler is. In the interest of stimulating
discussion on the subject, I would like to give my personal view
on that topic.
(Unfortunately, we do not receive info-vlsi here, so I have not
been able to follow any discussions which may be going on there.)
Let's start with the aspects of silicon compilers which most people
agree upon, and move from there to the more controversial aspects.
"A silicon compiler is a program which accepts a user's input specification
and produces the necessary masks to fabricate an integrated circuit."
I think most people would agree that this is a necessary condition to call
something a silicon compiler, but it may not be sufficient.
One of the terms used by some people to refer to some (or all) of the
products which vendors are offering as "silicon compilers" is
"silicon assembler". Well then, what distinguishes between a
silicon compiler and a silicon assembler? By analogy with software,
I would say that the distinction is that the compiler's input (language
or specification) is divorced from the target output (machine architecture
or process). This is important in software for two reasons:
1) it allows a person with no knowledge of the the target machine architecture
to write a program, and 2) the program can be run on a number of
different machines. This is why the program which compiles C is a
compiler and not an assembler (although I've heard some people claim
otherwise :-). We can use the same distinction to differentiate a
silicon compiler from a silicon assembler. A silicon compiler must
satisfy similar conditions as a software compiler: 1) it allows an
engineer with no IC design knowledge to design an IC; 2) the compiler
can be made to output the design to a number of different processes
without requiring significant change to the user's input.
(Strictly speaking, it should be possible to output to a different
process with NO changes, but for reasons of efficiency it is not
uncommon to make some minor changes. As with software compilers,
100% portability across platforms/processes is not always achieved
in practice.)
OK, given the above we can now make a definition for a silicon compiler
which distinguishes it from a silicon assembler:
"A silicon compiler is a program which accepts a user's input specification
and produces the necessary masks to fabricate an integrated circuit,
and satisfies the following conditions:
1) it allows an engineer with no IC design knowledge to design an IC;
2) the output can be targeted to a number of different processes
without requiring significant change to the user's input."
This is a usable, albeit narrow, definition for a silicon compiler,
but it is still missing something. The problem is that what is really
needed is a silicon development system, not just a compiler. Consider all
the tools other than the compiler used by a software developer under unix:
- a shell (sh, csh, ksh)
- an editor (vi, emacs)
- a linker (ld)
- automatic construction (make)
- a debugger (adb, dbx, cdb)
- standard libraries (clib (stream etc.), math, ...)
- user libraries (created with ar, ranlib)
- a strict type checker (lint)
- performance feedback (gprof)
- special purpose front ends or compiler-compilers (lex, yacc)
- checking and testing routines built-in to the user's program
- a revision control system (rcs, sccs)
- file management programs (ls, mv, rm, cp, mkdir)
- documentation tools (troff, draw, pagemaker)
- archiving facilities (tar, shar)
It's possible to write programs without using any of these tools
(well, perhaps the shell and linker are essential), but it would be
pretty difficult to do anything substantial. Each of the above tools
can be used to improve some aspect of software development, whether
it is productivity, performance, or quality. Some people choose not
to use some of these tools; they may not be interested in what that
tool provides, or they may not want to spend the time to learn about
it. However, the system provides the tools for those who wish
to use them, and in the development of most large software systems
almost all of the above tools are generally used.
In a silicon development system *every one* of the tools listed above
as being useful for software development is also useful for silicon
development, plus some more which are specific to silicon development
systems. Depending on how the silicon development system was designed,
some of the above unix programs may be the tools used in the silicon
development system (such as the shell or file management programs).
Some of the programs have to be silicon specific (such as performance
feedback and type checking).
I think that when most people use the term "silicon compiler", they
are referring to what I have described above as a silicon development
system which has been built around a silicon compiler. This being
the case, we could then define a silicon compiler as being a silicon
development system which satisfies the narrow definition of a silicon
compiler given above, and which contains some reasonable set of additional
development tools from the above list of tools. Defining silicon
compilation this way is probably of more practical use, although it
makes pinning down a precise definition much more difficult.
There is no one vendor who offers a system which has everything. Almost
every commercially available system has at least a couple of special
tools or features which are not provided by the other vendors. The
important question to ask is not "who sells a true silicon compiler?",
but "who has a silicon development system that meets my needs?".
The answer to this question of course depends on the individual user's
needs or goals. This brings up another question: what are different
users' goals when developing a chip, and what features do they
require in a silicon development system? I have my own ideas about
what I think the minimal and the optimal silicon development systems
should provide, but before moving on to that subject I would like
to see what others have to say about the definition of silicon
compilation.
-- For another definition of silicon compilation, see the article
"Silicon Compilation Speeds Design of Complex Chips", Computer
Design, March 1985, page 105. The article contains a box (p. 106)
titled "Silicon compilation defined", which gives a more rigorous
definition than my view above; there, a "compiler" is defined more
along the lines of what I referred to above as a "silicon
development system".
-- The ideas and opinions expressed above are entirely my own, and do
not necessarily represent the views of Silicon Compiler Systems
Corporation.
Jim McBeath {decwrl|oliveb|weitek|auspyr}!sci!jimmc
Silicon Compilers Systems Corporation (408)371-2900
2045 Hamilton Avenue, San Jose CA 95125spp@zion.berkeley.edu (Steve Pope) (07/17/87)
I will add just a few things to this discussion. The term "silicon compiler" was coined 10 or more years ago by, if I'm not mistaken, Ron Ayres. The original intent was quite obvious; to design a circuit layout by other than manipulating geometries, by using something a little higher level. Nothing more specific was spelled out at the time. As the term evolved, things which are called silicon compilers are more or less of two types. The first type, which is the less common and probably the least useful, involves something which compiles a transistor net-list (or equivalent higher-level representation) into a cell layout. The second type, which accounts for most of the silicon compliers out there (including all the commercial products I've seen) uses the following passes: a high-level front-end, the input to which may be either textual or graphical; a module generator, which generally accesses a cell library and produces two-dimensional blocks or macrocells of circuitry; and a place-and-route program (which sometimes is partially interactive). These passes correspond to the passes of a programming language compiler. Usually, two-dimensional module generation (as opposed to one-dimensional as in a standard-cell system) is a requirement. Also, to be called a compiler, the system should be able to produce a wide variety of circuits, not just a narrow subset such as PLA's or RAM's. Of course, other more restrictive definitions are possible. steve
pi@ashoka.usc.edu (Jen-I Pi) (08/05/87)
In article <7031@sci.UUCP> jimmc@sci.UUCP (Jim McBeath) writes: > >(Unfortunately, we do not receive info-vlsi here, so I have not >been able to follow any discussions which may be going on there.) Does anybody know hot to subscribe to info-vlsi? Thanks in advance! Jen-I Pi :-) ------------------------------------------------------------------------------- UUCP: {sdcrdcf,cit-cav}!uscvax!pi CSnet: pi@usc-cse.csnet BITnet: pi@uscvaxq ARPA: pi@cse.usc.edu pi@ashoka.usc.edu Voice: (213) 743-5530 -------------------------------------------------------------------------------
pi@ashoka.usc.edu (Jen-I Pi) (08/05/87)
In article <7031@sci.UUCP> jimmc@sci.UUCP (Jim McBeath) writes: > >(Unfortunately, we do not receive info-vlsi here, so I have not >been able to follow any discussions which may be going on there.) Does anybody know how to subscribe to info-vlsi? Thanks in advance! Jen-I Pi :-) ------------------------------------------------------------------------------- UUCP: {sdcrdcf,cit-cav}!uscvax!pi CSnet: pi@usc-cse.csnet BITnet: pi@uscvaxq ARPA: pi@cse.usc.edu pi@ashoka.usc.edu Voice: (213) 743-5530 -------------------------------------------------------------------------------