Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unexpected LVS fail (with ambiguous matching warnings) #1921

Open
FatsieFS opened this issue Nov 7, 2024 · 6 comments
Open

unexpected LVS fail (with ambiguous matching warnings) #1921

FatsieFS opened this issue Nov 7, 2024 · 6 comments

Comments

@FatsieFS
Copy link

FatsieFS commented Nov 7, 2024

I am using klayout 0.29.8 and have the following testcase: testcase_ambiguous.tar.gz

If you extract the tarball and run ./run_all.sh in the extracted folder you can see that it completes for the two testarrays but not for the top cells with signals connected to bond pads. Looking at the top lvsdb klayout seems to have problems with matching several of the bit/bit_n signals of the single SRAM cells. Looking at a netlist extracted using Trace All Nets->Hierarchical from the GUI I do expect this is a problem with the ambiguous matching and not a real layout problem.

I do need to run the LVS flat on the SP6TVar1TestArray_8X16/SP6TVar1TestArray_8X16C subcells as the vdd net is not handled properly in the hierarchy ATM. Working on that.

@klayoutmatthias
Copy link
Collaborator

Hi @FatsieFS,

The structure is really lots a ambiguities - a proper hierarchy and labels was really helpful.

All ambiguous nodes are bit/bit_n feedback nodes. Even the pad-attached feedback nodes from the SRAM cell are basically ambiguous as the pads do not contribute to the nets. I don't know why the backtracking algorithm gives up matching them. I need to debug somewhat further.

I just wonder what you expect to measure when you attach these super weak feedback nodes to a huge load such as a pad. Plus I'd be afraid that antenna charging from the pads would kill the devices.

Matthias

@klayoutmatthias
Copy link
Collaborator

A few labels on the pads are enough to make the LVS match.

I have attached a modified version of the layout and LVS script. I still have not debugged the problem in detail, but I guess the pad assignments shorten the backtracking paths enough so that all combinations can be evaluated. Also, the compare step takes less than a second now.

Matthias

with_labels.zip

@FatsieFS
Copy link
Author

Aah, two problems on my side. I failed to update the LVS when I put the pin labels in separate text layer as preferred by IHP. Also did not properly connect Passiv pad opening to the top metal and handling of it's pin layer. I corrected this now:

--- ../C4M.IHPSG13G2.lvs.orig	2024-11-10 09:56:14.501986239 +0100
+++ C4M.IHPSG13G2.lvs	2024-11-11 11:59:19.248454133 +0100
@@ -22,25 +22,25 @@
 GatPoly_pin = input(5, 2)
 GatPoly_obs = input(5, 100)
 GatPoly = input(5, 0)
-Metal1_pin = input(8, 2)
+Metal1_pin = input(8, 2) + input(8, 25)
 Metal1_obs = input(8, 100)
 Metal1 = input(8, 0)
-Metal2_pin = input(10, 2)
+Metal2_pin = input(10, 2) + input(10, 25)
 Metal2_obs = input(10, 100)
 Metal2 = input(10, 0)
-Metal3_pin = input(30, 2)
+Metal3_pin = input(30, 2) + input(30, 25)
 Metal3_obs = input(30, 100)
 Metal3 = input(30, 0)
-Metal4_pin = input(50, 2)
+Metal4_pin = input(50, 2) + input(50, 25)
 Metal4_obs = input(50, 100)
 Metal4 = input(50, 0)
-Metal5_pin = input(67, 2)
+Metal5_pin = input(67, 2) + input(67, 25)
 Metal5_obs = input(67, 100)
 Metal5 = input(67, 0)
-TopMetal1_pin = input(126, 2)
+TopMetal1_pin = input(126, 2) + input(126, 25)
 TopMetal1_obs = input(126, 100)
 TopMetal1 = input(126, 0)
