Commit Graph

257 Commits

Author SHA1 Message Date
Darryl L. Miles 9489b23985 freeMagic1() idiom insertion at all sites reported by static code analysis 2025-12-19 09:31:58 -05:00
R. Timothy Edwards 957d7edd64 A number of things in one commit:
1) Added a "*showmem" "wizard" command to get a dump of all memory
   being used by tiles in the database.
2) Made a slight correction to the way magic detects exact overlap
   of instances of the same cell.  This probably does not make any
   actual difference in practice.
3) Corrected an uninitialized variable in dbReComputeBboxFunc().
4) Changes DBSrCellPlaneArea() to use a static BPEnum variable, so
   that it does not waste time allocating and freeing memory for
   the same thing over and over again.
5) Corrected a memory leak in the tech file "extract" section that
   loses memory every time the extraction style is changed.
6) Corrected the tile join routines to fix a bad memory leak in the
   tile allocation and recovery---a fix which was mentioned in issue
   #414 but which had not yet been implemented.  This has now been
   tested and confirmed to work.
2025-11-07 11:00:22 -05:00
R. Timothy Edwards d3a0228958 Added a new device type "dsubcircuit" which basically behaves like
"csubcircuit" but swaps the first two pins (with the device
identifier layer becoming the 2nd pin and the other terminal the
first), which is needed for n-type diodes modeled as subcircuits
where the subcircuit pin order matches the order of pins for a
SPICE n-type diode component.  Previously "msubcircuit" was used
for this purpose, but will calculate the wrong L and W.  While
use of L and W for diodes is rare, this device type also works for
reversed capacitors (where the bottom or non-identifying layer
terminal is in the first pin position of the subcircuit).
2025-10-07 16:45:22 -04:00
R. Timothy Edwards 656d27b17a Added a new "devresist" type "terminal" to account for resistor
terminal resistance, for cases where the resistor value is
estimated and output along with (or instead of) the physical
length and width or area and perimeter.  Corrected the "area"
and "perimeter" type handling so that they combine in parallel,
not in series (note that "perimeter" resistance is just an area
resistance with the depth of the material factored in).
2025-10-07 12:12:33 -04:00
R. Timothy Edwards 8c323803b7 Additional modification to write out a resistor or capacitor value
as-is, without a parameter name and before any device model name or
substrate pin, according to CDL syntax, if the parameter has been
specified without a parameter name (e.g., "r=" instead of "r=r").
Corrected an error in the extract code which put the substrate node
name in front of parameters instead of after.  This was previously
unexercised because only in CDL format does a resistor or capacitor
model have parameters listed by name.
2025-10-06 17:42:34 -04:00
R. Timothy Edwards d6d8620a7c Added new statements "connect" and "disconnect" to the extract
section of the tech file, which can be used to alter the layer
connectivity tables from the default.  This can be used, for
example, to disconnect substrate and well from taps, to
generate a netlist that checks for soft-connect errors.
2025-10-06 11:50:38 -04:00
R. Timothy Edwards 78f7d22796 A number of changes:
1) Corrected spurious error messages about cells already existing
   in GDS when using "flatten" or "flatglob".
2) Fixed handling of resistance as a subcircuit parameter
3) Added area and perimeter resistance for a device;  this is done
   through the "devresist" statement in the tech file, which is an
   extension of the original "fetresist" statement.  Where "fetresist"
   only supported type "linear", "devresist" supports types "area"
   and "perimeter".
4) Support for CDL syntax, including generating subcircuit-like
   parameters for components starting with SPICE-standard prefixes
   like M, R, C, etc., adding "/" between pins and subcircuit name,
   and saving the file as ".cdl" instead of ".spice".
5) Estimated L and W for devices whose geometry is complex and do not
   reduce to a simple rectangle.  L and W are estimated as the square
   root of the area.
6) Changed the method of extracting L and W for diodes to use the same
   method as capacitors.  Note that diodes are not usually specified
   by L and W, but if they are, this will produce the right result.
7) Corrected the reported filename and line number when printing error
   messages related to errors inside a technology file, when the
   technology file uses "include" to combine multiple files.
