1 of 1 people found this helpful
Are the cells missing from both the layout and source in the LVS report?
Is there a difference in the numbers "before transformation" and "after transformation" sections of the LVS report for these cells?
No, just missing in the layout. And as I mentioned before, cells are missing just in one design.
There is a difference before and after transformation, but just related to ports and nets. There is no difference for instances. That difference is same when I run LVS with single design, and they are LVS match seperately.
Thanks Chris for your reply.
By the way, I am giving the spice netlist to Calibre. It is CDL export from Cadence. I am providing the spice netlist converted by Calibre.
1 of 1 people found this helpful
If just missing from the layout side, and no differrence in numbers of instances after transformation, then it sounds as if the instances may first be missing at the connectivity extraction stage. Maybe you can look at the netlist extracted from layout, to see the .SUBCKT definition for the DECAP64 cell (does it have pins? are there multiple .subckt definitions for the similar cell?), and then check to see if there are any placements of that subckt in parent cells you would expect it to be placed in.
I checked out the layout netlist. Yes, there is SUBCKT definition with VDD and VSS pins, which is correct. There is no multiple SUBCKT definitions for DCAP64 cell.
But, there is something strange in the netlist. There are a lot of SUBCKT definitions with ICV_XX naming such as ICV_2, ICV_19, ICV_124... Each of these cells include DCAP64 cells inside. In some of them there are 3 DCAP64, in some 2, different number of DCAP64 cells. But, there is no corresponding cells in source netlist.
I also should inform you about a DRC error. We have sent our layout to vendor to be checked for DRC. There are a lot of errors in one of the digital designs. We have realised that stream out (or stream in) of gds creates different namings for the cells used in both designs. It assigns suffixes to the cells common in both designs. In our case, DCAP64_131 for example. Since, there is no such cell in standard cell library of the vendor, these cells with different namings give DRC errors. But we could not find what to do, to prevent this naming problem. Most probably, Calibre also assigns different names while creating layout netlist. These ICV_XX cells may be the reason, I don't know. I could not find the stream out/in option to prevent this naming for same cells in different digital designs.
Thank you for your help.
The ICV_xx cells are a normal part of hierarchical injection and optimization during hierarchical connectivity extraction. I don't think they are part of the problem in this case.
If the DECAP64 cells are expected to be LVS BOX cells, then the correct name must be used during connectivity extraction and LVS comparison. If the cell names are being changed unexpectedly then that should be the problem. I'm not aware of a way for Calibre to rename cells on the way in, so I suspect the cells are being renamed while the stream file is originally being created. Personally I'm not aware of a good way to deal with that problem but hopefully the bit I mentioned helps you zero in on a solution soon. Maybe someone reading this will be able to fill in the last part of the solution.