Stats

  • Locked Locked
  • Replies 6
  • Subscribers 144
  • Views 4524
  • 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

Override variables defined in Corners with Design Variable for calcVal() calibration simulation in ADE Assembler/Spectre

smarshall

I have a set of corners defined for process, temperature, voltage as such:

temperature = -40, 125

VCC = 1.0, 1.4

Corner = Fast, Slow

I have 2 tests, Cal_Test and Val_Test (calibration and validation)

I want to run single calibration simulation Cal_Test at T=25 and VCC=1.2 (neither are defined in the corner sweeps), but DO want to apply the relevant process Corner, then apply the result of this calibration run to the subsequent corner run.

I am trying to force the Design Variables of Cal_Test to temperature=25 and VCC=1.2 by selecting the check-box so that they override the variable definition defined in the corners file. Then use a global variable with calcVal() to apply the result to Val_Test which would be run over the 8 defined corners (process, voltage, and temperature). For Val_Test I do not have variables checked for VCC or temperature, so as to allow the Corners to set the definition.

The initial Cal_Test simulation runs, but it appears the Design Variables are overridden by the definition in the Corners file, and thus the Cal_Test is not run at the correct temperature. When the Val_Test runs, it returns a netlisting error right after all the variables are defined (although not directly after the line which defines temp) and the simulation fails:


\o Setting var myVar1 = "0"
\o Setting var myVar2 = "1"
\o Setting temp(T) = 125
\o Setting var vcc = "1.4"
\o Setting var myVar3 = "1"
\e *Error* float: argument #1 should be a number (type template = "n")

\e *Error* failed at creating netlist

So, it seems this is not the intended use - the Corner definitions are overriding the Design Variables, and then the conflict must be causing the netlist error.

I realize there is a solution where I redefine my Corners setup to only vary the process models, and then change VCC and temperature to Global Variables which can be overridden on individual tests as I desire. But, I would like to keep those variables defined in the Corners setup if there is any way to do so.

Is there some way to change the precedence of where variables are defined, or is this impossible? Ideally the precedence would be checked Design Variable > Global Variable > Corner Setup whereas right now it seems like Corner Setup > checked Design Variable > Global Variable

Thank you for any information.

  • You should be able to do this with a corner setup like this:

    My variable was vdd not vcc. Then in the calcVal expression I had for the variable in the valTest I used this:

    calcVal("VBIAS" "calTest" ?ignoreParams list("vdd" "temperature" "modelFiles"))

    In this way, because I didn't have the corner enabled for calTest (you said you weren't varying over corners for that), it used my nominal vdd=1.2, nominal temperature, and nominal models. Then the calcVal was told to ignore the vdd parameter, the temperature and the modelFiles - and so all of the runs for valTest used the single calTest run's results.

    Is that what you wanted?

    Regards,

    Andrew 

  • in reply to Andrew Beckett

    Thanks for the reply Andrew. Actually I DID want to vary the process corner for the calTest, but not the vdd or temp.

    Maybe I can take the same approach of defining 2 corners, one for calTest which only varies the modelFiles, one for valTest which varies vdd, temp, and modelFiles and use the ?matchParameters instead? I will try and report back shortly, if you can think of a reason this wouldn't work it would be appreciated. Thanks!

  • in reply to smarshall

    I just tried creating a second corner:

    I then used:

    calcVal("VBIAS" "calTest" ?ignoreParams list("vdd" "temperature"))

    ie. not ignoring modelFiles.

    This worked too. So this should work (I didn't have time test using matchParams instead)

    Andrew

  • in reply to Andrew Beckett

    Unfortunately I can't seem to replicate this behavior. At this point I'll file a case. Below is a composite image showing a simple test bench, ADE Assembler Data View, Outputs Setup, Corners Setup, and Netlist Log file where it can't match the parameters.

    1. In calTest, I want to measure "vtest" at 40C at FF and SS corners. vtest should be a different value at FF and at SS corners.

    2. Then in valTest I want to set that voltage "vset" on an ideal voltage source and measure it at the corresponding process FF and SS corners, but with temperature being different T=-40, 125.

    So for valTest at FF, -40C I should see vset be the value from FF at +40C.

    calcVal("v_test" "calTest" ?ignoreParams list("vset" "temperature") ?matchParams list("modelFiles"))

    but I have tried a few permutations; one using only ?ignoreParams, and one using only ?matchParams and get roughly the same result. In my case, it appears to be getting the "modelFiles" param as the expanded "corner name" such as CAL_0, CAL_1, VAL_0, VAL_1 and therefore sees them as being different between the two tests, so the params don't match. I don't know why "modelFiles" isn't being read as "FF" and "SS" instead.

    I also tried adding "cornerName" to the ?ignoreParams list which also did not work.


  • in reply to smarshall

    Yes, customer support makes sense here. You didn't mention which IC sub-version you were using - I was using the latest (IC6.1.8 ISR31) - maybe there's a dependency on which version is used, as there have been many fixes and improvements for calcVal over time.

    Andrew

  • in reply to Andrew Beckett

    I am on 6.1.8 ISR29, so not that far behind. I have followed up with a case and may update this thread if we find a resolution. Thanks.

    Case# 46693705

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.