DBNMSrPaintPlane() where if "tile" is non-NULL then "plane" can be
NULL; the hint tile does not get set but the routine can be called
without knowing the plane other than that the tile is in it somewhere.
edge. This was catching geometry unrelated to the error when doing
a spacing check between geometry on different planes. In the
reverse-edge case, magic needed to run an additional search over
the area on the other side of the original edge that triggered
the rule to effectively clip that corner of the triangle from the
search area.
errors show up as "See error definition in subcell", which has
been the case since I modified the code to prevent showing DRC
errors in subcells that have been resolved by the hierarchy
above them. DRC errors are now intelligently searched
downward in the heirarchy when enumerated for "drc why".
Also changed the DRC check tile definition to offset such that
there is a tile centered on the origin, instead of the origin
being between four tiles. Since most layouts are subcells and
most subcells are small relative to the DRC check tile area,
and most subcells are placed near the origin, then most subcells
will appear in only one tile, which speeds up the DRC process
somewhat.
option "manhattan_dist" that causes corner checks to assume a
manhattan distance measure. This is useful for checking
distances involving generated edges that are created by a CIF
"grow" operator. For "spacing", "manhattan_dist" is equivalent
to "touching_illegal", as a use-case for forcing manhattan
distance measurements in corners has not been found for other
"spacing" options.
that all layer types passed to a single "angles" statement in the
tech file are mutually non-interacting. That is, "angles allm1 45"
will check angles on edges between metal1 and space, but not edges
between metal1 and via (which makes sense, given that a via is an
area into which to place contact cuts, and its edge is not a
physical boundary).
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.
it claimed to fix, but caused an incorrect DRC maxwidth check
instead. The problem appears to be correctly resolved now.
Also: Tracked down a recently-introduced minor issue in which
the interactive DRC stops running after issuing "drc check" and
does not resume until another key or mouse even occurs. This
turned out to be caused by the work on the "logcommands" command,
which should have used "*bypass" before "logcommands suspend"
and "logcommands resume", since the "*bypass" indicates that
the command has no impact on layout and should not interrupt
the DRC checker.
Fix code scanning alert no. 35: Multiplication result converted to larger type (#53)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
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).
engine. Rule checks of triggering rules are not subject to
clipping to the clip area. However, they *must* be clipped to
the (larger) overall DRC check area, because no layout is valid
outside of that area. This clipping was missed, allowing
triggering rules to trigger on areas outside the valid layout,
resulting in mysterious false-positive DRC errors. This has
been fixed.
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.
account for the fact that non-Manhattan tiles are processed twice
in the search, with the side mask bit 1 and 0 for each call. The
DRC check, like the Manhattan checks, only needs to check one of
these.
checks on non-Manhattan tiles were made only on the straight edges;
this was sufficient for most checks. However, it can miss the case
of facing non-Manhattan edges. This check does not do triggered
rules because there is no non-Manhattan maxwidth algorithm implemented,
and because the triggering clipping area is a triangle and needs an
extension to support it.
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.
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".
(such as widespacing or directional surround) that will cause the
rule to be triggered without a cause due to a failure to reset the
error count from a previous triggered rule (the condition of failure
is much more rare than this explanation makes it sound, which is why
it went undiscovered for so long).
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).
much larger area than necessary to the interaction check, and
the other which failed to scale the tech halo distance down
after scaling all the rules. Both of these led to huge areas
of a layout being unnecessarily checked when even a tiny part
of the layout was modified. Corrected behavior matches
expectations for interactive DRC response.