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

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

Parents

  • Hi Yi,

    Thank you for your reply.

    Unfortunately, this solution is not working for me. This solution will hard-code the PDK version in the CDF, it will not make it "dynamic". When the file with the CDF parameters is loaded, the line you proposed (see quote below), will simply be evaluated and results in a hard-coded version number in the "PDK_version" parameter.

    Unknown said:
    ?defValue       getShellEnvVar("TECH_VERSION" )

    This is not what I want to achieve.

    I want that when the cell is instantiated, it will then store the value of "TECH_VERSION" in the parameter "PDK_version".

    Just imagine the following:

    The current version of the PDK is 5.5.5 (= TECH_VERSION), and I have a cell called NMOS. I make a change to the PDK which is totally unrelated to the cell NMOS (maybe a start-up sequence change, or something completely different). The "TECH_VERSION" will be incremented to 5.5.6. If I do what you propose, and I instantiate the NMOS in a cell using the 5.5.6 version, it will still store 5.5.5 as the value for "PDK_version". In order to have that fixed, I have to re-load the CDF pararmeters SKILL file (the one with the cdfCreateParam statements in it) to set it to the correct version. This extra step, which has to be performed every time a new PDK is compiled, is what I don't want to do.

    What I want: regardless of what changes in the PDK, once a cell (i.e. NMOS) is instantiated, it stores the value of the "TECH_VERSION" in the "PDK_version" parameter. So even if the CDF parameters of the NMOS are not reloaded, it will still store the version of the PDK the cell was instantiated. Since it has to work on default devices too (devices for which none of the parameters change from the default thus not triggering the call-back procedure) I think it has to be a post-instantiation triggered call-back.

    With kind regards,

    Sjoerd

Reply

  • Hi Yi,

    Thank you for your reply.

    Unfortunately, this solution is not working for me. This solution will hard-code the PDK version in the CDF, it will not make it "dynamic". When the file with the CDF parameters is loaded, the line you proposed (see quote below), will simply be evaluated and results in a hard-coded version number in the "PDK_version" parameter.

    Unknown said:
    ?defValue       getShellEnvVar("TECH_VERSION" )

    This is not what I want to achieve.

    I want that when the cell is instantiated, it will then store the value of "TECH_VERSION" in the parameter "PDK_version".

    Just imagine the following:

    The current version of the PDK is 5.5.5 (= TECH_VERSION), and I have a cell called NMOS. I make a change to the PDK which is totally unrelated to the cell NMOS (maybe a start-up sequence change, or something completely different). The "TECH_VERSION" will be incremented to 5.5.6. If I do what you propose, and I instantiate the NMOS in a cell using the 5.5.6 version, it will still store 5.5.5 as the value for "PDK_version". In order to have that fixed, I have to re-load the CDF pararmeters SKILL file (the one with the cdfCreateParam statements in it) to set it to the correct version. This extra step, which has to be performed every time a new PDK is compiled, is what I don't want to do.

    What I want: regardless of what changes in the PDK, once a cell (i.e. NMOS) is instantiated, it stores the value of the "TECH_VERSION" in the "PDK_version" parameter. So even if the CDF parameters of the NMOS are not reloaded, it will still store the version of the PDK the cell was instantiated. Since it has to work on default devices too (devices for which none of the parameters change from the default thus not triggering the call-back procedure) I think it has to be a post-instantiation triggered call-back.

    With kind regards,

    Sjoerd

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.