How to automatically store technology version on instance in schematics and layout?

Hi Sjoerd

can you try this:

cdfCreateParam( cdfId

       ?name           "PDK_version"

       ?prompt         "PDK Version"

       ?defValue       getShellEnvVar("TECH_VERSION" )

       ?type           "string"

       ?display        "t"

       ?editable       "nil"

       ?storeDefault   "yes"

)

As you put the getShellEvnVar() functions into the quotation marks, then it has been treated as string.

Best Regards

Yi

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

Hi Sjoerd

You are right, with what I propose there, the PDK_version is indeed hard copied.

Sorry that I misunderstood your example, I used think you want to use getShellEnvVar() for the default value.

I am thinking the same way as you did. A post trigger call back is needed after the instantiation.

Is that possible to add an extra call back when "Add Instance" form is closed?

Then we may update the PDK version there.

There are might be some issues when the instance is not added via calling the "Add Instance" form.

We may deal it later.

Best Regards

Yi

Hi Sjoerd,

Look in the documentation for "formInitProc" - this is a procedure that is automatically called when the Create Instance or Edit Object Properties form is displayed - you could use this to set/update the PDK_Version CDF property. You could use a 'doneProc' too, but I think I would look at the formInitProc first.

Hopefully this will help you.

Best regards,

Lawrence.

Hi Lawrence,

Thanks for your reply, and pointing me in the right direction. Both of the options llok very promissing after reading a bit. I think the doneProc would work best for me.

I'm going to do some tests with both to see what happens if I open a cell with instances of a previous PDK, that do not have the "PDK_version" parameter, and then open the "Edit Parameters Form", and see how that works out. Code I put in the procedure for "doneProc" or "formInitProc" should check and handle accordingly for a situation like that.

I'll update this post with my solution.

With kind regards,

Sjoerd

Hi Sjoerd

Wish you success for the solution, and really looking for it.

It's a coincident that one of my colleagues asked for a procedure which can ban certain instance being instantiated today.

I am thinking, I may reuse your framework.

Instead of putting the PDK version into cdf parameters, I can do a check and somehow break the procedure of instantiating or delete such instance after instantiating.

Best Regards

Yi

Hi Lawrence,

Using both CDF options I can get the version number into the parameter. However, there is one huge drawback by using this: if I select an  instance which is created using an older version (that may or may not have the parameter set) upon looking at its properties (hitting the "q" key) and changing one parameter, the version number gets updated. This is something I don't want to happen. If it is not set, it should keep it untouched.

This is what I added to the CDF parameter file:

This is the code of the "doneProc" procedure:

What I think I need is a method to know how the procedure was triggered. I mean: was it triggered after instantiating a new device, or after any of the parameters were changed from an "Edit Object Properties Form". If I am able to determine this, it is easy to define whether or not the parameter must be updated.

Do you know a method of doing that?

With kind regards,

Sjoerd

Hi Sjoerd

I am thinking that the triggering of the procedure is not through initProc or donePorc of the CDF parameter.

We may use triggering functions calls via event.

The corresponding API is "ddRegTrigger()", and considering your case, the trigger name "PostCreateObj" might be an good option.

You may check the "cadence design framework II skill functions reference" for the details.

Best Regards

Yi