10

Click here to load reader

Efficiency Through Methodology

  • Upload
    dvclub

  • View
    81

  • Download
    1

Embed Size (px)

Citation preview

Page 1: Efficiency Through Methodology

1© 2006 Cisco Systems, Inc. All rights reserved.

Efficiency Through Methodology

DV Club RTPMark Strickland

October 18, 2006

Page 2: Efficiency Through Methodology

222© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006

Challenge of Verification

Quality (all bugs found)

Schedule and Resources

Page 3: Efficiency Through Methodology

333© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006

How to Meet the Challenge

• Efficiency – get the most from your timeUse 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

languagem

ethodology

Page 4: Efficiency Through Methodology

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 …

Page 5: Efficiency Through Methodology

555© 2006 Cisco Systems, Inc. All rights reserved.DV Club Oct. 2006

Three Stages of Testbench Creation

• Component DesignWant to describe the behavior of the component with minimal code to support the needs of the next stages

• Testbench IntegrationWant to specify only components and interconnections, instance-specific constraints and initialization

• Testcase CreationWant 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

Page 6: Efficiency Through Methodology

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

Page 7: Efficiency Through Methodology

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 Areset if 11 received

Block B

checker A

Scenario: A tries to reset B 10 is sent no reset of B

checker B

Page 8: Efficiency Through Methodology

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

Page 9: Efficiency Through Methodology

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

Page 10: Efficiency Through Methodology

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