• Previous message: Martin Guthrie: "General Help"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear Michael,

> Date: Tue, 05 Mar 2002
> From: Michael D Godfrey
> Subject: Re: Magic error fixed

>> Magic crashes on calma writes because it tries to close the file twice.
> I thought I sent you that fix a few years ago...

Prior to putting everything under CVS, a number of fixes just simply
disappeared from the code.  It's a very good argument for why version
control should be automated. . .   I think all of the fixes have been put
back, but I can't swear that it's true.

> I was just cleaning up my mail and came across this. I think
> you are a bit hard on the old Magic router. It is OK for
> doing simple block to PADs routing and a few other things.
> It routed one of the most complex imager chips built here
> and the results (while not very pretty) were just fine and
> the chips worked. It has some stupid quirks, like the
> undocumented port spacing rule, but it could easily be made a bit
> better and it is actually handy for simple stuff. It is definitely
> a good idea to get students to use it to wire up blocks. And,
> it even teaches a useful lesson: who cares if it looks cute:
> doing the job is what matters.
> 
> So, unless there is a compelling reason, I would say leave it
> in.

First there's the point to be made that magic doesn't have "a router",
it has about 5 1/2 routers (router, mzrouter, irouter, grouter, and
garouter, and the LLNL area router "art" which is both undocumented and
apparently unfinished.  I would guess that 98% of the people who have
used magic have never used one of its routers at all, and of the other
2%, I suspect that 98% of them have never used anything other than the
standard router.

Second, if it's true that the router is used mostly for small jobs, and
that it has some quirky behavior that needs to be cleaned up, then I
would argue that its proper place is a script for use by the interpreter,
not embedded in the code.  As a script, users will be more likely to
tinker around with it and improve it.  Embedded in the code, only a
handful of us dare to touch it, and it's not a really high priority,
either, or one of us would have fixed the quirks by now.

> It is OK for doing simple block to PADs routing and a few other things.

I abandoned the router when I tried to get it do to a simple block-to-PAD
routing where I had tried very hard to make sure that (prior to debugging
the netlist) everything was aligned so that the routing would be as
simple as possible, with hardly any crossovers at all.  Instead, the magic
router converged all the wires into a tight knot and spit them back out
again.  I believe that I did that one at Stanford, and showed it to you.
Of course the routing was correct, and DRC error-free.  However, in
certain applications that kind of layout is going to aggravate cross-talk,
and if the design were ever put into high-volume production (unlikely,
but you never know), a long series of (single) vias between pad frame and
core are going to lower yield compared to a single metal route that doesn't
jump up and down between layers (I've never observed a faulty via myself,
but I don't do high-volume production, and all the design rule sets I've
seen recently either require or strongly urge the use of redundant vias
at every connection).  Actually, that sort of underlines my point---the
original code never considered the need for redundant vias.  Putting
that capability into the C code requires considerably more effort than
adding that capability into an interpreter script.

Anyway, my main point is not necessarily to take the router out of the
distribution so much as to take it out of the core program.  The
popularity of "plug-ins" these days is due to the fact that they allow
the core program to remain "lean and mean", and don't take up unecessary
blocks of extra memory unless a certain feature is requested (never mind
that most programs completely subvert the idea of the "plug-in" by
automatically loading every plug-in in the universe on startup, like
"gimp" does. . .).  In such a setup, magic would start up without the
router(s) (and plotter, and wiring tool, and sim tool, or pretty much
any feature that's used by only a fraction of the users).  But if you
invoke the command "route", magic will observe that the feature does
not exist, go off and load it into memory, then execute the command.
If it's a script, then pretty much the same thing happens, as the
interpreter grabs the memory it needs to run the script and releases
it later during garbage collection.  I guess I really want to try hard
to keep magic functionally backwardly-compatible, but without
continuously dragging more and more stuff into the core executable.

						Regards,
						Tim

• Next message: Martin Guthrie: "General Help"
• Previous message: Martin Guthrie: "General Help"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]