device extraction working, and also resolved an unrelated error
in "getnode" and another unrelated error reading "resist" values
from the tech file "extract" section.
involving searches on split tile areas, including one very
important check for interaction between split tiles during
hierarchical extraction. There is still something wrong in
the hierarchical extraction, but it could be the last remaining
issue.
the extraction, especially for routines like ExtFindNeighbors where
it was previously not handled at all. A new method was introduced
in which split tiles with neither side TT_SPACE will get an extra
allocated structure that contains pointers to two regions representing
the nodes on the tile's left and right sides, independently. The fix
(as yet not fully tested) should resolve problems with extracting the
sky130 I/O cells, which contain a FET with 45 degree angles on the
gate, where a split tile is divided between the gate and the source or
drain, and therefore represents two different nodes. Also, there were
extraction errors related to incorrect handling of split tiles having
only one node, where a split tile became connected to the wrong node.
and forcing it to be passed as an argument to all the callback
functions for the search routines that require it. Magic now
compiles and runs with the new code, but there are a number of
known issues that need to be fixed up. Committing now so that
I can rebase on the last update to the master branch.
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*)
This is a complete guess based on function parameter types and the locallity of the 'pNum' value.
This error predates the 2017 Initial Commit git history.
Copilot Autofix rejected: extEnumTilePerim(tile, devptr->exts_deviceSDTypes[i],
SimTransTerms, (ClientData) &transistor, (ClientData) NULL );
CodeQL: https://github.com/dlmiles/magic/security/code-scanning/26
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.
to be more robust and not depend on the ordering of the devices in
the techfile. The extraction method now keeps a mask of which
properties of the device (source/drain types, substrate type,
identifier type) have been found, and will look only for device
records that match what is known about the device. Added a device
identifier record which is the last record before parameters if the
record begins with "+". This allows marker layers to be placed
over a device such that it will extract with a different type.
This helps reduce the complexity of the techfile and allows
certain specialized devices like RF or ESD to be identified without
a separate layer type for the device.
R. Timothy Edwards
Darryl L. Miles
Sean Cross
Alessandro De Laurenzis