• 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 Design
  3. MOS area and perimeter are not calculated from parametrized...

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 125
  • Views 14581
  • 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

MOS area and perimeter are not calculated from parametrized w and l

joliveros
joliveros over 16 years ago

Hi all..

In my design I'm using nmos4 and pmos4 active devices from AMS DKIT 3.70 PRIMLIB library. As shown in the figure, when I try to edit their properties in Virtuoso Schematic, their area and perimeter fields are recalculated for w and l values (and are not editable for that reason). So, there is no problem when I assign numerical values to w and l, but when I parametrize those variables (to do parametric analysis with the Analog Environment or to pass symbols parameters down through design hierarchy with "pPar") the area and perimeter values are miscalculated. In fact, they are not recalculated, and the last calculated numerical values remain fixed regardless the actual value the parameters take. I guess this is really no a Cadence issue, but a DKIT one. However, I need to get around this inconvenient and I don't know how to do that.

Thanks in advance for your help.

  • cad_img.jpg
  • View
  • Hide
  • Cancel
  • Andrew Beckett
    Andrew Beckett over 16 years ago

    Unfortunately this is one of the dangers of CDF callbacks that I describe in sourcelink solution 11223092. This happens all too often in PDKs - insufficient thought is made about how you parameterize things.

    A workaround would be to edit the CDF of the transistors (in the CIW Tools->CDF->Edit CDF, pick the component, and then look down for the fields for ad/as/pd/ps etc, and hit the "Edit" button in the parameters section. You can then make these parameters editable. If you don't have write access to the PDK, you can always make the change in the "Effective" CDF (rather than "Base"). 

    Having made the fields editable, you can replace the fixed numbers on the instances with edit properties, using pPar() with expressions (either based on the pPar() or using iPar() to reference the w and l).

    Regards,

    Andrew.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • joliveros
    joliveros over 16 years ago

     Hi Andrew,

    I modified the "Base" CDF (because I had write access) of the transitors as you suggested and that worked fine for the issue.

    However, it's not clear to me where these modifications are saved. I read CDF documentation and now I know there are 3 CDF types: Base, User and Effective. If I edit Effective CDF, those changes are lost when I close the cadence session, User and Base (having write access) CDF are effectively saved though.The place where they are saved (or how to save and recall them) is what I am missing. Previous issue is important to me because I am planning to move from dkit AMS 3.70 (with IC51.41) to 4.00 (with IC6.10), and I want to keep my previous work (assuming that AMS 4.00 still has the callbacks problem related to your sourcelink solution).

    Can I really keep my previous CDF modifications when moving to next dkit version? I think that now I have to move the previous Base CDF modifications to User CDFs (and discover how to save and reuse them) in order to be able to applying them to the new version dkit User CDFs, is that correct?

    What else do I need to take into account to do this Cadence and Dkit moving?

    How do I convert my CDBs to the new OpenAccess platfform?

    Thanks in advance !!

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 16 years ago

    Base CDF is saved in the cell's prop.xx (or data.dm in OpenAccess-based releases) or library's prop.xx (or data.dm) if it is library CDF rather than cell CDF. This is the "property bag" used for cell and library meta data.

    User CDF is not saved to disk. Effective CDF is just the Base CDF masked by User CDF; any changes you make to the Effective CDF are actually stored in the User CDF.

    You could dump the CDF using the SKILL cdfDump() function. You should be careful though within dumping it and loading it to the new PDK, because you may lose additional parameters which have been added in the new PDK. So you may be better off doing a cdfDump() from both your modified PDK, and the new PDK, and comparing them (with diff?) to see what changed.

    Migrating a design to  OpenAccess is relatively straightforward; there's a utility in the Tools->Conversion Toolbox in IC613 to do this (or you can use cdb2oa at the command line). You should read the Virtuoso Design Environment Adoption Guide in cdnshelp in IC613, which can also be found at <IC613instDir>/doc/dfoaAdopt/dfoaAdopt/pdf . If you're going to do this, you'll be best if the PDK you're going to use is developed/supported on IC613, because migrating a PDK yourself is not something we would normally recommend (although in many cases it works fine).

    Regards,

    Andrew.

    • 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