bpMain.c:265:11: warning: suggest parentheses around assignment used as truth value
CmdSubrs.c:413:12: warning: suggest parentheses around assignment used as truth value
CmdSubrs.c:759:13: warning: suggest parentheses around assignment used as truth value
CmdFI.c:1600:12: warning: suggest parentheses around assignment used as truth value
DBcell.c:109:12: warning: suggest parentheses around assignment used as truth value
DBcellname.c:2512:9: warning: suggest parentheses around assignment used as truth value
DBcellsrch.c:95:12: warning: suggest parentheses around assignment used as truth value
DBio.c:3998:9: warning: suggest parentheses around assignment used as truth value
DBlabel2.c:228:9: warning: suggest parentheses around assignment used as truth value
DBWelement.c:195:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:197:13: warning: suggest parentheses around assignment used as truth value
DBWelement.c:295:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:297:13: warning: suggest parentheses around assignment used as truth value
DBWelement.c:637:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:639:13: warning: suggest parentheses around assignment used as truth value
DBWelement.c:679:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:681:13: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1219:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1368:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1471:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1543:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1676:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1772:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1919:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2099:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2324:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2713:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2830:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2944:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3097:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3144:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3181:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3215:9: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3227:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3261:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3459:17: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Looks like logic error hiding behind warning
DRCtech.c:4365:22: warning: use of logical '&&' with constant
operand [-Wconstant-logical-operand]
DRCtech.c:4365:22: note: remove constant to silence this warning
clang18 default warning cleanup
The fractional part of the rule distance (modulus after scaling)
does not fit in the unsigned char variable unless it is first
divided by the scalefactor (also requires multiplying up by the same
amount when scaling the other direction). The truncation of the
unsigned char value was causing the minimum area value to be off by
a small amount, causing false negatives (no DRC violation is shown
when metal area is slightly smaller than the minimum allowed).
implement a GF DRC rule. This variant allows for a difference
between the minimum allowed surround on one side and the amount
that must be extended on the adjacent side.
contacts) take default values from the DRC section. Since both
are in lambda, but the DRC section uses a two-part integer and
modulus representation, if default values are taken before
scaling, the LEF layers may get rounded values. This has been
solved by marking values with -1 to indicate that they require
defaults, and then set those defaults (from scaled DRC rules)
after scaling all other tech values.
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.
that queries a default layer width. Otherwise this can cause a
segfault, especially when a technology file has not been specified
and the minimum tech is in effect.
recognized as a valid command when file locking has been disabled as
a compile-time option. The command then generates an error on
"locking enable" but simply ignores the command "locking disable".
gates when the gate length minimum may be larger than the gate
width minimum, and to implement an "angles" option on the "width"
rule that can implement rules where a layer width must be wider
as measured from angled edges than from straight edges.
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.
CmdRS.c:1269:22: warning: & has lower precedence than ==; == will be evaluated first [-Wparentheses]
DRCtech.c:2573:16: warning: & has lower precedence than !=; != will be evaluated first [-Wparentheses]
"|"), pointed out by Jim Everitt. The error is pretty major, but
because the section of code it affects is just eliminating
unnecessary DRC rules, I believe that the only effect is that the
DRC ruleset ends up using more memory than it needs to. But, good
to have fixed.
the layers2->layers1 swapped case from being implemented; the
surround_ok rule type is by definition asymmetric and the two
layer sets cannot just be swapped.
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.
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.
Before this modification "directed" surround rule only worked for layers1 and layers2 belonging to the same plane.
After this modification the "directed" rule works also for different planes, even if layer1 is a contact type.
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".
the compiler. Some are obscure functions (plot verstatec hasn't
been used in years) but others (like SPICE distributed junctions)
are potentially significant sources of unexpected crashes on
systems that don't zero uninitialized memory.
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).
enabling the "plow" command. At this time, however, not all
rules are being implemented correctly given the numerous changes
to the DRC handling since the last time "plow" was working. Fixes
are ongoing.
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.
development had been halted since it was first created back in April.
Version 8.2 is now the official development version, with the first
development push to create a Cairo graphics interface.
Darryl L. Miles
Tim Edwards
Anton Blanchard
Alessandro De Laurenzis
Brad Smith
fabian-l-c