|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Mon Jul 23 2001 - 09:44:37 EDT
Dear Stefan, Inasmuch as there *are* reasons for loading someone else's layout with possibly different rules into magic, your question deserves a more thorough answer. I do that occasionally; in fact, my non- Manhattan extensions were due mostly to frustration in trying to fab something on a Matsushita 0.25um process that demanded certain non-Manhattan rules like 45-degree bevels on pads. I didn't care so much about design rules because I didn't have any non-Manhattan geometry in my core; I just wanted to be able to read in the supplied pad frame, add my core, and write it back out without the pad frame getting mangled. Hopefully I'll have time to work on non-Manhattan DRC soon. About Jeff Solomon's texture mapping: He ended up stripping a version (earlier version, 6.5 probably) of magic down to its bare essentials so that things like DRC, extract, routing, etc., wouldn't get in the way of graphics performance, then he added all sorts of fancy caching and everything he could find to make use of video card memory and capability to squeeze out every last MIP in the rendering step. It's difficult for people like me to imagine magic rendering at 15 frames per second, but that's what he got out of his system. We have no plans to merge this custom hot-rod magic code into the regular distribution. This is what Jeff said about his version: > I have a super-hacked version of Magic that can render an arbitrarily > large design at interactive speeds (5 to 60 fps) and in proper > antialiased die photo detail. What I have is simply a viewer right now > and not an editor, but it would be neat to try to fit it into an > editor. > > I accomplish this speed and image improvement with a combination of > hardware accelerated texture-mapping (for speed) and my own > implementation of mipmapping (for quality). The end result is really > cool. I do everything on the fly with texture and hierarchy caches so > the memory overhead is not outrageous (but it's not zero either) and > the startup cost is not too bad. > > I call this thing a ChipMap and I wrote a paper about it that was just > rejected :-( from ICCAD. Check it out: > > http://www-flash.stanford.edu/~jsolomon/chipmap.pdf > > The paper hasn't been officially released yet so please don't > distribute it around, but it will give you a better idea of what I > did. Also, the paper is somewhat out of date as I've added some stuff > that the paper doesn't talk about or makes a reference to in the > Future Work section (specifically multi-threading and compositing). > I'm working on a new version of the paper that we plan on resubmitting > to another conference or journal. Jeff would be the best person to ask about the status of his "super-hacked" version. Finally, about your experience with the TSMC techfile: The error > mSCN6M_DEEP.09.TSMC.tech27: line 202: section contact: > Too many types to generate a new contact. Maximum=190 is due to an incompatibility between the magic source and some of the techfiles. Magic has internal limits to the number of types used, with larger numbers of types causing magic to run slower. We made a tradeoff between processing speed and the complexity of the tech files. However, magic can be compiled to handle all tech files with a (rather slight, and possible unnoticeable) performance hit. The *latest* source version, from a month or two ago, defines the maximum types to be 256 instead of 192, which is apparently the version you have. In the older version, changing from 192 to 256 is a pain, because a lot of the internal structures have to be changed by hand, but in the new code, this is done automatically. You should get your new code from the "official" website, which is http://vlsi.cornell.edu/magic/ If the source contains a file scripts/makedbh, then you have the correct version, which uses this script to automatically configure the database structures for the given no. of types. The number of types is 256 in the new version, which should let you read in the TSMC tech file without magic generating errors. Regards, Tim
|
|
|
|