Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
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?.
It sounds as if duplicating the code in a CDF callback is not a good idea. You could do several things:
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.
In reply to Andrew Beckett:
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?
In reply to Vasili:
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).