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.
previous behavior that had inadvertently been changed. In recent
versions, "load <absolute_path> -dereference" would incorrectly
apply the dereferencing to <absolute_path> rather than just its
subcells. Cleaned up the code around DBCellRead() in the process,
so everything is more straightforward (although probably more
could be done in that regard).
dereferencing, and making the behavior of "load" on the command
line (i.e., loading a cell from a file) the same as the
behavior of loading a cell as a result of expanding an unloaded
instance. In both cases, if "load -dereference" is used, and
a cell does not exist in any search path but does exist in the
original location, without dereferencing, then the cell will be
loaded from the original location. Also: Corrected an error
that has existed since adding the capability to read compressed
files, which causes magic to crash when attempting to run the
"crash recover" command (because that routine was mixing
compressed and regular file stream calls).
"cif *hier write disable" and "cif *array write disable" commands
for a specific cell def and its descendents. The revision ensures
that all descendents apply the override. The "cif write" command
uses a stack instead of recursion, which makes it difficult to
apply the same method. Currently the method only works for the
"gds write" command, and implementing the feature for "cif write"
is deemed not worth the effort.
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.
tech file to correct the underlying problem with the SkyWater
sky130 process in which a different layer/purpose pair is used
for TEXTTYPE and DATATYPE for the same layer. Previously, all
output from magic writes the same pair for both when writing a
port label. The new method preserves existing syntax, although
there are some differences based on what order the "port"
statement appears relative to other types for the same layer.
R. Timothy Edwards
Darryl L. Miles
Johan Euphrosine