Browse Prior Art Database

Verification Methodology to Check the Checkers

IP.com Disclosure Number: IPCOM000216635D
Publication Date: 2012-Apr-11
Document File: 6 page(s) / 450K

Publishing Venue

The IP.com Prior Art Database

Abstract

Currently verification methodologies rely on verification checkers (monitors/test cases/response-checkers, etc.) to check a design. Quality of the verification can be directly linked to the quality of these checkers. A miss in a verification test case can result in a “Miss in Design” which can go unnoticed in current verification flows. There are no means to verify and ensure that all required checks are incorporated in verification test cases/monitors/checkers. Current verification methodology misses issues that were completely unexpected and not normally part of checkers and test cases, e.g. unexpected events triggered by verification scenario in same or other module or unexpected memory (DDR or L2cache or SRAM) updates by verification scenario. Recently, many SoCs have had some issues found late in the design cycle by the Post-Silicon Validation Team. For example,  Core accesses to Reserved Memory Space hung the system.  SoC allowed unintended writes to memory mapped registers of some modules without a corresponding module_en assertion.  Writes to reserved module register space updated the supported register space due to issues in address decoding logic. Because the behavior was unexpected, verification didn't implement checks for the same and thus resulted in a miss. There is a need of a verification methodology that can catch all such and many other unexpected issues early in the design cycle, during the verification phase and can thus ensure completeness of the verification checkers. In this paper we present a new and innovative Verification Methodology that assures the verification engineer of the completeness of his verification checkers and safeguards against all such and many more possible issues in SoCs. The flow automatically generates a list of all memory-mapped registers and memory addresses that changed during the execution of a scenario but were not checked. The flow thus helps the verification team catch issues that are completely unexpected and not normally part of checkers and test cases.

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 35% of the total text.

Verification Methodology to Check the Checkers

Abstract

Currently verification methodologies rely on verification checkers (monitors/test cases/response-checkers, etc.) to check a design. Quality of the verification can be directly linked to the quality of these checkers. A miss in a verification test case can result in a “Miss in Design” which can go unnoticed in current verification flows.

There are no means to verify and ensure that all required checks are incorporated in verification test cases/monitors/checkers. Current verification methodology misses issues that were completely unexpected and not normally part of checkers and test cases, e.g. unexpected events triggered by verification scenario in same or other module or unexpected memory (DDR or L2cache or SRAM) updates by verification scenario.

Recently, many SoCs have had some issues found late in the design cycle by the Post-Silicon Validation Team.  For example,

Ø  Core accesses to Reserved Memory Space hung the system.

Ø  SoC allowed unintended writes to memory mapped registers of some modules without a corresponding module_en assertion.

Ø  Writes to reserved module register space updated the supported register space due to issues in address decoding logic.

Because the behavior was unexpected, verification didn't implement checks for the same and thus resulted in a miss.

There is a need of a verification methodology that can catch all such and many other unexpected issues early in the design cycle, during the verification phase and can thus ensure completeness of the verification checkers.

In this paper we present a new and innovative Verification Methodology that assures the verification engineer of the completeness of his verification checkersand safeguards against all such and many more possible issues in SoCs.  The flow automatically generates a list of all memory-mapped registers and memory addresses that changed during the execution of a scenario but were not checked.  The flow thus helps the verification team catch issues that are completely unexpected and not normally part of checkers and test cases.


Description

CONVENTIONAL VERIFICATION TEST CASE FLOW

Figure 1 shows the flow of a conventional verification test case.

Conventional verification scenario/testcase takes the system out of reset (POR), performs the basic configuration of the SoC followed by scenarios specific module register and memory configuration. Once the scenario is triggered, test case waits for the scenario completion and then performs required module status register checks and data checks.

Figure 1: Conventional Verification Testcase Flow

In the conventional approach, the list of registers and memory addresses being checked depends on the knowledge of the verification engineer. A useful register read or memory location missed by the verification engineer can result in verification miss.

The conventional verification approach doesn’t check the design for any unexpected event triggered by the ver...