Hierarchical cross-clock domain signal verification method and device, equipment and medium

Abstract

The invention relates to the technical field of very large scale integrated circuit design verification, and discloses a hierarchical cross-clock domain signal verification method, device and equipment and a medium. According to the method, on the basis of the physical layout information file corresponding to each functional module, the target functional module to be verified is dynamically, intelligently and accurately determined from the plurality of functional modules. And performing cross-clock domain signal verification on the previous level of the target function module by extracting the target sign-off abstract model of the target function module, and performing cross-clock domain signal verification on the top system of the whole chip by analogy. As clock domain crossing signal verification does not need to be carried out on all functional modules, the efficiency of chip verification can be improved, clock domain crossing signal verification, module level focusing functional module internal logic integrity verification and top layer enhanced module crossing asynchronous path analysis are carried out on the chip layer by layer through the target sign-off abstract model, and the chip verification efficiency is improved. Therefore, the accuracy of chip verification can be improved.

Description

Technical Field

[0001] This invention relates to the field of very large-scale integrated circuit design verification technology, specifically to a hierarchical cross-clock domain signal verification method, apparatus, equipment, and medium. Background Technology

[0002] As Moore's Law advances, the number of functional modules integrated in System-on-Chip (SoC) chips is gradually increasing. Since these functional modules may operate at different clock frequencies and clock domains, the verification paths for Clock Domain Crossing (CDC) signals increase accordingly. This leads to a wide distribution of risks such as timing conflicts, metastability propagation, and data inconsistency across various levels, significantly increasing the complexity of chip verification.

[0003] Currently, hierarchical verification methods are commonly used for CDC verification of SoC chips, but existing hierarchical verification methods still have some shortcomings in terms of verification reliability and verification efficiency. Summary of the Invention

[0004] This application provides a hierarchical cross-clock domain signal verification method, apparatus, device, and medium to at least solve the problem of low verification efficiency and accuracy of CDC verification of chips in related technologies.

[0005] This application provides a hierarchical cross-clock domain signal verification method. The chip includes multiple functional modules. The method includes: determining the target functional module to be verified from the multiple functional modules based on the physical layout information file corresponding to each functional module; if the target functional module passes the cross-clock domain signal verification, extracting the target signature abstract model of the target functional module; using the target signature abstract model to perform cross-clock domain signal verification on the next higher level of the target functional module; if the next higher level of the target functional module passes the cross-clock domain signal verification, taking the next higher level of the target functional module as a new module to be verified; and using the new module to be verified to perform cross-clock domain signal verification on the chip.

[0006] This application also provides a hierarchical cross-clock domain signal verification device. The chip includes multiple functional modules. The device includes: a first determining module, used to determine the target functional module to be verified from the multiple functional modules based on the physical layout information file corresponding to each functional module; an extraction module, used to extract the target signature abstract model of the target functional module if the target functional module passes the cross-clock domain signal verification; a first verification module, used to perform cross-clock domain signal verification on the upper level of the target functional module using the target signature abstract model; a second determining module, used to take the upper level of the target functional module as a new module to be verified if the upper level of the target functional module passes the cross-clock domain signal verification; and a second verification module, used to perform cross-clock domain signal verification on the chip using the new module to be verified.

[0007] This application also provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform any of the above-described hierarchical cross-clock domain signal verification methods.

[0008] This application also provides a computer-readable storage medium storing computer instructions for causing a computer to execute any of the above-described hierarchical cross-clock domain signal verification methods.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described hierarchical cross-clock domain signal verification methods.

[0010] This application, relying on the physical layout information files corresponding to each functional module, achieves dynamic, intelligent, and accurate identification of the target functional module to be verified from multiple functional modules. Then, by extracting the target signature abstract model of the target functional module, cross-clock domain signal verification is performed on the next higher level of the target functional module, and so on, performing cross-clock domain signal verification on the entire top-level system of the chip. Since it is not necessary to perform cross-clock domain signal verification on all functional modules, the efficiency of chip verification can be improved. By performing cross-clock domain signal verification on the chip layer by layer through the target signature abstract model, the module level focuses on verifying the internal logical integrity of the functional module, while the top level strengthens the analysis of asynchronous paths across modules, thus improving the accuracy of chip verification. Attached Figure Description

[0011] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this application; Figure 2 This is a schematic flowchart of a first type of hierarchical cross-clock domain signal verification method according to an embodiment of this application; Figure 3 This is a second flowchart illustrating the hierarchical cross-clock domain signal verification method according to an embodiment of this application; Figure 4 This is a schematic diagram of the third process of the hierarchical cross-clock domain signal verification method according to an embodiment of this application; Figure 5 This is a schematic diagram of the fourth process of the hierarchical cross-clock domain signal verification method according to an embodiment of this application; Figure 6 This is a structural block diagram of a hierarchical cross-clock domain signal verification device according to an embodiment of this application; Figure 7 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0015] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0016] As Moore's Law advances, the design complexity of System-on-Chips (SoCs) has increased significantly. The number of functional modules integrated into a single SoC is also increasing; for example, a single SoC may simultaneously include a processor core, memory controller, peripheral interfaces, and customized acceleration units. These functional modules may operate at different clock frequencies and clock domains, leading to a significant increase in the verification paths for Clock Domain Crossing (CDC) signals. This results in risks being widely distributed across all levels of the SoC, significantly increasing the verification complexity of the chip.

