One of the most convincing stories you can hear from any big EDA marketing person is that crosstalk is something which can only show up after the routes are laid down and thus needs to be fixed as a post-process step after routing. In theory, this looks reasonable since without real knowledge of the wires how can you predict coupling between them? But, if you step back and look at this from 1000 ft view, the same theory can apply to computing wire delays. Without routing how can you predict the wire delay and thus you need to route the design to accurately predict wire delays. But wait, how are we doing placement and placement-based optimization, CTS and post-clock optimization?

I recently surveyed few of my customers and P&R designers to check on how the big “three” handles SI in their flow:

Here is what I found/heard:

Company A : Detail Route the design. Fix all the regular timing. Turn on SI aware timing and do SI based timing optimization.

Company B : Route the design and later do SI based timing analysis and fix the regular and SI based timing. All this may be clubbed into one name but if you look at the logfile you can see the obvious!

Company C : They try to do some SI prevention during global routing based on heuristics and later some quick optimization following track assignment. Later post-detail routing, if you still have SI based timing violations left, you need to run post-route timing optimization.

The question anyone can have is what is wrong with the above approaches? These are perfectly valid approaches at 90nm or 130nm where SI was not significant in the designs. At 90nm, I know designers who’ll add 100ps extra margin to account for SI and not really do SI based timing analysis in implementation tool. They will just do it in sign-off tool and later run few ECOs to fix timing on outlier paths. There were several reasons for not doing SI based timing optimization in P&R tool:

a. P&R tool’s SI numbers wont correlate with sign-off tool’s SI prediction.
b. P&R tools runs really slow especially timer and extractor in post-route mode. So, if you want to do SI based timing optimization during post-route you are talking in days.
c. SI effects were not significant at 90 and 130nm. So, you can add extra margin and/or run few ECOs to close timing.

All this is changing at 65nm and 40nm. The crosstalk based timing effects are really significant. I have seen 500ps to 1ns difference in timing when between regular and crosstalk aware analysis. This is huge and cannot be solved by doing ECOs or adding 100ps or so margin.

So, all the designers who are working at 65nm and below are forced to run crosstalk aware timing closure flow in the P&R tool. The result be it company A, B or C, runtimes are loooong and no guarantee of complete SI based timing closure or correlation to sign-off tools (see my other post Myth # 9 : I need to tune R and C factors to get good correlation to sign-off tools and achieve predictable timing closure). While talking to one of my friend, I found that post-route SI aware timing optimization took 3.5 days in one tool and still it was not clean. Later, they did several (more than 10) ECOs for next 2 weeks to get timing closure!

This brings me back to my initial question: Crosstalk aware optimization is possible in post-route stage only? The answer is no. Any company, who wants you to believe otherwise are trying to hide the fundamental limitations with their P&R software to handle this effect appropriately.

Let me talk about how AtopTech’s Aprisa has tried to address this very issue. Instead of thinking about SI as a post-route issue, it is handled more in-line in the tool as any other thing like doing CTS or placement. Crosstalk prevention and fixing starts as soon as the global route is laid out. Here, actual optimization engine is called to optimize the design to fix and prevent crosstalk based timing effects. All this is not done based on some heuristics but actual timing windows etc. to accurately fix the problems where they will get reported by the sign-off tool. To do all this, P&R tool needs ultra-fast timer and extraction engines. Not only that, timer as well as extraction engines need to incremental to get to the next violating path faster. Both of this is achieved in Aprisa with help of multi-threaded extractor and timer. In addition, after doing global route and track assignment based SI fixing, the same is done during and after detail routing. Again, fast timer/extractor makes it possible to achieve timing closure in real time and not waiting for days to figure out if the design will be ultimately timing and routing clean.

In summary, if you are still struggling with timing closure on your chip, I will strongly recommend to challenge the methodologies setup for crosstalk aware timing closure…