PCell Instance inside PCell Callback Issues

You may be able to workaround this with this:

unless(isCallable('aelSuffixNotation)
  procedure(aelSuffixNotation(num @optional _precision)
    let((numStr)
      numStr=case(type(num)
        ((string symbol) num)
        ((fixnum flonum) sprintf(nil "%N" num))
        (t warn("argument must be a fixnum, flonum, or strnum") nil)
      )
      when(numStr
        cdfFormatFloatString(numStr "auto")
      )
    )
  )
)

If this is defined in your libInit.il for your library, it would hopefully solve the problem. It provides an alternative (not identical) implementation of aelSuffixNotation (it ignores the precision) - but may be good enough for the callbacks to function correctly.

Regards,

Andrew.

Thank you,

It would solve the problem for aelSuffixNotation, but some of the callbacks are also using aelNumber, aelEnvCreate, aelEnvSetGlobalList and aelEnvInterpret.

Thinking outside the box here, assume I am building an Inverter PCell from an N and P primitive. Once a Inverter CDF property has been changed, and the primitive values updated, can the PCell (pcDefinepcell) return the two dbObject instances to the Inverter callback such that this callback can run the callbacks of the primitives?

Example:

Inverter CDF property N-Length changed

 -> PCell changes nInstance "Length" value

 -> PCell returns nInstance and pInstance dbObjects

 -> N-Length calls its callback receives nInstance and pInstance dbObject

    -> Callback calls all nInstance and pInstance callbacks.

This way, I avoid these functions being hierarchically ran during stream out.

You wouldn't be able to get an instance (because nothing has been created, and you'd have to create an instance somewhere for this to work), but I don't think it's necessarily required.

Using the code in this post (abInvokeCdfCallbacks.il) you could do this in your higher level callback (for each transistor that  you'll need in the pcell itself):

1. Create a pseudo effective CDF (this is so that you can happily stamp all over the structure without messing anything up):
   

   ;--------------------------------------------------------
   ; Create the effective CDF, and set all the parameters
   ; for the underlying device
   ;--------------------------------------------------------
   baseCDF=cdfGetBaseCellCDF(ddGetObj(theLibName theTranName))
   cdf=abCreateEffectiveCDFLookalike(baseCDF t)

2. Then populate the values you want into this using cdf~>w~>value=... and so on
3. Then call the callbacks: abInvokeObjCdfCallbacks(cdf ?order '("DFM_options")) ; you may or may not want to specify the order
4. Convert the CDF parameters into a set of PCell parameters (which could be passed to dbCreateParamInst or dbCreateParamInstByMasterName:
   pcellParams=abConvertCdfToPcellParams(cdf)
5. Serialise this and store it as a CDF parameter on your parent cell (so in other words, the callback is computing the parameters that will get passed to the underlying instance, and then storing these as a pcell parameter). This could be done either as a list CDF parameter (there is only limited support for list CDF parameters - and it's not fully public yet) or a string parameter - so you'd need to convert the list of parameters to a string (probably just using sprintf(nil "%L" pcellParams) and then pull it apart again inside the pcell using linereadstring())

If you have one of these derived parameters per sub-instance (you could probably combine them together), your pcell code could then find out the instance parameters needed without needing to call the callbacks.

I've not tried doing the above - I've used the functions above in a pcell purely to invoke the callbacks more efficiently and to avoid multiple re-evaluations of the pcell, but the  principle should be OK. Of course, you then suffer the risks of the pcell being wrong due to the "dangers of CDF callbacks" (I have an article on this on support.cadence.com). I'm wondering whether all the ael functions used were an attempt by somebody to evaluate expressions in a hierarchical context (which is doomed to failure, as outlined in the dangers of CDF callbacks article).

Regards,

Andrew.