Lately, I have been hearing from a lot of customers using some of the big EDA place-and-route tools that they need to tune resistance and capacitance factors to achieve good timing correlation to sign-off tools for 65 and 40 nm designs. This started to make me wonder why is this needed.

I dug deeper with a few of the current and potential customers to find that things were O.K. at 90 nm and above, but, with 65 nm and below designs, the prediction by P&R tools of timing critical paths vastly differs from that of sign-off tools. Let’s first examine various things that may differ between implementation and sign-off:

a. R/C extraction
b. Timers (NLDM-based non-SI timing analysis)
c. Delta-delay (SI)-based timing analysis
d. Settings between implementation and sign-off tools

Let’s talk about this in more detail:

a. R/C extraction

Lower geometry nodes demand more from extraction engines because there will be more wires packed in a given square micron area as compared to higher geometry nodes. In addition, there are more things being demanded from foundries to be considered while doing extraction. Typically, sign-off extractors are 3D type and can model these effects in a most precise way. With implementation tools, the extractors are 2D, or 2.5D at the most, and it becomes a challenge to make up for that last 0.5D inaccuracy. One way to make up for this inaccuracy is by tuning R/C factors in the implementation tool.

In addition, extracting the right coupling caps is also important, since they will directly contribute to crosstalk effects. I once heard a customer saying that a certain company just told them that the difference in coupling caps is given and you need to rely on the sign-off tool’s extracted data (mostly SPEF) to get the right correlation!

b. Timers

Most P&R tools seem to have nailed down this part well, and mostly I see it as a problem a generation ago (i.e., designs at 130 nm or 90 nm). So, assuming you got the right R/C numbers plugged in, the design can be timed accurately.

c. Delta-delay (SI)-based timing analysis

Your implementation tool needs to predict the right crosstalk(delta-delay) values on each timing path based on the sign-off tool you are using. Mostly, people use PTSI or Celtic to compute the SI effects. Both of these tools use different heuristics, and most of the P&R tools in the market are tuned to work with one of the sign-off tools. So, what if you own the sign-off tool from one company and implementation tool from the other? Most likely, you are hosed!!!! This is like the fox guarding the hen house, since you are forced to buy both sign-off and implementation tools from the same company to achieve results correlated to sign-off. Having said that, there are designers out there who have found a way to address this. One of the ways is by tuning the R/C factors. I won’t even touch the topic of implementation and sign-off tools from the same company and still not achieving the desired timing closure. I simply consider that as a bug in that tool!

d. Settings between implementation and sign-off tools

A mostly overlooked part of the correlation process is that your sign-off tool runs at one setting to get better accuracy, but your implementation tool runs at a different setting to get better runtime. Lots of times, there are settings in your sign-off tool that are missing in the implementation tool. There is no way for you to match for those missing knobs, and your only resort is to make some adjustments to R/C factors or add some more margin in the design.

This brings me back to my original question: is it possible to achieve correlated results to sign-off without really tuning the R/C factors? The answer to this is yes, it’s possible. Using Aprisa, we have demonstrated to multiple semiconductor companies that it is possible to get correlated timing closure at 65 nm and below. What I am hearing and have seen with other tools is that their architecture won’t allow the desired scalability to address some of the issues I discussed here, since when they were designed, they were designed to solve different problems that existed at those tech nodes.

I won’t talk about how it is done in Aprisa, but if you are interested, you can invite the sales team to talk about it. ☺