Stats

  • Locked Locked
  • Replies 4
  • Subscribers 126
  • Views 14582
  • 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

Ocean script mal function

saikatc

Hi,

I am using ocean scripting for calculating propagation delay and energy per transition of my circuit. There I observed a weird behaviour. When I run the script for one certain value, it generates some value. But when I run a parametric simulation, for the same points the values changed a lot. My script is as follows. The interesting point is, the mismatch is happening only in case of energy calculation not anything else.

simulator( 'spectre )
design( "/homes/schatterjee/subvt_28/SUBVT28CORE_test/simulation/LSLH_LVT/spectre/schematic/netlist/netlist")
resultsDir( "/homes/schatterjee/subvt_28/SUBVT28CORE_test/simulation/LSLH_LVT/spectre/schematic" )
modelFile(
'("/homes/schatterjee/subvt_28/SUBVT28CORE_test/corners.scs" "")
)
definitionFile(
"models.scs"
)
analysis('tran ?stop "4u" )
analysis('dc ?dev "/V1" ?param "dc" ?start "0"
?stop "1" )
desVar( "t" 500n )
desVar( "wp1" 540n )
desVar( "lp1" 600n )
desVar( "wp2" 150n )
desVar( "wp3" 320n )
desVar( "lp3" 60n )
desVar( "wn1" 160n )
desVar( "wn2" 500n )
desVar( "vdd_h" 1 )
desVar( "vdd_l" 300m )
envOption(
'analysisOrder list("tran" "dc")
)
save( 'i "/V0/MINUS" "/V2/MINUS" "/V1/MINUS" )
temp( 27 )
run()
paramAnalysis("t" ?values '(500n 625n 1000n 1250n 2500n 5000n)
; paramAnalysis("vdd_l" ?start 250m ?stop 1000m ?step 50m
; paramAnalysis("wp1" ?start 200n ?stop 800n ?step 6n
; paramAnalysis("lp1" ?start 400n ?stop 800n ?step 4n
; paramAnalysis("wp2" ?start 80n ?stop 480n ?step 4n
; paramAnalysis("wp3" ?start 180n ?stop 580n ?step 4n
; paramAnalysis("lp3" ?start 50n ?stop 65n ?step 1n
; paramAnalysis("wn1" ?start 160n ?stop 660n ?step 5n
; paramAnalysis("ln1" ?start 48n ?stop 60n ?step 1n
; paramAnalysis("wn2" ?start 300n ?stop 800n ?step 5n
; )
; )
; )
; )
; )
; )
; )
; )
; )
)
paramRun()

vddl = ymax(v("in" ?result "tran"))
vddl_50 = vddl/2;
vddh_l = ymax(v("z" ?result "tran"))*.10
vddh_h = ymax(v("z" ?result "tran"))*.90

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ;;
;;The following section is for the calculation of delays and time related informations ;;
;; ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

tpd_r_z = delay(?wf1 v("/in" ?result "tran") ?value1 vddl_50 ?edge1 "rising" ?nth1 1 ?td1 0.0 ?wf2 v("/z" ?result "tran") ?value2 0.5 ?edge2 "rising" ?nth2 1 ?td2r0 nil ?stop nil ?multiple nil)
tpd_f_z = delay(?wf1 v("/in" ?result "tran") ?value1 vddl_50 ?edge1 "falling" ?nth1 1 ?td1 0.0 ?wf2 v("/z" ?result "tran") ?value2 0.5 ?edge2 "falling" ?nth2 1 ?td2r0 nil ?stop nil ?multiple nil)

tpd = ((tpd_r_z + tpd_f_z)*1e9) / 2; The average is taken of the rise and fall propagation delay

plot(tpd ?expr '("tpd"))

;; Energy per transition calculation

tr_l = cross(v("/z" ?result "tran") vddh_l 1 "rising" nil nil )
tr_h = cross(v("/z" ?result "tran") vddh_h 1 "rising" nil nil )

enr_trans_r= vddl * integ((IT("/V2/MINUS") + IT("/V0/MINUS")), value(tr_l, vddl), value(tr_h, vddl)) + integ(IT("/V1/MINUS"), value(tr_l, vddl), value(tr_h, vddl))

tf_l = cross(v("/z" ?result "tran") vddh_l 1 "falling" nil nil )
tf_h = cross(v("/z" ?result "tran") vddh_h 1 "falling" nil nil )

enr_trans_f= vddl * integ((IT("/V2/MINUS") + IT("/V0/MINUS")), value(tf_h, vddl), value(tf_l, vddl)) + integ(IT("/V1/MINUS"), value(tf_h, vddl), value(tf_l, vddl))

enr_trans = 1e15 * (enr_trans_r + enr_trans_f)

plot(enr_trans ?expr '("enr_trans"))

 

Any help would be appreciated.

Thanks

Saikat

  • Andrew Beckett

    Saikat,

    Usually when this happens it's because either there is a small numerical difference which is within the tolerances (and maybe your measurement is highly sensitive - I didn't check) or that the circuit has more than one stable operating point. This happens surprisingly often - circuit behaviour like hysteresis and latches can easily cause this kind of problem. It may indicate an expected property of the circuit, or it may be undesirable and warrant further investigation.

    I can't really tell without seeing the circuit itself and being able to run simulations. Presumably you could also put the currents through V2 and V0 and compare those.

    One trick is to add:

    option('rebuild_matrix "yes")

    This forces spectre to rebuild the matrix from scratch each time rather than starting from the previous solution. Note that this can then hide the fact that you have multiple operating points, so use cautiously - the other results aren't "wrong" - but this can lead to more consistent results.

    You can also experiment with using:

    envSetVal("spectre.envOpts" "controlMode" 'string "batch)

    right at the very beginning of the script (before the simulator() call). In this case, spectre will restart at each point in the parametric analysis; the performance is slower, but each individual run should be similar to what happens when you run an individual simulation. As I said, this isn't any more correct than the normal way of running, but could be a way of making your results more consistent in a circuit with multiple operating points.

    Regards,

    Andrew.

  • saikatc
    Andrew,
    I tried both. But nothing worked here. Consistently the same results are coming back.
    Just to clarify once again, I have included
    option('rebuild_matrix "yes")
    before I declare the type of simulator. I wonder whether that can be a source of problem. Both the commands generated same set of data.

    Regards,
    Saikat
  • Andrew Beckett

    The option() call should be after the simulator() call - ideally after the design() call.

    If that doesn't work, please contact customer support - we'll need to see your entire setup, I think.

    Regards,

    Andrew.

  • saikatc
    Thanks. It didn't work. I would try it with customer support.
    Regards,
    Saikat

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.