2025-10-01 15:17:49 -04:00
R. Timothy Edwards b4912fd550 Updated the version to go along with the merge of pull request
version 8.3.521 that, due to an argument size mismatch, causes
device parameters in netlist output to be printed as zero.
Also added a small extension to the list of extraction types
to include "device veriloga", which has the same syntax as
"device subcircuit" but generates a component type "N"
(Verilog-A component) in the netlist output.
2025-08-07 11:54:49 -04:00
Darryl L. Miles d55a2b74ac header file #ifndef guard namespace consistency (global change)
This add an effective namespace prefix to the guard ifndef
2025-07-29 10:50:32 -04:00
Darryl L. Miles 5e17855f31 header file #ifndef guard presence consistency 2025-07-29 10:50:32 -04:00
Darryl L. Miles 8b7e0aaec6 Makefile: whitespace only change 2025-07-29 10:50:32 -04:00
Darryl L. Miles 046401cbd8 Use HAVE_SYS_TIME_H and TIME_WITH_SYS_TIME from autoconf where possible 2025-07-27 12:43:04 -04:00
Darryl L. Miles 44bb9327a2 ExtTech.c: fix uninitialized exts_linearResist value leaks into extresist
This value appears to be initialised at only one spot in the codebase
(under very narrow conditions) but extresist will read it and make
branching decisions based on the uninitialised state.

This 'X' state propagation appears to eventually get processed in
ResWriteExtFile() near where final output formatting is occurring.

It is unclear (at this time) if it perturbs output values in a
problematic way, or if due to algorithmic reasons the data is
discarded before output anyway.  I have at least one trace run (with
multiple triggers) of printf formatters handling uninitialised data
in ResWriteExtFile().
2025-04-09 15:25:02 -04:00
Darryl L. Miles b3617f603d extract: DBSrCellPlaneArea() cb_database_srcellplanearea_t extContainsCellFunc() 2025-04-09 15:07:28 -04:00
Darryl L. Miles 5c8510355f extract: DBSrCellPlaneArea() cb_database_srcellplanearea_t extContainsCellFunc 2025-04-09 15:07:28 -04:00
Darryl L. Miles 00b479301f tiles: TiPlaneRect const ripple 2025-04-09 15:07:28 -04:00
Darryl L. Miles 1a84eab4ce Plane[GS]etHint() added to encapsulate access to Plane->pl_hint
This is ground work to intercept usage and validate changes in
this area.

Fixed conflicts with earler patch in extract/ExtNghbors.c
2025-04-09 15:02:59 -04:00
Darryl L. Miles f942ae6e78 TiGetClient() excessive use hotspots
This is reducing nearby calls to TiGetClient() API when the value
can be looked up one time and stored in a local variable to make
other decisions about.

This is due to TiGetClient() potentially having a slightly higher
cost to call than previously, this is a kind of peephole
optimization approach (if I can see multiple getters used within
the window it got optmized).

'ticlient' was used for retrieval as ClientData so that future
greps across the codebase for `ti_client` should only match naked
access.
2025-04-09 14:55:58 -04:00
Darryl L. Miles 606f37cc80 Ti[GS]etClient() usage enforcement
All naked access to `ti_client` now uses the function-like-macro
to encapsulate this action.  This macro existed before this just
makes all sites utilize it.

Added additional INT and PTR variants to remove the programmer
load on thinking about casing and casts polluting the point
of use.  So the use now looks cleaner.

Equivalent prototypes:

 void TiSetClient(Tile*, ClientData)
 void TiSetClientINT(Tile*, intptr_t) /* pointertype */
 void TiSetClientPTR(Tile*, void*)

 ClientData TiGetClient(Tile*)
 intptr_t TiGetClientINT(Tile*) /* pointertype */
 void *TiGetClientPTR(Tile*)
2025-04-09 14:55:58 -04:00
Darryl L. Miles e88dcba1c5 CodeQL File{MayNot,Never}BeClosed.ql file-handle resource leaks
Guided by CodeQL static code analyser.

FileMayNotBeClosed.ql
FileMayNeverBeClosed.ql

The trick with "if(fp != stdout)" is problematic (to analyser) as
technically 'stdout' can be a global pointer that COULD be modified any
time, so it might have changed between the fopen() and fclose() calls so
the close MAY NEVER occurs (which is problem the analyzer can see).

So local state is maintained as a bool which will also clarify to the
compiler see the intention without concern for external stdout
modification.

