|
|
Magic Mailing List |
|
From: Jeff Sondeen (sondeen AT ISI DOT EDU) Date: Mon Feb 10 2003 - 15:35:54 EST
so to clarify this, refering to fig. 9a. on page 29 of doc/psfiles/maint2.ps, i wish there were a variant of the edge4way rule edge4way t1 t2 X oktypes cornertypes Y "rule" where the 'cornertypes' could apply to the type in area B (adjacent to t2) not the left part adjacent to t1. so maybe it would be called edge4way2 to indicate that the cornertypes are adjacent to type t2. R. Timothy Edwards writes: > Dear Jeff, > > > Hi Tim, i think i just replied to you when i meant to followup > > (post) my last email. > > That's okay. I'm deep into polygon pushing at the moment, so I haven't > even had time to look at the rulesets and what their implications are. > > I'm pretty sure (without constructing a proof. . . ugh) that your > "edge4way1" rule can always be effectively instituted with two edge4way > rules. If so, then the question is whether the rule happens often > enough that you would actually get some speedup out of implementing > it as a single rule (as opposed to making it a macro which decomposes > itself into several rules in the DRC database). > > I have started a project to make a "techbuilder" script which could > compile rulesets from a graphical description that would basically > double as a design rule manual. I'd like to have the headaches > associated with working out edge4way rules handled automatically, so > that techfile writing becomes a process that anyone with a design > rule manual sitting in front of them can do. I'd like to work out > some of the remaining fundamental issues of how magic does (or > doesn't do) design rule checking so that magic can handle all the > rules that commercial design rule check programs can (such as doing > wide metal rules). > yeah, writing 'edge4way' rules with "negative" layer sets is pretty taxing, to me, at least. by the way, another nice rule would be one that enforces a spacing requirement between 2 types (each on a different plane), while allowing "touching OK". currently magic only allows touching_ok with types on the same plane. thanks, /jeff > I get lots of kudos for what I've done with magic version 7.2, but > any of the other developers would quickly (and correctly) point out > that everything I've added (with the exception of non-Manhattan > geometry) is largely superficial, and doesn't touch on some of the > fundamental problems of magic, including unimplementable DRC rules > and lots of extraction issues. > > Regards, > Tim
|
|
|
|