Hi Qing,

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?

Best regards,

-chris

Hi Qing,

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.

Hi Qing,

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.

Hi Qing,

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

Best regards,

-chris