[0017] As the scale of integrated circuit design continues to expand, the limitations of traditional CDC verification methods are becoming increasingly apparent. With the growth of asynchronous cross-paths between modules, problems such as timing conflicts, metastability propagation, and data consistency failures in asynchronous boundary transmissions are becoming more insidious. For example, an undetected synchronizer deficiency may lead to random data corruption in the SoC chip during system operation; asynchronous cancellation of the CDC reset signal may trigger state machine logic lock-up; even very small combinational logic paths may cause unreproducible functional anomalies due to glitches in CDC transmissions. These problems are difficult to fully cover during the simulation phase but will be exposed after tape-out.

[0018] Currently, there are three main CDC verification methods: fully flat verification, black-box verification, and hierarchical verification. The fully flat verification method treats the entire design as a flat structure, ignoring hierarchical relationships and directly performing CDC verification. While it can cover the entire design path, ignoring the hierarchical structure leads to exponentially increasing resource consumption. When dealing with designs with billions of gates, it struggles to balance efficiency and accuracy, and a massive number of low-risk violations overwhelm critical issues. Black-box verification simplifies the verification load through interface abstraction, but at the cost of masking deeper issues within modules, such as missing synchronizers or asynchronous reset signal cancellation. Furthermore, it lacks an automated arbitration mechanism for clock constraint conflicts between modules and the top layer, relying on manual, time-consuming, and error-prone checks. Therefore, for ultra-large-scale SoC chips, a common approach is to extract key features of clock domain interactions within modules to form a Sign-off Abstract Model (SAM). This retains necessary CDC verification path information while compressing the design size, thus enabling a bottom-up hierarchical verification process.

[0019] Existing SAM-based CDC verification methods also face several bottlenecks in practical engineering applications. For example, the confirmation process for SAM objects heavily relies on human experience, typically using simple heuristics such as module area thresholds or port counts for screening. This coarse-grained mechanism is prone to misjudgments; for instance, a single clock domain module might be mistakenly identified as a SAM object due to its large area, causing resource redundancy, while highly complex asynchronous interface modules might be missed due to their small size, creating verification blind spots. Furthermore, the lack of quantitative analysis of key physical layout features and the failure to consider the characteristics of dynamic clock relationships lead to discrepancies between the signed-off abstract model and actual post-silicon behavior. Additionally, the inheritance mechanism between module-level constraints and top-level global constraints has flaws. When the clock cycle defined within a module conflicts with top-level timing requirements, the system cannot automatically detect the constraint contradiction, requiring manual comparison of clock definition files line by line. This process is not only time-consuming but also prone to human error, making it difficult to meet the rapid iteration verification needs of ultra-large-scale SoC designs.

[0020] To address the aforementioned issues, this application proposes a hierarchical cross-clock domain signal verification method. This method can achieve intelligent confirmation of SAM objects by partially extracting target functional modules through a hierarchical screening strategy. It constructs a fully automated constraint management system from the module level to the top level using Register-Transfer Level (RTL) code standardization annotation parsing and constraint inheritance technology. Furthermore, it achieves global CDC risk control through a closed-loop process of module-level in-depth inspection and top-level integration analysis. This method avoids the problems of strong reliance on manual labor, low efficiency, and high resource consumption in existing technologies, and systematically solves the multidimensional contradictions of CDC verification in ultra-large-scale SoC design.

[0021] As an optional application scenario of this invention, the hierarchical cross-clock domain signal verification method of this application is applied in an electronic device. The electronic device is equipped with verification tools, which can be used to run the relevant code files of the hierarchical cross-clock domain signal verification method of this application to achieve CDC verification of the SoC chip. Figure 1 As shown, in the hierarchical cross-clock domain signal verification method of this application, for a chip such as a SoC chip, there are multiple functional modules. First, based on the physical layout information file corresponding to each functional module ( Figure 1 The SDC file shown is used to select target functional modules for CDC verification from multiple functional modules. Then, based on the CDC environment configuration corresponding to the verification tool, the physical layout information file corresponding to each target functional module, and the Register-Transfer Level (RTL) code, the target signature abstract model (i.e., SAM model) of the corresponding target functional module can be extracted, and each SAM model can be configured to the next higher level of the corresponding target functional module, such as... Figure 1In the subsystem verification environment shown, the SAM model of the target functional module can be used to perform CDC verification on the corresponding upper-level subsystem, such as the subsystem. Similarly, the SAM model of a subsystem can be configured on the upper-level subsystem, such as the subsystem itself. Figure 1 The top-level verification environment shown allows for CDC verification of the top level using the SAM model of the subsystem.

[0022] It should be understood that, Figure 1 The chip hierarchy shown is only a specific example and is not limited to in practical applications. Figure 1 The chip hierarchy shown can also be other hierarchical relationships, such as multiple levels of subsystems at one level. The specific hierarchical relationship of the chip is not limited here.

[0023] According to an embodiment of the present invention, a hierarchical cross-clock domain signal verification method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0024] This embodiment provides a hierarchical cross-clock domain signal verification method, which can be used in electronic devices. Figure 2 This is a flowchart of a hierarchical cross-clock domain signal verification method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Based on the physical layout information file corresponding to each functional module, determine the target functional module to be verified from multiple functional modules.

[0025] Within a chip, there can be multiple intellectual property (IP) cores, which can be pre-designed, reusable basic logic units. One or more IP cores can constitute a functional module, which can be used to implement a specific function. For example, a data acquisition module can include an analog-to-digital converter (ADC), registers, etc., and the data acquisition module can realize the function of data acquisition with the help of the ADC and registers. One or more functional modules can correspond to a subsystem, which can be used to implement a relatively complex system function. One or more subsystems can also form a subsystem, and of course, one or more subsystems can also form a top-level system. This top-level system can be the overall functional carrier of the chip, directly corresponding to the chip's final function.

