Stats

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

Parameters and pcells in ADE XL

kvntien

Hi all,

 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 have

if( 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... 

Thanks,
Kevin 

  • Andrew Beckett

    Kevin,

    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.

    Regards,

    Andrew.

  • kvntien

    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...

    Thanks,
    Kevin 

  • Andrew Beckett

    Hi Kevin,

    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!

    Regards,

    Andrew.

  • kvntien

    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 =]

    Thanks,
    Kevin 

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.