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).
Tim Edwards