LVS unexpectedly failing
Opened this issue · 27 comments
Environment
python 3.10, Linux Mint 21, klayout 0.29.5, LVS deck from latest dev branch
Expected Behavior
LVS passing
Actual Behavior
LVS failing
Steps to Reproduce the Problem
- Unpack lvs_case.tar.gz
- cd lvs_case
- ./run.sh
One can see that IHP deck reports failing LVS, the PDKMaster generated one reports matching netlists. I also tried with running the IHP deck in flat mode but that did not change anything.
Sorry, pressed wrong button (resulted in first empty problem description).
Updated the problem description with test case.
@stafverhaegen-chipflow @atorkmabrains @FaragElsayed2
I have just reproduced the testcase and indeed it fails in the command line but it seems to pass in the GUI
using the default settings:
The output contains some warnings:
The log view:
I have used klayout 0.29.0 and python 3.10.12
shouldn't the batch-mode deck and GUI-mode deck behave the same? do they share the same implementation?
@KrzysztofHerman, could you please share here the error message from the batch mode LVS run?
Here is the output from the command line run:
2024-11-07 13:37:44 +0100: Memory Usage (755784K) : ERROR : Netlists don't match
2024-11-07 13:37:44 +0100: Memory Usage (755784K) : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2024-11-07 13:37:44 +0100: Memory Usage (755784K) : LVS Total Run time 2.634887 seconds
07-Nov-2024 13:37:44 | INFO | Total execution time 4.176420450210571s
***** C4M deck *****
LVS OK
GUI based run
2024-11-07 13:38:54 +0100: Memory Usage (1472000K) : ==========================================
2024-11-07 13:38:54 +0100: Memory Usage (1472000K) : INFO : Congratulations! Netlists match.
2024-11-07 13:38:54 +0100: Memory Usage (1472000K) : ==========================================
2024-11-07 13:38:54 +0100: Memory Usage (1472000K) : LVS Total Run time 3.395420 seconds
:) what is the exact issue in the batch-mode?
I tried again with main branch and now for me it does seem to match when running from command line in flat mode; e.g. add --run_mode=flat. Does it work from GUI in hierarchical mode ?
If you use deep mode (I understand is the same as hierarchical) it fails in GUI:
When I run the C4M deck also in deep mode it also fails. It thus seems that klayout has problems with this layout in deep mode. I don't see immediately something wrong with it.
I changed C4M deck to deep mode by chaging line flat to deep in file c4m_klayout/share/C4M.IHPSG13G2.lvs of test case.
Hi @stafverhaegen-chipflow, you have connectivity issues..
so if we say the layout is the reference, you should change the netlist from:
.subckt SP6TCArray_2X1 vss vdd1 vdd2 wl[0] wl[1] bl[0] bl_n[0]
Xinst0x0 wl[0] bl[0] bl_n[0] vdd1 vss SP6TCCell
Xinst1x0 wl[1] bl[0] bl_n[0] vdd2 vss SP6TCCell
.ends SP6TCArray_2X1
to
.subckt SP6TCArray_2X1 vss vdd1 vdd2 wl[0] wl[1] bl[0] bl_n[0]
Xinst0x0 wl[0] bl[0] bl_n[0] vdd2 vss SP6TCCell
Xinst1x0 wl[1] bl[0] bl_n[0] vdd1 vss SP6TCCell
.ends SP6TCArray_2X1
KLayout LVS should be clean after this update (I would be very surprised if it will not be the case)
p.s. I checked on commercial tools
IMHO, from the KLayout LVS reports posted here it's nearly impossible to understand the issue root cause..
I was already checking with the change you proposed locally. It does not change anything. I made a new test case: 20241114_lvs_case.tar.gz
Here the spice netlist was updated as you proposed, I updated the run.sh script so it runs both the IHP-Open-PDK LVS in flat and deep mode and also my generated deck. Both are OK in flat mode, both fail in deep mode. The output of the run is in the included run.log file. I'm not sure how I can make the test case more clear.
ok, I asked KLayout LVS deck developers to take a look on this
@stafverhaegen-chipflow Just to confirm my understanding of the issue that you have, there is a test case that pass LVS if you run from GUI and fails if you run from command line.
- Case 1: Run GUI ----> Pass
- Case 2: Run cmd ---> Fail
- Case 3: Run cmd Flat ----> Pass
- Case 4: Run cmd Deep ---> Fail
- Case 5: Run GUI Deep ---> Fail
Could you please elaborate on what I mentioned above? If there are more cases, could you please list them the same way I mentioned above. That would really help us review quickly the root cause.
Fundamentally, it will fail if deep run and pass if it's flat regardless of the way of invocation. Is that correct?
One last question, Did you run this test case on other tool (Commercial) and it passed?
Hi @stafverhaegen-chipflow, you have connectivity issues.. so if we say the layout is the reference, you should change the netlist from:
.subckt SP6TCArray_2X1 vss vdd1 vdd2 wl[0] wl[1] bl[0] bl_n[0] Xinst0x0 wl[0] bl[0] bl_n[0] vdd1 vss SP6TCCell Xinst1x0 wl[1] bl[0] bl_n[0] vdd2 vss SP6TCCell .ends SP6TCArray_2X1to
.subckt SP6TCArray_2X1 vss vdd1 vdd2 wl[0] wl[1] bl[0] bl_n[0] Xinst0x0 wl[0] bl[0] bl_n[0] vdd2 vss SP6TCCell Xinst1x0 wl[1] bl[0] bl_n[0] vdd1 vss SP6TCCell .ends SP6TCArray_2X1KLayout LVS should be clean after this update (I would be very surprised if it will not be the case) p.s. I checked on commercial tools
@atorkmabrains, I ran it with commercial tools - there is indeed an LVS issue and I showed how to make it clean
Fundamentally, it will fail if deep run and pass if it's flat regardless of the way of invocation. Is that correct?
Indeed
Hi @stafverhaegen-chipflow, you have connectivity issues.. so if we say the layout is the reference, you should change the netlist from:
.subckt SP6TCArray_2X1 vss vdd1 vdd2 wl[0] wl[1] bl[0] bl_n[0] Xinst0x0 wl[0] bl[0] bl_n[0] vdd1 vss SP6TCCell Xinst1x0 wl[1] bl[0] bl_n[0] vdd2 vss SP6TCCell .ends SP6TCArray_2X1to
.subckt SP6TCArray_2X1 vss vdd1 vdd2 wl[0] wl[1] bl[0] bl_n[0] Xinst0x0 wl[0] bl[0] bl_n[0] vdd2 vss SP6TCCell Xinst1x0 wl[1] bl[0] bl_n[0] vdd1 vss SP6TCCell .ends SP6TCArray_2X1KLayout LVS should be clean after this update (I would be very surprised if it will not be the case) p.s. I checked on commercial tools
@atorkmabrains, I ran it with commercial tools - there is indeed an LVS issue and I showed how to make it clean
@sergeiandreyev I presume you ran it hierarchical in the commercial tool, correct? Did you use "Automatch" option in the commercial tool as well to see which exact cell needs changing?
I understand that you have provided a change required for the netlist, @stafverhaegen-chipflow Did you test that change and ran LVS in deep mode?
@atorkmabrains, yes, it was w/ default 'Hierarchical' setting
I have 'Match cell by name' switched-on, or should be another option to check on?
@sergeiandreyev That's automatch switch.
I understand that you have provided a change required for the netlist, @stafverhaegen-chipflow Did you test that change and ran LVS in deep mode?
The latest uploaded test case has the change applied.
Hi @stafverhaegen-chipflow, as I understand the issue is related to this one opened on KLayout:
KLayout/klayout#1921
I doubt this is related to that issue. In that issue LVS has a problem due to ambiguity between different floating nets but our test case should not have ambiguity. Also in that issue the problem is with flat LVS and in out case the problem is with deep LVS.
It may be related to KLayout/klayout#1813 though. My thesis is that extend("*") is not doing what it is expecting to do for the given test case. Will look a little further now.
Created KLayout/klayout#1935 now with slightly adapted test case using global net and not extend("*"). I assume solution for that will also be applicable for the IHP LVS deck.