How to achieve accurate reset domain crossing verification

SoCs contain highly complex reset distributions and synchronization circuitry. A typical SoC today contains multiple asynchronous reset domains, making reset domain crossing (RDC) verification a critical step in the verification cycle. SoC sizes have also increased to billions of gates making it difficult for flat RDC verification to scale. Verifying that a design can be correctly reset under all modes of operation presents significant challenges.

Simulation has been the primary method for verifying reset behavior, often with a heavy reliance on gate-level simulation. But simulation does not model silicon-accurate metastability behavior, simulation test coverage is incomplete, and gate-level simulation is available too late in the design cycle. Furthermore, flat RDC verification on a full chip is performance intensive and time-consuming, often producing voluminous results.

As most SoCs include multiple IP blocks that have been developed and verified independently, a new RDC verification methodology is needed. It must be one where IP block RDC verification takes place independently and SoC verification focuses on RDC issues at the IP interfaces.

This article describes the methodology for accurate RDC verification based on a hierarchical data model (HDM) approach. It details a novel approach that in part satisfies the requirements of this methodology by using a portable data model that captures and stores all the information required for SoC RDC verification. The HDM encapsulates the RDC intent of the block, which can be seamlessly integrated across SoCs, providing accurate verification and debugging capabilities and leading to faster RDC verification closure.

HDMs can be generated for any IP block with multiple configurations and can be reused whenever the IP is integrated into an SoC. The methodology also natively supports an IP-based development methodology. With an increase in design size and IP reuse, it promises to be a critical replacement for flat RDC verification.

But first, what exactly is a reset domain crossing?

Reset domain crossing

Data transmission across reset domains is known as reset domain crossing. It is illustrated in Figure 1.

Figure 1. A reset domain crossing (Mentor)

Similar to clock domain crossing, metastability may occur across a reset domain crossing. Special care needs to be taken to avoid the condition. The receiving register in an RDC can go metastable when the transmitting register reset is asserted close to a receiving clock edge. Various techniques are used to solve RDC problems. These include adding a synchronizer in the receiving domain, reset sequencing, and isolation techniques.

Asynchronous reset de-assertion can also cause metastability but in the reset path. The de-assertion of asynchronous resets close to the active clock edge can violate reset recovery times, resulting in a register going metastable. Failure to ensure synchronous de-assertion of asynchronous resets can cause major bugs. The problem is commonly solved by adding synchronizers in the reset path.

The reset de-assertion issue is shown in Figure 2: The output ‘Q’ goes metastable when ‘RST’ de-asserts close to the clock edge of ‘CLK’.

Figure 2. Reset de-assertion causing metastability (Mentor)

On-target hierarchical reset domain crossing verification

A hierarchical methodology dedicated to RDC verification must be able to accurately verify and detect the correctness of the reset tree and the reset usage for both the IP and large scale integrated SoCs. Furthermore, in terms of reset usage issues, the methodology must address three critical questions:

1. Do the asynchronous resets have synchronizers?
2. Are any data paths crossing reset domains?
3. Are the reset domain crossings metastability safe?

Because an SoC has various IP-level blocks that are developed and verified independently across multiple teams and geographies, the verification engineer typically integrates multiple IP blocks and focuses on the integration issues at the top level.

Block-level verification is not required during SoC integrations as the blocks are already verified independently as part of the block-level signoff. Flat RDC verification on an SoC is therefore redundant and time consuming. A hierarchical methodology should instead be used that checks for block-integration issues and detects RDC issues across block-level interfaces.

The following subsections describe the main challenges that arise when integrating an RDC-clean IP block at the top level.

Reset logic integrity

The reset logic of an SoC can be distributed across multiple IPs. In some cases, reset generator logic can be part of one subsystem that is verified separately and the resets of other IPs resets are dependent on the reset generator block. In such cases, the methodology must enable an understanding of the reset architecture and flag any unexpected behavior to the user due to the incorrect integration of blocks.

Then, there can be scenarios where the reset is synchronized inside an IP block and subsequently used as a reset outside the IP (Figure 3). In this scenario, the hierarchical methodology should enable understanding of the logic so the user can ensure the complete path is considered as the same reset tree.

Figure 3. Reset propagating through sequential logic inside an HDM (Mentor)

