LVS examples fail on macOS when using `deep` mode

[grahamrow]

Was excited to see the new LVS functionality and started playing around. When I run LVS macros on flattened cells such as inv.oas via inv.lvs everything runs just fine. If I try to run things like ringo.gds and ringo_simple.lvs the LVS fails with the following:

Internal error: ../../../src/db/db/dbHierarchyBuilder.cc:273 m_cm_entry != m_cell_map.end () && m_cm_entry != cell_map_type::const_iterator () was not true in Region::initialize in MacroInterpreter::execute
  /Users/my_name_here/.klayout/lvs/ringo_simple_io.lvs:15:in `execute_lvs'
  :/built-in-macros/lvs_interpreters.lym:18:in `instance_eval'
  :/built-in-macros/lvs_interpreters.lym:18:in `execute_lvs'
  :/built-in-macros/lvs_interpreters.lym:98:in `execute'

If I flatten the cells, then the LVS runs (but fails to match the circuit, presumably because the hierarchy has been lost).

I'm on version 0.26.3+ on macOS Mojave. I see the same behavior in compiled (master branch) and downloaded released versions.

Hopefully I'm just misunderstanding something! Thanks for the great software.

[klayoutmatthias]

How exactly do you run this LVS?

I tried this (Ubuntu 18):

1.) Load "ringo.gds" from "testdata/lvs":

2.) Copied "ringo_simple.lvs" into the macro IDE and changed the first lines to

if $lvs_test_source
  source($lvs_test_source, "RINGO")
  report_lvs($lvs_test_target_lvsdb, true)
  target_netlist($lvs_test_target_cir, write_spice, "Extracted by KLayout")
else
  report_lvs
end

This way it runs on the currently loaded layout. Tthe "$..." variables are used by the test driver to pass the paths of input and output files.

3.) With these changes the LVS matches:

When you flatten the layout, you'll also have to flatten the netlist to make it match. Flattening a netlist can be done within the LVS script. The layout is considered flat if the "deep" statement is omitted:

if $lvs_test_source
  source($lvs_test_source, "RINGO")
  report_lvs($lvs_test_target_lvsdb, true)
  target_netlist($lvs_test_target_cir, write_spice, "Extracted by KLayout")
else
  report_lvs
end

schematic("ringo.cir")
# flatten schematic netlist:
schematic.flatten

# without, use flat mode for netlist extraction:
# deep

# Drawing layers

nwell       = input(1, 0)
active      = input(2, 0)
pplus       = input(3, 0)
nplus       = input(4, 0)
...

[grahamrow]

Thanks for the quick reply! When I ran this I commented out the test vars and left just the report_lvs statement, so it shouldn't have tripped up trying to load the layout.

Some further testing has revealed the following:

1. Running LVS on the flattened circuit works (as in it runs AND matches the reference circuit) on macOS without having to flatten the actual cells, i.e.:

schematic("ringo.cir")
schematic.flatten
# deep

2. LVS runs (but does not match the reference circuit) in the following scenario:

schematic("ringo.cir")
# schematic.flatten
# deep

3. The deep keyword seems to be what causes the error to be thrown, i.e. the following raises the exception outlined above:

schematic("ringo.cir")
# schematic.flatten
deep

4. Running with deep on an Ubuntu 16.04 virtual machine works perfectly, just as you see on your Ubuntu 18 test.

So this may be a macOS specific problem — I'll try to dig into the internals a bit more and step through the debugger while running the macro.

[klayoutmatthias]

I don't own a Mac, so I can only try with a VM. Right now, I have Catalina. I was not able to reproduce it so far.

From the error message I'd say there is something fishy with the C++ standard library. I'm using default-constructed iterators to indicate a "nil" pointer and compare them against other default-constructed ones. But this does not seem to work on the clang/STL combination specific for MacOS 10.14. It's a kind of special use case, but AFAIK that's covered by the STL standard and does not create issues on all other compilers/STL combinations I know.

Currently I don't have the resources to run many MacOS VM's in parallel and MacOS in a VirtualBox is a pain. It's a pity you need expensive Mac hardware just for debugging.

Matthias

[grahamrow]

Thanks Matthias. I'm on my last thread of patience with macOS for development anyways (cost being only one of several reasons), and will look into a Catalina upgrade before dumping time into a peculiarity of Apple's compiler toolchain for 10.14. I'll post an update if I make any headway, though.

[klayoutmatthias]

This issue is fixed and will be released with 0.26.7.