open-source-silicon.dev

<@U03BEDQ0RGB> --- Don't remove backslashes from verilog.  That will just cause (more) issues with the parser.  There is probably some error in the verilog parser in netgen that needs to be fixed.  If you post the verilog file, I can track it down.

design_extracted.spice

lvs_results.log

design.lvs.v

OK I didn't remove backslashes and ran it as is. Here is teh verilog netlist, the extracted netlist, and the lvs_report.
<@U017X0NM2E7> <@U016EM8L91B>

I have not seen backslash-escaped verilog names used as pin names before.
```   BR64 BR64_inst (
        .RESET(\reset_in[1] ),
        .OUT(out_64),
        .\C[63] (\c[63] ),
        .\C[62] (\c[62] ),
  ...```
I think this is what is tripping up the parser, which is treating `\C` in the pin names as a vector, which it should definitely not since it's backslash-escaped.  Hopefully this should be fairly easy to track down and fix in netgen's verilog parser.

<@U03BEDQ0RGB>:  The primary error is trivial to fix;  I was just using the wrong delimiter set when parsing pins in one spot in the code.  However, there is now a more general problem that netgen needs to equate the backslash-escaped name in verilog with an equivalent non-backslash-escaped name in SPICE.  This is why I have not encountered backslash-escaped pin names in verilog, I expect, because converting back and forth to SPICE is a pain.  I think I can add a special exception here for pin matching by name.  I have a few other special exceptions like that, so it shouldn't be a big problem to implement.

<@U03BEDQ0RGB>:  If you pull the latest version of netgen, it should work for you now.  I can now see obvious errors such as a missing VSS pin in the BR32 instance in the verilog, so there are errors, but they now look like real errors as opposed to netgen getting hopelessly lost in the middle of the verilog parsing.

<@U016EM8L91B> thank you! this worked. LVS is clean now.