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
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.
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