|
|
Magic Mailing List |
|
From: Tim Chuang (chuang AT siti DOT com.tw) Date: Mon Jun 17 2002 - 06:38:32 EDT
Dear Developers, Magic crashes right after I type the following commands, magic :scalegrid 1 4 Segmentation fault Please help. Thank you. Regards, Tim Chuang >Dear Jeff, > Thanks for all the comments. Here are some further explanations and >some answers to your questions: > >> would there be anyway to override this to get back the old magic >> "snapping" effect? (just curious). > >As written so far, you can't put magic in some mode where it acts like it >did before. My opinion on this is that it is dangerous (not to mention >rude) for magic to alter input data without being told to do so explicitly. >The "snapping" effect *can* be forced, but only because the user intended >it. For instance, if you load a CIF file with some geometry on quarter- >lambda spacing, magic's grid will jump to 4x resolution to accept the >input exactly (the same effect as specifying the command "scalegrid 1 4" >before doing the CIF read). However, if after the CIF read, you decide >that it is better to snap the geometry to lambda boundaries, and fix any >resulting problems by hand, then you can specify "scalegrid 4 1" which will >force magic to go back to 1 lambda = 1 internal unit, snapping the geometry >as it goes. This reproduces the result of magic's original behavior, the >main difference being that the user is aware that he/she is potentially >altering the geometry of the layout. I had a situation like this recently, >where a file I received had one rectangle off the grid, apparently the >result of an unintended geometry change in Cadence. All that was really >called for was to snap that one rectangle back onto the lambda grid. > >> not sure i understand this, since math 1/72 = 0.0138888888888889, so >> vertices got "rounded" to this number ? or are they exact mulitples >> of it ? wish you could give an example of a 2x2 lambda box, >> what the units and scale factors are after each scaling. > >Sorry, maybe not such a good example. What I mean is that the CIF file >declares cells with the line "DS n 1 72", meaning that every geometry >value in the cell must be divided by 72 to get the equivalent measurement >in centimicrons (actually, it should be divided by 36, because magic >already multiplies all values by 2 to cover the problem of rectangle >centers landing at half-integer values). > >> i hacked the 'box' command to optionally take an extra scale factor, >> so for example, 'box 0 0 300 300 .3' means my integers are "microns": >> >> :box 0 0 300 300 .3 >> :box >> EDITbox width height llx lly urx ury >> 1000 1000 0 0 1000 1000 >> um AT 0 DOT 30 width height llx lly urx ury >> 300.00 300.00 0.00 0.00 300.00 300.00 > >That's basically what I had in mind, except that "natural" units of >micrometers would be stated relative to the current CIF output style; >that is, it would be saying that "if you write out CIF using the >current output style, then the measurement of this box would be xxx >microns". Your method is more flexible, but I'm not sure if there's >much value to looking at measurements which magic doesn't know how >to generate. > >I'm waffling at the moment as to whether it makes more sense to print >values in all three units (internal, lambda, and microns), or to set >a "default units" property which will show values in the requested >units. > >> i remember how difficult trying to hack in 'major' and 'minor' grids >> was: i never got very far. the 'minor' grid would be something like >> .01 or .005 um with the idea that you could draw most your stuff on >> the 'major' (lambda) grid but then occassionally 'pop into' the minor >> grid to tune certain dimensions. > >My implementation does more or less the same thing. "internal units" >are equivalent to the "minor grid" and "lambda units" are equivalent >to the "major grid". For the time being, I will leave the cursor box >on the minor grid, on the assumption that most people will continue >to work in the default 1 lambda = 1 internal unit ratio. I have >built an entire chip for a 0.25 micron process using a 1 internal >unit = 0.1um grid, which at times was a royal pain but which worked >(as did the chip). > >> however, that assumes that the resolution of the drc rules is really >> in terms of the minor grid (or let's just say microns). but the rules >> have to be 'intelligently' converted into lambdas to let me get >> drc-checking when i draw in lambdas, too. > >My implementation assumes that DRC rules are specified in lambda. >Magic starts off with a 1 lambda = 1 internal unit grid and makes the >grid finer as it needs to when reading CIF/GDS input, or if the user >makes the grid finer with a "scalegrid" command. DRC rule distances are >then multiplied by the scalefactor, so that the DRC rules continue to >be measured in internal units, while a "drc why" command continues to >tell you the result in lambda (because it belongs to a fixed char * >string, I can't scale what it reports. This method prevents the kind >of "tweaking" of DRC rules that you mentioned. For that, the best way >would probably be to implement something mentioned a while ago in a >posting to magic-dev (possibly by you?), which is to allow DRC "styles" >in the same manner as the tech cifinput and cifoutput sections allow. >Each "DRC style" might then have a scalefactor, so you could specify >"conservative" rules at a resolution of the lambda grid, and more >exact, foundry-specified rules at a resolution of 1/10 the lambda grid. >If someone wants to work in the conservative rules, no action is >required, whereas if someone wants to work with foundry rules, it is >only necessary to specify a couple of startup commands in the .magic >file, like "scalegrid 1 10; drc style foundry". Probably it would >only be necessary to use "drc style foundry", because the scalefactor >in the drc style would force magic to run the "scalegrid 1 10" >command---which is better, because if magic discovered that all of the >drc rules were divisible by 10, it would divide out the common factor >rather than rescaling the grid (this is what I have it do when it reads >the cifinput/cifoutput sections in the tech file: If I specify >"scalefactor 65 nanometers" for a 0.13 micron process, it treats this >as 6.5 centimicrons scaled in the output by a multiplier of 10, and >after discovering that all of the bloat/grow/shrink/squares rules are >divisible by 5, it reduces this automatically from 65:10 to 13:2. For >these sections, however, this only has a bearing on how magic writes >out CIF, not the resolution of magic's internal units). > >> but in general such 'tweak's can't be automatically computed from a >> set of design rules (as there are competing tradeoffs, believe me), so >> they have to be done by the techfile developer and explicitly >> specified in the techfile -- that is, the drc rules would need both >> 'minor' and 'major' values and the bloating between them specified >> (and shrinking can be done also for shapes that can't abut across >> cells, like contacts) > >I think my previous paragraph properly addressed that issue. Until/unless >I implement "drc styles", only the "conservative" lambda-based rulesets >will be possible, but that's no change from what is possible in the current >release. > > Regards, > Tim > > > ------------------------------------------------------------------------
|
|
|
|