My first inclination would be to try LVS Netlist Unnamed Box Pins NO.
If that doesn't work, then try LVS Box BLACK instead of regular LVS Box. If you do this, a correctly specified LVS Black Box Port statement is also needed. The SVRF Manual has details.
Thank you, Dan. With the "LVS Netlist Unnamed Box Pins NO" the LVS is clean.
Now I have a doubt about the usage of this statement. Acccording to the manual:
"If YES is specified, or if this statement is omitted, then unnamed pins appear in the netlist if
they are connected to devices or LVS Box placements inside the box cell (including subhierarchy
of the cell), or if they are connected to texted port objects in the box cell (at the top
level of the box cell, not including sub-hierarchy of the cell)."
I shouldn't have other connections to this cell than those of the pins. If I use "LVS Netlist Unnamed Box Pins NO" could I have connections to nets inside the cell and still have a clean LVS? I have checked many times looking for these connections and I would say that they don't exist but there is always a risk if this could happen.
When YES is specified, the unnamed box cell pins appear in the extracted netlist because of *internal* connections within the cell, either to device or box cell placement pins in the subhierarchy, or to texted top-level ports within the box cell itself. But if the cell is boxed, presumably you don't care (yet) about the internal connections of the cell. All of that will get checked later when you disable your LVS Box statements to check the whole design.
If there were *external* connections to these unnamed pins, then you would see LVS errors due to missing external connections to the box cells when NO is specified. I presume these are the types of connections that concern you at this point.
If you do not need the contents of your box cells for any parasitic extraction results downstream at this stage, then I suggest going with LVS Box BLACK. This can offer improved performance, because all of the shapes inside black box cells are ignored by default except specified port shapes.
Thanks for the explanation, Dan.
In fact this block is an IP that is not LVS clean so that I want to BOX it in order to have an LVS clean not taking it into account. My concern is if I could have a metal 1 path (for example) routed over this IP by mistake connecting to an internal net and I could not detect it because of the use of the BOX + "LVS Netlist Unnamed Box Pins NO".
I have checked the layout and I would say that everything is OK but I do not know if these extra pins could be created due to a non-desired connection in the top view. If so, I would like to detect and correct it.