• 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. How to automatically store technology version on instance...

Stats

  • Locked Locked
  • Replies 17
  • Subscribers 144
  • Views 19110
  • 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 automatically store technology version on instance in schematics and layout?

Sheppy
Sheppy over 9 years ago

Hi,

I'd like to store the version number of the PDK on an instance when this instance is instantiated in schematic or layout. I need this in order to be able to check with which version of the PDK a particular design has been made. Later, I will create a script that hierarchically checks all instances of a given design, and reports the used versions. This will then be a script run at tape-out to ensure all devices are generated with the correct (latest) PDK version.

It could be done by adding a parameter with the version number as value to the CDF, like this:

cdfCreateParam( cdfId
        ?name           "PDK_version"
        ?prompt         "PDK Version"
        ?defValue       "x.y.z"
        ?type           "string"
        ?display        "t"
        ?editable       "nil"
        ?storeDefault   "yes"
)

However, if the PDK gets updated, the version number will be increased, which would mean, with this implementation, that the CDF of all cells in the library have to be updated to the new version. Of course, this could be automated, but i would like to use a different approach.

The version of the PDK which is loaded in Virtuoso is stored in an environment variable called TECH_VERSION. It can be retrieved by doing:

getShellEnvVar( "TECH_VERSION" )

What I would like to happen is that when the instance is instantiated, the value of TECH_VERSION is automatically stored in the CDF parameter PDK_version. Something like this doesn't work:

cdfCreateParam( cdfId
        ?name           "PDK_version"
        ?prompt         "PDK Version"
        ?defValue       "getShellEnvVar( \"TECH_VERSION\" )"
        ?type           "string"
        ?display        "t"
        ?editable       "nil"
        ?storeDefault   "yes"
)

This would simply put the text "getShellEnvVar( "TECH_VERSION" )" as value in the "PDK_version" field.

An other solution could be by putting some code in a call-back procedure that puts the version number in the parameter value. However, this only works when this call-back procedure is triggered. If a default device is instantiated, with no modifications to its parameters, the call-back will not be triggered, thus the version number will not be set.

So, I think this has to be a post-instantiation trigger. And I don't know how to do that properly. Any help is highly appreciated.

If an other solution is possible, I would surely like to know that as well.

Thanks in advance.

With kind regards,

