Browse Prior Art Database

Design-Verification Ecosystem

IP.com Disclosure Number: IPCOM000235874D
Publication Date: 2014-Mar-28
Document File: 6 page(s) / 120K

Publishing Venue

The IP.com Prior Art Database

Abstract

This paper proposes a Design Verification Ecosystem, a platform to track logic changes iteratively , assign verification scope for each processed change and trigger cross communication between teams for sustain sign off and closusre of the changes.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 36% of the total text.

Page 01 of 6

Design-Verification Ecosystem

Complexity of hardware design and pressure of time to market is increasing day by day. In such a competitive model any bug in design can cost varying up to millions to company if they found later stage of project executions. With such a complex designs companies are investing most of money in verification but still not able to guarantee is our design is bug free or not. This paper is proposing here an ecosystem which has its footprint all from architecture to execution of design.

 This paper is trying to address some of obvious reason of bugs causing delay in Tapeout .

1. Cross team communication for complete sign-off of a design change/new feature. : Communication play vital role in verification plans there is several obvious cases where improper communication leads to serious bugs in logic. Designer communication to verification teams on changes in time , Verification team overlooking information given by designer and many more scenarios can lead to a unintentional bug.

2. How to track intermediate Design Change ?: Design changes that does not impact the current functionality might not be caught by the verification environment.

3. Iteratively review throughout the define project cycle.(discrete to continuous ) 4. Health monitoring of project :- detect intermediate spikes

5. How Boost up Verification efforts and to speculated more robust Tapeout :- Every company,group has their own sign-off criteria, checklist to forecast tape out date but there always a struggle or push in the end because of late detected bug.

6. How to make sure every RTL change is detected and Verified ? Testplan design by verification engineer never guarantee either its plan to verify all features or not.

7. What is the scope of verification required for every change ? Scope of verification of a function is always limited by the boundary of the logic . Having a clarity on the sequence , method and scope of feature being verified at each level - unit, chip , system and assignment of the same via proper channel that can be tracked is need of the hour.

1


Page 02 of 6

Problem also highlighted using below figure.

To Target some of the obvious reason of having bugs in chip one need to come up with more robust DV ecosystem that ensure each and every logic change (e.g feature addition, logic fix ,non functional changes) must identified and verified in the end , speculate in tapeout and increase turn around time. To achieve this goal ecosystem is build with a hybrid methodology that inspire from both Waterfall model and Agile methodology but thoroughly customized for HW needs. Methodology tracks each and every changes right from RTL level and convert each changes into verification sub task with a logic designer intervention and routes to respective verification team. This Methodology triggers its iterative mode once base/stable state reach and continue end of project. Each iteration has its unique task that need to be verified and close t...