DRCCheckThis() is called in order of top to bottom of the hierarchy
when called from drcCheckFunc() although it was changed to order
DRCPendingRoot from bottom to top. drcCheckFunc() then does it
backwards. Fixing this appears to have resolved some weird errors
with DRC errors not showing up when doing "drc check" (initially)
and DRC errors disappearing when making changes to a generated
cell. Appears to be okay now.
supported). Fixed the long-standing issue in which DRC does not
get stopped by the "drc off" command (the behavior for interrupting
the DRC was dependent on the DRC being turned on, and the "drc off"
command was turning it off before breaking, causing the interrupt
to be ignored).
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.
the bottom in non-interacting areas means that any change in DRC
to a subcell must be handled before checking DRC in the parent.
Previously the order of checks was reversed, moving parent cells
to the beginning of the check list. This prevents the error cited
in the previous commit which was showing up as a delayed DRC check
when creating parameterized cells.
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.
errors in the periphery of where a change has been made. For some
reason this was not apparent before, but seems to be from a change
dating back to 2008---which seems unlikely. The fact that it has
not been seen before may have something to do with the size of the
DRC halo compared to the DRC step size in the SkyWater PDK, where
it has suddenly become apparent. Jury is still out on this one.
errors from the area checked must use the same area as is used
by the interaction checker to recompute errors. In earlier code,
both these areas were much larger than necessary. In the last
code update, the area to make revised checks was reduced, but
the area cleared of errors was not, resulting in errors that
would disappear from the layout as paint changes were made, until
a full "drc check" was run again. This code commit makes the
areas the same again so that no errors are lost.
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.
R. Timothy Edwards