-
Notifications
You must be signed in to change notification settings - Fork 211
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
Comments
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 |
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 |
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 --- ../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: |
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 |
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. |
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:
the result will no longer be an original layer and the texts are lost. So, the right way to do this:
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:
These combined net names don't match properly either: Bottom line is: hierarchy will help. Specifically if you combine different modules in one layout. Matthias |
I am using
klayout
0.29.8 and have the following testcase: testcase_ambiguous.tar.gzIf 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 lvsdbklayout
seems to have problems with matching several of the bit/bit_n signals of the single SRAM cells. Looking at a netlist extracted usingTrace 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 thevdd
net is not handled properly in the hierarchy ATM. Working on that.The text was updated successfully, but these errors were encountered: