RTL signoff: A design imperative

This explosion in complexity is further compounded by very short market windows and shrinking product cycles. We are talking windows of 3-6 months sometimes; missing by even a little may transform a healthy profit margin into a significant loss. The need to manage this risk is driving an increased reliance on IP reuse, where a significant portion of the SoC design content comes from sources external to the SoC team. Using proven IP content reduces content design risk, but still leaves risk in assembly and "spec" compliance. IPs are not yet plug-and-play and are open to bugs, misuse and surprises when used outside tested configurations. Any of these problems can derail a project plan that seemed risk-free and on-track.

RTL signoff can address these issues quite effectively, and here's why:

• I believe it can contribute a 30-50% reduction in design schedule (or, if you prefer, a 30-50% reduction in design schedule risk):

1. In part because RTL tools run faster than layout tools; you can find and fix a lot more problems at RTL, per unit of time, than you can at layout.
2. In part, because higher quality RTL reduces risk of iteration from layout back to RTL. Problems caught at layout requiring an RTL change are expensive since they can force a restart of layout design.

In the current competitive climate, RTL signoff is no longer a choice; it is a design imperative. Leading edge SoC design teams have been reaping the benefits of RTL signoff for some years now. It has now made its way into mainstream SoC design flows. If you are not doing it, you should be! Patchwork checklists or ad hoc collection of tools are not a substitute for a disciplined approach. You wouldn't signoff layout with a patchwork of checks, you shouldn't accept anything less than a comparable solution for RTL.

?? 1???2