Stats

  • Locked Locked
  • Replies 7
  • Subscribers 143
  • Views 16133
  • 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

Is it possible to add properties to a layout pcell?

Sheppy

Hi,

This is what I would like to do:

The p-cell code to generate a layout instance must store certain values computed in the code as a property to that instance.

This is simular to someting I have done before: added properties of computed values for a group in layout.

In the code for generating shapes in a layout, I group all the generated shapes together and then add properties to this group. I use the command:

dbCreateProp( topGroupID fieldName fieldType fieldValue )

I want to do the same with a p-cell. The values I want to report are not parameters (I don't want them to be that either), so they should be stored as properties. When an instance is instantiated, upon selecting that instance and hitting the "q" key, I wnat properties to show-up under the properties tab. I tried to do it with the same command like so:

dbCreateProp( pcCellView fieldName fieldType fieldValue )

but this did not work.

Is there any way to get the p-cell code to store certain values as properties to the instance it is creating?

With kind regards,

Sjoerd

Parents
  • Andrew Beckett

    Hi Sjoerd,

    You can't do this. The reason is because the PCell code is evaluated once per variant, not once per instance. So if you have multiple instances with the same pcell parameters, the PCell code only gets evaluated for one of them - the first it encounters. Because of this, it isn't possible for the PCell to reliably have access to the instance - because it would only be one of the instances (I have seen people abusing a certain variable to do this, but it is not safe because it only will impact one instance). Subsequent instances you place would not trigger any re-evaluation of the code (unless the parameters were different), so it wouldn't work. Plus you wouldn't want subsequent opens of the database in future sessions scribbling on parent instances and modifying designs.

    One possibility (but I really don't like this idea, so I'd discourage you from pursuing it) is to store properties on the PCell subMaster (i.e. the pcCellView) and then have a CDF doneProc which copies them across from inst~>master~>propName to CDF properties on the instance (or instance properties). The reason I don't like this is that I thing that modifying properties on an instance in a doneProc is really wrong - you're potentially changing information after the user has seen what he has changed (so this may not be of any use anyway, because the user may not see the properties you want him to see until next time the form is opened), and secondly there are numerous places where the doneProc is not called - so you may end up with inconsistent data.

    You can use labels on the PCell to display information to the user - maybe that would be a better idea? Or you could have a button in the CDF called "Display PCell Info" with a callback that gets the current instance and displays the properties from the PCell master. That might be a bit clunky, because CDF shouldn't really be dealing with instances either - it doesn't know what the instance is necessarily because on the create Instance form you don't have an instance yet but the CDF is still active. So using a separate custom function to inspect the PCell might be better.

    Alternatively, do these calculations in a CDF callback and display the information to the user that way.

    Regards,

    Andrew.

Reply
  • Andrew Beckett

    Hi Sjoerd,

    You can't do this. The reason is because the PCell code is evaluated once per variant, not once per instance. So if you have multiple instances with the same pcell parameters, the PCell code only gets evaluated for one of them - the first it encounters. Because of this, it isn't possible for the PCell to reliably have access to the instance - because it would only be one of the instances (I have seen people abusing a certain variable to do this, but it is not safe because it only will impact one instance). Subsequent instances you place would not trigger any re-evaluation of the code (unless the parameters were different), so it wouldn't work. Plus you wouldn't want subsequent opens of the database in future sessions scribbling on parent instances and modifying designs.

    One possibility (but I really don't like this idea, so I'd discourage you from pursuing it) is to store properties on the PCell subMaster (i.e. the pcCellView) and then have a CDF doneProc which copies them across from inst~>master~>propName to CDF properties on the instance (or instance properties). The reason I don't like this is that I thing that modifying properties on an instance in a doneProc is really wrong - you're potentially changing information after the user has seen what he has changed (so this may not be of any use anyway, because the user may not see the properties you want him to see until next time the form is opened), and secondly there are numerous places where the doneProc is not called - so you may end up with inconsistent data.

    You can use labels on the PCell to display information to the user - maybe that would be a better idea? Or you could have a button in the CDF called "Display PCell Info" with a callback that gets the current instance and displays the properties from the PCell master. That might be a bit clunky, because CDF shouldn't really be dealing with instances either - it doesn't know what the instance is necessarily because on the create Instance form you don't have an instance yet but the CDF is still active. So using a separate custom function to inspect the PCell might be better.

    Alternatively, do these calculations in a CDF callback and display the information to the user that way.

    Regards,

    Andrew.

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.