slew derate from library

slew_derate_from_library

Can anyone refresh me on this liberty .lib parameter

slew_derate_from_library

The official synopsys documentation is confusing. If I specify slew_derate as 0.5, will all slew values present in .lib derated by 0.5 before being used ??

Thanks in advance

i found this answer in synopsys's site. hope it clarifies ur query.

Clarification on the Value to Be Specified for slew_derate_from_library

Question:

In a library that an intellectual property (IP) vendor gave us, the trip points
were specified as 30 - 70, with a slew-derating value of 0.5. The vendor tells
us that the cells were in fact characterized at 30 - 70 but were extrapolated
to 10 - 90 (that is, they used their own formula to calculate 10 - 90 slew
rates from their measured 30 - 70 numbers). The final extrapolated values were
placed in the lookup tables.

This doesn't look right to me because the cells were effectively characterized
10 - 90, so why not use 10 - 90 as trip points and slew_derate = 1 in the
header? I'm worried that the derating value will cause the final slew to be
derated twice in the end--once from when the vendor extrapolated and another
time by PrimeTime. Am I right to be concerned?

Answer:

The data given to you by the IP vendor is quite common for deep submicron
designs, which have a linear region between 30 and 70. So, if the vendor
characterized the cells as 30 - 70 and extrapolated to 10 - 90, the slew_derate
value that should be specified in the library is calculated as

slew_derate = (70 - 30)/(90 - 10) = 40/80 = 0.5

Your understanding that the final slew will be derated twice is not correct.
When the library contains slew trip points of 30 - 70 and a slew_derate value
of 0.5, PrimeTime will be able to calculate that the cells were characterized
as 30 - 70 and extrapolated to 10 - 90. If the vendor accidentally specified
the slew trip points as 10 - 90 and slew_derate = 0.5, that would indeed be a
problem, and PrimeTime would no longer be able to do correct slew calculations.
Setting trip points as 10 - 90 and slew_derate = 1.0 would work, but accuracy
would be lost, and the tool might generate an RC-004 warning because of that
inaccuracy.

For the most accurate calculations from PrimeTime, the library should specify
the slew trip points as 30 - 70 and slew_derate as 0.5. Setting the slew trip
points as 10 - 90 with slew_derate = 0.5 would be totally wrong in this
characterization situation.

So what the library vendor has done is correct.

rc-004 primetime

Thanks a lot for the very reliable clarification! it answers many questions but I am still left with one question that what is the requirement for slew_derate?
In above example, Vendor could have put 30-70 in .lib and slew_derate=1 and not extrapolate the values to 10-90.
I guess it is something to do with using only linear region and allowing PT to extrapolate correctly.

primetime derate

you are right about that, here is a link on how the trip points are chosen when characterizing for libraries, hope it helps

**broken link removed**

slew derate from lib

Hi Sree,

Thanks a lot! That was a very useful link. (reason for delayed reply is that I couldn't find time to read till today) The answer to my question is perhaps that some timing tools are unable to do the threshold manipulation themselves, and hence find it convenient to use slew_derate param