Stats

  • Locked Locked
  • Replies 2
  • Subscribers 125
  • Views 863
  • 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

What is meant by "device parameterization" in relation to "ignoreDesignChangesRun" limitation discussed in ADE user guide?

jehh

Hi,

We are exploring the "ignoreDesignChangesDuringRun" variable for the ICRP mode, and was trying to understand what the specified limitation in the user guide is referering to?

Quote:

When the ADE Assembler setup includes device parameterization, an incremental netlist needs to be generated for each simulation point during the simulation run. 
This is required to execute any CDF callbacks during the run.

The idea is we want to be sure that when running a sweep, changes to the schematics are not automatically included in the current sweep. But what does "device parameterization" cover?

Can we change a resistor value, using a variable for instance? Our initial testing with analogLib components seems to work. Does it depend on whether there is a CDF callback for the device parameter?

BR,

Christian

Parents

  • Hi Christian,

    The parameterisation is if you've defined any parameters in the Parameters section:

    This is where you can override or sweep the value of a parameter on a component directly, rather than setting it to a variable. You can set up matched or ratioed parameters (via the Variables and Parameters assistant) and can do this on readonly parts of your design hierarchy. It also takes care of calling any CDF callbacks to ensure that derived parameters are handled (which may not be possible with a design variable in the parameter of the instance).

    That flow is not supported with ignoreDesignChangesDuringRun with ICRP for the reasons described in the message.

    If, however, you move to the newer "LSCS" flow (which is supported since IC6.1.8/ICADVM18.1 ISR9 onwards), ideally using the most recent hot fix, then ignoreDesignChangesDuringRun becomes unnecessary as the netlists are generated at the beginning of the simulation run (in the background, so you don't have the big wait at the beginning that you have with ICRP and ignoreDesignChangesDuringRun because the foreground Virtuoso is blocked), and parameterisation is supported in that flow.

    Regards,

    Andrew 

Reply

  • Hi Christian,

    The parameterisation is if you've defined any parameters in the Parameters section:

    This is where you can override or sweep the value of a parameter on a component directly, rather than setting it to a variable. You can set up matched or ratioed parameters (via the Variables and Parameters assistant) and can do this on readonly parts of your design hierarchy. It also takes care of calling any CDF callbacks to ensure that derived parameters are handled (which may not be possible with a design variable in the parameter of the instance).

    That flow is not supported with ignoreDesignChangesDuringRun with ICRP for the reasons described in the message.

    If, however, you move to the newer "LSCS" flow (which is supported since IC6.1.8/ICADVM18.1 ISR9 onwards), ideally using the most recent hot fix, then ignoreDesignChangesDuringRun becomes unnecessary as the netlists are generated at the beginning of the simulation run (in the background, so you don't have the big wait at the beginning that you have with ICRP and ignoreDesignChangesDuringRun because the foreground Virtuoso is blocked), and parameterisation is supported in that flow.

    Regards,

    Andrew 

Children
  • in reply to Andrew Beckett

    Thank you Andrew - The device parameterization was not imideatly obvious to me. I was not aware of this feature - good to know.

    WRT LSCS, I am looking forward to - in the very near feature - moving to the LSCS method. We are waiting for ISR18, because we can not properly suspend licenses on our SGE grid, with anything but ICRP ;)

    BR,

    Christian

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.