[0026] The physical layout information file for a functional module describes the physical design details of that module. It mainly includes, but is not limited to, the module's physical hierarchy, clock network information, signal connections and paths, and the physical attributes of its IP cores. It should be understood that a functional module can correspond to one physical layout information file, a subsystem can also correspond to one physical layout information file, and of course, the top-level system can also correspond to one physical layout information file.

[0027] Here, based on the clock network information recorded in the physical layout information file corresponding to the functional module, it can be determined whether the functional module has an asynchronous clock domain. Then, the functional module with an asynchronous clock domain can be identified as the target functional module, that is, the functional module with an asynchronous clock domain is identified as the functional module that needs to be verified by CDC.

[0028] Step S202: If the target functional module passes the cross-clock domain signal verification, then extract the target signature abstract model of the target functional module.

[0029] Cross-clock domain signal verification here refers to the CDC verification mentioned earlier. This involves identifying all signal transmission paths (including single-bit and multi-bit signals) in the chip design across asynchronous clock domains and checking whether these paths employ correct synchronization strategies (such as two-stage flip-flop synchronizers, asynchronous First-In-First-Out (FIFO), handshake protocols, etc.) to ensure reliable and stable transmission of signals with asynchronous clock domains. For example, pre-configured verification tools can be used to perform cross-clock domain signal verification on the target functional module. Only when the target functional module passes the cross-clock domain signal verification is the target functional model extracted to obtain the target signature abstract model corresponding to the target functional module.

[0030] The signing abstract model can be an abstract model built for the chip "sign-off" stage. Its purpose is to improve the efficiency and feasibility of signing analysis by simplifying complex design details, while ensuring the accuracy of key design indicators (such as timing, physical rules, power consumption).

[0031] Here, based on the verification tool, the CDC environment configuration, the physical layout information file corresponding to the target functional module, and the Register-Transfer Level (RTL) code in the verification tool are jointly extracted to obtain the target signature abstract model (i.e., SAM model) of the target functional module.

[0032] like Figure 1 As shown, there can be multiple target functional modules. Therefore, each target functional module can be extracted to obtain the target approval abstract model corresponding to each target functional module.

[0033] Step S203: Use the target signature abstract model to perform cross-clock domain signal verification on the next higher level of the target functional module.

[0034] When multiple target functional modules constitute a subsystem, the relevant information of the target signature abstract model corresponding to each target functional module can be configured into the verification environment of the subsystem. This means binding the relevant information of each target signature abstract model to the subsystem for CDC verification. The relevant information of the target signature abstract model can include the file name, file storage path, and the hierarchical information of the target functional module within the entire chip.

[0035] As a concrete example, the `set_abstract_model` command can be used to bind information about the target approval abstract model to the subsystem at the next higher level of the target functional module, ensuring an accurate mapping of the module-level target approval abstract model to its parent level. This accurate mapping ensures the accuracy and reliability of the module-level abstract model during the verification process at its parent level. When performing CDC checks on the parent level of the target functional module, the verification tool can read the relevant information from the target approval abstract model and use this information for cross-module path analysis and global CDC verification.

[0036] Step S204: If the upper level of the target functional module passes the cross-clock domain signal verification, then the upper level of the target functional module is taken as a new module to be verified.

[0037] When the target functional module is verified through cross-clock domain information at the level above it, the level above it is taken as a new module to be verified. According to the extraction method shown above, the target signature abstract model of the new module to be verified is extracted.

[0038] The level above a target functional module can consist of multiple target functional modules. For example, such as Figure 1 As shown, three target functional modules form one subsystem, two other target functional modules form another subsystem, and the two subsystems together form a top-level system.

[0039] Step S205: Use the new module to be verified to perform cross-clock domain signal verification on the chip.

[0040] After extracting the target signature abstract model of the new module to be verified, CDC verification can be performed on the next higher level of the new module using this target signature abstract model. Similarly, CDC verification can be performed on the next higher level using the target signature abstract model of the current level, until CDC verification is performed on the top-level system (the entire chip system). Once the top-level system passes the CDC verification, the verification process ends.

[0041] It should be understood that when performing CDC verification on the level above the target functional module, if the level above the target functional module fails the CDC verification, it is necessary to return to the step of performing CDC verification on the target functional module again, and repeat the steps of CDC verification on the target functional module, extracting the target approval abstract model of the target functional module, and performing CDC verification on the level above the target functional module. Similarly, whether it is the level above the target functional module or the level above that level, if it fails the CDC verification, it is necessary to repeat the steps of CDC verification on the target functional module, extracting the target approval abstract model of the target functional module, and performing CDC verification on the level above the target functional module.

[0042] To ensure the integrity and reliability of the entire verification process, this application uses project management tools or a bug tracking system to track the progress of each violation, ensuring that all issues are resolved promptly. The CDC (Cut-Offline Control) process is only considered complete after all modules and subsystems have passed the CDC check and all violations have been cleared. This step not only ensures code quality but also provides a solid foundation for the final chip tape-out. This approach ensures the integrity and reliability of the entire verification process, thereby improving the success rate of chip design.

[0043] The hierarchical cross-clock domain signal verification method provided in this embodiment relies on the physical layout information files corresponding to each functional module to dynamically, intelligently, and accurately identify the target functional module to be verified from multiple functional modules. Then, by extracting the target signature abstract model corresponding to the target functional module, CDC verification is performed on the next higher level of the target functional module, and so on, to perform CDC verification on the entire top-level system of the chip. Since it is not necessary to perform CDC verification on all functional modules, the efficiency of chip verification can be improved. Moreover, by performing CDC verification on the chip layer by layer through the target signature abstract model, the module level focuses on verifying the internal logical integrity of the functional module, while the top level strengthens the analysis of cross-module asynchronous paths, thus improving the accuracy of chip verification.

