|
|
Magic Mailing List |
|
From: john wood (john.wood AT multigig DOT com) Date: Wed Feb 27 2002 - 10:20:31 EST
We are trying to use magic to analyse artwork created by other tools and merge-in new artwork. The approach we are looking at now is to retain magic for cell-generation where it excells [online DRC], and use the OpenAccess database (Cadance Gemini) which has been taken 'open-ish' source. The idea is that we can read LEF/DEF or interact directly with a design database and modify magic's GDS in and out code to write to and read from OpenAccess database intead of files. We will use the OpenAccess to view high-level hierarchy [e.g. the whole chip and all the global routing] but use magic to open up a cell for editing. OpenAccess comes with Tcl/Tk interface and a basic database viewer / editor. The license for OpenAccess is restrictive in principle (you cannot distribute either source or binary for modified OpenAccess) but in practice this isn't a problem because anyone can take the pristine source and have it 'changed' for internal use. OpenAccess has a technology file library but I have no idea whether it is possible to have magic get its technology from it - if it could be done we could use new techfiles written by the foundries. John Wood john.wood AT multigig DOT com ----- Original Message ----- From: "Steve Tell" <tell AT telltronics DOT org> To: "Jeff Solomon" <jsolomon AT vlsi DOT stanford.edu> Cc: <magic-dev AT csl DOT cornell.edu> Sent: Tuesday, February 26, 2002 7:20 PM Subject: Re: more corner stitching > > On Tue, 26 Feb 2002, Jeff Solomon wrote: > > > [This email contains more opinions related to magic's corner-stitching > > data structures. If this bothers you, I invite you to delete it now.] > > Quite fascinating, actually. Glad to see the discussion stay interesting. > > Most of my experience reading large designs is streaming in GDS2 from > cadence or elsewhere, and not saving the magic cells. But these are > huge designs. > > I have noticed that magic somtimes performs poorly on designs that aren't > done in our traditional "magic style" but rather from some other tool or > design tradition. > > Designs with all vias in subcells are one huge case in point. Besides > possible memory usage, they also make it harder to trace nets with the > "select" function, one of the main advantages to viewing layout in magic > vs. many of the commercial tools. The failing is really in the other > tools that lack abstract contacts (and the corresponding "squares" > function at cifout time). > > If you were to smash the via-subcells into flat paint in the top level, > how much better would memory use get? Sounds like the subcell plane > would clean right up in your case A. > > Naturally, this isn't always possible - depends on your design flow. If > you're just using magic for viewing, flatening the vias is probably the > right thing to do, but probably not if you need to shuffle the layout back > to another tool. > > (Related to another topic, I'm looking forward to being able write a > selective heirarchy-flattening script in a magic extension language.) > > You may be right on the subcell plane, especialy for a viewer that doesn't > include DRC or extract. Those are probably some of the major users of > DBCellSRArea and related "find subcells overlaping this rectangle" > routines. A magic-derived viewer project may the be the perfect testbed > for such an overhaul. > > Steve > > > Hi all, > > > > Before I start talking about corner-stitching again, let me state > > these two properties of magic that are noticable to me: > > > > 1. magic's memory footprint is large compared to commercial tools > > for large designs. > > 2. magic takes a lot longer to read a design than commercial > > tools. > > -- > Steve Tell tell AT telltronics DOT org > >
|
|
|
|