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.
Tim Edwards
Darryl L. Miles