• 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. How to set CDF to let both .subckt and .model work?

Stats

  • Locked Locked
  • Replies 5
  • Subscribers 125
  • Views 15434
  • 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

How to set CDF to let both .subckt and .model work?

YG screen name
YG screen name over 13 years ago

Hi,

    I will create a mos pcell. There are two kinds of simulation model for the mos, one is subcircuit type(.subckt), the other is model type(.model). I want to know how to set CDF parameters for the mos cell in order to make the hspiceD simulator run correctly under both types.

    I know that the simulator parameter namePrefix is "X" for subcircuit type, and "M" for the model type. They are different. If I create only one cell, its parameter namePrefix is either "X" or "M". So I have to create two cells to adapt two types.  When I change the model type from one to the other, I have to modify the mos cell name in the schematic. If the amount of mos is large, it will not be a good idea.

   Is there any way supporting the two types of model to create only one cell to simulate the mos?

  • Cancel
  • Andrew Beckett
    Andrew Beckett over 13 years ago

    One idea is to use view-specific CDF. Create a copy of the stop view for the device (hspiceD normally - I called it "hspiceD_subckt").

    Then define the view-specific CDF (no GUI for this; you have to use SKILL):

    lib="gpdk090"
    cell="nmos1v"
    stopView="hspiceD_subckt"
    almSetNamePrefix(lib cell "X" ?view stopView)
    ; copy the terminal list and parameter list from the standard CDF simInfo:
    almSetTerminalList(lib cell almGetTerminalList(lib cell ?tool "hspiceD") ?view stopView)
    almSetParameterList(lib cell almGetParameterList(lib cell ?tool "hspiceD") ?view stopView)
    ;; may need some of the other alm functions - see the documentation

    Then when you use the device you can either use the hierarchy editor to define "hspiceD_subckt" as another stopping view, and pick the instances that you want to be netlisted as instances by setting their view to use to be "hspiceD_subckt". Or in ADE (if you're not using a config) you can simply alter the switch list order (Setup->Environment - put "hspiceD_subckt" before "hspiceD", and add "hspiceD_subckt" to the stop list).

    I'm assuming here that your default simInfo will netlist as "M" prefix, and the code above will define the new view as netlisting as "X".

    If you are using spectre as the simulator, you don't have to do any of this messing around, since it does not use the instance name to determine the component type - it doesn't matter whether you are instantiating a built-in primitive, a model, a VerilogA module or a subckt - they all look the same as far as the instance is concerned.

    Regards,

    Andrew.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • YG screen name
    YG screen name over 13 years ago

    Hi,  Andrew

      Thanks very much. It works perfectly now!

      I have another question like above. One cell has only one auCdl setting whose parameters have only one value. Can I create only one cell but export several types of CDL netlist? For example, I have a resistor cell, and the different instances of the cell can be exported to different types like below:

      RR1 net1 net2 10*r1 $[R_NP]

      RR2 net3 net4 10*r1 $[R_PP]

      R_NP and R_PP are controled by another CDF parameter. They are set by modelName in auCdl setting, but one cell has only one modelName value. How to set auCdl or other settings to make that different instances of one cell have different modelname value?

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

    Assuming that the netlist procedure for auCdl is ansCdlCompPrim (or one of the similar variants), then this can be done if you have "model" in the instParameters. In my case I didn't particularly want to use the simulation model, so what I did was create a CDF parameter called "cdlModel" and then add this in the simInfo:

    instParameters: m W L model
    propMapping: nil L l W w model cdlModel

    (this was for a MOSFET, but should be similar for other devices).  Then whatever value I put in the cdlModel parameter gets netlisted out as the model name (subtype name) in the CDL netlist.

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • YG screen name
    YG screen name over 13 years ago

    Hi Andrew,

        Thanks for your reply. All of above have been solved.

        Another question about trigger function is whether I can set my own function as a trigger function before any window menu trigger function. For example, I want to add a function before ADE "RUN" trigger function.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 13 years ago
    It's generally a good idea to ask each new question in a new thread, so that it's clearer to anyone reading it, and particularly to anyone searching the community when looking to ask a similar question.

    Anyway, in ADE L there's no public trigger mechanism. There is a way to trigger when ADE starts (there's a cdsenv for this - which there's a solution for, I believe).

    For what you want, you could have customized menu files, as described in <ICinstDir>/tools/dfII/etc/tools/menus/README to alter what gets called when you hit the Run button or menu.

    Or you could use the solution below to trigger when netlisting is done:

    http://support.cadence.com/wps/mypoc/cos?uri=deeplinkmin:ViewSolution;solutionNumber=11586260

    If using ADE XL there is a trigger mechanism, using axlSessionConnect() and you could define a "preRun" trigger (see the manual for more details).

    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