Stats

  • Locked Locked
  • Replies 10
  • Subscribers 126
  • Views 16114
  • 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

Assura LVS using: setenv OA_UNSUPPORTED_PLAT linux_rhel40_gcc44x

bartman

I am having an LVS problem and I noticed this post.  I am not sure if anyone is still around (based upon the 2010 responses) to reply.

At the end of the lvs report I have the following message:

Preprocessing layout network phase 2
*ERROR* Device 'pfet(Generic)' on Schematic is unbound to any Layout device.
*ERROR* Device 'nfet(Generic)' on Schematic is unbound to any Layout device.
*ERROR* UnBound devices found.
Info: All devices must be bound or filtered for comparison to be run.
Exiting nvn.

It implies that I have devices in the schematic which cannot be matched to a layout device.  I have tried this in calibre and succeeded in getting a clean LVS; so I know the layout and schematic do match.  I would like to have assura working as well.  One possible issue is in the use of multiplicity; m>1 for every transistor in the schematic.   The LVS checks using assura for devices which have m=1 have worked.  Is it possible to fix this problem ?

alan

Parents
  • Quek

    Hi Alan

    Maybe we should just focus on the parameter mismatch issue for now. From the LVS report, we can also tell that the final number of devices that are being compared is the same for both schematic and layout:

    Match Statistics
    ================ Total Unmatched
    Cell/Device schematic layout schematic layout
    (nfet) Generic 0 0 0 0
    (nfet_m0) Generic 8 8 0 0
    (pfet) Generic 0 0 0 0
    (pfet_m0) Generic 9 9 0 0
    (subc) Generic 1 1 0 0
     ------ ------ ------ ------
    Total 18 18 0 0

    This means that the current parameter mismatch is not caused by the failure to expand schematic mFactored devices. My guess is that the rule deck is trying to compare totalNF and totalW but the CDF setup for auLvs is such that only finger NF and finger W are being exported. Hence this resulted in the parameter mismatch. You can examine the actual compare procedure in the compare rules file (e.g. compare.rul) to confirm this.


    Fullscreen test.txt Download 
    This is a test



    Best regards
    Quek

Reply
  • Quek

    Hi Alan

    Maybe we should just focus on the parameter mismatch issue for now. From the LVS report, we can also tell that the final number of devices that are being compared is the same for both schematic and layout:

    Match Statistics
    ================ Total Unmatched
    Cell/Device schematic layout schematic layout
    (nfet) Generic 0 0 0 0
    (nfet_m0) Generic 8 8 0 0
    (pfet) Generic 0 0 0 0
    (pfet_m0) Generic 9 9 0 0
    (subc) Generic 1 1 0 0
     ------ ------ ------ ------
    Total 18 18 0 0

    This means that the current parameter mismatch is not caused by the failure to expand schematic mFactored devices. My guess is that the rule deck is trying to compare totalNF and totalW but the CDF setup for auLvs is such that only finger NF and finger W are being exported. Hence this resulted in the parameter mismatch. You can examine the actual compare procedure in the compare rules file (e.g. compare.rul) to confirm this.


    Fullscreen test.txt Download 
    This is a test



    Best regards
    Quek

Children
No Data

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.