Home > Community > Forums > Custom IC Design > meassuring delay in viva

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 meassuring delay in viva 

Last post Sun, Dec 22 2013 1:04 AM by Andrew Beckett. 3 replies.
Started by jerry124 26 Nov 2013 02:26 AM. Topic has 3 replies and 459 views
Page 1 of 1 (4 items)
Sort Posts:
  • Tue, Nov 26 2013 2:26 AM

    • jerry124
    • Not Ranked
    • Joined on Fri, Jun 28 2013
    • Posts 12
    • Points 180
    meassuring delay in viva Reply

    dear all,

    I would like to measure delay on signal "gap" simulated on two temp -40 and 125 with "trigger" option like:

    dly_fr=delay( v("gap") 0.75 1 "falling" v("gap") 0.75 2 "rising" 1 1 t "trigger")

    I am getting results like:

    time delay(v("gap" delay(v("gap"

    temp                       -40               125

    17.8748u             38.4359u       7.67508u

    56.3107u             9.60973u       38.4348u

    65.9204u             38.4462u       9.60979u

    104.367u             9.60927u        38.4452u

     

    but I am expecting results something like:

     

    17.8748u             38.4359u          38.XXXXu

    56.3107u            38.XXXXu         38.4348u

    65.9204u             38.4462u          38.XXXXu

    (bold are expected values which also could be measured manually)

     

    Signal shape is:

           ___       ___                            ___       ___        

    ___|      |___|      |_____________|      |___|      |________
                               <       fr            >

    and I would like to measure value fr.

    How can I correctly measure value fr? What caracters 1 1 t in the command line (marked bold) mean?

     

    THX

    Jerry 

    Filed under: , ,
    • Post Points: 20
  • Tue, Nov 26 2013 10:21 AM

    Re: meassuring delay in viva Reply

    Jerry,

    Which subversion are you using? In recent versions that I've tried, ViVA uses the newer keyword argument form of delay() which is much clearer to see what the arguments mean because they are passed by name rather than order. 

    The subversion can be found by doing Help->About... in the CIW.

    Kind Regards,

    Andrew.

    • Post Points: 20
  • Wed, Nov 27 2013 1:16 AM

    • jerry124
    • Not Ranked
    • Joined on Fri, Jun 28 2013
    • Posts 12
    • Points 180
    Re: meassuring delay in viva Reply

     Hi Andrew,

     I am using version IC6.1.5-64b.500.10

     

    BR

    Jerry

    • Post Points: 20
  • Sun, Dec 22 2013 1:04 AM

    Re: meassuring delay in viva Reply

    Jerry,

    If you build the expression in that version (using the calculator) you'd get the newer keyword argument version of the function - for example:

    delay(?wf1 v("gap" ?result "tran"), ?value1 0.75, ?edge1 "falling", ?nth1 1, ?td1 0.0, ?wf2 v("gap" ?result "tran"), ?value2 0.75, ?edge2 "rising", ?nth2 2,  ?td2 0.0 , ?stop nil, ?multiple nil)

    which is much clearer as every argument is named. I did a bit of digging, and the ordered arguments are in this order (we seem to have removed this from the documentation):

    wf1 value1 nth1 edge1 wf2 value2 nth2 edge2 period1 period2 multiple xName

    The default is that the second edge is relative to time, rather than the first edge.

    So I believe your expression is equivalent to:

    delay(?wf1 v("gap" ?result "tran"), ?value1 0.75, ?edge1 "falling", ?nth1 1, ?td1 0.0, ?wf2 v("gap" ?result "tran"), ?value2 0.75, ?edge2 "rising", ?nth2 2,  ?td2r0 0.0 , ?stop nil,  ?period1 1 ?period2 1 ?multiple t ?xName "trigger" )

    This means that:

    • The bold t in your expression indicates that you are generating multiple delays, from the first falling edge to the second rising edge on the waveform gap. The second edge is not relative to the first.
    • It is using periodicity of 1 for both (the two bold 1s). 

    It's not clear to me if you really want the ?multiple occurrences or not.

    So my recommendation would be to try building the expression in the calculator and check to see what  you're getting, rather than using this positional argument version (I even checked back in IC5141 and the keyword argument version is documented there too).

    Regards,

    Andrew.

    • Post Points: 5
Page 1 of 1 (4 items)
Sort Posts:
Started by jerry124 at 26 Nov 2013 02:26 AM. Topic has 3 replies.