[0044] This embodiment provides a hierarchical cross-clock domain signal verification method, which can be used in electronic devices. Figure 3This is a flowchart of a hierarchical cross-clock domain signal verification method according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps: Step S301: Based on the physical layout information file corresponding to each functional module, determine the target functional module to be verified from multiple functional modules.

[0045] Regarding the selection of target functional modules, a large number of selected modules will affect the efficiency of CDC verification of the chip; conversely, a small number of selected modules may miss high-risk modules, affecting the accuracy of CDC verification. Therefore, target functional modules to be verified can be: ① Clock domain interaction modules, such as those using asynchronous FIFOs, handshake controllers, synchronizer chains (2FF / 3FF), clock dividers, etc. ② Reused IP cores, such as third-party IP cores or modules that have already undergone CDC verification, avoiding redundant checks. ③ Black-box modules with incomplete designs; if the module is not yet frozen, its interface behavior can be simulated using SAM. Conversely, target functional modules that do not require verification can be: ① Modules without CDC paths, pure combinational logic modules, or modules operating within a single clock domain. ② Low-risk modules, such as configuration registers (static signals), clock gating modules (synchronous clock generation), etc. ③ Verified full-chip low-level modules; if their CDC checks are already covered at the top level, they do not need to be identified as functional modules to be verified. Synchronizer chains are circuit structures in digital integrated circuits used to solve metastability problems during signal transmission across clock domains. Among them, 2FF synchronizers are two-stage flip-flop synchronizers and 3FF synchronizers are three-stage flip-flop synchronizers.

[0046] Specifically, step S301 includes: Step S3011: Based on the physical layout information file corresponding to each functional module, determine multiple initial functional modules with asynchronous clock domains from multiple functional modules.

[0047] An asynchronous clock domain can be a circuit region driven by two or more independent clocks with no fixed phase relationship.

[0048] As mentioned earlier, if a functional module has a single clock domain, then that functional module will not have a signal transmission path for an asynchronous clock domain. Based on this, by reading the physical layout information file corresponding to each functional module, the number of clock domains of the corresponding functional module can be determined. Then, functional modules with two or more clock domains, i.e., functional modules with asynchronous clock domains, can be used as the initial functional modules.

[0049] Step S3012: From multiple initial functional modules, determine multiple candidate functional modules with a predetermined number of intellectual property cores.

[0050] As a specific example, the predetermined quantity can be 3, but is not limited to 3; it can also be other values. There is no specific limitation on the specific value of the predetermined quantity here.

[0051] For an initial functional module, if the number of intellectual property cores in the initial functional module exceeds a predetermined number, it indicates that the cross-clock domain complexity of the initial functional module is high. For initial functional modules with high cross-clock domain complexity, further CDC verification is required. Thus, the number of intellectual property cores in the initial functional module can be used to further filter the initial functional modules, thereby obtaining multiple candidate functional modules.

[0052] Step S3013: Based on the clock frequency difference corresponding to each candidate functional module, determine the target functional module from multiple candidate functional modules.

[0053] Clock frequency difference can be the difference between the clock frequencies corresponding to two clock domains.

[0054] Within a chip, there may be two or more functional modules with the same IP core. For this type of functional module, the steps described above cannot be used to remove duplicates. Therefore, by using the clock frequency difference between the candidate functional modules, multiple candidate functional modules can be deduplicated to obtain the target functional module. This ensures that the same functional module is verified only once by CDC.

[0055] In some optional implementations, step S3013 above includes: Step a1: For any candidate functional module, query the physical layout information file corresponding to the candidate functional module, determine the cross-clock domain clock pairs with clock paths, and determine the clock frequency difference corresponding to the cross-clock domain clock pairs.

[0056] Step a2: Identify the candidate functional modules whose clock frequency difference is greater than the preset clock frequency difference as the target functional modules.

[0057] A clock path can be the complete circuit path through which a clock signal travels from its source to its destination. The source can be a clock generator or the clock input port of a chip, and the destination can be the clock pin of a timing element.

[0058] A cross-clock domain clock pair, also known as a CDC clock pair, can be two clock signals from different clock domains that are associated by a common signal path. For example, when a signal is sent from a register in one clock domain (driven by clock A) and then captured by a register in another clock domain (driven by clock B), clock A and clock B constitute a cross-clock domain clock pair.

[0059] As a concrete example, the `get_cdc_clock_pairs` function can be used to query the physical layout information file corresponding to the candidate functional module to obtain all CDC clock pairs that actually exist in the timing path. A CDC clock pair can be a combination of clocks that may have CDC interactions.

[0060] As a concrete example, the clock frequency difference between clock pairs across clock domains can be calculated using the `get_clock_freq_diff` function. The larger the clock frequency difference, the higher the risk of metastability.

[0061] The preset clock frequency difference can be a pre-set clock frequency difference threshold. As a specific example, the preset clock frequency difference can be 100. Of course, the preset clock frequency difference can also take any other suitable value, and this application does not specifically limit it. In practical applications, the preset clock frequency difference can be adjusted according to specific design requirements. Generally, functional modules with larger clock frequency differences are more likely to cause CDC problems, and appropriately increasing the preset clock frequency difference can reduce false alarms.

[0062] As a specific example, the get_module_by_clock_pair function can be used to find candidate functional modules corresponding to cross-clock domain clock pairs whose clock frequency difference is greater than a preset clock frequency difference, and these candidate functional modules can be identified as target functional modules.

[0063] To avoid redundant processing, clock frequency differences can be sorted in a specific order to filter out candidate functional modules corresponding to cross-clock domain clock pairs with clock frequency differences greater than a preset clock frequency difference, ensuring that each candidate functional module is processed only once. Furthermore, module priorities can be further refined, for example, by adjusting priorities based on module complexity or historical problem records.