Accurate RDC verification

The hierarchical methodology should ensure that all RDC issues inside and across IP blocks are accurately detected and reported. Figures 4a and 4b illustrate examples of RDC issues that can arise during the integration of IP. These issues can be across a single IP interface or related to the integration of multiple IPs. The verification methodology should be able to detect all complex variations of these issues. It should be able to detect synchronizers and reduce false RDC violations.

Figure 4a. Reset domain crossing across IP interface (Mentor)

Figure 4b: Reset domain crossing across multiple IP blocks (Mentor)

Reset ordering

Data crossing a RDC boundary will not go metastable if the receiving domain reset signal is asserted before the transmitting reset. This technique involves specifying the assertion order among two asynchronous resets, ensuring that the asynchronous reset signal in the receiver’s domain is always asserted before the asynchronous reset in the transmitter’s domain. The hierarchical methodology should absorb such a user-specified reset assertion order and flag safe RDC crossings across IP interfaces, thus ensuring that constraints are satisfied.

Reset synchronizers

The de-assertion of asynchronous resets close to a clock edge can result in metastability. This requires that all asynchronous resets are synchronized in the target clock domain before their use in the design. The hierarchical methodology should ensure the presence of synchronizers (or their absence) in the reset are correctly detected inside an IP and across IP interfaces during the integration of multiple blocks.

In addition to these RDC specific requirements, the methodology should also adhere to some common requirements of a hierarchical methodology to make it adaptable. There have been multiple hierarchical methodologies in the industry. However, only those methodologies that do not compromise on accuracy or debug capabilities can be used to replace a flat run.

To elaborate, the methodology should also support:

• Accuracy: It should ensure that the complete register-to-register RDC path across IP interfaces is reported for effortless debug; reporting up to an IP interface port is not sufficient. For seamless debug, the methodology should provide flat-run-like visibility to registers inside the IP.
• Reusable IP: The methodology should ensure that the hierarchical models for an IP block are readily available for reuse without there being any need to worry about scope and backward compatibility. The hierarchical models should be created once and then stored for reuse whenever the IP block is used across various SoC projects.
• IP-specific requirements: The method should specify IP integration rules, and these should be verified when the hierarchical model for that IP is used in an SoC. In most cases, the designer and user of IP are different, which requires a process to verify that IP and SoC setup constraints are consistent.

Now let’s look at this systematic, accurate hierarchical RDC verification methodology itself. We will see how it supports IP-based flows and also scales-up for billion-gate SoCs, generating accurate results efficiently.

Reset domain crossing verification methodology

In this example, RDC verification is done on the IP blocks, generating the HDM.

It encapsulates all the RDC information required for verification and seamless integration of the block into an SoC (Figure 5a).

Figure 5a: HDM generation flow (Mentor)

Figure 5b shows that the generated HDMs are then loaded during SoC verification, and all RDC information from the blocks is extracted from the HDMs.

Figure 5b. HDM usage flow in SoC-level run (Mentor)

HDM generation: The HDM is generated during IP-level RDC verification, along with IP-level RDC results. This is a binary model which can be archived and passed to the SoC verification team. The generated HDM stores the RDC intent of the block and contains all the information required for detecting and verifying RDC issues when integrated in an SoC. HDMs can be generated for various configurations of IP and with various levels of visibility. The designer can choose to hide the internal connectivity, and when integrated, such an HDM will show the RDC at the HDM interface.

HDM usage: In SoC verification, the HDM provided by the IP team needs to be loaded. All the required information will be obtained from the HDM and used for SoC RDC verification. An IP can be used with different configurations in the SoC run. For each configuration, a separate HDM needs to be generated during the IP run, and all generated HDMs for the IP need to be loaded during the SoC run. The SoC RDC verification results will report all RDC issues across the IP block interfaces and will also report any differences between the IP-level and SoC-level settings or constraints.

An HDM is a binary database generated during IP-level RDC verification. It can be decompiled anytime by the user to generate internal details of the HDMs and can be modified by overriding constraints in the SoC run. An HDM is a portable data model in the truest sense. Thus it can be archived and passed between various teams so that they can work seamlessly. This portable data model stores all the information required for RDC verification.

The following are the key features of the proposed hierarchical approach.

