How can ambiguity in LVS affect PEX results?

Version 1

    How can ambiguity in LVS affect PEX results?


    Is there any benefit from specifying LVS POWER NAME and LVS GROUND NAME for PEX analysis?


    How to remove ambiguity from LVS to cause better PEX results.


     


     

    Anything you can do to eliminate ambiguity between circuit elements will aid in the desired handling of your design data by the CAD tools being used.


    Consider the LVS POWER NAME and LVS GROUND NAME settings.


    These assist LVS in achieving a clean result, because they help identify initial correspondence points between the LAYOUT and the SOURCE datasets.


    They are used by LVS in logic gate recognition, filtering unused devices and in power supply verification. They are also used by LVS in connectivity extraction to help resolve texting conflicts for the power nets as they take precedence over the alphabetically least name method of such texting conflict resolution. They also assist in high short resolution. You can find these things described in the SVRF Manual.


    In addition, LVS POWER NAME and LVS GROUND NAME settings assist in minimizing and/or eliminating ambiguity between like circuit elements in the design.


    If LVS POWER NAME and LVS GROUND NAME are not specified, there is a greater possibility of ambiguity existing between regular structures in a design.


    Similarly, if robust texting of the layout is not done for regularly repeated like structures in the design, this will also contribute to increased ambiguity between like circuit elements in the design.


    Greater ambiguity increases the number of circuit elements matched arbitrarily by LVS.

     


    Ideally we desire LVS to conclude that SOURCE and LAYOUT match each other without any ambiguity at all.


    Leaving ambiguity on the table in the process of running LVS carries some risk. 

    This is because, unless there is zero ambiguity, some circuit elements will be matched arbitrarily.


    In a real life case in which LVS was clean, but ambiguity was cited by LVS involving several clock tree branch nets,

    the PEX results showed a total C per clock tree branch net that was not as expected across the set of clock tree branch nets.


    In this case LVS arrived at the happy face and cited specific detail in the LVS report file on the ambiguity discovered and the nets matched arbitrarily.
    As a result of the ambiguity some of the clock tree branch nets were not matched as desired.


    The solution here was to to remove the ambiguity.

    Ambiguity was removed by providing distinguishing Text objects to name the layout nets with names matching the corresponding source nets.

    This allowed the desired matching between layout and source nets to be made.


     

    LVS POWER and LVS GROUND were already being used in this case, so they did not need to be added. 

    LAYOUT TEXT statements were added to provide the needed text on the clock tree branch nets. 

    Also LVS was set to NOT ignore ports. 

    Using net identifying text and not ignoring ports made the difference.

    A proper result through the PEX flow produced expected simulation of the proper circuit.


    The key point here is that only when the ambiguity was removed did the layout to source matching align itself properly to produce expected PEX results which carried into expected simulation results.


    Another key point is that in such cases, there is usually no tool defect either in LVS or in PEX. 

    If one can show connections that are of concern in the layout netlist from LVS usually located here: svdb/*.sp,

    and ambiguity in the nets of interest is cited in the LVS report file,

    then this ambiguity must be elimninated first before even considering that a possible tool defect exists.


    Conclusion:


    Using LVS POWER NAME and LVS GROUND NAME, not ignoring ports, and adding robust text on circuit elements of like structures in the layout can all reduce or even eliminate ambiguity in your design. 
        

     

    Reducing ambiguity to zero in a design is a good thing.  

    It will allow the desired processing of a design's regular structures through the CAD flow

    achieving proper PEX representation and subsequent simulation of the proper representation of the circuit as defined in the layout.


    It is generally recommend that even with a happy face (i.e. clean/CORRECT LVS)

    designers should scrutinize all warnings and all ambiguity before embracing the results as acceptable.


    If you are not using Calibre xL then PEX GROUND NAME and PEX POWER NAME statements are not needed.


    When you see this type of warning from LVS:


          Warning: Ambiguity points were found and resolved arbitrarily.


    if the parts of the circuit identified as having ambiguity and having a match made for them arbitrarily are not being rendered as expected in the PEX results

    and/or are not simulating correctly, it is important to confirm that the problem connections exist in the svdb/*.sp file.  
       

     

    The specific manner that ambiguity is resolved arbitrarily is a likely cause of unexpected results in the analysis of the PEX netlist downstream in the design flow.
      

    Circuit elements involved in the reported ambiguity need to be reviewed due to the arbitrary matching that has taken place. 
        

    For example: the nets in some bit positions in a design could be matching to different bit positions than what is desired in a regular structure,

    like a RAM or a shift register design.  Such issues are able to be resolved by better layout texting which removes the ambiguity in the design.