[0064] By using the clock frequency difference between each candidate functional module, multiple candidate functional modules can be deduplicated relatively accurately and efficiently, thereby obtaining the target functional module.

[0065] Step S302: If the target functional module passes the cross-clock domain signal verification, then extract the target approval abstract model of the target functional module. For details, please refer to [link to relevant documentation]. Figure 2 Step S202 of the illustrated embodiment will not be described again here.

[0066] Step S303: Utilize the target approval abstract model to perform cross-clock domain signal verification on the next higher level of the target functional module. For details, please refer to [link to relevant documentation]. Figure 2 Step S203 of the illustrated embodiment will not be described again here.

[0067] Step S304: If the level above the target functional module passes the cross-clock domain signal verification, then the level above the target functional module is designated as the new module to be verified. For details, please refer to [link to relevant documentation]. Figure 2 Step S204 of the illustrated embodiment will not be described again here.

[0068] Step S305: Perform cross-clock domain signal verification on the chip using the new module to be verified. For details, please refer to [link to relevant documentation]. Figure 2 Step S205 of the illustrated embodiment will not be described again here.

[0069] The hierarchical cross-clock domain signal verification method provided in this embodiment filters multiple functional modules corresponding to the chip step by step by considering whether there is an asynchronous clock domain, the number of intellectual property cores inside the module, and the clock frequency difference. This method can accurately identify the target functional module to be verified by CDC, solving the problems of single clock domain modules being misidentified as high-risk objects and complex asynchronous interface modules being missed. It can also effectively solve the misjudgment problem caused by manual screening of target functional modules, i.e., SAM objects, improving the accuracy and reliability of target functional module positioning and ensuring the efficient use of verification resources.

[0070] This embodiment provides a hierarchical cross-clock domain signal verification method, which can be used in electronic devices. Figure 4 This is a flowchart of a hierarchical cross-clock domain signal verification method according to an embodiment of the present invention, such as... Figure 4 As shown, the process includes the following steps: Step S401: Based on the physical layout information files corresponding to each functional module, determine the target functional module to be verified from multiple functional modules. For details, please refer to [link to relevant documentation]. Figure 2 Step S201 of the illustrated embodiment will not be described again here.

[0071] Step S402: If the target functional module passes the cross-clock domain signal verification, then extract the target approval abstract model of the target functional module. For details, please refer to [link to relevant documentation]. Figure 2 Step S202 of the illustrated embodiment will not be described again here.

[0072] In some alternative implementations, cross-clock domain signal verification of the target functional module includes: Step b1: In the current loop of verifying the target functional module across clock domain signals, the target functional module is verified across clock domain signals based on the verification command of the pre-configured verification tool, and the verification result is obtained.

[0073] Step b2: If the verification result indicates that the target functional module has failed the cross-clock domain signal verification, then the target functional module is repaired according to the violation information in the verification result, and the next loop is entered.

[0074] Step b3 continues until any loop completes, at which point the loop ends, and the verification result indicates that the target functional module has passed the cross-clock domain signal verification.

[0075] During the CDC verification of the target functional module, the CDC verification environment and CDC verification constraints can be configured in the pre-configured verification tool first, and then the cross-clock domain signal verification of the target functional module can be performed based on the verification commands in the verification tool.

[0076] As a concrete example, during the repair of target functional modules, violations can be categorized based on their severity in the verification results. For instance, high-risk synchronizer missing issues can be fixed by modifying RTL code or CDC environment settings. Medium-risk data aggregation synchronization issues can be fixed by modifying code or adding filter files, while low-risk static signal CDC issues can be fixed by adding filter files. Simultaneously, a violation report can be output, recording the violation path, risk level, and repair status to ensure traceability. This tiered processing strategy ensures the accuracy and reliability of module-level verification while providing detailed violation information for subsequent repair.

[0077] After repairing the target functional module based on the violation information in the verification results, the target functional module can continue to be verified by CDC. If the target functional module still fails the CDC verification, the target functional module can continue to be repaired based on the violation information in the verification results. If the target functional module passes the CDC verification, the SAM model of the target functional module can be extracted, and the CDC verification of the next level of the target functional module can be performed based on the extracted SAM model, until the top-level system (i.e. the entire chip) is verified by CDC.

[0078] Based on the violation information in the verification results, the problem can be quickly located, and the target functional module can be quickly repaired.

[0079] Specifically, step S402 includes: Step S4021: Based on the extraction command of the pre-configured verification tool, the register transfer code and physical layout information file corresponding to the target functional module are jointly extracted to obtain the initial signing abstract model.

[0080] Register transfer code (RTL code) describes how data is transferred between registers in a digital system under the drive of a clock signal, and how it is combined and processed by logic during the transfer. As a concrete example, pre-configured verification tools can be used to jointly extract the RTL code and physical layout information files corresponding to the CDC environment configuration and the target functional module to obtain the initial approval abstract model corresponding to the target functional module.

[0081] Step S4022: Query the comment information in the register transfer code of the target functional module to determine the cross-clock domain verification constraints corresponding to the target functional module.

[0082] In register-transfer-level (RTL) code, comments are natural language descriptions embedded in hardware description language (such as Verilog and VHDL) code. They are used to explain key information such as the code's design intent, functional logic, timing constraints, and interface definitions. They are an important means of improving code readability, maintainability, and team collaboration efficiency.

[0083] As a concrete example, all comments related to CDC_CFG and CDC_IGNORE are automatically extracted from the RTL code, such as / / CDC_CFG: scheme=2FF_sync defining the synchronization strategy, and / / CDC_IGNORE: path=config_reg used to mark filtering paths. Based on these comments, cross-clock domain verification constraints, i.e., CDC constraints, corresponding to the target functional module are generated. Determining the cross-clock domain verification constraints for the target functional module in this way avoids manual coding errors and ensures the accuracy and consistency of the constraints.

