Home > Community > Forums > Custom IC SKILL > Optimal (fast) callback for pcells

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 Optimal (fast) callback for pcells 

Last post Thu, Sep 3 2009 2:50 PM by Andrew Beckett. 3 replies.
Started by Vasili 02 Sep 2009 12:36 PM. Topic has 3 replies and 2279 views
Page 1 of 1 (4 items)
Sort Posts:
  • Wed, Sep 2 2009 12:36 PM

    • Vasili
    • Not Ranked
    • Joined on Wed, Feb 18 2009
    • Posts 5
    • Points 100
    Optimal (fast) callback for pcells Reply

     What is the optimal (fast) callback procedure for pcells?

    For example, I have a pcell that draws a shape that has a resistance. The value of the resistance is calculated inside pcell. I need to know the resistance of the instance, for example, to create another resistorwith a predefined total resistance. Is CDF callback the best solution or it could be avoided?

    I even not sure that "callback" is the correct term. I simply want to know the numerical value of a local variable that has been used inside pcell to execute dbCreatePCell or rodCreatePCell.For example, I can creare a handle and assign to this handle the numeric value of my parameter and then get its value from the instance by using get ...handle. But maybe there is a "recommended" solution?.

    Vasili 

    • Post Points: 20
  • Thu, Sep 3 2009 4:47 AM

    Re: Optimal (fast) callback for pcells Reply

    Hi Vasili,

    It sounds as if duplicating the code in a CDF callback is not a good idea. You could do several things:

    1. Get your pcell to add a label with the value of the resistance displayed. 
    2. Store it as a cellView property on the generated subMaster - then you could do geGetSelSet()~>master~>resVal (assuming the property was called resVal) to find it.
    3. Store it as a ROD handle, as you've suggested.

    The alternative is to perform the same calculation inside a CDF callback. My views on CDF callbacks for computing values are fairly well known (see sourcelink solution 11223092 on the Dangers of CDF Callbacks), but provided that this is used for estimation only, it's reasonable. That said, the advantage of getting the pcell to output it is that you know it's up to date.

    Regards,

    Andrew.

    • Post Points: 20
  • Thu, Sep 3 2009 11:55 AM

    • Vasili
    • Not Ranked
    • Joined on Wed, Feb 18 2009
    • Posts 5
    • Points 100
    Re: Optimal (fast) callback for pcells Reply

     Hi Andrew,

     Thank you very much. Your comments are good for me. I am doing strange things (in particular, I pretend that the superconductor electronics exists), and I should appology for strange questions. It would be very natural for any new comer that different views of one cell should have common properties. Of course one can argue that, say, (Virtuoso) layout view deals with geomety, while schematic view deals with electric properties. But I would like to state that geometrical properties are derivative of electric properties and parasitic electrical properties are derivative of geomerty. I already know how to use pcell technique to derive geometry from required electrical properties and I know how to extract parasitic electrical properties from the layout. But I did not find a convenient way to bound together scematics and layout views. Ideally it could be that the layout adjusts itself if some schematics parameter is changed or the schematic change itself if the layout is edited.

    I guess, there are fundamental problems with joining different cell views. Where I can read about such view unification? I know that CDF allows to synchronize views (and parameter values) but why not to declare that could be a single parameter that is shared by several cell views?  

    • Post Points: 20
  • Thu, Sep 3 2009 2:50 PM

    Re: Optimal (fast) callback for pcells Reply

    Normally you would use a tool such as Virtuoso Layout XL to perform connectivity driven layout. This will generate layout instances with the same parameters as the corresponding schematic - and has checks in place to ensure that parameters match. You have the ability to deviate in the layout - there may be good reasons for setting some parameters differently on the resulting layout. Similarly, it's possible to have a different hierarchy - you might (for example have hierarchy on the schematic, but not want it on the layout).

    SImilarly you might want to have parameter inheritance on the schematic (functions such as pPar), but on the layout you need to "harden" any parameters because in reality your layout needs to be fixed.

    So normally you wouldn't have it directly linked between the schematic and layout views of a particular instance - but it is very easy with Layout XL to update your layout to match the schematic.

    In general I suggest that people have pcells with parameters which are the same parameters you would use for simulation - so these may be electrical (although with MOSFETs they're often physical - width and length), and then the pcell is responsible to transform them into physical dimensions. As long as what you simulate is consistent with what your layout generates, and you can verify that, you're fine. In general you want all views to be driven from the same set of parameters - the danger of CDF callbacks is that if you have (say) pcell parameters derived from the parameters you enter on the schematic, and you simulate using the entered parameters, there's a risk that the callbacks didn't trigger, and so you are laying out something different to that which you simulated. If you're not careful you can end up LVSing the layout against the derived parameters, so you never know that what you laid out is not what you simulated... (more on this in the solution I mentioned).

    Best Regards,

    Andrew.

    • Post Points: 5
Page 1 of 1 (4 items)
Sort Posts:
Started by Vasili at 02 Sep 2009 12:36 PM. Topic has 3 replies.