The document discusses methodologies for improving efficiency in verification testing at Cisco, including using reusable components from other projects, avoiding duplicate specifications, providing flexible testbenches, and automating tasks. It provides examples used at Cisco such as separating testbench creation into three stages, using testflow to synchronize component behavior, reusing unit-level checkers, linking transactions between checkers, and generating common infrastructure from templates to reduce designer effort. The biggest efficiency gains come from methodologies that push shared behavior into reusable components and standardize common elements.

1. 1© 2006 Cisco Systems, Inc. All rights reserved.
Efficiency Through Methodology
DV Club RTP
Mark Strickland
October 18, 2006

2. 222© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006
Challenge of Verification
Quality
(all bugs found)
Schedule
and Resources

3. 333© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006
How to Meet the Challenge
• Efficiency – get the most from your time
Use components from other projects
Don't specify behavior twice in the same project
Don't specify standard behavior that can be inferred at
instantiation
Provide flexibility to meet all late-stage needs
Let automation do a lot of the work
Eliminate decisions regarding infrastructure
Describe testbench concisely
Run simulations faster
languagemethodology

4. 444© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006
Some Examples Used at Cisco
• A high-level overview of some reuse methodology
techniques that we use at Cisco follows …

5. 555© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006
Three Stages of Testbench Creation
• Component Design
Want to describe the behavior of the component with
minimal code to support the needs of the next stages
• Testbench Integration
Want to specify only components and interconnections,
instance-specific constraints and initialization
• Testcase Creation
Want to specify only valid configuration space and
sequences of constrained data (for the most part);
everything else is a necessary evil
May be done by those with shallower language knowledge

6. 666© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006
Testflow
• The Issue: Sometimes all components must finish
an activity (e.g. reset) before any of them moves on
• Solution: A built-in testflow
–Testcase specifies unique behavior for each phase
–Testbench integration specifies standard behavior for
each phase
–Component starts processes in appropriate phase
–None of these has to worry about synchronization of
behavior between components

7. 777© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006
Unit-Level Benches and Reuse
• Unit-level benches offer best control of stimulus
and visibility of results
• Reuse of unit-level checkers avoids creating new
chip-level checkers that could be complex in cases
such as dropped packets
• Problem: Specification inconsistencies between
two blocks can be missed
to reset B,
send 10
Block A
reset if 11
received
Block B
checker A
Scenario: A tries to reset B 10 is sent no reset of B
checker B

8. 888© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006
Transaction Linking
• Each checker that corresponds to a block that
passes information to the next block contributes to
building a linked list of the information hops
• Each checker where information terminates (with
some effect) traverses the linked list to find the
source and the intent at that source
Transaction linking is also a great debug aid

9. 999© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006
Templates and Generators
• Burden falls on the component designer
• The infrastructure of components can be made in a
common manner
• This commonality can be captured in templates and
generators, allowing the designer to focus on the
particulars of the component

10. 101010© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006
Summary
• Biggest efficiency gains from methodology
– If code was in the same language but did not include
testflow, transaction linking, and the testcase / integration /
component separation, it would not help much if at all
• Push most behavior into the components that can
be used by many testbenches which in turn can be
used by many tests
• Make the component designer's job easier by
standardizing common pieces into templates