|
|
Magic Mailing List |
|
From: Jeff Solomon (jsolomon AT vlsi DOT stanford.edu) Date: Mon Feb 18 2002 - 14:42:13 EST
Hi all,
I've just finished reading some of the other posts to this mailing
list pertaining to Magic's GUI, Magic's future and all the rest.
I've been hacking on the guts of Magic for over 2 years now so I
wanted to add my opinion to the discussion.
There has been a lot of talk about whether magic is going to be useful
in the future and what can be done to it for some people to not
consider it a toy. I want to spell out the things that I think need to
happen to magic to help it stay relevant.
First, I'd like to say that magic is *always* going to be useful if
for no other reason than it's the only VLSI layout editor whose source
code is available (or are there others?).
Now, here are the thing about magic that I think need to be changed:
1) For people to use magic, it should be easier to build.
The code needs a major overhaul. Everybody knows this - it's just a
question of finding someone motivated enough to do it. I've been
tempted, but I just can't find the energy. The code needs to be
protoize'ed, autoconf'ed, cleaned and purged. There are so many
historical #ifdef's that could and should be removed. This is my
favorite line of code in magic (found in misc/magic.h):
#define Void int
Huh? My second favorite thing about magic is how it was written
pre-stdarg days so that many of the printf() like functions are
actually declared with 20 arguments. Actually, the stdarg versions
are there too, they are just #ifdef'ed. All that crapola should be
removed.
It would also be great if an rpm were available so that people
didn't have to build it. We could also change the OGL version to
use dlopen() so that we could distribute one binary for an
architecture and have it work regardless of whether someone had OGL
installed or not.
2) The corner-stitched data structure is too memory-inefficient.
The great thing about corner-stitching is that it gives you very
nice computation time for editting tiles. It does this at the price
of extra memory because it explicitly allocates memory for all the
empty space. This incur's about a 3x cost.
Corner-stitching was invented in 1982. Back then, the cost of
computation vs. the cost of communication was a lot more balanced.
Which is cheaper now? Using magic on real designs of any
consequence is currently impossible because they don't fit into
memory. The memory footprint of magic vs. Cadence/Mentor/whatever
is often 10to1. These companies have spent lots of time optimizing
the database size because that is what is important now. Do we care
if it takes longer iterate over the database in some cases? No,
because our processor runs at 2Ghz. What we really want is for the
entire design to fit into main main memory and we'd like to avoid
going to memory as much as possible.
I hate to say it, but a purely naive approach where tiles were
binned (and placed in linked lists) based on location would
probably be good enough. Think about this - the time to iterate
over the entire database is about the same regardless if it's
corner-stitched or binned. The time to iterate over a small subset
of the database is much less for corner-stitched, but who cares? By
definition, it's a small subset - so I'm happy to let my 2Ghz
processor do little extra work - I'll never notice. Since 1982,
everything has gotten a lot faster - but I haven't. :-)
3) 24-bit magic is ugly (and menus and dialog boxes aren't all evil)
Since I've started my research, I've really come to believe that
using a modern graphics API like OpenGL is far and away the way to
go with regards to CAD design. Technically, it's a perfect fit. And
financially, it's now feasible. If you're using a Sun or a Linux
box, it's really no burden at all. Any Sparc of post-Sparc Sun can
download OpenGL for free from Sun's website and you can get a
totally capable Linux opengl graphics card for about $100.
I'm almost ready to advocate that OpenGL be the primary GUI that
magic concentrate on. Here's why: I'm advocating that magic needs
to grow as VLSI design has grown. That means larger designs with
more and more layers. The 8-bit color view of the world ran out of
steam with *2* metal layers. It's basically meaningless to have
colormap transparency for metal1 and poly if it's covered by *7*
metal layers that are solid (or even worse if they are a hideous
stipple). If you agree that magic need to change to accomodate
larger designs with more layers then I argue that it's non-sensical
to say that magic should work well with old hardware. You don't
use old hardware to do new designs. I say that if you have old
hardware and want to run magic - use an old version.
I think that the correct way to handle layers is for magic to run
in 24-bit color with OpenGL. Each layer would have their own alpha
which would be separately controlled. This wouldn't preclude the use
of stipples, outlines and crosses, actually it would enhance their
appearance. Then, magic needs a little dialog box that would allow
you to turn layers on and off, and change their transparency and
stacking order with ease. Now, I know this could all be done with
commands (ie. 'see poly' etc.) but even unix commandline bigots (of
which I count myself) would probably find this easier.
Of the things that I've mentioned - I think the build system is by far
the most important. If magic is easy to build and modify, I think it
increases our chances that people will use it. I don't know how many
times I've downloaded a package and disregarded out of hand because it
wasn't autoconf'ed. I wonder how many people have had that experience
with magic?
Finally, it's easy to suggest all these things - talk is really cheap.
The real question is finding someone to actually do it! :-}
Jeff
|
|
|
|