How is the input transition time used in calculating input d

[Rajat Mitra]

For a certain design I have the following constraint -

set_input_delay 100 -max -clock SYSCLK <other options> pin_MDQ_15
set_input_transition 10 -clock SYSCLK [all_inputs]

Then when I do a
report_timing .<options> -transition <other_options>

In the timing report for pin_MDQ_15 as a start point I see the transition
time column
column with the correct transition time but the transition time appears not
to be used
in determing the incremental delay. This is actually the canse for just
about every timing
report I have seen come out of primetime that the transition time on the
net is never factored
into the delay calculation.

Any idea why ???

Rajat Mitra

 

[Avrum]

The propagation delay of a CMOS cell (a gate/buffer/etc...) is generally a
function of two things, the capacitance on the output of the cell, and the
transition time of the input to the cell. The exact relationship between
these two variables and the delay through the cell is determined by the
design of the cell in question, and is therefore different for each cell in
each library. As a result, it is up to the library vendor to provide this
information to Synopsys (DesignCompiler/PrimeTime) for each cell. This is
done in the technology library (.lib or equivalent) file.

For each cell, Synopsys allows for two tables for timing, one for
calculating the propagation delay through the cell, and one for calculating
the transition delay on the output of the cell. The propagation delay table
consists of NxM values that represent the propagation time for the cell at
different combinations of output load and input transition. Along with each
table is a list of the N capacitance values, and the M input transition
times, that are the independent variables for the table in question...

So, for example, the cell can be characterized at loads of 0.1pF, 1pF, and
10pF (these would then be the load values for the N columns), and at input
transition times of 0.1ns, 0.5ns, 2ns. Then, if the table were

0.1pF 1pF 10pF
-------------------
0.1ns 0.12 0.34 3.25
0.5ns 0.23 0.45 3.67
2ns 2.44 2.66 4.99

the table would be interpreted as follows;

For an input transition of 0.1ns, and an output load of 1pF, the delay
through the cell would be 0.34ns
For an input transition of 2ns, and an output load of 10pF, the delay
through the cell would be 4.99ns

When Synopsys needs to calculate the propagation delay through a cell, it
uses this table to interpolate the actual delay using the load/transition
for the cell. A similar table (with different combinations of loads and
transition times) is used to calculate the output transition time of the
cell (which is used for the input transition of the following cells).

So, by changing the input transition time on a primary input (your
pin_MDQ_15), you are changing one of the variables used in the delay
calculation of the cells connected to that pin/net. In the case of a primary
input, this will change the propagation delay through the input buffer.

If the table for the input buffer, supplied by the ASIC library vendor,
doesn't have any variation with input transition (i.e. the table has the
same value for all input transition times), then changing the input
transition time would not have any effect on the delay.

Of course, this only applies in the cases where you allow DC/PT to do delay
CALCULATION - if you are using annotated delays (you read in an .sdf file),
then the delay through the cell is completely determined by the value in the
..sdf file; the input slope/output load is completely irrelevent to DC/PT
(after annotation). This is something that is often overlooked; if you want
to experiment with different loads/slopes on your primary inputs/outputs
after extraction, you must provide these values to the tool that GENERATES
the .sdf file, and generate different .sdf files.

Avrum


"Rajat Mitra" <rajsaima@yahoo.com> wrote in message
news:2u-dnRr3NPTTQtTeRVn-uw@rcn.net...

For a certain design I have the following constraint -

set_input_delay 100 -max -clock SYSCLK <other options> pin_MDQ_15
set_input_transition 10 -clock SYSCLK [all_inputs]

Then when I do a
report_timing .<options> -transition <other_options

In the timing report for pin_MDQ_15 as a start point I see the transition
time column
column with the correct transition time but the transition time appears
not
to be used
in determing the incremental delay. This is actually the canse for just
about every timing
report I have seen come out of primetime that the transition time on the
net is never factored
into the delay calculation.

Any idea why ???

Rajat Mitra

 

[Rajat Mitra]

