• Previous message: Gustavo Adolfo Cerezo Vásquez: "Magic 7.1"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear Jeff,

   I've tried to be a good boy and have kept all the non-Manhattan stuff
as isolated as possible from the rest of the code.  If you don't configure
with the non-Manhattan extensions, you get the original magic code,
unaltered except for a very few changes in variables.  There should be
no performance hit.  With non-Manhattan extensions, there's a slight
performance hit associated with the bit masking of the TileType fields
(basically a couple extra machine instructions for every "TiGetTileType"
call), plus quite a bit of overhead whereever non-Manhattan geometry
appears in the layout.  However, that overhead disappears if there is
only Manhattan geometry in the layout.  Thus, for the vast majority of
designs, where non-Manhattan geometry is minimal, you should not be able
to notice the difference.  Since you've done a lot of performance
measurements, you'd probably be in a good position to test that theory.

   In a nutshell:  The diagonally split tiles have a second tile type
hidden in the upper bits of the 32-bit TileType (it's 32 bits
because it doubles as a pointer to a cell structure if the tile
represents a cell in the cell hierarchy rather than a VLSI layer).
Actually, two bits are reserved to denote the orientation of the
split, one bit denotes that the tile is split, and the remaining
bits form two 14-bit fields to hold the left and right side tile
types (14 bits being more than enough to hold even the most layer-
abundant technology).  All calls to "TiGetTileType" do one mask
AND operation to check the presence of a diagonal split, and revert
to normal non-Manhattan operation if the tile is a normal,
Manhattan rectangular tile.  If the diagonal split bit is set,
magic then goes into further processing to parse the left and right
sides separately.  The worst case of non-Manhattan processing (so
far;  I haven't done DRC yet. . . ) is the DBPaintPlane() function,
which has to deal with all combinations of painting Manhattan or
non-Manhattan geometry on top of Manhattan or non-Manhattan geometry,
which you may notice has nearly doubled the size of the DBpaint.c
file.  The most complicated function is the rewritten
CIFMakeManhattanPath() function which will parse any CIF or GDS polygon
geometry, splitting it into a bunch of Manhattan and non-Manhattan
tiles.  It's really a beautiful thing.

   Hope that answers your questions.  Let me know if there's anything
else you need to know about the code changes.

						Regards,
						Tim


> Date: Fri, 13 Apr 2001 13:20:47 -0700 (PDT)
> From: Jeff Solomon <jsolomon AT vlsi DOT stanford.edu>
> Subject: Re: CVS: 'magic/drc DRCarray.c drc.h'
> 
> Hi Tim,
> 
> I have a question about your non-manhattan changes. I see that you've
> #ifdef'ed the changes, but I haven't looked at all your code. If I
> check out the latest source and do not enable the non-manhattan code,
> am I going to take any performance hit over the old code? I guess I
> should also ask if having the code enabled is a performance hit if you
> don't use any non-manhattan shapes, or if it's a performance hit if
> you do?

• Next message: R. Timothy Edwards: "flock_buf initialization"
• Previous message: Gustavo Adolfo Cerezo Vásquez: "Magic 7.1"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]