A

---

Advice and Warnings

---

This section answers frequently asked questions not already covered, and warns you about common mistakes.

• Library CDF versus Cell CDF
  A cell inherits all definitions from the library CDF. If there are changes in the cell CDF, the changes override the library CDF at the cell level. It is important to be aware of what is in the library CDF of any cell you work on.
• CDF level differences
  Remember that only the base-level CDF is saved to disk. The user-level CDF is used only for one session and cannot be saved. If you have a base and user CDF, the effective CDF is everything from the base CDF updated with anything new from the user CDF. In the Edit CDF form, you can “edit” the effective CDF. In reality, the effective CDF is just there to give you a way to look at the total CDF for a component. There is nothing to edit in an effective CDF, so changing the effective CDF in the Edit CDF form does nothing.
• Update
  The update function under Cadence Analog Design Environment– Design Variables – Update in the schematic editor updates only what is in the current window and for only one level of hierarchy.
• Parameter values and callbacks
  If you use iPar, pPar, atPar, dotPar, or the old notation ({}) to inherit the value of a parameter, as the real value changes, the callbacks associated with that parameter are NOT triggered. So, be aware of that when determining which parameters inherit values. Similarly, if you assign a design variable as a parameter value, the setting of the design variable does not trigger callbacks.
• Units
  The units you can use in the CDF are limited to those offered in the Edit CDF form. There are no user-defined units.
• Range checking
  CDF provides no automatic range checking. You must use callbacks to do that.
• Pcell default values
  There is no system mechanism to ensure that your Pcell defaults and CDF defaults are synchronized, so you must manage this.
• Callback files
  If you define your callbacks in a separate file (not self-contained in the CDF or attached to the library), you must remember to archive that file whenever you archive your library.
• Callback limitation
  You can control parameter values with callbacks, but you cannot affect anything in the simulation information section.
• Boolean properties
  Be careful of using the CDF “Boolean.” It is defined as t or nil. If you add a property to an instance using the Add button in the Edit Object Properties form you will see that the system models that kind of Boolean as TRUE or FALSE. There are some applications that depend on that. For example, the property lvsIgnore used in DLE and LVS must be TRUE or FALSE. So, if you want to add it to your CDF, instead of making it a CDF Boolean type, make it a cyclic type and set its choices to TRUE and FALSE.
• Triggering callbacks
  Callbacks are triggered whenever a change is made to the parameter value, even if the change is caused by loading a default value. You need to ensure that default values do not violate any relationships that you are trying to enforce.
  Use callbacks to establish dependencies between parameters whose values are numeric constants.
  Avoid using callbacks on parameters whose values are expressions. Such values require update evaluations and can quickly become out of date. If you do choose to use callbacks of this type, you will need to run a hierarchical evaluator that will walk the entire design to trigger all CDF callbacks whenever the value of the parameter is changed. Note, too, that a hierarchical evaluator will not be reliable with pPar() parameters.
• Layout extraction, properties, and callbacks
  When you run layout extraction to find devices in the layout, you can also measure the sizes of the devices. When you save that information, it is stored as a property on the symbol (auLvs or an ivpcell) that is placed in the extracted layout. For example, when extraction finds an NFET, it places the cell nfet auLvs at the location of the recognition shape. That instance has the connectivity that was found and has the properties for the measured values saved, probably the length and width. Setting those measured parameters by extraction does not trigger any callbacks on those parameters. This is especially important to remember if you are doing parasitic resimulation, because you need all parameters necessary for simulation to be set in the extracted layout. You cannot rely on the callbacks; you must redo the calculations in the extraction rules.
• LVS case sensitivity
  Remember the property mapping example for LVS. Even though CDF might use lowercase parameter names, LVS expects capital letters. If you do not enter this mapping properly, the parameters are not netlisted correctly and in LVS this most likely means that size comparisons are not made at all.
• The Virtuoso^® layout editor now accesses and uses CDF parameters.
• Property value replacement and callbacks
  Using Edit – Search – Replace to find a property and change its value across a set of instances does not trigger callbacks associated with the parameter. The Cadence Analog Design Environment – Design Variables – Update command triggers the callbacks associated with each variable, but you cannot control the order in which the callbacks are executed.
  In addition, if you use the default value for a parameter, and set storeDefault to no, there is no property for Edit – Search – Replace to find. However, changing the default value does change it.
• Numerical value format
  Be careful about entering blanks when entering values in a form or defining values or default values. In the CDF, “ 12” does not equal 12; nor does “12 ”. “12 u” does not equal “12u”. This can cause errors.
• The dontSave parameter attribute
  Do not use the dontSave parameter attribute unless you are absolutely sure you need to. It can lead to unexpected results, especially when callbacks are used. The only thing that dontSave does for you is save the space used to store the property value on a parameter that you think is not so useful. One example is when you use the parameter resType on a resistor to trigger callbacks to set up the rest of the parameters based on the resistor type. Once that is done, you do not think the value of resType needs to be saved. The problems occur when you edit the parameters on existing instances and the values do not match.
• Reserved words
  There are words that are reserved and cannot be used as net, component, property, or parameter names. Do not use any of the following:
  • Command or function names that your simulator uses
  • A parameter or property name or prompt that is already in use
  • The names of fields
  • “others,” “loadSave,” “simInfo,” “othersFG,” “area,” “resistor,” or “multiplier”
  
  In addition, if you want to make sure a property you define does not go into the netlist, do not use the name of a CDF parameter.
• Initial and final procedures
  Avoid using too many initial and final procedures (formInitProc and doneProc). Running one or two procedures every time you change a parameter can slow down system performance noticeably.
• Layout name labels
  Labels in layout do not know the hierarchy, so they cannot display hierarchical names, only current names.
• Do not use parameter names that begin with a number.
• Changes in the Edit CDF form do not take effect until you click Apply on the Edit CDF form.
• Avoid using the dontUse attribute.

Return to top