Some items appear to be out and out leaks when certain commands are use.
2025-02-22 21:02:49 -05:00
Darryl L. Miles 90c03738ce ExtPerim.c: extEnumTilePerim() pass by-pointer const TileTypeBitMask* instead of by-value
sizeof(TileTypeBitMask) == 32
2025-02-22 20:58:59 -05:00
Darryl L. Miles e8d7888300 extract.h/EFVisit.h include database.h for TileTypeBitMask
This has a knock on effect of causing EFvisit.c to require database.h
to be defined BEFORE the EFint.h due to an identical copy of ArrayInfo
type being present in both files.

Maybe there should be database_arrayinfo.h ?  To remove the copy.
2025-02-22 20:58:59 -05:00
Darryl L. Miles 6afadf9809 gcc11 -Wall -Wpedantic cleanup (post __attribute__) 2025-01-06 16:25:38 +00:00
Darryl L. Miles 07f9bbe1fb gcc11 -Wall -Wpedantic cleanup 2025-01-06 16:12:11 +00:00
Darryl L. Miles 6851f27284 extract/ExtBasic.c: Lookup() constify call-site 2024-12-26 15:20:58 -05:00
Darryl L. Miles 14b6453707 LookupStruct() constify call-site
irouter/irTestCmd.c: LookupStruct() constify call-site
irouter/irCommand.c: LookupStruct() constify call-site
mzrouter/mzTestCmd.c: LookupStruct() constify call-site
mzrouter/mzTech.c: LookupStruct() constify call-site
router/rtrCmd.c: LookupStruct() constify call-site
plow/PlowTest.c: LookupStruct() constify call-site
plow/PlowTech.c: LookupStruct() constify call-site
plot/plotVers.c: LookupStruct() constify call-site
grouter/grouteTest.c: LookupStruct() constify call-site
garouter/gaTest.c: LookupStruct() constify call-site
extract/ExtTest.c: LookupStruct() constify call-site
extract/ExtTech.c: LookupStruct() constify call-site
extflat/EFread.c: LookupStruct() constify call-site
DRCtech.c: LookupStruct() constify call-site
debugFlags.c: LookupStruct() constify call-site
CmdSubrs.c: LookupStruct() constify call-site
geometry.c: LookupStruct() constify call-site
set.c: LookupStruct() constify call-site
2024-12-26 15:20:58 -05:00
Darryl L. Miles 1e916ee361 ExtBasic.c: oppdir, The right operand of '==' is a garbage value
BD_xxxxx are a bitmask.  So it makes sense due to equality check to
set to zero so it becomes a no-op situation.

I assume lb->dir not matching one of the 4 BD_xxxxx labels would be
a data error anyway and should never occur.

SonarCloud
The right operand of '==' is a garbage value
https://sonarcloud.io/project/issues?open=AZJB16p0NGfDNup0RiW9&id=dlmiles_magic
2024-12-26 13:01:24 -05:00
Tim Edwards e0c95d6d78 Additional coding to handle discovery of terminal types on
different planes of a device that are connected to a multi-tile
device.  This is a more general solution than previously coded,
in which only the first tile of a device would be searched for
terminals on other planes, which was only guaranteed to work
if the device was represented by a single tile.
2024-12-06 20:51:59 -05:00
Tim Edwards 0a67151292 Extended the device parameters to allow a terminal width that is
different from the device (i.e., gate) width, for devices that do
not define a MOS-like gate spanning the width of the device.  This
is restricted to the assumption that the terminal is rectangular
and therefore a simple width and length can be derived from the
area and perimeter.  Also, length is defined as the smaller
dimension and width as the larger dimension.  For additional
restrictions, see the updated documentation.  This was added to
allow correct width and length extraction of a bipolar emitter
window, but may be more generally useful.
2024-12-06 16:42:43 -05:00
Tim Edwards ea29aa3306 Modified behavior of the "property device" value. It was
previously ignoring the parameters of the entire cell including
the device being overridden by the property, causing the output
to be wrong.  The parameters should always be written out to the
.ext file, including the device whose output is being overridden.
2024-11-19 16:16:48 -05:00
Tim Edwards 1fdca3a57a Tracked down an obscure error that was causing a property
mismatch in the SkyWater sky130_fd_io__top_pwrdetv2 circuit
because a resistor with ends shorted together was being assigned
an incorrect length and width.  This was due to the similarity
in characteristics of the boundary vector between a shorted
resistor and an annular resistor.  The terminals need to be
checked for shorted ends to disambiguate the two cases.
2024-11-14 22:22:27 -05:00
Tim Edwards a35993a81b Corrected a long-standing but rare error in which diagonal tiles
surrounding a device tile may cause the device to be extracted
with the wrong node (picking up the node from the wrong side of
the diagonal tile).  Added extra handling to capture the case
where two ports on two different nets are merged when using
"ext2spice short" (previously it was handling only ports on the
same net).  Also:  Removed the redundant readline-4.3 from the
readline/ directory;  only readline/readline is left, which is
version 4.3.
2024-11-02 11:00:05 -04:00
Darryl L. Miles 7feb298f7a ExtBasic.c: warning: variable ... is used uninitialized whenever
ExtBasic.c:408:7: warning: variable 'urx' is used uninitialized whenever '||' condition is true
ExtBasic.c:417:7: warning: variable 'ury' is used uninitialized whenever '||' condition is true

