5 Replies Latest reply on Nov 13, 2012 7:08 AM by chris_balcom

    LVS BOX problem?




      I have two seperate digital designs. They are LVS match seperately. However, when I combine them, they are not LVS match. LVS sees only one of the designs. In LVS report, cells used in one of the designs are absent. For example there are 1000  DECAP64 cells in total. There are 900 DCAP64 cells in one design, and 100 DCAP64 designs in other design. When I run a LVS on these two designs seperately, there is no problem. But, when I connect these two designs, and run LVS, it sees 900 of DCAP64 cells, but does not see 100 of them. This means it sees one of the designs. I could not figure out problem.


      I am using LVS BOX statement for the cells, because the vendor does not supply the backend information of the library.


      Do you have any recommendations?


      Thank you.

        • 1. Re: LVS BOX problem?

          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?

          1 of 1 people found this helpful
          • 2. Re: LVS BOX problem?

            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.

            • 3. Re: LVS BOX problem?

              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.


              Best regards,


              1 of 1 people found this helpful
              • 4. Re: LVS BOX problem?

                Hi Chris,


                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.


                Kind regards,


                • 5. Re: LVS BOX problem?

                  Hi Omer,


                  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.


                  Kind regards,