Debug capability

In most existing hierarchical methodologies, debugging violations across a block is a challenge. In most cases, the IP block is shown as a blackbox in the schematic during SoC verification. This methodology preserves the block schematic in the data model and displays it to the user. This ensures the user can view the complete schematic. In Figure 6, the complete view of the RDC violation inside the HDM block is shown for debugging the RDC path, even if part of it is inside the IP block.

Figure 6: Accurate schematic across an IP interface (Mentor)

Consistency check during IP integration

This methodology supports consistency checks whenever an IP is integrated. This ensures that if there are any mismatches in constraints across the IP and SoC specifications, they will be highlighted to prevent inaccurate verification. In Figure 7, both resets “rst1” and “rst2” are placed in the same group during a block run, but in the SoC run they are in a different group. These differences are reported in the SoC run as warnings.

Figure 7. Integration checks between IP and SoC runs (Mentor)

IP integration conflicts occur when the IP is instantiated at the top-level with an incorrect configuration or a usage that is not supported by the IP. This may be an indication that the integration team has used the IP in a configuration that is not supported by the IP team. IP integration conflicts may also indicate that the IP verification was not correct, so either the wrong configuration was verified by the IP team or the assumptions used by the IP team are not consistent with the usage within the SoC.

Configurable visibility inside IP

The methodology facilitates the use of each HDM with different visibility levels. For example, an SoC owner can control whether to use the IP internal information or not. In the case of the former, the RDC violations will be reported at the IP interface. This makes the approach more flexible, and thus it can be used for any third-party or encrypted IP. In Figure 8, the HDM loaded in an SoC is used as a grey box where all possible RDC issues from port ‘out’ are reported.

Figure 8. An HDM used as a grey box – all possible crossings are reported (Mentor)

You also have the option of using the same HDM as a blackbox, as shown in Figure 9, where only one RDC violation is reported from the HDM interface in the SoC run.

Figure 9. A use-model to report crossings to HDM ports (Mentor)

Reusable IP

IP and SoC development happen independently with different teams, and different teams may use different processes for RDC verification. This requires a robust method in which the HDM generated by the IP team remains usable to the SoC team across designs and releases. Using the hierarchical model ensures that an HDM generated for an IP can be seamlessly integrated across SoC designs and releases without having to regenerate the HDM repeatedly. The HDM is a complete RDC IP that can be generated and stored to be used later, allowing it to be integrated in any number of SoC designs where this IP block is used.

Constraints-based methodology

Our hierarchical methodology also provides an option to specify an HDM through hierarchical constraints. This allows the SoC designer to bridge the gap between the complete development of the IP block and SoC RDC verification. The SoC designer can specify an IP block with the help of hierarchical constraints to create a black-box model.

The methodology supports different levels of IP abstraction, including white-box and black-box abstraction. Integration teams may use a black-box model in the phases of the project before the IP is stable and before a more accurate white-box model is available. When the IP matures, the integration team can incorporate a higher-accuracy, white-box abstraction model. This methodology allows design teams to start integration-level clock domain crossing verification earlier.

Parameterized IP support

The same IP block can be used or instantiated with different configurations in the SoC run. For accurate RDC verification, the correct HDM needs to be used with the correct instantiation of the IP block. The IP-level user must generate a separate HDM for each IP configuration, which will then be used in the SoC run. This methodology addresses instance-specific HDMs by automatically using the correct HDM with the correct configuration of the IP in the SoC analysis. If there are any mismatches or the correct HDM is not found, the analysis will generate an error message.

Going further

For more information on this innovative and powerful methodology, please read Scalable Reset Domain Crossing Verification Using Hierarchical Data Models. It presents a full discussion on how this approach addresses all the requirements for hierarchical RDC verification, and offers detailed results from 10 case studies. They compare the results from this HDM methodology with a traditional flat verification approach for SoCs with multiple IPs.

About the authors

Soumya Palit has more than five years of experience in design and verification. He is an R&D engineer at Mentor, a Siemens business, working on clock and reset domain verification signoff.

Kurt Takara has over 20 years of experience in engineering design and verification, technical marketing and engineering services. He is a Product Engineer at Mentor, a Siemens business, specializing in assertion-based verification methods and applications.