Role of Static Sign-Off Tools vs. Methodology2019-09-18T20:28:18-07:00

The Role of Static Sign-Off Tools vs Methodology

DAC 2019 panel presentation by Oren Katzir of Real Intent (edited transcript)

Presentation Overview

Oren Katzir of Real Intent presented on the interrelated role of tools vs methodologies for static sign off.

Static Sign-Off Goal: Move toward Ideal Verification Method

Prakash showed this schematic with the different angles of the kinds of verification you can do and the flaws with each type of verification.  Each one has some flaws.

Ideally, if I could use a tool that could reduce the noise to accelerate sign-off, I’d have exhaustive coverage and would reduce simulation and synthesis issues and iterations right at the beginning of my flow. That’s what I would want to do as an engineer.

Best Practice #1: Two-step Early Functional Verification

Ten years ago, there was hardly any usage of static checking. You would write RTL and run simulations.

These days it’s mainstream. People are using static everywhere — linting RTL, RDC, AutoFormal, CDC, DFT, and more.

The power is clear. We’re getting advantages by finding issues early in the flow, iterating faster, and getting to that cleaner RTL before even going to simulation and synthesis.

Best Practice #2: Implement Complete CDC & RDC Sign-Off

If you have simple designs you don’t necessarily have to go to the most complex tool, the most complex technology. e.g.  you can use single-mode CDC, and then use multi-mode CDC where you do need it.

You need to complete the RTL verification with gate-level analysis for some of the aspects such as DFT, lint, and CDC.

Static Sign-off Methodology vs Tools

How can you implement the things you care about versus the generic tool? I’ll take an example from lint. Some people who want to implement a lint methodology ask for a “default lint policy”.

My response is there is no default lint policy.

We believe that you start with methodology. What are the things you want to check– for lint, for DFT for CDC, for RDC and so on?

You further refine the configuration based on your initial results, and then work with your tool vendors and the key methodology people to align your tools with your methodology.  Not vice versa.

You want to start with methodology, work with tool vendors, work with technology experts, and refine your policies, refine your checks; and in parallel to that – enable a strong debugging environment.

Static Sign-Off Methodology Results

What’s the impact of using such an approach? These are just two examples.

One company that we started to work with, was struggling with 1-2 months of their design team; they said it was basically tens of engineering-months — on every project in debugging and waiving lint, CDC, and RDC issues.

We worked with them to apply their methodology in our tool and force their rules. They were able to refine the flow and deploy continuous integration, and reported very significant time savings.

Another company had basically multiple bug escapes due to insufficient checks, primarily because they never finished all their checks before tape-out because of run times and capacity issues.

We were able to define stricter rules and increase the performance – enabling them to run their entire design, all the way to full chip.

For some areas, they reported a reduction of 10X-100X of their effort on static. And they basically enforced all of the checks they wanted to enforce on full chip significant bugs to avoid escapes.

That’s it. Thank you very much.