dbNetlistCompare: internal error when comparing schematic and netlist

[Scafir]

Hi,

I am currently doing a bit of work on the gf180 pdk and have a design that causes the following internal error during LVS's compare step on klayout 0.30.5, locally compiled (qt6):

ERROR: ../../../src/db/db/dbNetlistCompare.cc,1871,n == jj->first.size ()
ERROR: In ../../../gf180mcu.lvs: Internal error: ../../../src/db/db/dbNetlistCompare.cc:1871 n == jj->first.size () was not true in LayoutVsSchematic::compare
ERROR: RuntimeError: Internal error: ../../../src/db/db/dbNetlistCompare.cc:1871 n == jj->first.size () was not true in LayoutVsSchematic::compare in Executable::execute
  ../../../gf180mcu.lvs:388:in 'LVS::LVSExecutable#execute'
  :/built-in-macros/lvs_interpreters.lym:31:in 'BasicObject#instance_eval'
  :/built-in-macros/lvs_interpreters.lym:31:in 'LVS::LVSExecutable#execute'

The steps for reproducing involve cloning my own repo. This is because it requires some improvements I've implemented that are not yet upstreamed (currently in discussion with the guys at wafer space/fossi), such as:

• isosub support
• poly resistors in nwell
• removal of connect_implicit('*') as a default

Steps to reproduce:

1. Download the design/netlist files: gf180mcu-project-trident-gf180-teststructure.zip
2. Decompress them

# Install latest gf180 pdk
git clone git@github.com:Scafir/gf180mcu.git --branch klayout_lvs_improvements
klayout -b -r gf180mcugf180mcuD/libs.tech/klayout/tech/lvs/gf180mcu.lvs -rd input=gf180mcu-project-trident-gf180-teststructure.gds.gz -rd schematic=gf180mcu-project-trident-gf180-teststructure.spice -rd run_mode=deep -rd combine=true -rd top_lvl_pins=true
## Error

As it is a somewhat large design, I have not been able to run it in flat mode.

The error does not happen when a handful of devices are modified, but of course then LVS fails, rightfully so. Here is the minimum amount of device modifications that do not cause an internal error:

gf180mcu-project-trident-gf180-teststructure-no-internal-error.zip

Have a great end of the year, and thank you for all you work :)

[klayoutmatthias]

Hi @Scafir,

Perfect! Thanks for reporting this issue and taking your time to prepare that nice testcase. It reproduces perfectly!

I think it's easy to fix - actually the problem is inside a piece of code that tries to identify "similar" subcircuits in case of mismatches. There is a logic error which causes this internal error.

Best regards,

Matthias

[klayoutmatthias]

I filed a PR that fixes your issue.

While I debugged the issue, I found a few problems in your fork of the GF180 LVS. Maybe you like to fix that:

1. Line 56 of gf180mcu.lvs should be

  report_lvs(report_path)

instead of

  report_lvs($report_path)

otherwise by default no report is written

2. "compare" is called twice in the same file. To speed up the compare step, you should store the result of "compare" instead of calling "compare" again:

result = compare

exec_end_time = Time.now
run_time = exec_end_time - exec_start_time
logger.info(format('LVS Total Run time %f seconds', run_time))

# use result instead of another "compare":
if !result
  logger.info('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx')
  logger.error("ERROR : Netlists don't match")
  logger.info('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx')
else
  logger.info('==========================================')
  logger.info('INFO : Congratulations! Netlists match.')
  logger.info('==========================================')
end

3. Line 84 from rule_decks/general_connections.lvs spoils the netlist formation. I should be removed:

With this line

connect(comp, comp_label)

comp will become a valid conductive layer. However, in the other connections comp is not used directly. Instead the derived shapes (ptap, psd etc.) are used and are properly connected to metal 1 through contact. comp is not.

Because of that, single guard rings are extracted as individual nets without being actually connected to something. Those are exposed as pins because they touch guard rings from other cells. The unwanted pins vanish if you take out comp from the connectivity.

What is left are errors I consider true wiring issues. I have not analyzed them in detail however.

Best regards,

Matthias

[Scafir]

Hi Matthias,
My pleasure, it's only natural, I've been very happy using klayout.

Thank you very much for your feedback concerning the pdk, especially point 3. This issue has been nagging me since I started my design, but I could not figure out why these nets were considered. You've just saved me (and probably countless others) from a lot of head scratching!