LVS performance issue ? (infinite loop ?)

tnt

Hi,

I'm trying to run LVS on a subblock of tiny tapeout and for most of them it works fine. However when trying to do the same for the "mux" part
(which selects/mux signals between a row of projects), this doesn't. It looks like it's not completing. It's been running for 1h30 now ... (while the others blocks are a minute or two at most).

I've attached the input files and LVS script we're using.

Cheers,

Sylvain

tnt

Actually I think the CDL written out by OpenROAD is incorrect.
Of course it's still be nice if KLayout reported a LVS mismatch instead of not finishing

Matthias

Of course

In most cases, "stuck LVS" comes from ambiguities - manifold parallel nets that share the same signature. This is typical for buses for example. In that case, helping LVS with proper net labels helps.

But I will check if that is the case there and if something can be done. Thanks for the test case.

Matthias

dick_freebird

Might I suggest a "watchdog timer" that will "shake the Etch-a-Sketch" if it ends up "stuck"? That's an approach in systems for making layers of "self-righting" (this being the back-backstop).

Then that event might trigger some "introspection" or whatever.

tnt

Attached is a new CDL which I think is correct.
OpenROAD had a bug, I think I fixed it but LVS still isn't proceeding. I didn't wait as long yet, but in 15 min, still no results.

EDIT: CDL definitely looks correct. I was actually able to match it against the netlist extracted by klayout using netgen.

Matthias

grml .... found the issue.

So here is the story:

You can turn on noisy debugging in the netlist compare code when you set

KLAYOUT_NETLIST_COMPARE_DEBUG_NETCOMPARE=1

It shows the backtracking algorithm goes into tentative evaluation due to massive ambiguities like this:

...
*1 analyzing ambiguity group with 72/72 members
...
*1 trying in tentative mode: um_ow[169] vs. UM_OW73
*1 trying in tentative mode: um_ow[169] vs. UM_OW74
*1 trying in tentative mode: um_ow[169] vs. UM_OW75
...

that translates into "the names do not give me a clue" because one name (layout) contains square brackets, the other (schematic) doesn't.

In the CDL file the brackets are there.

I then debugged my own code without finding anything that removes the brackets. They simply are not there.

That was until I looked into the LVS script which has this code (line 243++):

...
  # Override parse_element method to handle exceptions gracefully
  def parse_element(line, element)
    # clean line
    line = line.delete('[]$\\/')   # <---------- HERE!

    # Prep sch for R, C
    line = clean_sch(line, element) if %w[R C].include?(element)

    super
...

In other words, it clears all square brackets, dollars and slashes. I don't know why.

After removing that line, LVS gets the hints it needs from the layout labels and passes in a little more than 12 seconds.

...
2024-10-29 21:57:06 +0100: Memory Usage (429932 KB) : Starting SG13G2 LVS Options Preparations
2024-10-29 21:57:06 +0100: Memory Usage (429932 KB) : Starting SG13G2 LVS Alignment
2024-10-29 21:57:06 +0100: Memory Usage (446316 KB) : Starting SG13G2 LVS Simplification
2024-10-29 21:57:06 +0100: Memory Usage (446316 KB) : Starting SG13G2 LVS Comparison
2024-10-29 21:57:07 +0100: Memory Usage (446444 KB) : ==========================================
2024-10-29 21:57:07 +0100: Memory Usage (446444 KB) : INFO : Congratulations! Netlists match.
2024-10-29 21:57:07 +0100: Memory Usage (446444 KB) : ==========================================
2024-10-29 21:57:07 +0100: Memory Usage (446444 KB) : LVS Total Run time 12.469408 seconds

Great.

Matthias

tnt

\o/ Matthias you rock !

Indeed with that change it checks out in no time at all.

I've pinged the ihp folks about that, we'll see what they say ...