-TopMetal2_pin = input(134, 2)
+TopMetal2_pin = input(134, 2) + input(134, 25)
 TopMetal2_obs = input(134, 100)
 TopMetal2 = input(134, 0)
 Cont_obs = input(6, 100)
@@ -59,12 +59,15 @@
 TopVia2 = input(133, 0)
 Substrate = input(40, 0)
 Passiv = input(9, 0)
+Passiv_pin = input(9, 2)
 EXTBlock = input(111, 0)
 Recog_dio = input(99, 31)
 RES = input(24, 0)
 SalBlock = input(28, 0)
 Recog_esd = input(99, 30)
+SRAM = input(25, 0)
 TEXT = input(63, 0)
+dfpad = input(41, 0)
 prBoundary = input(189, 0)
 
 # Derived layers
@@ -167,6 +170,10 @@
 connect(TopMetal1, TopVia2)
 # connect(TopVia2,TopMetal2)
 connect(TopVia2, TopMetal2)
+# connect(Passiv,Passiv.pin)
+connect(Passiv, Passiv_pin)
+# connect(TopMetal2,Passiv)
+connect(TopMetal2, Passiv)
 
 # Resistors
 # Rppd

With the labels my single port test structure now seems to match but the dual port test structure seems to have ambiguous matching problems despite the top level labels. I made new test case with top cell including two pad frames:
two_frames.tar.gz

@klayoutmatthias
Copy link
Collaborator

Hi Staf,

the problem is not necessarily solved by the top level labels, but it is less likely.

In the original case, as far as I debugged it, the problem comes from an ambiguity between the bl and bl_n lines. Without hierarchy and starting from a known match - the word line - the transfer gates lead to a number of floating bl and bl_n's. These floating bl and bl_n and their otherwise related nets (bit, bit_n) all share the same signature, hence are symmetric. So in the end the algorithm will assign schematic bl and bl_n randomly to layout nets, not realizing that they are interlocked pairwise. This leads to the mismatch.

Tying them all to zero or any other level or simply connecting them would remove that ambiguity. Also a hierarchy would do that as the instance path makes them non-ambiguous. Or giving them a proper label (bl[0], bl_n[0], bl[1] etc.) also helps.

I can try to make the algorithm smarter, but in the end, full ambiguity analysis may be prohibitive in terms of runtime.

Matthias

@FatsieFS
Copy link
Author

Tying them all to zero or any other level or simply connecting them would remove that ambiguity. Also a hierarchy would do that as the instance path makes them non-ambiguous. Or giving them a proper label (bl[0], bl_n[0], bl[1] etc.) also helps.

Problem is I can't connect them together as they will have different voltages. The lines do have labels in the appropriate level of the hierarchy though.
As said I know best way is to make design LVS clean hierarchically but these changes take more effort than I originally expected.

@klayoutmatthias
Copy link
Collaborator

Hi Staf,

You're right, the bl are labelled, but there is an issue.

First of all, text handling is kind of special. "input" will give you an "original layer" which is able to carry texts and polygons, but if you call an operation on it, like this:

Metal1_pin = input(8, 2) + input(8, 25)

the result will no longer be an original layer and the texts are lost.

So, the right way to do this:

Metal1 = input(8, 0)
Metal1_pin = input(8, 2)
Metal1_text = input(8, 25)
...
connect(Metal1, Metal1_pin)
connect(Metal1, Metal1_text)

This way, the texts will be seen, but in flat mode, only top level labels are used to avoid name clashes.

You can see the effect if you use "labels" instead of "input" - this will collect all labels on all levels of the hierarchy, and the net names will become a combination of the labels found on different hierarchy levels in flat mode:

Metal1 = input(8, 0)
Metal1_pin = input(8, 2)
Metal1_text = labels(8, 25)
...
connect(Metal1, Metal1_pin)
connect(Metal1, Metal1_text)

These combined net names don't match properly either:

image

Bottom line is: hierarchy will help. Specifically if you combine different modules in one layout.

Matthias

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants