MAGIC Magic Mailing List
 
 

From: Steve Tell (tell AT telltronics DOT org)
Date: Tue Feb 26 2002 - 22:20:49 EST

  • Next message: john wood: "Re: more corner stitching, Database OpenAcess aka Gemini"

    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 
    


  •  
     
    Questions? Contact Rajit Manohar
    cornell logo