54 lines
2.7 KiB
Plaintext
54 lines
2.7 KiB
Plaintext
Hierarchical "extresist" notes:
|
|
------------------------------------
|
|
Project started January 28, 2026
|
|
|
|
Follow-on from code development of "extresist" to remove dependence
|
|
on ".sim" and ".node" files and instead to read only the ".ext" file
|
|
that will be annotated.
|
|
|
|
When we last left off. . .
|
|
The code works both for running the "extresist" code standalone,
|
|
and for using "extract do resistance" to run the detailed extraction
|
|
in sequence with the normal extraction.
|
|
|
|
Since "extresist" has only ever been recommended for use with flattened
|
|
layout, the differences appear minimal. However, by avoiding the
|
|
(flat) .sim file in favor of the (hierarchical) .ext file, it is now
|
|
possible in theory to run "extresist" on hierarchical layouts.
|
|
|
|
The one thing that is missing from this is the ability to find where
|
|
a wire connects to a subcell, and to mark this as a kind of terminal;
|
|
specifically, a terminal that connects to a subcell, as opposed to a
|
|
terminal that connects to a device. If the contents of subcells are
|
|
considered to be "black boxes", then each cell def should have its
|
|
own self-contained network of drivers and terminals. Drivers are
|
|
already handled as requiring being ports. That's meaningful only on
|
|
the cell top level, where something has to be marked as a point of
|
|
entry for each signal expected to drive the subcircuit. However,
|
|
within a hierarchy, all drivepoints that are parent-to-child connections
|
|
will be identified and recorded as "merge" entries in the .ext file.
|
|
Since the ".ext" files are built from bottom up, it should be possible
|
|
to get a complete list of drive points with exact locations instead of
|
|
relying on port labels as the expected point of entry.
|
|
|
|
Question: If "extresist" is done right after "extract", then won't
|
|
the parent cell not be available at the time of processing any given
|
|
cell, such that the list of node merges not be available? How to work
|
|
around that problem?
|
|
|
|
There is a point in extExtractStack() in ExtMain.c when all cells up
|
|
to the top have been processed but the substrate planes have not been
|
|
replaced. Here the "extresist" could simply operate on the same stack
|
|
as "extract", and parent cell .ext files will be available to parse
|
|
for "merge" statements for finding drive points upward in the hierarchy.
|
|
At the top level, when no parent exists, then the declared ports can be
|
|
used to determine the drive points.
|
|
|
|
This will require duplicating the code that actually runs "extresist",
|
|
because it will have to be run independently in any routine that calls
|
|
"ExtCell". This looks like two places, discounting "ExtTech" which
|
|
shouldn't need it: ExtractOneCell() and extExtractStack().
|
|
|
|
Start by running tests of how the existing code works given a hierarchical
|
|
layout.
|