[Magic-dev] Re: Magic MAXPLANES

[R. Timothy Edwards]

Dear Malvin,

> 1.  MAXPLANES was set to 32 to illustrate the boundary
> of the problem (when MAXPLANES = 64, the same problem
> arises).  When MAXPLANES = 31, everything works as it
> should be, but you would be limited to 31 minus the 6
> built-in planes = 25 planes.  That's bad because of
> the number of planes and layers our layouts require
> these days.

You've uncovered a major error in magic.  At some point I
changed MAXPLANES from 32 to 64.  However, definitions like:

#define PlaneNumToMaskBit(p)    (1 << (p))
#define PlaneMaskHasPlane(m, p) (((m) & PlaneNumToMaskBit(p)) != 0)

usually have a target type defined as integer, which is normally
32 bits.  So while MAXPLANES may be set to 64, plane definitions
are limited to 32 or strange things will start happening.  Crashing
is not likely, just that any routine that maps planes into a bit
mask will ignore any plane above number 31.  This matches the
description you provide about how magic behaves when 32 or more
planes are defined in the technology file.

There is no quick fix.  The simplest fix is to create a typedef for,
e.g., "PlaneMaskType", that would be a 4-byte integer if MAXPLANES is
32 or less, or an 8-byte integer if MAXPLANES is 64 or less.  Then every
typecast for variables used as plane mask must be changed from "int"
to "PlaneMaskType".  This works assuming that 64 planes is enough.  In
general it should be true that a technology file never needs more than
64 planes.  However, there are cases, like mapping an unknown GDS file
into magic with one type per plane, where one may very easily overreach
64 defined planes.  In this case, the plane mask has to be defined like
"TileTypeBitMask", with an array of integers, and any logical operation
on the bitmask has to be replaced with a macro.

Or, we get rid of all instances of using bitmasks as planes and replace
the plane array with something else, like a hash table (which is the
approach that MicroMagic took.

I will probably go ahead an implement the "simple solution", because
at least Magic will be consistent between the defined value of MAXPLANES
and the number of planes that are correctly handled.  Later, I'll
probably work on the hash table thing as part of the next development
version.

					Regards,
					Tim

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: tim.edwards at multigig.com     |
| MultiGiG, Inc.                 | web:   http://www.multigig.com      |
| 100 Enterprise Way, Suite A-3  | phone: (831) 621-3283               |
| Scotts Valley, CA 95066        | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+