Stats

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

PCell Instance inside PCell Callback Issues

snee

Hello all,

I have created a PCell of an inverter, by placing instances of N-MOS and P-MOS devices. Each of these primitives have pPar values for their width and length, and allows my Inverter PCell to have custom CDF properties to change the lower level instances, for example pPar("NW") for N width,pPar(" PW") for P width etc.

Once the primitives are instantiated, I refresh the callback functions of those primitives to update reliant CDF properties to the new values. Everything works great and my PCell functions properly.

However, when I run DRC/LVS, it errors with
"ERROR (XSTRM-231): Pcell evaluation has failed. This is because of either a syntax error or the usage of an unsupported XStream function in Pcell SKILL code."

I have found that while DRC generates the PCell, it is attempting to run the callback functions of the primitives and failing.
 Specifically, DRC complains that aelSuffixNotation() is an unknown function.

The only way to get DRC to run properly, is by disabling call-back refresh of the primitives in my inverter PCell.

Any tips on how to handle this?

Thanks.

Parents
  • Andrew Beckett

    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.

Reply
  • Andrew Beckett

    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.

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.