Raising The Bar On Flat CDC Verification With Hierarchical Data Models

By Ashish Hari, Aditya Vij, and Ping Yeung

Traditionally, clock domain crossing (CDC) verification at the SoC level has relied on flat simulation runs. But flat CDC verification has run out of gas. Largely because of the increase in the number of asynchronous clocks in larger, faster, more complex designs. Flat CDC runs are too performance intensive, time-consuming, and result in high noise. They incur the additional burden of redundant debug, as the same CDC bug can be replicated across multiple instances of the same module in the full chip.

Traditional CDC verification approaches also are not adept at handling design modules developed by different designers in different geographies. These dispersed design efforts require a distributed CDC verification mechanism, where each module can be verified separately and then integrated for complete CDC verification on the SoC. This distributed CDC verification methodology should be scalable to handle multi-billion gate designs and should not compromise accuracy or ease-of-debug.

Furthermore, third-party IP and design reuse challenge flat CDC verification approaches. Because IP blocks are often already verified to be free of CDC issues (i.e., they are CDC clean), verification shifts to validating the integration of various IP rather than the internals of IP blocks. Frequently third-party IP internal details need to be hidden yet their integration must still be verified comprehensively. SoC teams are desperate for a CDC IP-based flow to simply integrate the CDC IP models and verify any CDC issues that may arise due to incorrect integration.

To address these pressing issues, we developed a new hierarchical CDC verification approach that supports an IP-based flow and can be used as an alternate to the flat CDC verification flow. In this article, we describe the backbone of this solution: the hierarchical data model (HDM). HDM is equivalent to a portable CDC IP that captures the CDC intent of any block along with its integration rules. It is a generic data model that can be seamlessly reused across releases and across designs wherever the IP is reused.

The HDM methodology
We developed the next generation hierarchical verification methodology to address the shortcomings of traditional flat methodologies and the limitations associated with existing hierarchical verification. The result is a systematic and accurate hierarchical verification approach that leads to faster CDC closure. The configurability and flexibility of this methodology ensure it can cater to CDC verification at different levels — from IP blocks to sub-systems to the entire SoC.

This new HDM-based hierarchical methodology has several important characteristics. HDM is an abstract heterogeneous representation of a module. It is stored in an abstract object-oriented database in a compressed format. An HDM is lightweight and portable. It captures various information about a module; such as the CDC intent of the block, interface attributes, environment constraints, schematic information, integration requirements, and possible configurations. The HDM is compact and fast for processing without losing any CDC related information. It is designed to store abstract netlist representations to support CDC reconvergence analysis at the top level. Hence, for CDC analysis, it has significant advantages over other interface representations; such as liberty, design constraints, timing constraints, etc. Even though HDM is a binary database, users can decompile it anytime to see the internals and also override the interface attributes with constraints. Figure 1 shows an example of a decompiled HDM file.

Fig 1: User-readable version of HDM

The basic flow of the proposed hierarchical methodology is illustrated in Figures 2 and 3.

Fig 2: HDM generation during IP verification

Hierarchical data model generation during IP verification: During IP-level CDC verification, a data model is generated along with CDC results. This HDM contains all the necessary information about the block to verify and debug issues during block integration in the SoC. The IP designer can choose to generate the data model for each configuration of the IP. Also the designer can embed the integration requirements in the HDM. For example, if a clock port is expected to be connected to a specific clock generator module, then such connection information can be provided during HDM generation. The IP designer can also control the visibility level inside the IP. If the designer intends to provide only the CDC model and hide the internal connectivity, then the HDM can be generated accordingly. Once the HDMs are generated for the intended configurations, they can be archived or passed on to the SoC team.

Fig 3: HDM usage in SoC verification

HDM usage in SoC verification: During SoC-level CDC verification, the SoC team only needs to include the HDM files provided by the IP team. All necessary information of the IP is extracted from the HDM and used in SoC CDC analysis, and all the CDC issues across the IP block are reported to the user. Also, the user is notified about any differences between the IP-level and SoC-level settings or constraints. The integration requirements specified by the IP owners are also extracted from the HDM and verified in the SoC-level CDC run. For example, if the clock port is not driven by the specified clock generator module then the violation will be flagged.

Improving on other hierarchical approaches
We have developed and deployed constraint-based model methodologies for many years. Based on our experience with the existing methodologies, we were able to design the new HDM-based verification approach explicitly to address their limitations.

