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.
missing copying one line with a conditional. The error results
in "bloat-all" DRC checks reporting false positive errors. This
commit fixes that error.
more points to accept interrupts during DRC checks, and
modified the tech file parser to allow the full syntax for
magic layers that is allowed elsewhere (e.g., "(*ndiff,poly)/a")
(this applies to magic layers, not GDS layers). Fixed a
clipping error in the bloat-all function which was causing
non-manhattan geometry to produce bad results, which would
cause false-positive DRC errors when used in a CIF-DRC rule.
prefix when doing a reentrant load, causing include files to not
be found. Fixed a divide-by-zero issue that occurs when some
tech file sections are not loaded to the abovementioned error.
a self-intersecting or reversing path is seen in the input.
Added a new feature in which "save <cell>.tcl" will create a
file of magic commands that will re-create the cell when sourced
as a command file.
not to re-process processed tiles made an incorrect assumption,
causing tiles not to be re-processed when the clip area changed,
such that areas would be missed. It is not clear that in its
corrected version, "bloat-all ... [dist]" is any more efficient
than the original implementation of an incremental series of bloat
+ AND. At least the syntax in the tech file is much simplified.
Previously this was returning two values, a 'bool' and a data
structure that is created. Now it simply returns the data
structure which makes it easier to reason about who takes
ownership of the memory and when, also that no address-of can
be supplied that has any side-effect that interacts with how
the method works / the returned result.
-extern bool CIFParsePath(CIFPath **pathheadpp, int iscale);
+extern CIFPath *CIFParsePath(int iscale);
Previous related comments:
Easier to reason about, there can be no interaction from *pathheadpp
and the various functions called, which maybe the first concern to
the next reader as visibility of new data is limited to that of a
local variable of the function.
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*)
manhattan shapes (especially minimum-sized ones) to be eliminated,
as these can survive a shrink-grow operation intended to get rid
of such shapes. This implementation may not be in its final form
but should suffice for now.
new CIF operator is used in a tech file. Reworked yesterday's
commit to add more related operators, so there are now four new
ones (also renamed them): interacting, noninteracting, overlapping,
and nonoverlapping. "interacting" now means overlapping or touching;
so the four cases allow all variations of adjacency between the two
material types.
regions of a given type and retains only those regions which
interact with (overlap) another given type. Both sets of types
can be either magic database types or CIF temp layers. This will
allow the implementation of rules that were not previously
possible.
The type is actually an enum (assumed to be int by default) but relies
on the magic typedef to (unsigned char) so we make this explicit and
better document what the real type is.
I guess in the past it was really a bool with only 2 states NONE|TEXT.
C29 bool type compatibility
There are 3 states for CLOSE_xxxxxx with 3 different values.
Issue introduced from 2f7f76bf9 merged since tag:8.3.509
This affected the scenarios using non-zero non-one values such as:
#define CLOSE_DONE 2
This looks the result of an original bug where the forward declaration
had a type mismatch with the real method, so the method implementation
prototype was taken as the correct one. The forward decl was rewritten
with the correct prototype signature.
Maybe this is the cause of CIF data once drawn into view does not always
seem to always erase after disabling and a redraw ?
This direction was chosen due to #define integer use of special values
instead of TRUE/FALSE. This makes the prototype and use consistent
removing compiler warning from recent K&R removal.
Beware of the MISMATCH with the prototype found in original
source, with the type declaration below.
External call sites checked to confirm argument order is
correct with the argument name order.
// nedges <> dir
bool
cifOrient(edges, nedges, dir)
CIFPath *edges[], /* Array of edges to be categorized. */
int dir[], /* Array to hold directions. */
int nedges) /* Size of arrays. */
// spacing <> border
int
CIFGetContactSize(type, edge, spacing, border)
TileType type,
int *edge,
int *border,
int *spacing)
K&R obsolete syntax removal for C23 compatibility series
The data types CIFPath and CIFReadStyle are part of CIFread.h
and all users outside include CIFread.h already.
K&R obsolete syntax removal for C23 compatibility series
"bloat-all" which is "bloat-all types1 types2 distance" where the
"distance" value is a maximum amount to grow. It is not (that I
know of) particularly useful for generating output GDS, but it is
very useful for generating temporary layers for DRC checks,
especially things like determining tap distance for latch-up
rules. The alternative (used in the sky130 tech file) is a
tedious step-by-step "grow" followed by "and-not". This rule
option is much cleaner to implement and computes faster (although
it is still a boolean operator and is much slower than an edge
rule).
PlowRules1.c:439:9: warning: suggest parentheses around assignment used as truth value
PlowTech.c:645:17: warning: suggest parentheses around assignment used as truth value
PlowTech.c:652:17: warning: suggest parentheses around assignment used as truth value
PlowTech.c:1019:17: warning: suggest parentheses around assignment used as truth value
ResReadSim.c:270:13: warning: suggest parentheses around assignment used as truth value
ResReadSim.c:871:9: warning: suggest parentheses around assignment used as truth value
ResRex.c:1840:17: warning: suggest parentheses around assignment used as truth value
getrect.c:72:9: warning: suggest parentheses around assignment used as truth value
getrect.c:79:9: warning: suggest parentheses around assignment used as truth value
getrect.c:86:9: warning: suggest parentheses around assignment used as truth value
getrect.c:93:9: warning: suggest parentheses around assignment used as truth value
hash.c:732:16: warning: suggest parentheses around assignment used as truth value
heap.c:328:17: warning: suggest parentheses around assignment used as truth value
heap.c:344:17: warning: suggest parentheses around assignment used as truth value
netlist.c:323:17: warning: suggest parentheses around assignment used as truth value
niceabort.c:121:9: warning: suggest parentheses around assignment used as truth value
path.c:1102:12: warning: suggest parentheses around assignment used as truth value
pathvisit.c:245:13: warning: suggest parentheses around assignment used as truth value
pathvisit.c:295:17: warning: suggest parentheses around assignment used as truth value
tech.c:656:17: warning: suggest parentheses around assignment used as truth value
ext2spice.c:1591:16: warning: suggest parentheses around assignment used as truth value
ext2spice.c:1622:16: warning: suggest parentheses around assignment used as truth value
ext2spice.c:1813:12: warning: suggest parentheses around assignment used as truth value
ext2spice.c:1862:12: warning: suggest parentheses around assignment used as truth value
ext2spice.c:3808:16: warning: suggest parentheses around assignment used as truth value
CalmaRdio.c:437:9: warning: suggest parentheses around assignment used as truth value
CalmaWrite.c:396:9: warning: suggest parentheses around assignment used as truth value
CalmaWrite.c:1772:29: warning: suggest parentheses around assignment used as truth value
CalmaWriteZ.c:372:9: warning: suggest parentheses around assignment used as truth value
CalmaWriteZ.c:1608:29: warning: suggest parentheses around assignment used as truth value
CIFrdtech.c:209:9: warning: suggest parentheses around assignment used as truth value
CIFrdtech.c:214:9: warning: suggest parentheses around assignment used as truth value
CIFrdtech.c:220:9: warning: suggest parentheses around assignment used as truth value
CIFrdtech.c:226:9: warning: suggest parentheses around assignment used as truth value
CIFrdutils.c:1258:12: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
Added pointer casts to hint to compiler the programmer intention
is to compare as pointers to the start of the array (and not be
concerned the programmer is overlooking the contents of the array).
GCC14 -Wall cleanup series [-Warray-compare]
angled edges. This is a rare case and so has never come up before,
but can happen especially on transistors with gate or diffusion
with 45 degree chamfers or flanges. Thanks to Mark Martin for
providing the use case.
The 'isvalid' pointer argument to CmdFindNetProc() is for an optional return value, so must be
NULL when feature is not used.
Copilot Autofix rejected: ttype = CmdFindNetProc(netname, CIFDummyUse, &bbox, FALSE, additional_arg1, additional_arg2);
commands/CmdFI.c
cfb81101 (2022-03-30 13:02:12 -0400 1584) bool *isvalid;
commit f89d52dbcc (tag: 8.3.253)
Date: Thu Jan 6 13:29:43 2022 -0500
CodeQL: https://github.com/dlmiles/magic/security/code-scanning/7
report it after "Failure to read in entire sub-tree". This will
not report every failing cell (since it quits reading after the
first failure) but will avoid the existing issue of printing
nothing and leaving the user with no feedback as to which cell
was the problem.
that resolves issues of excessive tile fracturing during read-in
of GDS (or CIF) polygons and paths that have non-manhattan geometry.
This was particularly noticeable when reading the GF180MCU corner
I/O cell, which ended up being something close to a worst-case
scenario.
no way to implement boolean operators on labels, so any "label"
statement in the section can apply only to one magic layer. This
is regularly violated in most (all?) techfiles (due mainly to lack
of explanation and guidance). The addition of the "no-reconnect-
labels" option for cifinput made it worse, as it can cause a label
to be attached to the wrong layer and be stuck that way. Even
without the option, an attachment to a non-connecting type is a
problem; DIFF cannot simultaneously have a connection to both
ndiff and pdiff, so it will be one or the other, and the one not
connected can easily get labels moved to other nets. To avoid
this: (1) removed the "no-reconnect-labels" option, and (2) made
the automatic label reconnection smarter, as well as splitting it
into two different behaviors based on whether a label is being
created or manipulated from the command line (more or less the
original behavior) vs. being read from GDS or LEF. The new rules
assume that labels attached to a GDS type will all map to the
same plane in magic. To avoid excessive error messages from
existing tech files, a warning is issued only if "labels" changes
the plane of the target layer (a realistic solution rather than
the preferred one). Also: Fixed an error that causes a crash on
the "wizard" command "*watch" if the cell being observed is
read-only (see github issue #271).
"unexpected asymmetric device" is printed prematurely, as it
is inside a loop checking over all device entries compatible
with a device type. Also: Flagged an issue with the "label"
keyword in the "cifinput" section of a tech file. The "label"
keyword cannot be used in conjunction with boolean operators.
It can only connect labels on a specific GDS type to one magic
type. Unfortunately, because this was not flagged before as
an error or warning, the incorrect usage has crept into a lot
of tech files. This uncovers an underlying issue that labels
must be allowed to automatically reconnect types, which is
undermined by the "no-reconnect-labels" cifinput option. That
issue will be addressed in an upcoming commit.
R. Timothy Edwards
Darryl L. Miles
Johan Euphrosine