Magic Mailing List |
|
From: Steve Tell (tell AT telltronics DOT org) Date: Tue Feb 26 2002 - 22:20:49 EST
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
|
|