expression in a property that was not necessarily a parameter,
and if it wasn't, then netgen would crash. Surfaced by an
example using complicated parameters that netgen was apparently
unable to handle (an issue for another day; the main goal here
was to avoid a segmentation violation).
tracker #96) in which a subcircuit with only one port (in this
case, a pad) but which has properties (in this case, "M") will
fail to set the pointer position ahead of the property because
the loop starts after the first pin, so it has already missed
the position that needs to be saved. Fixed by initializing
the value to the first pin position before starting the loop.
to be caused by failing to have a systematic way of determining
which pin's hash value would be used for the hash value of all the
pins. Because equivalent cells in the two netlists may have pins in
different order, it was possible that they might end up with
different hashes. This was solved simply by always taking the
larger hash value of the two pins belonging to the permutable pair.
Now permutation works correctly for arbitrary subcircuits.
(Previously it worked for low-level components like MOSFETs because
the pin order is always the same.)
forced flattening to be done whenever any pin mismatch occurred,
which undermined the whole proxy pin method. With the proxy pins
fixed, reinstated the method of avoiding flattening when pin
issues can be trivially corrected. Also: Added output to the
pin matching for one mismatch case that was being missed.
decided that it is beneficial to break symmetries by net name;
it's just that net names should not be used before all symmetries
related to pins have been broken. So I rewrote the compare
routine to take an argument allowing or disallowing net name
matches, and make one call to break symmetries by pin name
followed by another call to break symmetries by net name. This
still solves the original problem, but does not allow symmetries
to be broken randomly on internal nets if names have been matched
in both netlists. Otherwise the output may report nets that
appear to be swapped, making the output confusing.
to check that the nodes with matching names are pins, but never does.
This results in an attempt to resolve automorphs by matching pin
names AND net names. However, net names can match without the nets
matching, as pointed out by Andrey Bondar (private communication).
Fixed simply by adding the specified check that the node being name-
matched is actually a pin.
open-source-silicon slack on Nov. 3 in which the simple verilog
expression "assign name1 = name2[a:b]"; this revealed an error
where the parsing of "name2" was being incorrectly run with
GetBusTok() which must be called when the token starts with "[".
This problem existed both for the left-hand-side parsing and
the right-hand-side parsing, and has been fixed for both (where
either side may be a subset of a bus and the other a complete
bus).
a verilog escaped string against an equivalent non-escaped
string (requires that the escaped string differs from the non-
escaped string by having a "\" at the front and " " at the end.
The space character is always maintained as part of the string).
formatted output to make it much cleaner and easier to read. This
is in preparation of correcting the circuit1<-->circuit2 asymmetry
in the MatchPins() routine.
the critical property (e.g., L for transistors) is required to
match exactly between devices in order to allow the additive
property (e.g., W for transistors) to be summed. The critical
property should match if all values are within the slop value,
for floating-point values. Note: The implementation is still
not rigorous, as the saved critical value may shift from
device to device; so comparing, e.g., 1.00 to 1.01 to 1.02 to
1.03, etc., can find that all individual comparisons are within
the slop value even though the slop is exceeded across all values.
ditch effort of matching based on combining devices with the same
critical property (e.g., adding gate widths together for transistors
of the same gate length, if the property records remain stubbornly
mismatched to the end). Thanks to Bondar Andrey Renatovich for
surfacing this issue and providing a reproducible example.
a long time ago into the code. The improvements collided with
intervening changes to the same routines and would not merge
cleanly, which is why they were never merged. Step 1: Show the
net name of a matching net that is missing a pin. Remove output
of missing pins that is redundant (pin names being output twice).
instance is matched to a verilog module definition, and the SPICE
instance is read before the verilog definition, forcing a
placeholder cell to be created. Netgen will now make the
assumption that the verilog ports are in the same order as the
SPICE instance port order. At the same time, it will output a
warning message that it is making this not-necessarily-warranted
assumption. If the number of ports don't match or the placeholder
did not come from a SPICE instance, then the placeholder pins are
left alone.
some errors failing to list in the output while also being responsible
for a number of non-errors showing up in the output. This fix may
substantially clean up netgen output. Also: Added text to the
output noting that pin matching may be incorrect with respect to
symmetries if the nets have failed to match.
port-to-port short (formed by "assign" in verilog or zero-valued
resistors in SPICE) does not get checked when counting nodes
before adding a proxy pin to a subcircuit in that cell, causing
the proxy pin to be assigned the same node number and forming an
unintended connection to the port-to-port connecting net.
such a zero-ohm resistors or zero-volt sources during the pre-match
phase, since the list of nodes gets changed by merging nets across
the removed devices. Otherwise, the node-name cache gets
corrupted and random LVS errors occur.
structure variable is not checked for the condition of being NULL
before attempting to read a component of the structure. These
conditions imply that something is badly wrong in the netlist but
should not be causing a segfault.
pass the right cell name to the routine which counts the number of
pins. Using this in a setup file will prevent netgen from spending
time matching low-level devices.
to 1 before the loop over devices in "run", resulting in "M"
taking the value of the previous property record if the following
record did not have an "M" value, instead of setting it to 1.
PropertyMatch() but not corrected symmetrically between circuit1
and circuit2; this left the possibility that "M=1" in one
circuit vs. no "M" entry in the other would still pop up as a
property error, depending on which circuit (layout or schematic)
was listed first.
verilog netlists makes a difference to the matching (or failure
thereof), I applied the same in-circuit pin matching as previously
applied to mixtures of SPICE and verilog netlists. This is clearly
a more robust way to handle pin order differences between parent
and child than was implemented previously.
while back, shorted pins were moved into contiguous positions.
When that method was discovered to cause matching issues, it was
abandoned with a note that doing so might have unintended
consequences because other code might depend on the shorted pins
being contiguous. Such a case was just found, and corrected.
However, it was also found that shorted pins were still not
completely handled correctly in MatchPins(); a solution was
found that adds such pins to the "permutes" list (which needs to
be done if the shorted pins are to be correctly handled in any
higher level of the hierarchy, if there is one), and the
"permutes" list is then checked by MatchPins() to determine if
pins match because they belong to the same group of shorted
pins.
incorrectly evaluated; "(w+l)" for example treats "w+l" as
a single string instead of three tokens. Corrected the code
to watch for a failure of strtod() when parsing the expression
at the "+" sign (also for "-").
were not compared for sorting in the same way they are compared
for property matching. The "slop" value was treated as absolute,
not a percentage, so for example a slop of 0.01 on a dimension
of microns would cause all dimensions to be treated as round-off
error, and no sorting would occur.
before its component cells, and the component cells are read in as
SPICE netlists. Then the original verilog cell and its instances
need to have pins reordered to match the subcircuit definition in
the SPICE netlist. Otherwise, when verilog and SPICE netlists are
mixed, the order in which the files are read is critical, and
failures due to reading out-of-order are very obscure and nearly
impossible to debug.
the following: (1) Checking that the parent cell is verilog,
(2) only running after the two cells themselves have been compared
and matched, then (3) added the missing pin or pins while reordering
pins on instances (note: this may not work if the verilog netlist is
the first passed to netgen; that case needs to be checked).
(1) When a comment line follows a ".subckt" line, and the comment
line is empty or all whitespace, then the following line would
be ignored. This condition appears to be very specific and
was solved simply by detecting it and handling it.
(2) Occasionally the "M" parameter of a subcircuit will be recorded
as type double, and this was not being anticipated by the code
that checks if "M=1" matches a corresponding entry with no "M"
parameter. Simple fix to check the condition where the "M"
parameter is type double.
"-flat_namespace -undefined suppress -noprebind" to "-undefined
dynamic_lookup" which is what was done in magic, which has a
similar structure to netgen.
move to the start index before relinking the sorted entries. That
will cause properties to be lost whenever the start index is greater
than zero. Not sure why this hasn't been caught previously, or
whether other errors are involved here.
devices from a .prm file into class "subckt" when they should be
class "module" (because they are primitives). Otherwise, netgen
will crash when attempting to flatten them.
with IRSIM including recent changes made to support multiple device
types using the subcircuit "x" component type. This requires
reading in a .prm file, which incidentally can be used with any
SPICE file to inform netgen of the specific component type of any
model defined as a subcircuit.
the removal of zero-valued devices between ports on the top level
(from version 254 they are ignored for levels under the top to
prevent port order from getting scrambled). An invalid check was
being made to determine if the cells being compared were the top
of the compare queue. This has been fixed.
string vs. integer) will cause a segfault. Not sure if
type promotion is needed at that point because the failing case
was a syntax error that caused a double value to be interpreted
as a string because it could not be cast into a numeric form.
devices between two ports is ignored for top-level cells, because
the scrambled ports won't affect anything in that case, and the
error will be reported as a port error, as it should.
so that they are *not* removed to make a better match if they are
shorting across two ports. If removed, then the port lists will
get screwed up. It is better to let the subcircuits fail matching.
Then, after the mismatched subcircuits are flattened, if the zero-
valued resistor or voltage source no longer connects two ports, it
can be safely removed to make a better match.
response to Mitch Bailey's github issue #82:
(1) When skipping comments, skip the contents of "(* ... *)"
delimiters as well as "/* ... */" delimiters.
(2) When checking for qflow's "\abcd\" names (final space
replaced with a backslash for SPICE compatibility of
names), make sure that the last "\" is followed by end-
of-string. Otherwise names like "\a\bcd " will fail to
parse correctly.
when they are shorted, because doing so is scrambling the pin
order of cells with respect to the instance calls to the cell.
Not sure if there is any code that relies on shorted pins being
adjacent, though.
fault that would happen if the verilog had illegal syntax of a
misspelled net name (although normally netgen is expected not to
have to check the verilog for syntax, and there are probably many
such cases of netgen failing to handle incorrect verilog and then
crashing as a result).
R. Timothy Edwards