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]
front of the list during extraction, except that after copying
they're not. Removed the expectation, although that causes the
entire linked list of labels to be parsed and may cause excessive
run-times in pathological situations. Keep an eye out for
unintended consequences.
labels that are not connected to their declared layers. It's the
latter type that need additional processing in ExtSubtree.
Limiting this processing significantly cuts down on processing
time when there are many labels in a layout, as happens with the
"def read -labels" command option.
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.
The extSubtree() routine cuts a layout into squares and extracts
each separately, checking for subcell interactions. In each
square it parses all labels looking for unconnected ones. This
section of code not only parses all labels M x N times, but it
then marks interaction areas where there may be none, forcing
additional unnecessary processing. This commit makes the first
quick optimization, which is to change the return value of
DRCFindInteractions() from boolean to integer, allowing it to
return a value indicating that there are no subcells in the
area. This prevents the loop through labels from happening in
cases where there can never be interactions. More to come.
record to the label structure to hold the port number. One major
issue stemming from this was reported in github issue #203 by Anton
Blanchard. This commit fixes that error.
wrong, and it needs revisiting. This is the cause of a number of
negative capacitances appearing in the netlist (even after accounting
for overlap with subcircuits).
support asymmetric FETs and other devices like bipolars that have
three distinct terminals. This does not go as far as it should to
make the array independent of the number of declared terminals of
the device. However, it suffices to make, e.g., parameter "a2=area"
work for a bipolar device, and to generate the right drain and source
areas and perimeters for asymmetric (e.g., extended-drain) devices.
supposed to pull "sticky labels" into the cumulative flattened
layout. Because it failed to check for the "sticky" flag, it
would copy all labels, causing extraction time to go exponential
as the number of labels in the design increases. Based on this
correction, the extHierConnectFunc1() routine should be able to
be optimized by stopping the search for sticky labels on the first
non-sticky label, since extSubtreeFunc() ensures that all sticky
labels come first in the label list.
substrate more than once for the same subcell, since the substrate
extraction method scans the entire plane area; this was making
large standard cell layouts extract very slowly, as every component
cell was causing the substrate search to be repeated.
extraction: Fixed a problem causing long extraction times, at
least some of which had to do with a poor string hash function
implementation. Fixed a huge problem in ext2spice, where the
node merge function was particularly poorly implemented, causing
exponentially increasing processing times with layout size.
Corrected a minor issue with ext2spice where arguments were
improperly specified, causing unnecessary error messages to be
issued. Fixed an error in the "load -dereference" command option,
which again caused unnecessary error messages to be issued.
Changed .gitignore to ignore Depend files, which are now regenerated
on every build.
extraction times, which is an incorrect units conversion of the
"step" parameter in the extract section. It was converting based
on the "lambda" parameter in the same section, which has to do with
the scaling of values in the output file, not the scale factor of
the database to be extracted, which is set by the current CIF output
scale. Once fixed, extraction times are minimized using the rule of
thumb mentioned in the techfile reference, which is 50 times the
minimum feature size. Also: Give the lengthy nature of extraction
on large designs no matter how well optimized, added a feature to
mark the progress of the extraction in increments of 5%. Does not
output progress for small cells that extract quickly.
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.