[0084] Step S4023: Read module-level constraints from the physical layout information file corresponding to the target functional module.

[0085] Module-level constraints may include, but are not limited to, clock constraints, reset constraints, logic constraints, power consumption constraints, and physical constraints.

[0086] As a concrete example, the physical layout information file can be parsed according to the organization of various information in the physical layout information file, thereby reading the module-level constraints.

[0087] Step S4024: Add cross-clock domain verification constraints and module-level constraints to the initial signature abstract model to obtain the target signature abstract model.

[0088] Adding cross-clock domain verification constraints and module-level constraints to the initial approval abstract module ensures that the target approval abstract model contains the cross-clock domain verification constraints and module-level constraints of the target functional module. Subsequently, when performing CDC verification on the level above the target functional module using the target approval abstract model corresponding to the target functional module, the level above the target functional module will also possess the cross-clock domain verification constraints and module-level constraints of the target functional module. This allows the level above the target functional module to inherit the constraints corresponding to the target functional module, automatically associating module-level CDC constraints, clock constraints, and reset constraints to the level above the target functional module, thus ensuring consistency between module-level constraints and top-level constraints.

[0089] Furthermore, when conflicts arise between module-level constraints and top-level globally defined constraints, the verification method in this application can automatically recommend conflict resolution solutions by invoking a rule-based inference engine and generate a visual conflict report for manual verification. For example, when the clock cycle defined within a module is inconsistent with the top-level requirement, the clock cycle defined by the top-level engine is adopted first, and a detailed report explaining the conflict and recommended solutions is generated, thereby ensuring consistency across constraints. The rule-based inference engine can be trained based on a large model.

[0090] By using module-level constraints and cross-clock domain verification constraints, the constraints of the target functional module can be inherited by the next level in a more intelligent way. This also avoids the risk of errors and omissions introduced by manually writing the constraints of the next level of the target functional module.

[0091] In some alternative implementations, the method further includes: Step c1: If the register transfer code of any target functional module changes, then the changed register transfer code and the physical layout information file corresponding to the target functional module are jointly extracted to obtain a new target approval abstract model.

[0092] For modules that are not yet frozen or functional modules that require re-verification, this application provides the function of re-extracting the SAM model. This helps ensure that all interface-related CDC issues are accurately captured during top-level verification, further enhancing the comprehensiveness and accuracy of the verification. Moreover, during design iterations, the RTL code of functional modules may change. This application supports incremental updates of the SAM model, i.e., re-extracting the SAM model only for the affected functional modules, rather than re-running the extraction process entirely. This mechanism significantly reduces iteration costs and avoids the resource waste caused by full recompilation. Simultaneously, it ensures that the SAM model can reflect the latest design state and constraints in a timely manner, improving the flexibility and efficiency of the verification process.

[0093] When the register transfer code of a target functional module changes, SAM regeneration and incremental verification are performed only on the affected module, which can avoid full duplication calculation, thereby improving verification efficiency and reducing resource consumption.

[0094] Step S403: Use the target approval abstract model to perform cross-clock domain signal verification on the next higher level of the target functional module.

[0095] Specifically, step S403 includes: Step S4031: Obtain the hierarchical information of the target functional module.

[0096] The hierarchical information of the target functional module is used to characterize the hierarchical information of the target functional module within the entire chip hierarchy. As a concrete example, the hierarchical information of the target functional module can be obtained by querying the RTL code corresponding to the target functional module.

[0097] Step S4032: Obtain the file storage path and file naming information of the target signature abstract model.

[0098] The file storage path can be the file storage path of the target signature abstract model relative to the root directory of the entire verification file. The file naming information can be the naming information of the model file corresponding to the target signature abstract model.

[0099] As a concrete example, the file storage path can be obtained by accessing the location where the target signature abstract model is stored, and the file naming information can be obtained by accessing the target signature abstract model.

[0100] Step S4033: Bind the hierarchical information, file storage path and file naming information to the upper level of the target functional module, so as to use the target signature abstract model to perform cross-clock domain signal verification on the upper level of the target functional module.

[0101] Binding the hierarchical information of the target functional module and the file storage path and file naming information corresponding to its target signature abstract model to the upper level of the target functional module is equivalent to configuring the target signature abstract module corresponding to the target functional module into the verification environment of the upper level of the target functional module. This ensures a precise mapping between the module-level abstract model and the upper level of the target functional module.

[0102] By binding hierarchical information, file storage path, and file naming information to the upper level of the target functional module, the target approval abstract model corresponding to the target functional module can be mapped to its upper level relatively accurately and quickly.

[0103] Step S404: If the level above the target functional module passes the cross-clock domain signal verification, then the level above the target functional module is taken as the new module to be verified. For details, please refer to [link to relevant documentation]. Figure 2 Step S204 of the illustrated embodiment will not be described again here.

[0104] Step S405: Perform cross-clock domain signal verification on the chip using the new module to be verified. For details, please refer to [link to relevant documentation]. Figure 2 Step S205 of the illustrated embodiment will not be described again here.

[0105] The hierarchical cross-clock domain signal verification method provided in this embodiment automatically extracts the SAM model from the target functional module that has passed the cross-clock domain signal verification, thereby generating a standardized signature abstract model from the verified module for use in higher-level CDC verification. This not only achieves an efficient transition from module-level verification to top-level integration verification, but also improves the automation and accuracy of the verification process, further enhancing verification efficiency and reducing resource consumption.

