Stats

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

Invalid CDF choice

RVERP

I have been using some skill code where an instance (pcell) master is replaced with another pcell. The parameters are not the same, so I assumed all the cdf parameters are set to the default value of the new pcell.

I do this in combination with clones, doing following steps:

  • Generate all instances from a schematic
  • Select the group I want to clone, and generate synchronous copy clones
  • Descend in on of the clones, and replace the instance master.

These steps don't give any problems, in all the clones the master is replaced with my custom pcell.

But sometimes, while altering a parameter, I get an error message An invalid CDF choice "netlist" was specified for the CDF parameter "source".

My new pcell has a cdf parameter "source", a string. My original pcell doesn't have a cdf parameter "source", so I have no idea where this is coming from. This problem occurs on about 20% of the clonegroups I work on with above procedure.

I tried to do something with resetting or clearing cdf parameters, but with no succes. Any ideas??

  • First thing I'd check is looking at the original instance (before changing) to look at instead~>prop~>?? to see what properties are actually on the instance to see if there's a property called "source" on the instance. 

    If that's not it, I think you'll need to contact customer support, as debugging this without seeing the data is going to be hard.

    Regards,

    Andrew.

  • Is do see an instance~>source with the value "netlist". The mixup is coming from there, but I wonder how it gets in the CDF.

  • Instance CDF is formed by overlaying the effective cell CDF with properties stored on the instance. Put another way, when you override a CDF parameter (on the create instance or edit properties form), it's actually stored as a user defined property on the instance. So it's not surprising at all.

    You could call dbDeletePropByName(instId "source") before remastering.

    Regards,

    Andrew.

  • But on the original instance there is no property "source", there is also no CDF named "source".
    There is only instance~>source = "netlist", like there is on any other instance.

    I do see that after I replace the instance, the properties are still the ones of the old instance. I'll try to delete them first, and replace them with the parameters of the new instance. See if the problem stil occurs.
  • I've deleted all the instance parameters before replacing it. The replaced instance has no properties. Is there a way place the (default) parameters of the pcell in the property list?

  • In general you don't need the default values of each CDF parameter stored on the instance property list - that's not so efficient, and the point of CDF is that the default value comes from the CDF.

    There is a setting on each parameter in the CDF called "storeDefault" which can be set to "yes" - this means that it will then store an instance property on the instance whenever the create instance/edit properties form sets the value of that parameter to the default value. It won't do this if you create the instance with SKILL though. 

    However, as I said, there's no need to do this, and in general you should not do it (there are some occasional specific cases where it's useful or even necessary to set the default, such as when the CDF default is different from the pcell default but the general situation is that you should not need to do this).

    Regards,

    Andrew

  • The original devices have cdf parameters stored on the instance property list, but storeDefault for those parameters is set to "no".

    Even after deleting the device parameters, the mixup still happens after replacing the device. I'll try to set a default value in op the instance property named, "source". If this doesn't work, I'm running out of ideas. Maybe there is a naming restriction for a CDF called "source"??

  • There are a number of other situations where the default value might still get stored on the instance - so that might happen (particularly in layout with Layout XL). However, I don't see how the problem can occur if you actually deleted the properties before remastering. Need to be sure you really did delete them. As I said, you may need to contact customer support.

    Regards,

    Andrew

  • The properties are gone, I double checked.

    As a first solution I'm gonna rename my CDF parameters. It's a bit of a strange error since it only happens in combination with synchronous copy clones, and only on about 20% of the devices.

    Last question, what is the "instance~>source" variable? Is it to indicate an instance was generated with layout XL. They seem to have it set on "netlist", instances that are manually placed have it on nil. Is there a way to reset it from "netlist" to nil?

  • You know what, I should have checked in a real database, rather than just off the top of my head. I checked in the documentation too. The issue is that "source" is the name of a built-in attribute for instance objects in the database, and so you should never have a CDF parameter called that (it's asking for trouble).

    Every instance has the attribute (not user defined property) called "source". You can see that by doing instId~>? . Here's what he relevant section of the Virtuoso Design Environment SKILL Reference says (in the chapter on Database Access, in the section at the end of that chapter called Attribute Retrieval and Modification:

    source: (string) The different sources you can assign to an instance. Valid Values: netlist, timing, dist, test, user

    The default value is "netlist". I'm not sure anything really uses it any more (it was probably used by older place and route tools, like Block Ensemble, which are long gone). I may be wrong though! I'd never noticed that it existed though, mostly because I'm not aware of anything using it.

    Regards,

    Andrew.

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.