risetime and falltime in the calculator

There were some bugs introduced between ISR8 and ISR10 (fixed in ISR11) where if the arguments (in some cases) were supplied as documented, the functions did not work properly. The result is that the two functions currently behave the same as each other - but we do plan to do something about that.

The falltime function is documented this way:

    Returns the fall time measured between theta1 (percent high) to theta2 (percent low) of
    the difference between the initial value and the final value.
    ...
    Percent High is the percentage high difference between initial and final values.
    Percent Low is the percentage low difference between initial and final values.

This is actually more clearly described on the MDL page:

    theta1 is the threshold high expressed as a percentage of the difference
between the initial and final values.
    theta2 is the threshold low expressed as a percentage of the difference
between the initial and final values.

This (along with the pictures) suggests that if the initial value is "high" and the final value is "low", then the percentages should be specified in the order 10 90. What was happening before was some attempt to handle the arguments being specified in the wrong order - but this unfortunately broke a few cases.

So the key difference is that the arguments are not supposed to be specified the same way - for rise time you should  specify the initialValue as the "low" value, adn the finalValue as  the "high", and then specify the percentages as (say) 10 then 90. For fallTime you should specify the initialValue as the "high" and finalValue as the "low", and then the percentages as 10 and 90 again.

What we ultimately want to do is make this unambiguous so that you always know that fallTIme is finding a falling edge and riseTime a rising edge. The challenge is that since these functions are already "out there" we may have to support the way they work currently because otherwise we're at risk of breaking somebody's measurements if they've specified them with the arguments counter to the documentation (in fact that was why it broke in the first place, because somebody tried to correct the behaviour without checking what the documentation said).

Regards,

Andrew.

 Hello Andrew

I  am currently facing the same problem with regarding to rise and fall time . whatever variation in the width of the Nfet and Pfet chain is resulting in  same rise and fall time. I was wondering what is ISR and how can i know which version of ISR i am currently using inoder to over come the problem

That doesn't sound as if it's the same issue, but Help->About in the CIW will tell you the subversion. You can also type getVersion(t)  in the CIW input pane and see what it tells you.

The version will be something like  IC6.1.5.500.17 - the bit after the .500 tells you the ISR number (so ISR17 in this case).

Regards,

Andrew.

Hi Andrew, 

This is what I am doing for the 'Fall Time'

 Initial Value= 1.1

 Final Value = 0

 Percentage High = 90

 Percentage Low = 10

And it gives me exactly the same readings as taken for the RiseTime, ( I have followed the documentation for giving inputs for the rise time),

 I am confused following the above post though I understood clearly, Please help, 

Thank you,

Kind Regards,