Eliminating noxref items from Calibre xRC netlists for backannotation flows

Version 1

    If you are in the parasitic extraction and analysis stage of your design flow and are using Calibre xRC

    and you receive warnings such as the following in certain third party downstream analysis tools:

     

         \o WARNING: Schematic instance 34/446/M0_noxref not found.     
         \o WARNING: Schematic instance 38/31/M0_noxref not found.

     

    You can take steps to eliminate the"noxref" named items causing such warnings.

     

    To eliminate noxref items choose either SOURCEBASED or SCHEMATICONLY for naming of devices and nets in the output netlist from Calibre parasitic extraction.   These two choices produce a parasitic netlist from Calibre xRC based on the SOURCE network.  Such a netlist will not contain any noxref items.  SCHEMATICONLY is the preferred choice as it contains layout device properties giving a more accurate result than the other choices.

     

    Layout parasitic netlists used in backannotation flows need to fully align with the schematic data on both a device and net basis for the backannotation to be successful.

     

    Often there are devices and nets in the layout that are not explicitly in the schematic.  In Calibre xRC netlists these will appear with "noxref" in their names.  This simply means that there is no cross-reference in the schematic dataset for this "noxref" named item in the layout dataset.  An example of this would be several intentional resistors in series in the layout corresponding to one resistor in the schematic.  In this case some of the devices in the layout parasitic netlist will have noxref in their names as will some of the connecting nets in the series chain i.e. those devices and nets that only appear in the layout,

     

    The following two settings only affect the generation of parasitic models for the noxref nets.

    These settings will not remove the noxref net nets or devices from the netlist.

     

    Prior to v2009.1 release:

       setenv PEX_FMT_NOXREF_MODEL_MODE  {KEEP | NONE }

     

    Release v2009.1 and following:

       PEX NETLIST NOXREF NET NAMES {YES | NO }

     

    Noxref devices and nets also affect the CalibreView flow:

     

    In this flow, the step that creates the view performs consistency checking   

    with the schematic as it renders the calibreview.

     

    If there are any noxref devices or nets in the parasitic netlist from Calibre xRC,      

    you will see messages similar to these:     

     

       rick@miles [191]: grep -n -i noxref CDS.log     

       1419:\o WARNING: Schematic instance X4/M0_noxref not found.    

       1436:\o WARNING: Schematic net      N_121_noxref not found.    

       rick@miles [192]:          

        

    The presence of "_noxref" named items in the output from Calibre xRC     

    (from the "Run PEX" in Calibre Interactive)    

    indicates that the netlist produced from Calibre Interactive     

    is based on the layout network instead of the source network.    

        

    In Calibre Interactive on the "Outputs" panel    

    on the "Netlist" tab there is a button called:     

        

        Use Names From:  ______________    

     

     

     

    There are four choices presented:    

     

       [1] SCHEMATIC       

       [2] LAYOUT    

       [3] SOURCEBASED    

       [4] SCHEMATICONLY     

        

    You can think of a netlist as containing three separate parts:    

    the network, the names, the device properties.    

        

       

    The SOURCE netlist contains:      

       

        source network:                    S1    

        source names:                     S2    

        source device properties:       S3      

        

    The LAYOUT netlist contains:     

        

        layout network:                   L1    

        layout names:                     L2    

        layout device properties:      L3    

        

    The four choices then render the following:    

        

       [1] SCHEMATIC                L1, S2, L3    

       [2] LAYOUT                      L1, L2, L3    

       [3] SOURCEBASED          S1, S2, S3    

       [4] SCHEMATICONLY       S1, S2, L3    

        

        

    Choices [1] and [2] render a netlist based on the layout network (L1).    

        

    Since these first two choices render the network from the LAYOUT    

    the output netlist from Calibre xRC will contain "_noxref" items if they exist.     

        

    Choices [3] and [4] render a netlist based on the source (schematic) network (S1).    

    There should never be any "_noxref" items in a netlist from choice [3] or [4].    

        

    In running the calibreview flow:    

      If the layout has devices, instances, or nets   

      that do not appear in the source for any reason, (i.e. _noxref items frequently due to parallel or serial intentional device reduction, for example)    

      you need to choose either [3] or [4] in generating the output netlist from Calibre xRC.     

        

    This will insure that you will not get anything with "_noxref" in its name in the parasitic netlist.    

        

    It will then avoid Warnings like these, and any issues that may arise from them:    

                      

       rick@miles [191]: grep -n -i noxref  my-downstream-analysis-tool.log     

       1419:\o WARNING: Schematic instance X4/M0_noxref not found.    

       1436:\o WARNING: Schematic net      N_121_noxref not found.    

       rick@miles [192]:    

        

    It is recommended to choose SCHEMATICONLY to get the best netlist for the calibreview flow,    

    as the device properties will then be computed from the layout, but the network and namings will be

    from the source.    

        

    In an extraction based on a UNIX run script i.e. a batch run, the PEX NETLIST rulefile statement needs to contain either the SOURCEBASED or SCHEMATICONLY keywords to eliminate the noxref items from the resulting parasitic netlist.   Please consult the SVRF Manual for more detail.

     

    This should help clarify these netlist content choices and their possible impact on the flow.