identifies areas which meet the proper definition of run-length
(both edges are parallel for the run-length distance or more).
Previously, errors were getting triggered for geometry where
only one edge exceeded the run-length distance.
completely implemented for the "cifwidth" and "cifspacing" rules,
resulting in those rules being Manhattan distance checks. Finished
the implementation (duplicating code from DRCbasic.c, with
appropriate scaling to CIF coordinates).
"drc printrules". Implemented a new "drc" command option called
"drc ignore", which can be used to suppress reporting of specific
rules, for both "drc why" and "drc find". This can help with
finding an error buried among a large number of other errors.
This commit makes the code (mostly) C99-compatible, enabling to compile
it without the -Wno-error=implicit-function-declaration flag. This
way, Magic becomes usable on arm64 architectures, specifically on Apple
computers with M1/M2 SoC.
the "width" rule is assumed to be symmetric, and not checked in all
four directions, as that would be redundant. But non-Manhattan tiles
are not symmetric and must be checked all four directions. Implemented
in a way that does not increase the DRC processing time.
in github issue #149. This causes magic to no longer write log files
for "make" and "make install" but will properly exit with a non-zero
return code on any error during compile.
Also: Corrected the command "tech drc surround <type1> <type2>" so
that it now returns the correct value when <type1> and <type2> are in
the same plane. Added new command "tech drc directional <type1> <type2>"
which works the same way as "tech drc surround" except for directional
surround rules. Used this to generate vias from "def write" with the
correct metal surround amounts included in the via definiton. The
route analysis then ignores tile slivers that make up the surrounding
material around contacts. Also implemented a method that handles
routes that are made of multiple thin tiles due to the maximum horizontal
stripes rule. Now magic handles "def write" well except for not dealing
with non-minimum-width routes unless they're specifically called out as
"special" nets.
The extSubtree() routine cuts a layout into squares and extracts
each separately, checking for subcell interactions. In each
square it parses all labels looking for unconnected ones. This
section of code not only parses all labels M x N times, but it
then marks interaction areas where there may be none, forcing
additional unnecessary processing. This commit makes the first
quick optimization, which is to change the return value of
DRCFindInteractions() from boolean to integer, allowing it to
return a value indicating that there are no subcells in the
area. This prevents the loop through labels from happening in
cases where there can never be interactions. More to come.
one is an "off_grid" DRC type, which can be used to check geometry
that is below the manufacturing grid. Normally magic prevents the
grid from being subdivided below the manufacturing grid, but this
limit can be removed and replaced by DRC checks to check for such
errors in a GDS file of unknown origin. The second version looks
for interactions between subcells that end up with intersections
of non-manhattan geometry landing on points that are not on the
database internal grid. Such errors cannot be seen by magic's DRC
engine by definition, and so must be detected while flattening
geometry for the DRC checks.
the handling of subcell instances generally. Previously it would check
the interaction between neighboring cells in an array without regard to
any material in the parent cell which might remove those errors;
consequently, the array would have to be DRC clean by itself in order for
the parent cell to show as DRC clean. The array check has been moved
inside the DRCInteractionCheck() routine, so that it runs only where
arrayed instances do not interact with anything else. Within interaction
areas, the area is flattened and checked, so the array check is not
needed.
processes "interaction areas". This should eliminate weirdnesses
where errors will fail to show up in a subcell that does not
interact with paint or other subcells in the top level edit cell.
These errors cannot be reported directly in the top level cell,
but a new error message has been created to direct the user to
check the subcell for errors. Also: Modified the toolkit procedures
to force DRC to be run on newly created or modified parameterized
cell layouts. There is some oddity about the process that causes
DRC errors to be delayed unless a print statement is put before the
DRC check; I would like to investigate this further.
the rule is a normal database rule or a CIF-DRC rule. For the latter,
the flag is used when substituting for escape strings in the "why"
rule explanation to produce the correct value in microns.
DRC records contain an index into a string array instead of containing
a copy of a string. This is preliminary to changing the way the DRC
error plane is painted, so that the types painted will mark the error
type. This will (1) allow "drc why" to simply scan the DRC error
plane rather than running the DRC engine, (2) allow DRC errors to be
counted by area rather than by tile, and (3) let the DRC count be the
same whether done by "drc listall why" or "drc count".
to be investigated here. I am no longer sure why I removed the
cell search from DRC count, but it appears that the cell search is
non-functional, and it should be determined why. There is no
particular reason not to have a DRC count search. It could be
implemented such that "list" vs. "listall" counts the top cell vs.
all cells. First it must be determined why there are no subcell
counts.
categorized by error type and scrolled through conveniently. However,
it needs work dealing with finding the actual error bounds. The
"DRC count" counts tiles, which is tile-plane-geometry-specific, and
"DRC listall why" fractures errors both over tiles and over the square
areas that the interactive DRC splits the layout into, for performance.
The DRC error plane needs to be changed to hold different types for
each error class, so that errors can be scanned by boundary instead of
by tile (work to be done).
behaviors: (1) An additional syntax for "widespacing" that allows
both the triggering metal's width AND run-length, which is typical
of rules in 65nm-and-below processes; and (2) a new "option"
statement for the DRC section, with (for now) one possible flag
"wide-width-noninclusive", indicating that the metal width given
for "widespacing" rules means that a violation is only triggered
for material with a width greater than the given rule width (as
opposed to the default interpretation of a width greater than
or equal to the given rule width).
Darryl L. Miles
Tim Edwards
Alessandro De Laurenzis
Anton Blanchard