RTL signoff is comprehensive signoff
I believe that it is a comprehensive series of well-defined MUST-pass requirements that your RTL needs to attain before you commit the design to downstream implementation such as synthesis and physical layout. In addition to this complete set of RTL signoff requirements, you will need the means to measure them against your design as well as reports to ensure compliance.
Some examples of RTL signoff MUST-pass requirements include:
Functional coverage (including high quality assertions)
Clock domain crossings (static and dynamic verification)
Timing constraints (including false and multi-cycle paths)
Power consumption (and meeting the power budget)
Power intent (CPF / UPF correct?)
Testability (stuck-at and at-speed coverage OK?)
Routability (congestion OK; area and timing OK?)
There are other strains of thought, RE: what constitutes reliable RTL signoff. Running SoC designs through rigorous checks of a few to several critical functions certainly saves time and focuses RTL signoff resources on more critical areas where your SoC will most likely have problems.
Traditional signoff: source Atrenta
But that’s a lot like saying a car doesn’t need a chassis and four wheels to roll … that you only need three wheels and the car more than likely will roll fine. It’s a decent bet … but I also wager that a lot of SoC designers would prefer to have the chassis and four wheels approach and be absolutely sure their SoC has signed off at RTL.
What has changed in today’s SoC design to require this RTL signoff mandate? There’s been an explosion in design complexity resulting from hyper integration of multiple functions on a single chip. Compounding this issue, increasing reliance on externally sourced semiconductor Intellectual Property (IP) content, both from 3rd party suppliers and from other design groups within the same company, impedes the quality assurance process.
In many cases, the SoC replaces an entire printed circuit board (PCB) in a previous generation device, or the entire device itself. What does this mean to the SoC? A surge of functionality (computing, audio, video, wireless, gaming, external interfaces, memory interfaces, power management, etc.) is crammed into a single chip the size of your thumbnail.
We are beginning to see SoC designs with more than a billion gates. It is a staggering task to ensure that all SoC functions work seamlessly, that the device can be manufactured reliably, is cost effective, has hours of battery life, and responds instantly to your every command. Although we expect no less from our electronic devices, meeting all these requirements can be quite overwhelming.
The explosion in design complexity is further compounded by very short market windows and shrinking product cycles – sometimes windows of only 3-6 months – turning 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 outside the SoC team. Using proven IP content reduces content design risk, but still leaves risk in assembly and “spec” compliance. IP are not yet plug-and-play and are open to bugs, misuse, abuse, and surprises when used outside tested configurations. Any of these issues can derail a project plan that previously appeared risk-free and on-track.
RTL signoff, however, can be the preventative medicine a designer needs, and here’s why:
It can contribute a 60% reduction in design risk because:
RTL tools run faster than layout tools, which allows you to find and fix a lot more problems at RTL, per unit of time, than you can at synthesis or layout.
Higher quality RTL reduces risk of iterations from synthesis or layout back to RTL. As we all know, a restart of design layout is very expensive.
RTL signoff can be applied very effectively to IP, both internal and external. Since most IP is sourced as RTL, signoff checks can and must be enforced as part of handoff requirements from the IP supplier, and as acceptance checks by the SoC team. When dealing with configurable IP, there is no guarantee the configuration you want to use in your SoC has been thoroughly validated by your supplier.
RTL signoff: source Atrenta
A rigorous IP signoff methodology at RTL also enables significant efficiencies for SoC level RTL signoff (SoC signoff). At the SoC level, you must validate assumptions in the IP and make necessary tweaks when the two are not in sync. Once validated, the SoC level signoff can focus on IP integration and common place issues at the top level. It should not be necessary to validate the internals of IP at this stage, as long as you can intelligently abstract IP validation models. Abstraction can drive an order of magnitude improvement in analysis time and hardware requirements. Ultimately it leads to a significantly simplified signoff flow.
For 2014, RTL signoff is no longer a choice … It is a design imperative!
For a number of years now, leading edge SoC design teams have been practicing and reaping the benefits of RTL signoff, and it is now included in mainstream SoC design flows. If RTL signoff is not part of your methodology, it should be! Selective checklists are not a substitute for a comprehensive and disciplined approach. You would never sign off layout with selective checks. So, why would you accept anything less than comprehensive RTL signoff?
About the author
By Piyush Sancheti is Vice President, Marketing at Atrenta Inc. – www.atrenta.com
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
