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.
I have a schematic pcell that generates an n-stage chain of (non-pcell) instances, each with different instance parameters. To do this, I have a pcell string parameter 'numStages' (also defined in the CDF for the cell), and something in the pcDefinePCell let block like
n = atoi( numStages )for( inst 1 n ....I'd like to be able to sweep this parameter for optimisation in ADE by assigning it a design variable. First problem I ran into is, of course, when pcell evaluation happens, numStages is a text string representing a design variable, so atoi( numStages ) is nil. To get around that, I haveif( n == nil then n=round( VAR( numStages ) ) )
Not the most foolproof, but at least it seems to work in ADE L. When I try to move it to ADE XL for global optimisation, it fails: all instances of the pcell at every design point are instantiated as if numStages were set equal to the value it takes on in the first design point.Is this due to the pcell evaluation only happening once, then ADE XL just changing the parameter declaration line in subsequent netlists? Either way, does anyone have any insight into how I can make this work? Or is this a fool's errand...
I think you're doomed to failure if you try to do this with a design variable on the instance, because you need the variable to be evaluated before netlisting - and in general variables are handled by the simulator.
It might work if instead you give a fixed value for the numStages parameter on the instance, and then define a parameter (using the Variables and Parameters assistant in ADE XL), and define the sweep range for that for optimization.
Even then, I suspect it may fail - because I think ADE XL converts it into a parameter for spectre, but it's worth giving it a try and seeing what happens! The reason why it might just work is that the modification is done in memory and then renetlisted when doing optimization - this is done to handle the scenario where CDF callbacks are involved.
In reply to Andrew Beckett:
Thanks for the response, Andrew!I'd already tried using the parameter sweep, and indeed, the conversion to a Spectre parameter seems to throw off the entire thing, and it does not work. I'm a little surprised that you say re-netlisting is performed for the parameter sweep... does that only occur if a CDF change is detected? Since the numStages parameter isn't actually referred to anywhere in the cell after pcell eval, it never shows up in the CDF, which means no re-netlisting, I guess?You also mention that a modification is done in memory; which modification exactly? The one for a parameter as opposed to a design variable? Can you perhaps provide some insight into how ADE XL effects netlist changes for design variables vs. component parameter sweeps? I'd given up on trying to vary numStages days ago, but now I'm just curious as to how this all works. The docs for ADE XL weren't too forthcoming about the details...
In reply to kvntien:
I also just tried the parameterization flow - and that doesn't work. The reason is that it's being smart to allow for something we've not turned on yet, which is running the parameter variations in the simulator memory without needing the simulator to restart (essentially similar to spectre's "interactive" mode).
Anyway, the reason why I thought it might work is because when you alter a parameter using the Variables and Parameters assistant, it doesn't really change the design - it might be readonly, for example. So what happens is that in the ICRP background process it modifies the design in "scratch" mode (which is in memory only, and not saved) and then netlists the modified design. However, if you put a sweep on a parameter, it netlists it as a spectre parameter called DPAR_1., DPAR_2 etc - and hence it doesn't actually have to create a whole new netlist for each point in the sweep in practice - only the parameters line at the top varies (this is faster, because it doesn't really need to re-netlist, just assemble the new netlist for that point in the sweep).
So I think this is doomed to failure, sorry!
Got it! Thanks for confirming that my intuition about what was going on was correct. At the very least, this info will get filed away and hopefully solve an issue for me in the future =]