Stats

  • Replies 4
  • Subscribers 125
  • Views 97
  • Members are here 0

PVS LVS not flagging device W/L mismatches in gpdk045 (IC23.1 / PVS 23.11)

RK202509013321

Hello,

I am a teaching assistant for an IC design course, and I’m currently migrating our design flow to Cadence IC23.1 / PVS 23.11 with the gpdk045 PDK.

I have successfully run DRC and LVS. LVS reports as MATCH when connectivity and pins line up, but I noticed something strange:

  • If I deliberately change the device size (e.g., double the PMOS width in the schematic while keeping the layout the same), LVS still reports clean.

  • I expected LVS to flag a mismatch on the device width.

Environment details:

  • Virtuoso: IC23.1 (cadence/2024-08)

  • PVS: 23.11-s036

  • PDK: gpdk045_v_5_0

  • Rule deck: pvlLVS.rul

  • LVS run invoked from Virtuoso → Verify → PVS → LVS

What I tried so far:

  • Verified that LVS_CHECK_PROPERTY lines exist in the rule deck for MOS devices, e.g.:

    LVS_CHECK_PROPERTY MN ( g45n1svt ) l l -tolerance 0; LVS_CHECK_PROPERTY MN ( g45n1svt ) w w -tolerance 0;

  • Ensured I am generating the CDL netlist..

  • Tried both flattened and unflattened PCells.

  • Examined the comparison report (.cls file) — it shows devices matched, but parameters are not being compared.

Question:
Is there an additional option, switch, or rule deck directive I need to enable so that PVS LVS actually checks W/L mismatches?
Or does this require a specific setup in the PDK rule deck (e.g., mapping properties to schematic parameters)?

Any guidance on enabling strict property checking in PVS LVS would be greatly appreciated.

Parents

  • You might want to update the gpdk version (just for good measure). gpdk045_v_6_0 has been available for quite some time.

    My first port of call for the check would be the netlist.

     runName.cdl (schemaitic netlist)

     runName.spi (layout netlist)

    Check if the values are correct there before you address the comparison rules.

  • in reply to RobMan
    RobMan said:
    You might want to update the gpdk version (just for good measure). gpdk045_v_6_0 has been available for quite some time.

    I'd just checked using gpdk045_v_6_0 and then gpdk045_v_5_0 as Rob suggested; the problem shows up in the older PDK (with the same PVS version you're using). It works correctly with gpdk045_v_6_0. I believe this is because of a change in PVS some time ago, and the rule decks needed to be updated to add additional lvs_map_device rules to map the type from M to MP etc.

    Andrew

Reply
  • in reply to RobMan
    RobMan said:
    You might want to update the gpdk version (just for good measure). gpdk045_v_6_0 has been available for quite some time.

    I'd just checked using gpdk045_v_6_0 and then gpdk045_v_5_0 as Rob suggested; the problem shows up in the older PDK (with the same PVS version you're using). It works correctly with gpdk045_v_6_0. I believe this is because of a change in PVS some time ago, and the rule decks needed to be updated to add additional lvs_map_device rules to map the type from M to MP etc.

    Andrew

Children

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.