|
|
Magic Mailing List |
|
From: Stefanos Sidiropoulos (stefanos AT aeluros DOT com) Date: Mon Feb 25 2002 - 15:19:31 EST
Can someone please get me off the mailing list ?
I have been following on and off for a while
with interest, but I'd rather keep my mbox
clean if the whole thing is going to degenerate
to a holy war about corner-stitching.
Thank you,
-- Stefanos
PS: I thought people fought that specific war back
in 1985 and moved on from there.
----- Original Message -----
From: "R. Timothy Edwards" <tim AT stravinsky DOT jhuapl.edu>
To: <magic-dev AT csl DOT cornell.edu>
Sent: Monday, February 25, 2002 12:01 PM
Subject: Jeff Solomon's Future of Magic
> Okay, Jeff's email deserves a response, and anyone who has been reading
> this list for any length of time knows that I always run in -verbose
> mode, and can't resist. . .
>
> > 1) For people to use magic, it should be easier to build.
>
> > I've been tempted, but I just can't find the energy.
>
> Understandable. But I was under the impression from some time ago
> that you were planning to do it. If not, I'll work on it. It will
> need more than just one person, though. "autoconf" is not fundamentally
> better than magic's existing "config" script, so we'll need some
> volunteers to test compilation and running on all major platforms.
>
> > 2) The corner-stitched data structure is too memory-inefficient.
>
> First note that magic is one of those programs where the data structure
> IS the program. The corner-stitched tile structure touches every part
> of the code, and changing it would be tantamount to writing a new
> program.
>
> I can't agree with your assessment of the memory/speed tradeoffs in
> magic without some hard data. Magic's DRC has to be at least 1000
> times faster than any other VLSI layout tool. But of course a large
> part of that has nothing to do with corner-stitching at all, but
> rather is due to its running DRC as a background process and updating
> only over areas where the layout has been modified, saving DRC info
> in the output file, and using timestamps for validating the DRC of
> each cell. The bottom line is that the cost of fundamentally
> rewriting magic is huge, whereas the benefit is not entirely known.
> A good cost/benefit analysis is warranted, even if it involves just
> back-of-the-envelope calculations.
>
> > 3) 24-bit magic is ugly (and menus and dialog boxes aren't all evil)
>
> I agree that OpenGL is the way to go, but my implementation was
> rather quick-and-dirty and needs some refinement. First, the cursor
> box should attempt to use a 1-bit overlay plane which will keep
> magic from redrawing layout every time the box is moved. And there
> are probably other optimizations which can speed up the redraw rate.
> Currently, most systems (including SGIs, which are supposedly highly
> optimized for OpenGL rendering speed) seem to redraw layout at about
> 2/3 the speed of redrawing in 8-bit indexed color. I was hoping that
> the speed would turn out to be faster, not slower, but that's not the
> case.
> OpenGL is also more cross-platform independent than X11, but my
> first attempt to use "glut" (the OpenGL server-level interface) had
> horrible interactions with X11. It appears that OpenGL has to work
> on top of interface code linking it to the display's native graphics
> server. The interface also slows down rendering. On my system, if
> any window obscures a portion of the OpenGL window, OpenGL switches
> from hardware acceleration to software emulation, apparently the only
> way X11 can prevent OpenGL from drawing overtop the X11 windows.
> These issues are all likely hardware-dependent. I'm curious as to
> whether anyone has found a hardware setup in which the OpenGL
> interface runs faster than the 8-bit X11 interface.
>
> ------------------------------------------------
> I should add my own additions:
>
> 4) Threading is the way to go.
>
> Magic was written in pre-threads days. I've been able to switch the
> graphics from using a forked process handling the server graphics calls
> to a separate thread, but magic should be using threads much more
> routinely, such as having a separate thread to run DRC, and possibly
> handling repainting for each open window as a separate thread.
>
> 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
> such a system by June, based more-or-less on John Wood's GUI-wrapped
> magic system, but more concerned with using the interpreter for
> fundamental extensions to magic than with GUIs. Namely, it will run
> SPICE in much the same way it now runs irsim; indeed, it should be
> possible to mix-and-match with any simulator. Also, the interpreter
> will handle interaction with other independent programs, such as
> FastHenry for inductance extraction.
>
> 6) It pains me to say it, but we need a Windows version of magic.
>
> Linux has been gaining a lot of ground, but programmers who have their
> idealism tempered with a measure of realism admit that any program
> which seeks to expand its user base as much as possible should run
> conveniently in Windows. I'm currently writing a native-Windows-API
> version of the graphics. There will be much wringing of hands and
> gnashing of teeth, but at least the setup of magic allows the addition
> of Windows graphics while minimally touching the rest of the code.
>
> 7) Finally, did anybody mention documentation??
>
> I think that's a well-known issue, another one like the build/install
> interface that just needs doing, not discussing.
>
> ---------------------------------------------
>
> ---Tim
>
|
|
|
|