clang18 -Wall warning cleanup [-Wsometimes-uninitialized]
2024-10-09 21:34:12 -04:00
Darryl L. Miles 9ca8697659 strings.h: add #include required when strict
Due to use of strcasecmp() or similar C API.

Maybe HAVE_STRINGS_H is needed ?  If so which platforms needs this ?

clang18 default warning cleanup (strict)
2024-10-09 21:22:37 -04:00
Darryl L. Miles 165f1b35b4 ExtBasic.c: warning: incompatible pointer types passing 'NodeRegion *' ...
The NodeRegion is an extended form of LabRegion (which is smaller) and
has the same layout.  So we cast into the smaller type.

ExtBasic.c:1025:31: warning: incompatible pointer types passing 'NodeRegion *' (aka 'struct nreg *') to parameter of type 'LabRegion *' (aka 'struct lreg *')
ExtBasic.c:2291:29: warning: incompatible pointer types passing 'NodeRegion *' (aka 'struct nreg *') to parameter of type 'LabRegion *' (aka 'struct lreg *')
ExtBasic.c:2335:46: warning: incompatible pointer types passing 'NodeRegion *' (aka 'struct nreg *') to parameter of type 'LabRegion *' (aka 'struct lreg *')
ExtBasic.c:2339:47: warning: incompatible pointer types passing 'NodeRegion *' (aka 'struct nreg *') to parameter of type 'LabRegion *' (aka 'struct lreg *')

clang18 default warning cleanup [-Wincompatible-pointer-types]
2024-10-09 21:22:37 -04:00
Darryl L. Miles e3bfe8c59e 42 x warning: suggest parentheses around assignment used as truth value
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]
2024-10-09 21:12:55 -04:00
Darryl L. Miles d94cd72538 37 x warning: array subscript has type 'char'
Compiler is expressing range concern with the warning mitigated by using
unsigned C array offsets.  This also draws attention to the range concern
when reading the code and making changes.

DBundo.c:263:45: warning: array subscript has type 'char'
DBundo.c:279:49: warning: array subscript has type 'char'
DBundo.c:317:52: warning: array subscript has type 'char'
DBundo.c:318:64: warning: array subscript has type 'char'
DBundo.c:324:52: warning: array subscript has type 'char'
DBundo.c:325:64: warning: array subscript has type 'char'
DBundo.c:329:50: warning: array subscript has type 'char'
DBundo.c:330:58: warning: array subscript has type 'char'
DBundo.c:338:52: warning: array subscript has type 'char'
DBundo.c:339:64: warning: array subscript has type 'char'
DBundo.c:345:52: warning: array subscript has type 'char'
DBundo.c:346:64: warning: array subscript has type 'char'
DBundo.c:350:50: warning: array subscript has type 'char'
DBundo.c:351:58: warning: array subscript has type 'char'
DBundo.c:371:52: warning: array subscript has type 'char'
DBundo.c:372:64: warning: array subscript has type 'char'
DBundo.c:378:52: warning: array subscript has type 'char'
DBundo.c:379:64: warning: array subscript has type 'char'
DBundo.c:383:50: warning: array subscript has type 'char'
DBundo.c:384:58: warning: array subscript has type 'char'
DBundo.c:392:52: warning: array subscript has type 'char'
DBundo.c:393:57: warning: array subscript has type 'char'
DBundo.c:399:52: warning: array subscript has type 'char'
DBundo.c:400:57: warning: array subscript has type 'char'
DBundo.c:403:53: warning: array subscript has type 'char'
DBundo.c:407:50: warning: array subscript has type 'char'
DBundo.c:408:58: warning: array subscript has type 'char'
EFbuild.c:1048:32: warning: array subscript has type 'char'
EFbuild.c:1056:32: warning: array subscript has type 'char'
ExtBasic.c:2358:43: warning: array subscript has type 'char'
ExtBasic.c:2493:43: warning: array subscript has type 'char'
ExtBasic.c:2519:43: warning: array subscript has type 'char'
ExtBasic.c:2644:43: warning: array subscript has type 'char'
ExtBasic.c:2678:43: warning: array subscript has type 'char'
ResPrint.c:143:43: warning: array subscript has type 'char'
plotRutils.c:713:34: warning: array subscript has type 'char'
plotRutils.c:786:29: warning: array subscript has type 'char'

