|
|
Magic Mailing List |
|
From: Jeff Solomon (jsolomon AT vlsi DOT stanford.edu) Date: Tue Feb 26 2002 - 20:21:46 EST
[This email contains more opinions related to magic's corner-stitching
data structures. If this bothers you, I invite you to delete it now.]
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.
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.
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. Right now, my gating factor is
magic's memory consumption.
Here are two designs that I benchmarked:
Unique Total Mentor Cadence
Rectangles Rectangles GDS Magic StreamView Virtuoso
A 1.2 20.0 113 850 130 145
B 5.0 20.0 129 455 130 135
All the rectangle counts are in millions and the memory counts are in
MBs. What's going on?
Design A is a standard cell design that is flat except for the
standard cells and the vias. Each via is instanced as a subcell just
like all the other gates. There are about 1.1 million sub-cells
including vias. However, the sub-cell plane of the main design is a
whopping 500MB because of the tile fracturing of the 1.1 million
cells. 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.
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.
And each of these two designs takes a loooong time to read in:
Mentor Cadence
Magic StreamView Virtuoso
A 300 22 20
B 80 15 20
All time is in seconds.
What is going on here? 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.
My analysis:
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.
However, I do believe that they're are a few things that could be done
if someone were to care. Now, I'm not suggesting that anyone do these
things, they just could be done:
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. Unfortunately, the file
size grows about 2.5x - 3x because the binary data includes the
space tiles. I do think you could create a binary format that
excluded the space tiles, but that was compact and easy to read in.
I'm not sure how much faster this would be since tile insertion
would still be necessary.
2) Is corner-stitching necessary for the sub-cell plane? Given the use
of CellTileBody structures is kind of hackish, it seems like
corner-stitching was just a convenient thing to use when magic was
written. Certainly in the case of Design A, a different expression
of subcells would be a tremendous win in terms of sub-cell plane
memory consumption. My inspection of the database code shows that
while non-trivial, the amount of interaction betweent the sub-cell
plane and the rest of magic is manageable.
So am I the only one who's noticed the memory footprint and read-in
time of magic?
Jeff
|
|
|
|