Hello Avrum,
Thanks for the detailed analysis of this problem. Your are absolutely
right,
after I set the transition delay and load cap to one that was included in
the cell's Transition Time
Vs Load Cap table, the corresponding incremental delay correctly got
accounted for
in the path timing report.
I had suspected this; since I came across a similar issue when
I was using the LIB files for doing power calculation couple of years ago.
There I was
specifing a transtion time that was not supported by the energy template and
I was getting
0 power dissipation for that cell eventhough it had a fair amount of toggle
activity.

Again thanks much for your help,

Rajat Mitra
"Avrum" <noasvpraumm@nospamsympatico.ca> wrote in message
news:xbF2f.3469$S43.308211@news20.bellglobal.com...

The propagation delay of a CMOS cell (a gate/buffer/etc...) is generally a
function of two things, the capacitance on the output of the cell, and the
transition time of the input to the cell. The exact relationship between
these two variables and the delay through the cell is determined by the
design of the cell in question, and is therefore different for each cell
in
each library. As a result, it is up to the library vendor to provide this
information to Synopsys (DesignCompiler/PrimeTime) for each cell. This is
done in the technology library (.lib or equivalent) file.

For each cell, Synopsys allows for two tables for timing, one for
calculating the propagation delay through the cell, and one for
calculating
the transition delay on the output of the cell. The propagation delay
table
consists of NxM values that represent the propagation time for the cell at
different combinations of output load and input transition. Along with
each
table is a list of the N capacitance values, and the M input transition
times, that are the independent variables for the table in question...

So, for example, the cell can be characterized at loads of 0.1pF, 1pF, and
10pF (these would then be the load values for the N columns), and at input
transition times of 0.1ns, 0.5ns, 2ns. Then, if the table were

0.1pF 1pF 10pF
-------------------
0.1ns 0.12 0.34 3.25
0.5ns 0.23 0.45 3.67
2ns 2.44 2.66 4.99

the table would be interpreted as follows;

For an input transition of 0.1ns, and an output load of 1pF, the delay
through the cell would be 0.34ns
For an input transition of 2ns, and an output load of 10pF, the delay
through the cell would be 4.99ns

When Synopsys needs to calculate the propagation delay through a cell, it
uses this table to interpolate the actual delay using the load/transition
for the cell. A similar table (with different combinations of loads and
transition times) is used to calculate the output transition time of the
cell (which is used for the input transition of the following cells).

So, by changing the input transition time on a primary input (your
pin_MDQ_15), you are changing one of the variables used in the delay
calculation of the cells connected to that pin/net. In the case of a
primary
input, this will change the propagation delay through the input buffer.

If the table for the input buffer, supplied by the ASIC library vendor,
doesn't have any variation with input transition (i.e. the table has the
same value for all input transition times), then changing the input
transition time would not have any effect on the delay.

Of course, this only applies in the cases where you allow DC/PT to do
delay
CALCULATION - if you are using annotated delays (you read in an .sdf
file),
then the delay through the cell is completely determined by the value in
the
.sdf file; the input slope/output load is completely irrelevent to DC/PT
(after annotation). This is something that is often overlooked; if you
want
to experiment with different loads/slopes on your primary inputs/outputs
after extraction, you must provide these values to the tool that GENERATES
the .sdf file, and generate different .sdf files.

Avrum


"Rajat Mitra" <rajsaima@yahoo.com> wrote in message
news:2u-dnRr3NPTTQtTeRVn-uw@rcn.net...
For a certain design I have the following constraint -

set_input_delay 100 -max -clock SYSCLK <other options> pin_MDQ_15
set_input_transition 10 -clock SYSCLK [all_inputs]

Then when I do a
report_timing .<options> -transition <other_options

In the timing report for pin_MDQ_15 as a start point I see the
transition
time column
column with the correct transition time but the transition time appears
not
to be used
in determing the incremental delay. This is actually the canse for just
about every timing
report I have seen come out of primetime that the transition time on
the
net is never factored
into the delay calculation.

Any idea why ???

Rajat Mitra