|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Fri Jan 11 2002 - 17:58:25 EST
Dear Magic Hackers, I have almost finished my changes to the CIF and Calma sections of Magic, so before I commit the changes (which are substantial) to the CVS source, I will give a brief description of what it all does, and if anyone sees any logical flaws in the new methods, please let me know before I commit the code changes. 1) I have expanded the "scalegrid" command which I added a while back so that it can be invoked at any time with the expected result. Before, it altered the CIF and DRC distances to match the new scaling. Now, it alters all existing geometry as well. This allows me to play games with CIF input and output. 2) The "calmaonly" parameter to "scalefactor" was already deprecated, and so it is now simply ignored. 3) The "reducer" parameter to "scalefactor" was just confusing, and if the CIF bloat/grow/shrink values weren't divisible by the reducer, then the CIF output would be in error. Now, any reducer value is ignored, and magic figures out its own reducer by finding the greatest common factor between the CIF operation distances and the scalefactor. 4) The "nanometers" parameter is retained, although it no longer must be accompanied by "calmaonly". "nanometers" still does exactly what it used to---it declares that all values are nanometers instead of centimicrons, so magic can handle output for deep submicron processes like 0.13 (scalefactor = 6.5 in centimicrons, 65 in nanometers). 5) The scalefactor can be specified by a decimal, so "scalefactor 6.5" is allowed. However, CIF operation distance values are still in centimicrons and must be integer values, so in most cases it will probably make more sense to use "nanometers". 6) During CIF or GDS reads, magic checks every value before scaling, both at the input level for CIF only (scaling by the multiplier/reducer amounts declared in the cell "DS" definition), and during the conversion from CIF units to magic units. If fractional centimicrons result from a CIF read, the CIF planes will be redefined so that the input can be read exactly, without realigning itself to an integer boundary. When converting to magic units, the same consideration applies, except that some half-lambda geometry is allowed, such as for box centers and for contacts (which can be placed on the half-lambda grid by the "squares" operation in CIF output). Otherwise, fractional-lambda geometry causes magic to redefine its basic grid unit so that the input geometry is not altered. I tested the code out by writing out a CIF file at 0.065um, reading it back in a 0.09um style, then writing it back out in a 0.065um style. It preserved the geometry as specified throughout all of the operations, although the final output is some awful thing measured in angstroms (units of 1/72 centimicron, to be precise). There are a couple of things I still need to do. By relaxing the 1 Magic unit = 1 lambda restriction, it is necessary to have magic start measuring boxes in lambda rather than internal Magic units, or perhaps both (and perhaps it should also give measurements in microns according to the current CIF output style). It might also be useful to define a 'drawing grid' spacing in lambda instead of magic units to make it easier to move around and draw simple geometry when the magic grid is very finely defined. I was thinking perhaps that mouse click operations on the cursor box might always snap to the lambda boundary, whereas specific "box" commands could be made to move around on a finer scale, if necessary. This sort of suggests that all geometry-related commands should accept values either in lambda or in internal units (maybe even in microns). You could say "move e 10" (lambda) or "move e 10i" (internal) or "move e 1um" (according to current CIF output style) or even "move e 10.5" (lambda, if 1 lambda = 2 internal units or finer). I would like some feedback on this before launching into another massive code rewrite. Regards, Tim
|
|
|
|