Argument order and type declaration mismatches:
Label *
portFindLabel(editDef, port, unique, nonEdit)
CellDef *editDef;
bool unique;
bool port; // If TRUE, only look for labels that are ports
bool *nonEdit; // TRUE if label is not in the edit cell
This warrants inspection at call site CmdLQ.c:1712 as both types are bool
is it not so straightforward to check.
It looks like when PORT_MAKE is the option 'port make [index] [dir...]'
port=FALSE is this the correct intention ? This looks ok in that
we're searching for labels to make (upgrade) into ports.
Where as all other 'port ....' commands are operating on items that are
already ports, and ignoring labels.
So the K&R argument name order is also how the call-sites are using it.
void
cmdStatsHier(parent, nuses, child)
CellDef *parent, *child;
int nuses;
This was checked and found ok as callback to ../database/DBcount.c
DBTreeCountPaint(... hiercount, ...)
Due to this not-obvious K&R style also being used in the documentation
this was changed as well (in another commit0.
K&R obsolete syntax removal for C23 compatibility series
bpMain.c:265:11: warning: suggest parentheses around assignment used as truth value
CmdSubrs.c:413:12: warning: suggest parentheses around assignment used as truth value
CmdSubrs.c:759:13: warning: suggest parentheses around assignment used as truth value
CmdFI.c:1600:12: warning: suggest parentheses around assignment used as truth value
DBcell.c:109:12: warning: suggest parentheses around assignment used as truth value
DBcellname.c:2512:9: warning: suggest parentheses around assignment used as truth value
DBcellsrch.c:95:12: warning: suggest parentheses around assignment used as truth value
DBio.c:3998:9: warning: suggest parentheses around assignment used as truth value
DBlabel2.c:228:9: warning: suggest parentheses around assignment used as truth value
DBWelement.c:195:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:197:13: warning: suggest parentheses around assignment used as truth value
DBWelement.c:295:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:297:13: warning: suggest parentheses around assignment used as truth value
DBWelement.c:637:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:639:13: warning: suggest parentheses around assignment used as truth value
DBWelement.c:679:12: warning: suggest parentheses around assignment used as truth value
DBWelement.c:681:13: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1219:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1368:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1471:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1543:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1676:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1772:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:1919:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2099:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2324:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2713:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2830:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:2944:17: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3097:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3144:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3181:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3215:9: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3227:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3261:21: warning: suggest parentheses around assignment used as truth value
DRCtech.c:3459:17: warning: suggest parentheses around assignment used as truth value
GCC14 -Wall cleanup series [-Wparentheses]
argument, which is supposed to flatten all selected instances.
After flattening, instead of deleting the instance from the
cell, it deleted the instance from the selection, leaving the
one in the cell.
natural flattening from a selection. That is, instead of
specifying "flatten -doinplace <cell>", you can select some
number of instances and just do "flatten -doinplace".
flattening, since the appearance of the layout will change even
though there are no physical changes. Finally got around to
debugging and correcting the input mask-hints, which can
preserve vendor GDS by marking areas where the vendor GDS differs
from magic's automatically generated output (the method was
almost correct and only needed an input scale factor change).
commit to prevent port labels from being copied up from the
flattened cell into the parent, and prefixing the instance
name to text in the instance top level so that there will be
no port or label collisions in the parent cell after flattening
the child cell in place. Also: Changed "extract dolabelcheck"
to be the default setting.
should have been done a long time ago! Allows an instance to be
flattened in place inside a cell def, which otherwise requires
a complicated set of commands to do. Also: Modified the polygon
handling routine from the previous commit so that it correctly
removes the polygon cell defs after flattening them into the
parent cell.
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.
flattening based on cells which have a property "flatten". Also:
Modified the DEF read and write to convert DIEAREA into a
FIXED_BBOX property. This solves issues with placing of components
from DEF, when those components may not have have come from place &
route and may not have P&R bounding boxes. Also: Fixed the
documentation for the "dump" command, which was missing the optional
orientation in the description.
alternative separator "." instead of "/". This prevents other
routines that expect "/" to indicate a true hierarchy from treating
the label as hierarchical instead of flat, which should be the
correct handling for a flattened cell.
to be annotated from a DEF file. This is particularly useful if
"def read" has been used without the "-labels" option, and the
labels are needed at some point.
this limited ports to 16384, which seemed reasonable at the time.
However, the sky130_sram_macro layouts connect power and ground in a
way that when coupled with "extract unique" can generate tens of
thousands of ports and overrun the bit field, showing that automation
can do the unexpected. The solution was to split out the port number
from the label record as its own 32-bit value.
to eliminate all redundant names resulting from redundant labels.
Changed the behavior of "goto" so that it will find local names with
slashes, which are the result of using "flatten". A hierarchical
search is done first, as before, but on failure to find a subcell
component, the local cell is searched for the verbatim name.
is not necessary that the target cell not exist. That allows a
layout to be flattened into a destination in pieces. Also found
that the "flatten" command never frees memory for the CellUse it
creates for the copy, so fixed that as well.
restricted to its original intent, which is to replace the long name
formed from the plane short name and the "minfinity" coordinate.
This avoids issues with conflicting substrate names derived from a
real layer such as pwell. Also, the global substrate node name now
returns the variable name without the "$" in front if the variable
has not been set to anything. This avoids potential syntax errors
in the netlist.
to allow a cell to be flushed with dereferencing (i.e., discard any file
path attached to the cell, and use the search paths to find the cell when
it is reloaded).
occurrence of the label to place the box on. This can be used with
"findlabel -glob <name>" to get a list of labels and determine the
length of the list, and then iterate through each occurrance of the
label in the edit cell.
could cause serious errors on systems that do not auto-zero allocated
memory. Also: Fixed an error introduced by a recent commit to allocate
character memory for efReadLine() which frees the memory before reading
a .res.ext file, causing a crash when using "ext2spice" with the
"extresist on" option.
Conflicts:
VERSION
Merged recent changes from master back into bplane, as the efficiency of
bplane for doing extraction on large layouts is unquestionably better.
Fixed the implementation of DBMoveCell() for bplane. Corrected an error
in the bplane version of dbScaleCell() that enumerates cell uses but
does not free the list.
Conflicts:
VERSION
database/DBcellsrch.c
database/DBconnect.c
extract/ExtInter.c
lef/Depend
utils/Depend
Updated bplane branch with all changes to master since the bplane branch
was last modified.
down in the hierarchy when selecting a region or net, but with a
(hopefully very useful) twist: To avoid the problem of ambiguous
labels in subcells, the subcell name hierarchy is generated in
the same way as is done when flattening a cell, with the instance
name prepended. For example, when selecting a net in a standard
cell design, a terminal would highlight the name "OR2X1_1/B"
instead of just "B".
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.
Darryl L. Miles
Carsten Wulff
Tim Edwards
Alessandro De Laurenzis