[Magic-dev] Re: Update on GDS problem

[R. Timothy Edwards]

Dear Michael,

> This is a little odd. I looked at the GDS (ESD_struct_2_neg.strm) and found
> that the MAG record contained 0x41, 0x10.  In ASCII this is A\lf.  Maybe 
> the
> "correct" interpretation is byte - " ", i.e A - " " = 1.  If this is 
> true the MAG
> record calls for a magnification of 1.  And, your result makes sense.

I ran the GDS file through "streamutils" sf2ascii and got an ascii dump
of the file, then looked at the magnification records.  Indeed, all of
the magnification records call for scale=1.0 except for two instances
in the *_neg.strm file, which call for scale=5.0 on a text record.
Since transformations are ignored entirely by magic on text labels,
it only complains about the scale=1.0 records, which it ignores in
favor of the default (1), so the result is the same in any case.

However, on our last tapeout I generated an "artifact" cell in Cadence
with a copyright text.  To get the DRC errors to disappear, I had to
save the copyright text at scale=2.  This gave me a good example to
test GDS scale magnification in magic.  I wrote a simple routine to
multiply all elements of the transform by a constant factor
(GeoScaleTrans()), and processed the magnification record directly.
This worked perfectly without any other modifications to the code,
amazingly enough.  So the end result is that there was never any
reason for the prohibition of scale records in the GDS input stream.
I still have to disallow non-integer scales, or at least round to
the nearest integer.  This can potentially be worked around by
subdividing magic's internal grid to compensate for fractional
magnifications.

Anyway, this extension (which I will post as 7.3.90, along with a
fix to the backing store code that prevents magic from crashing
when you open a non-layout window) verifies that the interpretation
of the MAG record is correct.

My suspicion about cells getting flipped in the GDS output is that
for very large layouts at very tiny scales, some kind of integer
overflow occurs.  I have corrected some instances of integer overflow
as I work with larger and larger layouts, but there are probably
pathological cases that have not been caught.  The last time I got
bad GDS output was on a 5mm x 5mm chip in 0.18um technology.  We used
a vendor padframe that was off lambda by 0.01um, forcing magic to
scale its internal grid by a factor of 9.  So in integer units, the
top-level cell was huge.  Not enough to overflow a 32-bit integer,
signed or unsigned, but clearly enough to overflow in some manipulation
of the GDS output.  The problem forced us to do the final layout
assembly in Cadence (ugh), but I came up with a method of including
vendor GDS that avoided the problem, so the last chip I could
assemble the final GDS entirely in magic.

						---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               |
+--------------------------------+-------------------------------------+