[0106] As a specific application embodiment of the present invention, such as Figure 5 The diagram illustrates a specific hierarchical cross-clock domain signal verification method. This method includes steps S501 to S509.

[0107] Step S501, SAM object confirmation. By considering whether it has an asynchronous clock domain, the number of intellectual property cores within the module, and the clock frequency difference, multiple functional modules corresponding to the chip are gradually screened to determine the target functional module, i.e., the SAM object.

[0108] Step S502, Module-level CDC verification. Based on the verification commands of the pre-configured verification tool, cross-clock domain signal verification is performed on the target functional module.

[0109] Step S503: Determine whether the module-level CDC verification is passed. If the module-level CDC verification is passed, proceed to steps S504 to S509; if the module-level CDC verification is not passed, return to step S502.

[0110] Step S504: Query the comment information in the register transfer code of the target functional module to determine the cross-clock domain verification constraint, i.e., CDC constraint, corresponding to the target functional module, and read the module-level constraint from the physical layout information file corresponding to the target functional module.

[0111] Step S505, SAM model extraction. Using a pre-configured verification tool, the CDC environment configuration, the RTL code corresponding to the target functional module, and the physical layout information file are jointly extracted to obtain the initial approval abstract model corresponding to the target functional module; cross-clock domain verification constraints and module-level constraints are added to the initial approval abstract model to obtain the target approval abstract model.

[0112] Step S506, SAM model configuration. Bind the hierarchical information of the target functional module, along with the file storage path and file naming information corresponding to its target signature abstract model, to the parent level of the target functional module. This is equivalent to configuring the target signature abstract module corresponding to the target functional module into the parent verification environment of the target functional module.

[0113] Step S507: Perform CDC verification on the level above the target functional module. This process is repeated to progressively perform CDC verification on each level of the SoC chip.

[0114] Step S508: Determine whether to perform CDC verification on all levels. If CDC verification is performed on all levels, proceed to step S509; if CDC verification is not performed on all levels, continue to step S507.

[0115] Step S509: Determine whether the top layer passes CDC verification. If the top layer fails CDC verification, return to step S502 to continue CDC verification of the chip. If the top layer passes CDC verification, the verification ends.

[0116] This application focuses on verifying the integrity of internal logic at the module level, while strengthening the analysis of asynchronous paths across modules at the top level. This overcomes the detection blind spots of black-box methods and eliminates the possibility of missing hidden risks such as metastability propagation. Furthermore, the hierarchical verification architecture of this application breaks through the limitations of traditional flat architectures, constructing a unified verification framework that supports cross-level penetrating analysis. Through a multi-level nesting mechanism, it achieves progressive analysis from the IP core level, subsystem level to the SoC top level, accurately capturing asynchronous interaction paths between multi-level modules and effectively identifying potential defects in complex signal links. Simultaneously, based on parameterized configuration, the core elements of this method (such as clock domain parameters and synchronization strategies) can be replaced with other replaceable variables for quality checks, seamlessly extending to verification in multi-physical domain scenarios such as reset domain crossover and voltage domain crossover.

[0117] This application constructs a closed-loop feedback system for dynamic iterative optimization of the SAM model, providing precise tuning capabilities for design changes and verification feedback. When the module RTL code is modified, the affected scope is identified, and only the SAM model of the related modules is regenerated, avoiding resource redundancy from full re-extraction. Based on the analysis results of the top-level CDC violation report, the SAM model parameters are locally fine-tuned to ensure that the abstract model is consistent with the latest design state. This mechanism transforms manual debugging intervention in the traditional process into automated closed-loop tuning, significantly accelerating the design iteration cycle while maintaining the traceability and reliability of the verification process.

[0118] This embodiment also provides a hierarchical cross-clock domain signal verification device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0119] This embodiment provides a hierarchical cross-clock domain signal verification device, such as... Figure 6 As shown, it includes: The first determining module 601 is used to determine the target functional module to be verified from multiple functional modules based on the physical layout information file corresponding to each functional module.

[0120] Extraction module 602 is used to extract the target signature abstract model of the target functional module if the target functional module passes the cross-clock domain signal verification.

[0121] The first verification module 603 is used to perform cross-clock domain signal verification on the next higher level of the target functional module using the target signature abstract model.

[0122] The second determining module 604 is used to determine the upper level of the target functional module as a new module to be verified if the upper level of the target functional module passes the cross-clock domain signal verification.

[0123] The second verification module 605 is used to perform cross-clock domain signal verification on the chip using the new module to be verified.

[0124] In some optional implementations, the first determining module 601 is further configured to determine, based on the physical layout information file corresponding to each functional module, a plurality of initial functional modules having an asynchronous clock domain from a plurality of functional modules; determine, from the plurality of initial functional modules, a plurality of candidate functional modules having a predetermined number of intellectual property cores; and determine, based on the clock frequency difference corresponding to each candidate functional module, a target functional module from the plurality of candidate functional modules.

[0125] In some optional implementations, the first determining module 601 is further configured to query the physical layout information file corresponding to any candidate functional module, determine the cross-clock domain clock pair with clock path, and determine the clock frequency difference corresponding to the cross-clock domain clock pair; and determine the candidate functional module whose clock frequency difference is greater than the preset clock frequency difference as the target functional module.

[0126] In some optional implementations, the extraction module 602 is further configured to, based on the extraction command of a pre-configured verification tool, jointly extract the register transfer code and physical layout information file corresponding to the target functional module to obtain an initial approval abstract model; query the comment information in the register transfer code of the target functional module to determine the cross-clock domain verification constraints corresponding to the target functional module; read the module-level constraints from the physical layout information file corresponding to the target functional module; and add the cross-clock domain verification constraints and module-level constraints to the initial approval abstract model to obtain the target approval abstract model.