Sjoerd

  • Cancel
  • Sheppy
    Sheppy over 9 years ago
    Hi Yi, I can confirm your results, it doesn't work. I might have to look for an other solution... Thanks for your suggestions. Kind regards, Sjoerd
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • fatcat1206
    fatcat1206 over 9 years ago

    Hi Sjoerd

    I consider another approach: "Hacking the callback function of "Add Instace" form".

    the original callback function of the "Add Instance form" can be retrieved by viewing the form property.

    If we can hack the callback, add the our own script in (adding the PDK version in your case). It might be an work around.

    For hacking the callback, see the post below. Sorry that I do not find a time to try it out.

    Adrian Nistor
    Trigger for refreshing technology information
    Hi, We are using incremental techfiles, for some technical reasons we can not use leSetLSW to set the order of the layers, so we have the problem that the layer order is not anymore the needed one. …
    By Adrian Nistor over 9 years ago in Cadence Technology Forums > Custom IC SKILL
    3 replies
    Latest by dmay over 9 years ago

    Best Regards

    Yi

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Sheppy
    Sheppy over 9 years ago

    Hi Yi,

    Very interesting solution to their problem, Never thought of "hijacking" a standard form.

    I have tested it, but it doesn't work. It doesn't work with specifying a different _doneAction procedure. The problem is: the form for creating a new instance does not have an "OK" button, so the form is never "done". I haven't found an other entry in the form that gets triggered once an instance has been created (by clicking in the layout/schematics window). Just for reference, below the code I tested.

    procedure( spdkHiCreateInst()
        let( (  ( port nil )
            ( fileName "/tmp/spdkHiCreateInst.il" ) )
            port = outfile( fileName )
            fprintf( port "leHiCreateInst()\n" )
            fprintf( port "leCreateInstForm->_doneAction = \"spdkHiCreateInstCB()\"" )
            close( port )
            load( fileName )
            sh( strcat( "rm -f " fileName ) )
        ) ;;; end of let
    ) ;;; end of procedure spdkHiCreateInst

    procedure( spdkHiCreateInstCB()
        let( ()
            ;;; Call the original callback...
            finishEnterFun()
            ;;; And the custom part...
            printf( "Done!\n" )
        ) ;;; end of let
    ) ;;; end of procedure spdkHiCreateInstCB

    hiSetBindKey( "Layout" "<Key>I" "spdkHiCreateInst()" )

    The code (the procedure spdkHiCreateInst) is working. When I do the lines below with the form still open, it is showing that the _doneAction is set to my custom callback.

    f=hiGetCurrentForm()

    formStruct@0x16edd3e0

    f->_doneAction

    "spdkHiCreateInstCB()"

    This is identical to:

    leCreateInstForm->_doneAction

    "spdkHiCreateInstCB()"

    Although it is not working in this particular case,  I'll keep this solution, might be useful for some other problem.

    Thanks for all your suggestions.

    With kind regards,

    Sjoerd

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • fatcat1206
    fatcat1206 over 9 years ago

    Hi Sjoerd

    Sorry to see it fails again.

    I also tried it out, and have the same results as you.

    You may right about why such solution fails.


    I made some experiments, the "finishEnterFun()" seems to serve the same functions as pressing "Esc" key while the form is called.

    You may give a try to see whether "Done!" has been printed out with "Hacked callback" while pressing "Esc" to quite the "Add Instance" form

    The actual procedure for adding the instance might be "_handleBindKey(...)", see the screen shot below.

    Schematic editor always shows the corresponding API for the mouse button.

    Things might go really complicated. By looking at the name of the API, this private function should sever a lot of purpose.

    (Just tried the bindkey "Z" for zooming, it's the same API for LMB :(  )

    We may need to find something else.

    Best Regards

    Yi

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

    I wouldn't suggest any of this level of hacking. It's likely to end in tears (especially when something unexpected changes in our code because you're using private APIs or relying on altering the standard behaviour of the tools).

    Unfortunately this isn't straightforward to solve, because you can't really distinguish between an old instance which never had the property (i.e. before it was added to the CDF) and a new device just created with create instance. One way to solve this is to determine if you're in a create instance command, which is what the approach below does - utilising getCallingFunction to look up the call stack to see if you are called within a create instance command from either layout or schematic. Hopefully this does what you want?

    procedure(CCFinCreateInst()
        let(((level 0) (funcPat pcreCompile("^(sch|le)HiCreateInst$"))
            func found)
            while(!found && level<20
                func=getCallingFunction(level++)
                found=pcreExecute(funcPat func||"")
            )
            found
        )
    )
    
    procedure(myInitProc(cdf)
        when(CCFinCreateInst() && blankstrp(cdf->PDK_version->value)
            cdf->PDK_version->value="1.1"
        )
    )

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Sheppy
    Sheppy over 9 years ago

    Hi Andrew,

    Thank you for this solution, it does exactly what I want.

    Now I have only one more thing to get working too: when an instance is created using a script, by using the dbCreateParamInst(), I want to automatically store the PDK version as well. I tried to register a trigger like Yi suggested, but that doesn't work. There is not a valid trigger for creating an instance using the dbCreateParamInst() function.

    What I have done now is adding a bit of code to the callback procedure that handles all parameter input. When after the creation of an instance the CCSinvokeInstCdfCallbacks() is called, it will look in the stack to see whether or not it was called from that procedure and then updates the PDK version parameter. This works, but if run on an old cellview, it will update the PDK version parameter on old instances as well. So far I haven't found a solution to get around this. What I think I need is a trigger after an instance is created.

    With kind regards,

    Sjoerd Herder

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

    Sjoerd,

    Unfortunately there is no trigger for dbCreateInst or dbCreate.* in fact. You have to call any relevant function yourself.

    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