• Previous message: R. Timothy Edwards: "TSMC 0.35"
• Maybe in reply to: R. Timothy Edwards: "TSMC 0.35"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Timothy,

thanks for the answers.

a) reading/viewing/writing gds with magic

   Since I "only" read the magic doc's, I have the sneaking suspicion
   that I'm totally ignorant to some fundamental basics of magic.

   One of the doc's references some DAC and other papers, which I could
   not locate on the web, so I don't have immediate access to them.

   Could it be that magic can't "just" read a gds without a techfile
   containing DRC-rules ?

   Is there a way to "only" provide layer numbers without DRC rules to
   view/merge stream files ?

b) Jeff Solomon's viewing extensions

   I've contacted Jeff directly via the e-mail address in his DAC-paper,
   but either he takes a well deserved break, or didn't bother to answer :-)

   At least I know now that he used a "barebones" magic outside the CVS
   tree.

c) tsmc.tech27

   Thanks for the hint, but I got the latest and greatest magic-current.tar.gz
   from http://vlsi.cornell.edu/magic and it didn't contain scripts/makedbh

   Unfortunately I'm sitting behind a firewall that doesn't allow me to use
   CVS, so if anybody could update the magic-current.tar.gz, I'd appreciate it.


Best Regards

Stefan





"R. Timothy Edwards" <tim AT stravinsky DOT jhuapl.edu> on 07/23/2001 06:44:37 AM

To:     Stefan Thiede/SVL/SC/PHILIPS@AMEC
cc:     magic-dev AT csl DOT cornell.edu
Subject:  TSMC 0.35
Classification:



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

• Next message: Dr. Jon R. Fox: "postscript mask making"
• Previous message: R. Timothy Edwards: "TSMC 0.35"
• Maybe in reply to: R. Timothy Edwards: "TSMC 0.35"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]