GCC14 -Wall cleanup series [-Wchar-subscripts]
2024-10-09 21:12:55 -04:00
Darryl L. Miles 967b41343b GCC14: warning: missing braces around initializer
GCC14 -Wall cleanup series [-Wmissing-braces]
2024-10-09 21:12:55 -04:00
Darryl L. Miles 41913fbd78 ExtUnique.c: '_uq' directive writing 3 bytes into a region of size between 1 and 1024
GCC14 loud default warnings series [-Wformat-overflow=]
2024-10-09 20:39:12 -04:00
Darryl L. Miles 66734bbaee ExtHier.c: format '%ld' expects argument of type 'long int', but .. 'dlong'
GCC14 loud default warnings series
2024-10-09 20:39:12 -04:00
Darryl L. Miles b3cb528e46 ExtBasic.c: comparison between pointer and integer
GCC14 loud default warnings series
2024-10-09 20:39:12 -04:00
Tim Edwards a3b61abe2b Corrected an error in which "extract unique noports" and
"extract unique notopports" both fail to work correctly because
an attempt some time ago to avoid issuing warnings about shorted
port names when using those options was changed in the wrong
line.
2024-10-07 11:48:27 -04:00
Tim Edwards dba6f99d93 Updated the revision number to go along with the merge of pull
request #325 from Daryl Miles.  Made a few simple style changes
to conform to (what is vaguely defined as) the overall programming
style for magic (passed down from John Ousterhout).
2024-10-01 12:56:31 -04:00
Darryl Miles 14a1b21fb6 extract/ExtHier.c: Wrong type of arguments to formatting function
Fix code scanning alert no. 159: Wrong type of arguments to formatting function (#66)

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
2024-10-01 12:36:13 -04:00
Darryl Miles 1a351efd56 extract/ExtBasic.c: Multiplication result converted to larger type
Fix code scanning alert no. 52: Multiplication result converted to larger type (#49)

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
2024-10-01 12:36:13 -04:00
Darryl Miles 00086817a4 extract/ExtCouple.c: Multiplication result converted to larger type
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>
2024-10-01 12:36:13 -04:00
Darryl Miles 3848ec7b4e extract/ExtHier.c: Wrong type of arguments to formatting function
Fix code scanning alert no. 71: Wrong type of arguments to formatting function (#37)

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
2024-10-01 12:36:13 -04:00
Darryl L. Miles 2703f55449 extract/ExtTest.c: Too few arguments to formatting function
A bit of a guess based on context.

CodeQL: https://github.com/dlmiles/magic/security/code-scanning/58
        https://github.com/dlmiles/magic/security/code-scanning/59
2024-10-01 12:36:13 -04:00
Darryl Miles 21924ec151 extract/ExtTech.c: Too few arguments to formatting function
Fix code scanning alert no. 61: Too few arguments to formatting function (#35)

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
2024-10-01 12:36:13 -04:00
Darryl Miles 66297bd7d0 extract/ExtTech.c: Too few arguments to formatting function
Fix code scanning alert no. 60: Too few arguments to formatting function (#36)

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
2024-10-01 12:36:13 -04:00