[0127] In some optional implementations, the first verification module 603 is further configured to obtain the hierarchical information of the target functional module; obtain the file storage path and file naming information of the target approval abstract model; and bind the hierarchical information, file storage path and file naming information to the upper level of the target functional module, so as to use the target approval abstract model to perform cross-clock domain signal verification on the upper level of the target functional module.

[0128] In some optional implementations, cross-clock domain signal verification of the target functional module includes: within the current loop of cross-clock domain signal verification of the target functional module, performing cross-clock domain signal verification on the target functional module based on the verification command of the pre-configured verification tool, and obtaining the verification result; if the verification result indicates that the target functional module has failed the cross-clock domain signal verification, then the target functional module is repaired according to the violation information in the verification result, and the next loop is entered; until in any loop, the verification result indicates that the target functional module has passed the cross-clock domain signal verification, and the loop ends.

[0129] In some alternative embodiments, the device further includes: The update module is used to extract the changed register transfer code and the physical layout information file corresponding to the target functional module if the register transfer code of any target functional module changes, so as to obtain a new target approval abstract model.

[0130] The hierarchical cross-clock domain signal verification device provided in this embodiment of the invention can execute the hierarchical cross-clock domain signal verification method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the above modules and units are the same as in the corresponding embodiments described above, and will not be repeated here.

[0131] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0132] The following is a detailed reference. Figure 7 This diagram illustrates a suitable structural schematic for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 701, which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 702 or a program loaded from memory 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the electronic device. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0133] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0134] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 709, or installed from a memory 708, or installed from a ROM 702. When the computer program is executed by the processor 701, it performs the functions defined in the hierarchical cross-clock domain signal verification method of the embodiments of the present invention.

[0135] Figure 7 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0136] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the hierarchical cross-clock domain signal verification method shown in the above embodiments is implemented.

[0137] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0138] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A hierarchical cross-clock-domain signal verification method, characterized in that, The chip comprises a plurality of functional modules, and the method comprises: determining a target functional module to be verified from the plurality of functional modules based on physical layout information files corresponding to each of the functional modules; if the target functional module passes the cross-clock-domain signal verification, extracting a target register-transfer level (RTL) abstract model of the target functional module; performing cross-clock-domain signal verification on a previous level of the target functional module by using the target RTL abstract model; if the previous level of the target functional module passes the cross-clock-domain signal verification, taking the previous level of the target functional module as a new functional module to be verified; performing the cross-clock-domain signal verification on the chip by using the new functional module to be verified.

2. The method of claim 1, wherein, The method comprises: determining a plurality of initial functional modules having asynchronous clock domains from the plurality of functional modules based on the physical layout information files corresponding to each of the functional modules; determining a plurality of candidate functional modules having a predetermined number of intellectual property (IP) cores from the plurality of initial functional modules; determining the target functional module from the plurality of candidate functional modules based on a clock frequency difference corresponding to each of the candidate functional modules.

3. The method of claim 2, wherein, The method comprises: for any one of the candidate functional modules, querying the physical layout information file corresponding to the candidate functional module to determine a cross-clock-domain clock pair having a clock path and determine the clock frequency difference corresponding to the cross-clock-domain clock pair; determining the candidate functional module having a clock frequency difference greater than a preset clock frequency difference as the target functional module.

4. The method of claim 1, wherein, The method comprises: jointly extracting register-transfer code corresponding to the target functional module and the physical layout information file based on an extraction command of a preconfigured verification tool to obtain an initial RTL abstract model; querying annotation information in the register-transfer code of the target functional module to determine cross-clock-domain verification constraints corresponding to the target functional module; reading module-level constraints from the physical layout information file corresponding to the target functional module; adding the cross-clock-domain verification constraints and the module-level constraints to the initial RTL abstract model to obtain the target RTL abstract model.

5. The method of claim 1, wherein, The method comprises: obtaining level information of the target functional module; obtaining a file storage path and file naming information of the target RTL abstract model; binding the level information, the file storage path, and the file naming information with a previous level of the target functional module to perform cross-clock-domain signal verification on the previous level of the target functional module by using the target RTL abstract model.

6. The method according to any one of claims 1 to 5, characterized in that, The method comprises: In a current loop of the cross-clock-domain signal verification of the target function module, the cross-clock-domain signal verification of the target function module is performed based on a verification command of a preconfigured verification tool, and a verification result is obtained; If the verification result indicates that the target function module fails the cross-clock-domain signal verification, the target function module is repaired according to exception information in the verification result, and a next loop is entered; Until the verification result indicates that the target function module passes the cross-clock-domain signal verification in any loop, the loop is ended.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: If the register transfer code of any target function module is changed, the register transfer code after the change and the physical layout information file corresponding to the target function module are jointly extracted to obtain a new target sign core abstract model.

8. A hierarchical cross-clock-domain signal verification apparatus, comprising: The chip includes a plurality of function modules, and the device includes: A first determination module configured to determine a target function module to be verified from the plurality of function modules based on physical layout information files corresponding to the function modules; An extraction module configured to extract a target sign core abstract model of the target function module if the target function module passes the cross-clock-domain signal verification; A first verification module configured to perform cross-clock-domain signal verification on a previous level of the target function module using the target sign core abstract model; A second determination module configured to use a previous level of the target function module as a new target function module to be verified if the previous level of the target function module passes the cross-clock-domain signal verification; A second verification module configured to perform the cross-clock-domain signal verification on the chip using the new target function module to be verified.

9. An electronic device, comprising: It includes: A memory and a processor, which are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the hierarchical cross-clock-domain signal verification method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for causing a computer to perform the hierarchical cross-clock-domain signal verification method of any one of claims 1 to 7.

Images