• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC SKILL
  3. auCdl Netlist LVS Naming Conflict

Stats

  • Locked Locked
  • Replies 2
  • Subscribers 143
  • Views 10733
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

auCdl Netlist LVS Naming Conflict

Kevin Buck
Kevin Buck over 3 years ago

I've written a SKILL script that generates a wrapper cell for a digital cell library. The original library uses global power/ground nets and I'm generating a new library that adds explicit schematic pins. The basic operation is: create a new schematic and instantiate the old symbol with netSet properties for the global supply nets with additional pins for the supply nets. Copy the old symbol and add the additional supply pins. Generate an empty layout, instantiate the old cell within it and overlay it with the new pins and pin labels. This is all working as expected, when I do the verification there is an LVS error that there is a mismatch between the layout and the schematic. I've found that the problem is the PVS tool does not like that the wrapper schematic and the instantiated cell have the same name and it breaks the verification even though they are in different libraries. The tool adds a suffix to the wrapper cell _schematic that somehow makes it recognize the name of the power (vdd018) and ground (vss018) nets in the PVS tool as inh_dig_vdd and inh_dig_vss respectively (theses are the names of the power/ground nets in the subcircuit when generating an auCdl netlist, they are vdd! and gnd! in the drawn schematic). If I copy the newly generated cell and re-name it then I get a matching LVS confirmation. Below I've copied both auCdl netlists, the first netlist is the one that fails LVS and the second netlist passes LVS. I'm not sure if this is the expected behavior or if this is a bug.

LVS Failing Netlist

************************************************************************
* auCdl Netlist:
*
* Library Name: test_lib_ana_lv
* Top Cell Name: INV_X0d5
* View Name: schematic
* Netlisted on: Nov 30 15:23:41 2021
************************************************************************

*.BIPOLAR
*.RESI = 2000
*.RESVAL
*.CAPVAL
*.DIOPERI
*.DIOAREA
*.EQUATION
*.SCALE METER
*.MEGA
.PARAM

************************************************************************
* Library Name: test_lib
* Cell Name: INV_X0d5
* View Name: schematic
************************************************************************

.SUBCKT INV_X0d5 A Q inh_dig_vdd inh_dig_vss
*.PININFO A:I Q:O inh_dig_vdd:B inh_dig_vss:B
MM_i_0 Q A inh_dig_vss inh_dig_vss MN W=600n L=150n
MM_i_1 Q A inh_dig_vdd inh_dig_vdd MP W=870n L=150n
.ENDS

************************************************************************
* Library Name: test_lib_ana_lv
* Cell Name: INV_X0d5_schematic
* View Name: schematic
************************************************************************

.SUBCKT INV_X0d5_schematic A Q vdd018 vss018
*.PININFO A:I vdd018:I vss018:I Q:O
XINV_X0d5 A Q vdd018 vss018 / INV_X0d5
.ENDS

LVS Passing Netlist

************************************************************************
* auCdl Netlist:
*
* Library Name: test_lib_ana_lv
* Top Cell Name: TEST
* View Name: schematic
* Netlisted on: Nov 30 16:56:28 2021
************************************************************************

*.BIPOLAR
*.RESI = 2000
*.RESVAL
*.CAPVAL
*.DIOPERI
*.DIOAREA
*.EQUATION
*.SCALE METER
*.MEGA
.PARAM

************************************************************************
* Library Name: ohc15l_digital
* Cell Name: INV_X0d5
* View Name: schematic
************************************************************************

.SUBCKT INV_X0d5 A Q inh_dig_vdd inh_dig_vss
*.PININFO A:I Q:O inh_dig_vdd:B inh_dig_vss:B
MM_i_0 Q A inh_dig_vss inh_dig_vss MN W=600n L=150n
MM_i_1 Q A inh_dig_vdd inh_dig_vdd MP W=870n L=150n
.ENDS

************************************************************************
* Library Name: test_lib_ana_lv
* Cell Name: TEST
* View Name: schematic
************************************************************************

.SUBCKT TEST A Q vdd018 vss018
*.PININFO A:I vdd018:I vss018:I Q:O
XI1 A Q vdd018 vss018 / INV_X0d5
.ENDS

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 3 years ago

    I'm assuming the issue here is that you're at the mercy of the renaming rules in the CDL netlister, and you want the top-level cell to be the one that gets the original name without a suffix to distinguish it from the other. This should only be an issue if you're LVSing the cell as the top level.

    This article shows how you can alter the renaming rules to ensure that the top level doesn't get renamed:

    auCDL: If use same cellname from multiple libraries, how to get top level to netlist with just cellname

    Regards,

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 3 years ago

    I'm assuming the issue here is that you're at the mercy of the renaming rules in the CDL netlister, and you want the top-level cell to be the one that gets the original name without a suffix to distinguish it from the other. This should only be an issue if you're LVSing the cell as the top level.

    This article shows how you can alter the renaming rules to ensure that the top level doesn't get renamed:

    auCDL: If use same cellname from multiple libraries, how to get top level to netlist with just cellname

    Regards,

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
  • Kevin Buck
    Kevin Buck over 3 years ago in reply to Andrew Beckett

    Thank you for the reply, adding the linked procedure to the .simrc file fixes this problem.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information