Open d-m-bailey opened 2 months ago
@d-m-bailey : This isn't a valid LVS setup. You are providing a netlist which has an instance of subcircuit "brownout_dig", for which you have pin connections but no pin names, so there's no way to determine the pin order. To that you attach a verilog module of "brownout_dig" which lists pin names but bears no relationship to the pin order of any SPICE netlist. So there's absolutely no way for netgen to determine what order the pins of "brownout_dig" are supposed to be in the SPICE netlist. You probably need an additional SPICE file with a black-box entry for the "brownout_dig" subcircuit that provides the pin names and order.
@RTimothyEdwards Thanks for checking. What is the best way to handle verilog files called from spice files? Maybe use a spice subckt stub that has the pins in the order expected by the calling instance and then override it with the verilog netlist later (keeping the original port order).
In the current setup, I have manually verified that the spice instance nets correspond to the order of the verilog pins. But as you say, there is no way to programmatically verify that this is correct.
Up to netgen
1.5.269
, it's possible to call a verilog module from a spice netlist. Here are the results of the verilog cell compare.From netgen
1.5.270
these are the resultsThe proxy pins are causing a mismatch.
The screen output also has this relevant info
Here's a test case. test-mixed-signal.tgz