You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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
The text was updated successfully, but these errors were encountered: