magic/README

128 lines
5.8 KiB
Plaintext

Second major code overhaul of 2026
-----------------------------------------
Implement the planned changes to "extresist":
(1) Remove the .sim format as a requirement. extresist will get its node
list from doing a standard extraction (extFindNodes() or
ExtFindRegions(), whichever is appropriate. This should be able to be
done as a relatively simple change, allowing "extresist" to be used
without doing "ext2sim" as part of the process.
(2) Move extresist into the "extract" code. "extresist" will become a
command "extract do extresist" and "ext2spice extresist on|off"
will determine if split nodes and terminals are kept apart in the
final netlist or aggregated---Exactly as capacitance is done now.
Need to figure out how "tile junk" client data and extract client
data can exist simultaneously.
"extresist" will run within "extBasic", being called on a node after
the devices and nodes are identified; nodes created by ExtFindRegions()
will get sub-divided into more nodes. The difficult case will be where
a single tile gets multiple nodes (such as where other wires branch off
the tile in the up or down direction). Maybe this can be done like
ClientData for split tiles, with an indicator bit in ti_body?
-----------------------------------------------------
For (1):
Reading the "nodes" file only creates "node" entries, one per net.
With an ExtFindRegions and ExtLabelRegions (or extFindNodes?) there
should be an equivalent list from which node names, locations, and
types can be taken. This information will be redundant, for now.
Note that ExtResisForDef() runs extResPrepSubstrate() which is like
extPrepSubstrate(), which is run from extCellFile().
So ExtResisForDef() could replace lines 150 to 174 with the ExtBasic
calls to ExtFindRegions(), extFindNodes(), and ExtLabelRegions().
This is followed by temporary code that creates the tables and lists
that the extresist code uses. Then, run the ResCheckSimNodes() code,
or at least the part for a single node (which is ResRex.c lines 1071
to 1240)
Add a ClientData record to a NodeRegion, and extresist can run
by adding "tileJunk" records to the NodeRegion client data, and
leave the region records in place. (done)
Then need to figure out how to output the data all at once.
Replace the "extresist" command with "extract do extresist".
EXT_DOEXTRESIST. Maybe later replace "resistance" and make it
equivalent to "extresist", or maybe make "resistance" *be*
DOEXTRESIST and use "lumped" instead of "resistance" (I like
this better). (done)
"ext2spice extresist on" will then output the netlist exactly as
it appears in the .ext file, while "ext2spice extresist off" will
conglomerate the .tX and .nX sub-nodes and produce what is
hopefully the equivalent of a netlist from a .ext file without
"extract do extresist".
We keep (maybe)
HashTable ResNodeTable
RDev *ResRDevList
At issue: Doing it this way might be more convenient, but by
keeping the NodeRegions in place and adding "tileJunk" records,
it's harder to find where the subnets are connected. If the
NodeRegions get replaced, then there are way more regions but,
for example, a transistor terminal node is easily found by
looking at the Region pointer connected to the terminal type.
However, nodes are output by working through the node list and
devices are output by working through the device list, so the
information is readily available.
Currently the "to-do" work starts at ExtBasic.c line 313.
Pulled out the central part of ResCheckSimNodes() into "ResProcessNode()".
This allows ExtBasic.c to loop over its own nodeList, prepare the
ResSimNode structure, and then call ResProcessNode() to process a
single network.
These are all then bypassed:
CmdExtResist()
ExtResisForDef()
extResPrepSubstrate()
ResReadSim()
ResCheckPorts()
ResCheckSimNodes()
(clean up ResNodeTable and ResRDevList)
The only one of the bypassed routines which may need to be handled
is "ResCheckPorts()". Possibly the ExtSubtree/ExtHier stuff can be
used in place? The main issue is figuring out where the ports are.
Unlike the original "extresist" method, it should be possible to do
this properly. Punt on it for the moment.
Try to compile with the separated-out ResProcessNode() routine.
Okay, got that working.
Now, the hard work: Prepare an extresist node record from ExtBasic.c.
Don't worry about how ClientData records are managed, for now.
Now, what does ResCleanUpEverything() do? We don't want to destroy
the records until the end. Maybe node regions should be replaced by
subnets here? And the resistors can be kept in a linked list or
hash table to be output along with the devices.
The issue here is that some tiles can contain multiple sub-nets,
if there are wires branching off. Note, however, that wires can
only branch off of a single rectangle in the north or south directions,
due to the "maximum horizontal stripes" rule. What if subnets within
a tile were handled by splitting the tile, which would only be done
horizontally, and keeping the tiles separate by setting a flag in
ti_body such that a long wire with many branches would be split into
multiple segments with the flag set to 1010101. . ., which allows the
normal tile handling to work. The flags can be cleaned up afterward
and the tiles merged (maybe just erase and repaint the tile)? Note
that this would never happen with split tiles. Probably okay with
contacts?
Due to the maximum horizontal stripes consideration, does
ResCalcNorthSouth() *ever* get called??
Okay, a long vertical contact with metal branches on either side
would invalidate my assumption, and yes, ResCalcNorthSouth() would
be called.