System Design Frontier with Exclusive Coverage on IC Design and Software Engineering from Hometown Innovation Automation Inc- Journal Page

 Frontier Journal       

Exclusive Frontier Coverage on System Design              Vol. 2 No. 2 Feb 2005

            Guest Editorial How Shall We Build Chips to Work in This Century? - Cadence

Nanometer Physical Verification

DSL Anywhere Whitepaper ¨C Part III

The PDA Challenge

Reliability Modeling of SCI Ring-based Topologies

Studying Cooperation and Conflict between Authors with History Flow Visualizations



GUEST EDITORIAL

 

How Shall We Build Chips to Work in This Century?

 

Michael McNamara

Senior Vice President of Technology, Verisity Ltd.

First someone must decide what we want the circuit to do. Typically Marketing, Sales and Engineering working together define the product requirements. With this in hand, Engineering begins implementation.

In the last century, design engineers would start defining their portions of the design. After a few months, verification engineers would be brought in to begin writing tests exploring the behavior of the design given typical inputs; and once all the features were implemented, and the rate of finding new bugs begins to drop off, the project manager would ask the million dollar question of the verification team: ¡°How good is the design? Is it ready to tape out?¡± The verification manager, relying on his years of experience, and after poring over test results, would say, ¡°I feel good! Let us release the chip to manufacturing.¡± Victory would be declared, and the chip would be shipped to manufacturing. 3 months later the team would learn whether they¡¯d built a rock, or chip that functioned enough so that the inevitable bugs could be avoided using clever software techniques.

In this century, such an unplanned process will not work. Numerous examples in the field demonstrate this, where high profile design projects require re-spins as the first silicon fails to work. ¡°Hmm, we should have tested that,¡± is an unacceptable observation heard just before the design team is laid off, or the company¡¯s doors are closed. Clearly we must apply engineering management principles to the design and verification process. We must define objective criteria, or metrics, to use to measure our progress towards implementing the design. We must on a regular basis, examine our progress towards our goals, and then redeploy resources to address areas where we are falling behind. Fundamentally, we must automate the verification process.

You must have metrics

Most IC verification teams have a good deal of experience and skill. And in fact, many project managers also have great confidence in their team, based in most cases, on decent track records.

What they don't have is a way to allow them to more accurately predict and plan the process steps that lead toward verification closure. The solution lies in metrics: simple, succinct measures, or indicators, of a project's progress.

Overwhelmingly the industry has found that coverage is a good indicator of the quality of verification. Total coverage is a combination of functional, code, and assertion coverage, and when combined, monitored, and measured, it is a powerful metric by which to manage projects. There are many tools in the market place that collect information on one or more of these coverage metrics; what is also needed is something that gathers together the information from these diverse sources and provides a unified view over the complete state of the project. It is great to get information from the front lines; but if the general has to read every line of every report in order to decide what to do next, the battle will be lost.

Then you need to tools to manage the metrics

Let¡¯s look briefly at the technologies you¡¯ll need to take advantage of automation at the process management level.

First, you¡¯ll need to manage "sessions", groups of simulations that verify various parts of the device or system under test. Session management gives you the ability to launch and track parallel simulations.

Next, you will need methods for automated failure triage, facilitating rapid identification of the more important simulation failures. By focusing the team on the set of defects that are implicated in most of the sessions failures, allows the most rapid improvement in the over all design quality. This type of automation eliminates hours or even days of work that is traditionally done manually.

It¡¯s important to perform automated coverage analysis against the original verification plan. This enables engineers to create unique simulations and frees them from performing redundant tasks.

Finally, a comprehensive verification process automation strategy provides managers simply methods to rapidly create and share reports. Overall status reports as well as scope-specific reports are vital for assessing progress and identifying where adjustments need to be made in resource allocation, which brings me full circle:

To achieve major productivity improvements in verification we must deploy a process-oriented approach. We must step back and re-examine what we are and are not doing at the system and project level. We must then deploy a tool set and process that constantly extracts metrics upon which we will base critical management decisions. We must examine implementation tools we plan to use, and select those that generate data in a form that can be used by our metric measurement infrastructure.

It¡¯s all about improving predictability. And I guarantee that this is the approach that will make you successful going forward.

 

 

Back to Joural Home Page

Back to Home Page