Parameterized IP support: In most cases the IP blocks have multiple parameterized configurations, each configuration having different functionality. For accurate CDC verification it is important to generate a hierarchical model with the correct configuration to be used in the SoC run. An SoC can also contain multiple instances of the IP with different configurations. It is the responsibility of the verification methodology to ensure that a hierarchical model with the correct configuration is plugged in for the correct instance. The proposed HDM-based methodology addresses this challenge by automatically selecting the correct configuration data model and alerting the user in case no match is found. This use model also enables the user to perform CDC analysis for each configuration of the IP and generate the HDM files, as shown in Figure 4.

Figure 4: Use-model for design with parameterized IPs

Accuracy: The primary advantage of the proposed methodology is the data model, which stores all relevant information to ensure accurate CDC verification at the SoC level without any compromise on debug. Any complex crossing that can be detected by flat CDC analysis will also be detected by this methodology. Also, the reporting and debug capabilities match flat run behavior. For example, if the IP block has multiple fan-outs and fan-ins inside the block, then the CDCs for each fan-out or fan-in will be reported accurately in this methodology. In Figure 5, the IP input port is connected to synchronizers in the clk1 and clk2 domains inside Block IP1, and it also drives the output port. Using the HDM methodology all crossings are correctly reported — two synchronized crossings and one unsynchronized crossing through the output port.

Fig 5: Accurate crossing detection by the HDM-based flow

Through this methodology, complex divergence and reconvergence issues can also be detected. Figure 6 shows where a reconvergence issue spans across two different IP blocks. Such issues can be identified using HDMs of Block IP1 and Block IP2.

Fig 6: Reconvergence detected by the HDM-based flow

Debug capability: In most existing hierarchical methodologies, debugging violations across a block is very challenging. In most cases, during SoC verification the IP block is shown as a blackbox in the schematic. The proposed methodology preserves the block schematic in the data model and displays it to the user. Thus the user can view the complete CDC path even if part of it is inside the IP block. Figure 7 shows an example of a top-level schematic with a redundant synchronization violation across two IP blocks, reported in the SoC-level run.

Fig 7: Redundant synchronization across IP blocks schematic using HDMs

Support for IP integration checks: The HDM methodology supports integration rule checking, which is necessary for IP-based flows. During CDC verification of the IP, designers can also provide requirements on properties that should hold during IP integration. The recommendations will be verified through the data model during CDC verification at the SoC level. For example, if an input port of an IP is connected to a synchronizer, then the user can specify that this port should not be driven by combinational logic after integration. Similarly, if some port of the IP is expected to be connected to some specific module or specific clock domain, the IP designer can embed these rules in the HDM. The proposed methodology will verify this property during SoC CDC verification and notify the user if any of the specification rules fail. This methodology not only ensures CDC-clean IPs, but also ensures clean integration of the IPs.

Figure 8 shows a DMUX synchronizer at the boundary of the IP block. The DMUX synchronizer is valid only when TXDATA and TXSEL are driven by the same clock domain. The IP designer can embed this information through the “hier assume port” constraint, as specified below. The HDM methodology will ensure this rule is verified when the IP HDM is integrated in any SoC.

Fig 8: Example of integration rules for IP blocks

Configurable visibility inside IP: This methodology facilitates generation and use of each HDM with different visibility levels. For example, during generation the IP owner can control whether to expose IP internals through the HDM or not. This ensures this methodology can be used for encrypted IP as well as when the IP owner needs to pass on the HDM with the integration rules without any visibility inside the IP. In such cases the block schematic will not be available during SoC-level verification, and CDC issues will be reported up to the IP block ports. Also if the IP owner has provided visibility permission, the SoC owner can control whether to use the IP internal information or not.

Constraints-based methodology: The proposed methodology also provides flexibility to use a constraints-based hierarchical model. Sometimes the SoC-level verification starts before the block development is complete. In such cases, generating an abstract model for the IP is not possible. In such cases, IP designers can describe the HDM through constraints that can be used during SoC verification. The constraints can also be generated from an HDM file. So in this methodology, there is flexibility to choose the use model for both IP and SoC verification engineers.

Reusable CDC IP: The HDM is essentially a CDC IP that can be archived and used whenever the block is used in any design. Generally, IP and SoC development happens independently by different teams, often using different releases or different methodologies for verification. Also, after its development, the IP can be used in multiple SoCs across different releases. Every time the IP is integrated, the hierarchical model does not need to be regenerated. Once the IP is finalized the HDM can be generated and archived and then reused across designs and releases.

For more details on how the HDM-based CDC verification methodology can help you enjoy much faster analysis of CDC issues and faster CDC verification closure, please download the whitepaper, Comprehensive CDC Verification Using Advanced Hierarchical Data Models.

Aditya Vij is a Product Engineer, ICVS DVT Questa Marketing at Mentor, a Siemens Business.

Ping Yeung is a Verification Technologist, ICVS DVT Verification Technologies at Mentor, a Siemens Business.