Browse Prior Art Database

Tri-Sect: A Tool for Tri-Section (Feature, Cause and Effect) Analysis for any Verification Platform

IP.com Disclosure Number: IPCOM000241889D
Publication Date: 2015-Jun-05
Document File: 5 page(s) / 262K

Publishing Venue

The IP.com Prior Art Database

Abstract

While verifying a feature of a DUT (Design Under Test), configurations are done and stimulus is applied and then the behavior of the DUT is compared with an expected behavior. If the behaviors match, the feature is confirmed as working. However, if a configuration was expected to be required, but actually is not required by the design, then this defect will go undetected. Tri-Sect is a tool that generates a number of test cases by eliminating a configuration or a stimulus in each case, from the original test. The expectation is that in all of the cases, the DUT should fail to meet the expected behavior. If any of the generated tests passes, then the configuration or the stimulus eliminated in that test is not required, this points to a design defect.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Tri-Sect: A Tool for Tri-Section (Feature, Cause and Effect) Analysis for any Verification Platform.

Abstract:

While verifying a feature of a DUT (Design Under Test), configurations are done and stimulus is applied and then the behavior of the DUT is compared with an expected behavior.  If the behaviors match, the feature is confirmed as working. However, if a configuration was expected to be required, but actually is not required by the design, then this defect will go undetected. Tri-Sect is a tool that generates a number of test cases by eliminating a configuration or a stimulus in each case, from the original test. The expectation is that in all of the cases, the DUT should fail to meet the expected behavior. If any of the generated tests passes, then the configuration or the stimulus eliminated in that test is not required, this points to a design defect.

Introduction:

Test Plans for a DUT are built based on a system-level description of the design, which enlists various features encompassing the operations the design can perform. The test cases thus built are structured to configure the design for a particular feature, apply relevant input, and check for expected output.  Typically the traditional approach assumes that the configurations as done by feature-extraction of design are golden. However, in some instances the configuration required for a particular feature might be redundant and even hide a design bug. By generating numerous test cases in which the configurations are selectively eliminated, running them on the design and analyzing their effect could lead us to discover redundant logic in the design or hidden bugs which would’ve been missed while following the traditional approach.  

Over-configuration of design from the verification environment might not be consequential to the design behavior but could considerably blot-up the verification environment. Removing redundancy in verification collaterals helps in reducing the make, compile, simulation time, as well the hexadecimal code image.  

Key terminology:

1.       Feature: When a test case is created, it is intended to verify a specific behavior of the design.  Every such specific behavior is termed as a Feature.

2.       Cause: For verifying a feature, there are some configurations done in the design and th...