Are you able to try a quick experiment? Maybe you could test this on a small layout that has the same empty cell situation? I wonder if someone setup your design to have an empty cell in the layout on purpose, and then expected it to be boxed. Here are the options I would suggest for an experiment:
LVS PRESERVE BOX CELLS NO
LVS BOX "my_cell_that_was_empty"
And then do just "calibre -spice" to perform connectivity extraction from layout, without doing the LVS comparison yet.
In the layout netlist you should now see an empty subcircuit similar to the one you had in the source.
Then, comment out the LVS BOX statement so that it won't be used during comparison. This may be important, as you mentioned, using LVS BOX can be dangerous unless you use it properly. There are several points to consider but in your specific case I think the main issue is to make sure that nothing is ignored by accident. If there are any layout errors, you don't want LVS BOX to mask those problems. LVS BOX will cause devices in the cell to be ignored during somparison so for your specific case let's make sure not to use it for comparison. As long as you use LVS PRESERVE BOX CELLS NO then all devices from LVS BOX cells will be netlisted during connectivity extraction, based on DEVICE statements from the rule file.
// LVS BOX "my_cell_that_was_empty"
And now do the "calibre -lvs -hier" etc. etc. for your comparison.
If everything proceeds as I am expecting it to, then the "empty" cell in the layout will now be represented as an empty .subckt in the layout netlist and with the LVS BOX statements commented during comparison, any accidental devices such as resistors or transistors that could have accidentally been in an LVS BOX cell should be discovered during LVS comparison.
Will you let us all know how it goes?
Thanks a lot for your quick reply. Now I have 2 different questions based on my test.
1. I thought the solution should work the first time I saw it. However I got some new mismatch. The new mismatch is a mismatch of net. First, those empty cells all go extracted in the layout netlist. However I found something new in the result. There are 2 type of empty cells.
a. no pin in schematic and only vss in layout. -- clean after BOX it.
b. 1 pin VCC in schematic and 2 pin VCC/vss in layout (both vcc connect VDD on high level) -- new net mismatch. Instances are found in both layout and source, but 0 of that instance go to matched part. all of them are not matched.
DISC LAYOUT NAME SOURCE NAME
Net VDD VDD
X44/X7/X1038/X0(x,y):VCC ** unmatched connection **
** unmatched connection ** Xtop/Xfiller_<empty cell>_8:VCC
instance mismatch - not show in INCORRECT OBJECTS
Matched layout Matched source unmatched layout Unmatched Source Component Type
Instance : 0 0 1915 695 enpty_cell
2. With that solution, we have to run LVS seperately. - Is there any way, it can be run automaticly by change the LVS BOX in the middle. - I can do by a wrap script - Can Calibre handle it automaticly?
Sorry for late reply, I got some issue in the result after testing. Tried to figure out before reply.
I'm not sure what's causing the current problem but it seems nothing is matching, everything is unmatched, and there are several hundred devices. Personally, my best suggestion at this point is to create a special test cell with just a few devices in a test layout and test schematic and then use the following statements in the rulefile to see how Calibre is considering the layout and source:
LVS WRITE SOURCE NETLIST source.net
LVS WRITE LAYOUT NETLIST layout.net
Those two statements would apply only to the LVS comparison step, so those two files (source.net and layout.net) should be created automatically for you after the "calibre -lvs -hier" etc. etc.
Maybe those statements will help with your original layout but if there is too much information then maybe a smaller test will speed up the debug. Once the problem is found with a small case the solution may apply immediately to solve the whole larger case too.
I build a small test case, Here is the result.
.SUBCKT empty_cell_test G VDD VSS
MMN0 net12 G VSS VSS n
MMP0 net12 G VDD VDD p
CELL NAME PLACEMENTS ARRAYS POLYGONS PATHS TEXTS
empty_cell 0 0 8 0 5
empty_cell_test 3 0 24 0 3
p_0 0 0 10 0 0
n_1 0 0 10 0 0
That one come with LVS clean
hacked cdl to re-produce the error caused by the empty cell (I don't have that symbol, so I cannot generate it.)
.SUBCKT empty_cell vcc
.SUBCKT empty_cell_test G VDD VSS
MMN0 net12 G VSS VSS n
MMP0 net12 G VDD VDD p
Xi VDD / empty_cell
LVS dirty for missing instance
I added LVS BOX
LVS BOX SOURCE LAYOUT
The empty_cell show up in my netlist. I remove the BOX and run compare - it is clean.
You suggestion is working as we expected. There must be something tricky in the large netlist. - I need figure out by myself.
Now the question is - Do we have to manually run extraction/compare seperately. (That is a safe way to solve this issue right now. ) Can we define 2 different BOX list or any other switch to force a list of layout cell not flattened during extraction? I tried LAYOUT PRESERVE CELL LIST one more time, and it really not working.
LVS BOX is the only way to force an empty cell in layout to be extracted into the layout netlist as a placement with a pin (requires empty subckt).
Then, there's no way I can think of to have the same Calibre run ignore the LVS BOX statement during comparison (which we are doing in this case only to make the comparison more robust). This is the reason for the separate LVS comparison run (without LVS BOX)
I suppose it might be better if the special device (whatever is supposed to be represented by that empty cell) could be recognized with a DEVICE statement instead of LVS BOX statement but that is just speculation on my part... whoever developed the flow you have probably had good reasons to do it as it is, I'm just not familiar with it.
Another thing to consider is that maybe you and I are being overly cautious by considering the possible risk of using LVS BOX for the comparison too. The only time it would become a problem I think is if there were any layout devices put in that cell by mistake, then the LVS BOX statement could mask them during LVS comparison. If the cell is so small, or the possibility of any unwanted devices being drawn in that cell is small, then maybe the risk is small too. Maybe you will find it convenient to use LVS BOX in the same run for both LVS extraction and comparison for most of the runs, and then you could remove the LVS BOX statements from the final comparison run just as an extra safety check.
Thanks again for your reply. Those filler cells are small but some of them still can fit in one finger MOS. BOX those cells has low risk but not sure it is 100% safe or not. (maybe not. For example, if someone put a PMOS there with S/VDD G/VSS and D floating. and by accident, one of the INV output touch that D - the INV won't work, it will be pull up always.) Define that fillers as devices is one option, but I also think about to run a script to remove all those device from source side. Anyway, thanks a lot for your help!
I think you are developing several alternatives that could be used at your convenience to check thoroughly. Your last reponse reminds me there is an SVRF rulefile statement you could use instead of a script if you want to remove those devices from the source for a run:
LVS FILTER my_fill_cell OPEN SOURCE
Yes, I should try that. I was using LVS FILTER for both source and layout early and failed
I will try it and update you later.
finally worked. Thanks a lot!
i do have similar issue.
Does LVS FILTER work the same way when the fill/decap devices are inside a macro, irrespective the hierarchy in which it is present.
Otherwiise, what should i apply to get the same done?
In my case for this particular macro, the decap device is gettign filtered out from LAYOUT.
But remains unflitered in the SOURCE. This macro is self-contained, i.e., has its own cdl/gds/verilog
LVS FILTER should work to remove a device anywhere in the hierarchy in my thinking. For your case, is it that you are using LVS FILTER but the device still exists?
That's correct. LVS FILTER is affecting all hierarchies.
In my case, the IPs that i am using have a different name for the same cell inside IP.
But, I do have a couple of query regarding, LVS FILTER & VIRTUAL CONNECT.
LVS FILTER & LVS BOX :
when we do run these statements on either LAYOUT or SOURCE for a particular IP -or- a physical cell
Does LVS extraction filter out all the components ( ports, nets & devices ) of the IP or only devices are filtered out ?
LVS FILTER & VIRTUAL CONNECT : This is what I think:
LVS FILTER should be used for those nets shorted in layout but bearing different labels.
VIRTUAL CONNECT is used where in there is not physical connection on the die, but are connected on package/board.
Is this understanding correct ?
LVS FILTER is just for devices, and it only works during the "comparison" phase... it doesn't apply during the "connectivity extraction" phase. Devices are recognized during the connectivity extraction phase such as "calibre -spice" and depending how LVS BOX is used, devices may or may not exist in the resulting netlist for LVS BOX cells.
VIRTUAL CONNECT also works only during connectivity extraction so LVS FILTER doesn't really relate to VIRTUAL CONNECT.