EFbuild.c:466:9: warning: suggest parentheses around assignment used as truth value
EFbuild.c:662:20: warning: suggest parentheses around assignment used as truth value
EFbuild.c:682:24: warning: suggest parentheses around assignment used as truth value
EFbuild.c:690:24: warning: suggest parentheses around assignment used as truth value
EFbuild.c:1760:12: warning: suggest parentheses around assignment used as truth value
EFbuild.c:1973:9: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2062:12: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2063:13: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2091:12: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2134:12: warning: suggest parentheses around assignment used as truth value
EFbuild.c:2135:13: warning: suggest parentheses around assignment used as truth value
EFread.c:673:12: warning: suggest parentheses around assignment used as truth value
ExtArray.c:693:12: warning: suggest parentheses around assignment used as truth value
ExtArray.c:800:13: warning: suggest parentheses around assignment used as truth value
ExtBasic.c:4569:9: warning: suggest parentheses around assignment used as truth value
ExtBasic.c:4949:13: warning: suggest parentheses around assignment used as truth value
ExtBasic.c:5032:12: warning: suggest parentheses around assignment used as truth value
ExtCell.c:218:13: warning: suggest parentheses around assignment used as truth value
ExtCouple.c:222:12: warning: suggest parentheses around assignment used as truth value
ExtCouple.c:278:12: warning: suggest parentheses around assignment used as truth value
ExtCouple.c:467:9: warning: suggest parentheses around assignment used as truth value
ExtHard.c:379:12: warning: suggest parentheses around assignment used as truth value
ExtHard.c:458:12: warning: suggest parentheses around assignment used as truth value
ExtHier.c:740:16: warning: suggest parentheses around assignment used as truth value
ExtHier.c:831:12: warning: suggest parentheses around assignment used as truth value
ExtHier.c:841:13: warning: suggest parentheses around assignment used as truth value
ExtHier.c:851:17: warning: suggest parentheses around assignment used as truth value
ExtHier.c:865:34: warning: suggest parentheses around assignment used as truth value
ExtLength.c:264:12: warning: suggest parentheses around assignment used as truth value
ExtLength.c:276:12: warning: suggest parentheses around assignment used as truth value
ExtLength.c:878:9: warning: suggest parentheses around assignment used as truth value
ExtMain.c:499:12: warning: suggest parentheses around assignment used as truth value
ExtMain.c:970:12: warning: suggest parentheses around assignment used as truth value
ExtNghbors.c:298:13: warning: suggest parentheses around assignment used as truth value
ExtSubtree.c:683:12: warning: suggest parentheses around assignment used as truth value
ExtTest.c:457:21: warning: suggest parentheses around assignment used as truth value
ExtTest.c:466:21: warning: suggest parentheses around assignment used as truth value
ExtTimes.c:216:12: warning: suggest parentheses around assignment used as truth value
ExtTimes.c:226:12: warning: suggest parentheses around assignment used as truth value
ExtTimes.c:235:12: warning: suggest parentheses around assignment used as truth value
ExtYank.c:236:34: warning: suggest parentheses around assignment used as truth value
ExtYank.c:238:42: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Fix code scanning alert no. 51: Multiplication result converted to larger type (#50)
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
partitioning of unshielded areas reaching outward from any given
edge, caused by using a boundary value in the 2nd recursion call
that had been modified for the 1st recursion call and so was no
longer valid.
computing the amount of fringe shielding was wrong. This fixes
one of my example cases, but not the other one, so I still need to
pin down a condition that can result in negative capacitance.
inside a halo area. The previous implementation used a linear
accounting of error to determine the amount of shielding, but
since the shielding is nonlinear, this is a poor approximation
and regularly overestimates the shielding and leads to negative
capacitances. The corrected method makes many more calls to
the atan() function and the performance impact for extraction
will need to be evaluated.
This is diagnostic only and does not change the read-in
behavior.
(2) ext2spice: Corrected an error that had been introduced
into version 8.3.171 that accidentally marks all devices
as visited which causes all source/drain areas and
perimeters to be output as zero.
(3) extract: Sweeping changes to handling of fringe
capacitance. Removed the (recently added) "fringeshieldhalo"
parameter from the tech file. Reworked the fringe
capacitance models based on results from the "capiche"
project (github/RTimothyEdwards/capiche). Fringe shielding
is now done by clipping fringe at the boundary of a
shielding shape, rather than trying to calculate the
amount of shielding (as the "capiche" project proved this
to be equivalent). Values for partial fringing are modeled
by atan(x), which like the sidewall (1/x) curve, extends to
infinity and values are limited by the halo but do not
otherwise depend on the halo. Because of this, the halo can
be made variable and controlled by the user for deciding on
the tradeoff between accuracy and run time. A new command
option "extract halo" was added to allow this control over
the halo distance.
fringe capacitance halo where the default halo distance was set to
zero instead of one and caused divide-by-zero issues; (2) Found
extraction issues where labels picked up from cells flattened
during GDS reading cause the flattened/emptied cells to show up
in the extraction with extra pins that can mess up LVS. Solved
this by removing labels from flattened/emptied cells.
using the newer methods for nearest-edge searching and fringe area
of effect. Removed a same-net check in a routine that removes
capacitances that are redundant due to hierarchical overlaps; these
redundancies must be checked on shapes within the same net. Corrected
(again) an out-of-clip-bounds check.
reading GDS files, caused by an unneeded change to pass both
the "original" filename and the actual filename when handling
compressed files---The original filename is unneeded.
(2) Implemented several new methods for parasitic extraction. The
first is an option offset value to apply to sidewall calculations.
This handles issues where actual wire separation is different
from drawn wire separation, which can be significant for the
1/d calculation of sidewall coupling. The second method is to
use the recently-added fringe halo to compute the coupling of the
fringe capacitance to nearby wires. Prior to this change, all
fringe capacitance was applied to surfaces directly under a wire
edge as if the fringe capacitance did not extend outward from the
edge. Now the capacitance is properly pro-rated for the position
of any overlapped shape inside the fringing field. Finally, the
third method added is a new search algorithm for finding the
nearest shapes along the length of a boundary. This is used for
sidewall coupling and fringe shielding, where the nearest shape
dominates the coupling, and any shapes behind are shielded and
may (to first order) be ignored. Previously, the entire halo
was searched without regard to shapes shielding other shapes
behind, and a recent correction added an ad-hoc search for
blocking shapes that was inefficient and not always correct.
The new method is both efficient and accurate.
to the fringe shielding calculations, which uses very similar code and
suffered the same problem of not being able to recognize when another
shape was between the two edges under consideration. Fixing this
makes the fringe shielding calculations symmetric, as they should be.
computing coupling to shapes that are shielded by other
intervening shapes. This is not a perfect solution but will
properly handle all but a few pathological cases.
is specified in the extraction section of the techfile, then magic
will compute the effect of a nearby shape partially shielding the
sidewall overlap capacitance, which approaches 100% shielding as
the shapes converge to zero separation. This method prevents
magic from vastly overestimating the fringe capacitance of closely
spaced wires, which was magic's worst problem with parasitic
accuracy. The "fringeshieldhalo" value is the distance at which
the fringe shielding becomes negligible. Typically, it will be
about three times the distance at which half the fringe value is
shielded. It may be necessary at some point to make both the
fringe shielding halo and the sidewall halo values per-type values
(or per-plane, at least). For now, it should suffice to bring
Magic's parasitic extraction back in line with other tools.
which had become fouled up due to the changes in the way that the
substrate is defined and handled. Worked through a large torture
test until all types of substrate coupling and overlap shielding
were resolved to be extracted as expected.
a routine that should have been called with a NULL argument, but
instead was called with no argument, making the behavior system-
dependent. Revised the parsing of the "defaultareacap" and
"defaultperimeter" statements in the tech file, such that the short
version of both statements gets automatic handling of the substrate
and isolated substrate areas; this goes back to the recent change
in extraction behavior to redefine the "substrate type" (e.g., pwell)
during extraction as defining isolated substrate areas, and not the
default substrate. The earlier code change dealt with problems
related to extracting nodes and regions, but did not consider how
parasitic capacitance was affected. This commit resolves that issue.
Darryl L. Miles
Tim Edwards
Anton Blanchard