• Previous message: Jeff Solomon: "more corner stitching"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Jeff Solomon <jsolomon AT vlsi DOT stanford.edu> 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.]

Some discussion on alternative database representation for magic or
some hypothetical layout tool is appropriate to this e-mail list.  But
if the discussion generates too much e-mail, then it should be move to
a more suitable (e.g. generic) forum.

> Before I start talking about corner-stitching again, let me state
> these two properties of magic that are noticeable 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.

From your later explanations, I gather that you mean:
1:  Memory usage:
    Magic with no layout loaded:                        W bytes
    Magic with a layout using N rectangles loaded:      X bytes
    Other tool with no layout loaded:                   Y bytes
    Other tool with a layout using N rectangles loaded: Z bytes

    Your claim is that (X - W) > (Z - Y)

    This is certainly true.

2:  The time required for Magic to load a .mag file of N rectangles
    (not including Magic's start-up time) is greater than the time
    required for other tools to read in their proprietary file of
    N rectangles (not including the start-up time).

    This is certainly true as well.

> Now this is only really true for designs with lots of unique
> rectangles. If your designs are small or contain tons of hierarchy,
> then these aren't issues for you.

Its likely that 1 and 2 apply in all cases, but aren't as noticeable
for small designs, etc.

> And perhaps huge designs will never be of interest to people using
> magic. They are to me because I'm trying to make a layout viewer
> that can handle designs of arbitrary size.

If this is the single most important issue, because you are otherwise
running out of RAM (or worse -- address space), then naturally you should
use a different layout tool.  Alternatively, perhaps you need to change
the way you do layout in Magic.


> [Benchmark results deleted]

> The fracturing is pathologically bad because all the cells besides
> the vias are perfectly stitched together. Add the vias randomly over
> the surface and you get 5.5 million tiles with about 12 million
> CellTileBody structures.

Right.  Magic creates new subcell tiles for each subcell, as well as
each rectangular intersection of subcell boundaries.  This is one of
the situations where you can't merge tiles on the same plane -- and
there can be an arbitrary number of these subcell tiles.  The memory
usage penalty for corner-stitching as analyzed by Magic's authors only
holds for a finite number of distinct tile types per plane.

> Design B has a major metal layer that interacts with a contact on the
> same plane is such a way that each metal wire is actually broken into
> 3 tiles. I believe the additional difference between 455 and ~130MB is
> due to the memory cost of the space tiles.

Sounds like a worst-case scenario.


> [Benchmark results deleted]

> Two things I believe. The first is that .mag files are ascii and
> verbose. Even though magic has special code to subvert the standard
> file i/o interface, it's still slow. Second is that magic must
> re-create the corner-stitching each and every time the design is
> read in. This is a lot of work.

You can estimate the penalty for using ASCII by looking at the file
size for the .mag files versus the proprietary formats.  The penalty
for recreating the corner-stitching should be amortized over the time
needed to DRC the design.  For example, it would be unfair to claim
that Magic takes 300 seconds to read in the design and Virtuoso takes
20 seconds, if a DRC then takes 20 seconds in Magic and 300 seconds
in Virtuoso.


> It's probably true that magic is just never going to be used for
> huge designs. If the majority of magic users are happy with its
> current memory footprint and the read-in time, then who cares? I
> truly might be the very special case of someone who cares about
> these things but also must have the source code.

Read-in time shouldn't be an issue, unless you are restarting Magic
often right?  Memory footprint is a problem only if you are running
low on memory in your machine right?


> 1) Magic could have a binary format. I've hacked one into my version
>    but I wouldn't call it pretty. I can read in the above designs in
>    about the same time as Mentor or Cadence.

What did you do?  Dump the memory straight to a file?  If not, you
still need to fix-up pointers don't you?  And then, how can you match
Mentor and Cadence, unless your pointer fix-up is faster than your
file i/o?

> 2) Is corner-stitching necessary for the sub-cell plane?

No, but a good replacement database scheme is not trivial to invent.


> So am I the only one who's noticed the memory footprint and read-in
> time of magic?

I've found that the time saved in the layout phase more than compensates
for these two inconveniences.  Also, when I do layout with Magic, I try
to minimize the cell overlap as much as possible.  In your case, perhaps
an additional hierarchy level would help.

> Jeff

Thanks for clarifying your previous contributions to this list.  I had
not understood that you were concerned about corner stitching on the
subcell plane.

Philippe Pouliquen
The Johns Hopkins University

• Next message: Steve Tell: "Re: more corner stitching"
• Previous message: Jeff Solomon: "more corner stitching"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]