The requirements for complete RTL signoff

By Piyush Sancheti |  No Comments  |  Posted: October 16, 2013
Topics/Categories: EDA - IC Implementation, Verification  |  Tags: ,  | Organizations:

Piyush Sancheti, vice president of product marketing at Atrenta.Piyush Sancheti is vice president of product marketing at Atrenta. He has more than 18 years of experience in marketing, sales, business development, and engineering. He has previously held senior positions at Cadence Design Systems, Sente, and Sequence Design.

When you have a project targeting 28nm with more than a couple hundred million gates there are dire consequences if you find you need to re-spin the design due to errors turning up after the place-and-route phase.

Problems become much more expensive to fix after the place-and-route stage than they are when everything can still be represented as RTL. For this reason, SoC design teams are thinking seriously about RTL signoff as an integral part of their design flow.

It seems to me that the more comprehensively defined the RTL signoff is, the more likely your SoC will tape out on time and in budget after post-layout signoff. But beyond this, it is important to start defining the specifics of RTL signoff and decide how safe the design needs to be before it gets to post-layout signoff. I see two major challenges with today’s SoCs that necessitate RTL signoff:

The increasing complexity of SoC design that complicates chip assembly and validation

The varied quality of third party IP that hinders the quality assurance process.

RTL signoff is not a new term but no clearly articulated definition yet exists. In my opinion, RTL signoff stands for a series of well-defined must-pass requirements that your design needs to achieve at the RTL level before moving to the next phase in the design flow, which is most likely physical synthesis, and place-and-route. These must-pass requirements include:

  • good functional coverage (including high quality assertions),
  • proven-correct clock domain crossings (static and dynamic verification),
  • accurately specified timing constraints (including false and multi-cycle paths),
  • optimal power consumption (and meeting the power budget),
  • verified-correct power intent (CPF/UPF),
  • acceptable testability (stuck-at and at-speed coverage),
  • efficient routing (congestion, area and timing).

Running checks at RTL will detect a lot of these issues. Once possible problems are corrected, post-layout signoff will have an easier job sending the design to tapeout. There are further advantages to RTL signoff. Shorter runtimes – often an order of magnitude better than at the physical stage – can lead to a 30 to 50 per cent net gain in overall design time.

If your RTL tools have good quality of results, you can simply find and fix a lot more problems per unit of time and, at the same time, avoid complete design respins. This is not to say that you can drop post-layout signoff. Both RTL and post-layout signoff processes are needed, even though some experts have argued that RTL signoff precludes the need for post-layout signoff.

Can you reduce the number of checks below those I listed above? Running SoC designs through rigorous checks of a few to several critical functions probably saves time and focuses RTL signoff resources on where you think your SoC most likely will have problems.

But that’s a lot like riding in a car without a seatbelt. Chances are you’ll be just fine. But if the brakes cease to work, the car goes too fast and flips, or you have interference with another car, you could have a meeting of the minds with the windshield or fly right out the window.

I bet that a lot of SoC designers would prefer to go for the safer ride, to be absolutely sure their SoC has signed off at RTL.

Comments are closed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Siemens EDA
View All Sponsors