|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Mon Feb 25 2002 - 15:01:30 EST
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
|
|
|
|