Browse Prior Art Database

Method for verifying the Behavior of Pipeline Flops During the Reset phase in an SoC

IP.com Disclosure Number: IPCOM000241237D
Publication Date: 2015-Apr-07
Document File: 5 page(s) / 177K

Publishing Venue

The IP.com Prior Art Database

Abstract

With the size of SoCs increasing day by day, the number of pipelines added to meet timing requirements is also increasing. The expected behavior of these pipelines is that they should be functionally transparent and they should not introduce any logic change between the source and the destination flops. However, it has been observed that at times these expectation are not met, resulting in functional bugs, especially when reset is applied on the SoC. This primarily happens due to the incorrect reset value of the pipelines flops. These incorrect values break the transparency of the pipelines because the value seen at the input of the destination flop differs from the output of the source flop. In this paper, we propose a mechanism that helps to catch all such reset value issues.

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

Method for verifying the Behavior of Pipeline Flops During the Reset phase in an SoC


ABSTRACT:

With the size of SoCs increasing day by day, the number of pipelines added to meet timing requirements is also increasing. The expected behavior of these pipelines is that they should be functionally transparent and they should not introduce any logic change between the source and the destination flops. However, it has been observed that at times these expectation are not met, resulting in functional bugs, especially when reset is applied on the SoC. This primarily happens due to the incorrect reset value of the pipelines flops.

 These incorrect values break the transparency of the pipelines because the value seen at the input of the destination flop differs from the output of the source flop. In this paper, we propose a mechanism that helps to catch all such reset value issues.

1.    MOTIVATION

Pipeline verification is an essential part of SoC verification and hence all aspects of pipeline flops should be verified including their behavior during reset.

The following problems in the current verification strategies were encountered:   

1.    Lack of a specific checker/checks to monitor the behavior of the pipelines during the reset phase.

2.    Dependency on limited set of functional patterns that do not guarantee 100% coverage of the pipeline flops.

3.    Requirement of a checker that can be easily updated with the changes in the pipelines in the subsequent design releases.

Take for an example where a 4 stage pipeline between a source and a destination flop has an incorrect reset value so when reset is asserted, the pipeline flops start transmitting their reset value to the destination flop, which is different from the reset value of the source flop. Hence here the expectation that the pipeline is functionally transparent breaks. Thus, effectively the behavior of the signal observed at the destination flop is not coherent to the source output.  Rather it is receiving a pulse of an incorrect logic value of the window equal to the number of clock cycles for which reset was asserted plus the length of the pipeline (as shown in Figure 2).

       This incorrect pulse may cause several serious issues at the destination flop. For example, if the destination flop is a non-resettable flop then the reset value of the destination flop depends on the value driven at its data input, but if the reset values are incorrect for the pipeline flops, they would corrupt the destination flop output.

 

2.    INTRODUCTION

The proposed flow uses and implements a new Pipeline Reset Auditor (PRA), which is complimented by a functional stimulus that invokes various types of resets supported in a SoC. During the entire reset phase, the auditor observes and compare the values between the source and destination flops where the pipelines have been added. Whenever a mismatch in the values occurs, it generates a report highlighting all such violations/failures.

The flow is capable of ca...