Stats

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

Can a cell-level CDF stay with its cell, regardless of library?

caver456

In order to add control to pcell parameters in the edit parameters GUI (i.e. make a cyclic field, change the parameter display text, etc) I understand you need to use CDF.  (Interesting that this support case uses the wording that CDF is "the best method"... that implies there's another way... is that true?) - CDF works nicely, but, it looks like a base-cell-level CDF still depends on the library it was created with, i.e. if you copy that cell to a different library that doesn't have the same CDF, then the pcell edit parameters form will use the default display (i.e. actual pcell parameter names as the field labels; no cyclic fields; etc).  One post mentions that you can copy the CDF of the cell along with the cell itself by using ccpCopy but that seems pretty cumbersome and I didn't get it to work as expected.

The CDF docs seemed to indicate you could attach a CDF to a cell only, but maybe I'm misunderstanding?  Based on all of the above, it looks like a cell-only CDF is only valid for that cell when it is in the library specified in the cdfCreateBaseCellCDF command?

In other words, is there a way to get a nice clean modular independent pcell along with the user-friendly edit parameters form fields, such that the cell can be copied to any library and still work and look the same?

Parents

  • The cell-level CDF is not specific to the library it was created with; if you copy the cell to another library, the CDF would go with it and it should still work. The only exception would be if you had any CDF callbacks which explicitly coded the library name into the callback - but there really shouldn't be a need to do that.

    Even if you copy (via the library manager) just the cellView (e.g. just the layout view) the default behaviour would be to copy the cell CDF (i.e. the cell's data.dm) too; there are settings in the Edit->Copy Preferences form that change this behaviour and these can be controlled in the .cdsenv too (this is in the Library and Cell Property Files section). You do need to be aware that if there already is CDF for that cell in the destination library then it would show up as a conflict during the copy, but that's fair enough in my opinion:

    The article you mentioned is specifically talking about stretch handle parameters and how to have them so that they can't be edited on the edit properties form. The alternative to creating a CDF parameter and then having it not display is to just not have the CDF parameter at all (but have CDF parameters for everything else) - so that's why it is described as the "best method". It doesn't mean that there's another way of defining the appearance of the parameters.

    So I think it actually behaves the way you want. No need to use ccpCopy to do anything special - standard library manager copy should copy everything needed.

    Regards,

    Andrew

Reply

  • The cell-level CDF is not specific to the library it was created with; if you copy the cell to another library, the CDF would go with it and it should still work. The only exception would be if you had any CDF callbacks which explicitly coded the library name into the callback - but there really shouldn't be a need to do that.

    Even if you copy (via the library manager) just the cellView (e.g. just the layout view) the default behaviour would be to copy the cell CDF (i.e. the cell's data.dm) too; there are settings in the Edit->Copy Preferences form that change this behaviour and these can be controlled in the .cdsenv too (this is in the Library and Cell Property Files section). You do need to be aware that if there already is CDF for that cell in the destination library then it would show up as a conflict during the copy, but that's fair enough in my opinion:

    The article you mentioned is specifically talking about stretch handle parameters and how to have them so that they can't be edited on the edit properties form. The alternative to creating a CDF parameter and then having it not display is to just not have the CDF parameter at all (but have CDF parameters for everything else) - so that's why it is described as the "best method". It doesn't mean that there's another way of defining the appearance of the parameters.

    So I think it actually behaves the way you want. No need to use ccpCopy to do anything special - standard library manager copy should copy everything needed.

    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.