FPGA Central

Hi All,
In an earlier post we had discussed gate level simulation post
synthesis and members of the group pointed out that gate level
simulation is best done post layout so that we have the SDF file
available. Also, $sdf_annotate will override the delays in the specify
blocks of the technology cells provided by the library vendor. I did
notice that Design Compiler has an option 'write_sdf <filename>'. My
guess was that DC would generate a file that would have INTERCONNECT
delays based on the wire load model specified in the library. Indeed I
see INTERCONNECTs for every path in my design but they all come as
0:0:0. Can anyone shed any light on what write_sdf is basically trying
to do? It does not look like it is generating a delay file based on
the information from the tech library -- at least the net
interconnects should then not be all 0s.

Thanks and Regards,
Arpan

Hi Arpan.

First of all, the default value in the specify block is just a
placeholder.
That is meant to be replaced by the sdf.

What dc is doing is:

- calculate the load seen by each cell. This will be the actual C of
all the input pins being fanout by the driver, plus an estimation of
R, C due to the net. The amount will come from the wireload model
tables, if the library has them (in 90nm and smaller this is really a
useless approximation)
- use the library files to calculate, based on the load, what will be
the delay of the cell

I have rarely seen (at least in the flow my company uses) interconnect
delays used.
What really is considered important is the delay on the cell only.

I will repeat here the comment I made on the other post: because of
the huge inaccuracy of the wireload models, the estimation of the net
length, R, C, other couplings is ridiculous.

In every technology younger than .13 you'll usually get results way
too optimistic, unless you have small designs.

On Jun 19, 8:19 am, hairyotter <marco.br...@gmail.com> wrote:
> Hi Arpan.
>
> First of all, the default value in the specify block is just a
> placeholder.
> That is meant to be replaced by the sdf.
>
> What dc is doing is:
>
> - calculate the load seen by each cell. This will be the actual C of
> all the input pins being fanout by the driver, plus an estimation of
> R, C due to the net. The amount will come from the wireload model
> tables, if the library has them (in 90nm and smaller this is really a
> useless approximation)
> - use the library files to calculate, based on the load, what will be
> the delay of the cell
>
> I have rarely seen (at least in the flow my company uses) interconnect
> delays used.
> What really is considered important is the delay on the cell only.
>
> I will repeat here the comment I made on the other post: because of
> the huge inaccuracy of the wireload models, the estimation of the net
> length, R, C, other couplings is ridiculous.
>
> In every technology younger than .13 you'll usually get results way
> too optimistic, unless you have small designs.

Hi Marco,
Thank you very much for the response. Couple of questions for you,
note that I am not trying to generate SDF using DC post synthesis from
the perspective of creating a new flow. This is more an academic
pursuit at my end. I hope your response helps in clarifying my
doubts:
1) Post synthesis, I expected the wire load models to have some effect
on the INTERCONNECT delays. My problem is that in the SDF file DC
generates all interconnect delays come as 0s. I am confused as to why
this should happen? I think that you agreed with me on the non-zero
interconnect delay part, the issue is the accuracy of the WLMs.
2) What steps should I take to generate an SDF file in DC that has non-
zero interconnect delays? Any specific command or options would be
very appreciated.

Once again, I look forward communicating with you.

Best Regards,
Arpan

On Fri, 19 Jun 2009 10:25:01 -0700 (PDT), Arpan <arpansen@gmail.com>
wrote:
>1) Post synthesis, I expected the wire load models to have some effect
>on the INTERCONNECT delays. My problem is that in the SDF file DC
>generates all interconnect delays come as 0s. I am confused as to why
>this should happen?

This happens because SDF files are not a representation of a netlist
but representation of delay. When delay is calculated one needs to
know all the pin load plus all the wire load a cell output sees and
this is calculated by the extractor and the delay is calculated. At
that point there is no separate wire delay anymore. There are few
instances that two pin loads of a cell will see different delay times
because of different routing but the difference is quite slow for
current processes so most of the interconnect delay values are 0.
Personally I have seen interconnect values other than 0 but at 1ps
resolution nothing higher than 10 yet (at 65nm). As chips get bigger
and feature sizes get smaller this may change but one also has to
remember that we like to keep connectivity local so most delay
differences because of routing will be quite small indeed.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

I actually just asked someone in my team to check and she confirmed
that indeed (it was a .13 design) the interconnect delays are there,
which does make sense if you have a net with a fanout > 1 and the
different branches are very unbalanced.

I need to doublecheck that the 65nm devices do have interconnect too.

At the same time I think that Muzaffer is right: DC cannot estimate
wire length, so it does not make sense to add interconnects there.
It just lumps all the delay at the output of the driving cell.

We need to check on Solvnet, but alas I have the username/pwd on the
work computer. I'll try later if I power the laptop on

Marco