|
|
Magic Mailing List |
|
From: Steve Tell (tell AT telltronics DOT org) Date: Tue Feb 26 2002 - 00:58:35 EST
I've been working inside the magic code since 1996 or so, and still get to
spend some work time supporting for us locally, and would like to help
out as time allows. So I'm glad to see a useful discussion. Please
indulge my $0.02...
>> 1) For people to use magic, it should be easier to build.
Hear here! Autoconf is definitely a bit better than even magic 7.1's
cleaned up makefiles, mainly because the configure process doesn't have to
ask the user questions; when done right it just figures things out and
works. Besides, making RPMs from a well-autoconfed package is usually
quite straightforward; ditto for other package managers.
I got irsim mostly autoconfiscated in about half a day - anyone interested
in that? This is definitely a "just do it" sort of proposition.
As for old code, magic may be one of the few mid-80's pieces of C code
worth running any more, but I'm all for dragging it kicking and screaming
into the 21st century. Target AnsiC + POSIX, with workarounds for
the oddball cases anyone wants to support.
Given assurances that the huge patches that such build and code updates
will represent will be accepted, I'm ready to contribute to the necessary
coding.
>> 2) The corner-stitched data structure is too memory-inefficient.
Here I must agree with Tim and perhaps go a bit further. A research
project into new data structures is welcome to fork the code (if any of it
can even be reused at all) with all my best wishes - but please don't call
it "magic" until it works with all existing techfiles, and also benchmarks
reasonably.
>> 3) 24-bit magic is ugly (and menus and dialog boxes aren't all evil)
I must agree that speed matters a lot, and getting openGL running isn't
always easy. In fact, I must admit that I havent tried the GL flavor of
magic. The 8-bit version works quite well for us, especialy with my
colormap-sharing patch. Speed matters when browsing around a whole chip.
But I'd like to try the GL driver, and I'm willing to be convinced by any
true enhancements possible by using more alpha-blending. Perhaps change
the opacity of selected rectangles instead of or in addition to outlining
them?
Menus and dialogs, especial if they can somehow help teach the
corresponding macros and text commands would be a fine addition. Watching
a first-time magic user get up the learning curve is quite painful.
>4) Threading is the way to go.
Sounds good to me, although I don't have much experience coding with
threads under unix. Keeping a second CPU busy doing DRC could be a win.
>5) Scripting is the way to go.
> Rajit did a fine job embedding SCHEME into magic, but I have since
> become convinced that EDA programs should have interpreters "wrapped"
> around them rather than embedded in them. I'm hoping to demonstrate
I'm not sure what you mean by interpreters "wrapped around," but I'll look
forward to your demo. I do really like the way Rajit's scheme interpreter
interfaces to magic with so few changes, although I wish it was a standard
scheme interpreter library such as guile.
My preferred style for implementing an EDA tool is
- write the core algorithms and data structures or objects in C (or C++ if
you must)
- expose those objects into the extension language
- Implement as much of the UI in the extension language as possible
(but do speed-critical things such as screen redraws directly in the C
core)
My current favorite set of tools for this are guile and guile-gtk.
>6) It pains me to say it, but we need a Windows version of magic.
While personally (and professionaly) I don't need magic on windows ("let
them use X (or vmware)"), making magic accessible to more users is great.
I hope it can be done cleanly. A few places in the code I've found the
existing "#ifdef MAC" and "#ifdef OS2" distracting; maybe factoring some
of the variations into seperate implementations of functions having the
same interface can keep the main line of the code more readable?
Can I add another:
8) The extractor needs further rework for today's and tomorrow's CMOS
processes. Processes are getting smaller by shrinking the width of the
metal, but keeping the thicknesses about the same, so sidewall capacitance
dominates, and magic doesn't handle this very well. In 0.18u, magic's
extractor is only a few percent pessimistic compared to say Star-RC.
With 0.13u, we found it easy to be off by a factor of 4 without careful
juggling to split the difference on the errors.
"Sideoverlap" (up and down), and "sidewall" within plane essentialy need
to conserve capacitance among each other, instead of treating them as
seperate effects. I've spent a lot of time in the extractor code chasing
down very minor issues, enough to know that this won't be a simple
project.
But unless the documentation evolves to say "magic is free but you'll have
to pay synopsys or avanti full freight for an accurate extractor" this
will have to be addressed.
Steve
--
Steve Tell tell AT telltronics DOT org
|
|
|
|