Verification method and device, computer device and readable storage medium

Abstract

The application relates to a verification method and device, computer equipment and a readable storage medium. The method comprises the following steps: obtaining a to-be-verified object in a register transfer level design stage of a system on chip; performing static checking on the to-be-verified object to obtain an abnormal item in the to-be-verified object; performing dynamic verification on the abnormal item according to a target verification model and register transfer level code in the register transfer level design stage to obtain a verification result of the to-be-verified object. The method can accelerate the verification speed in the chip design process.

Description

Technical Field

[0001] This application relates to the field of chip design verification technology, and in particular to a verification method, apparatus, computer equipment, and readable storage medium. Background Technology

[0002] In System-on-Chip (SoC) design, pre-silicon verification is a crucial step in ensuring the correctness of chip functionality and timing reliability. Simulation verification typically includes pre-simulation and post-simulation. Pre-simulation inputs can be provided in parallel during the Register Transfer Level (RTL) design phase, while post-simulation inputs are only put into production at certain project milestones. Therefore, pre-simulation can begin verification earlier than post-simulation and discover potential problems that post-simulation might simulate, resulting in higher efficiency in problem detection. Based on past project experience, it typically takes about 6.4 days to discover design problems in the post-simulation phase, while it usually takes only 0.5 days in the pre-simulation phase. However, existing pre-simulation verification methods can only verify functional issues in the chip design and cannot verify timing issues. Timing constraints (Synopsys Design Constraints, SDC) and clock domain crossing (CDC) design problems can only be verified through post-simulation, leading to slower timing problem verification speeds. Summary of the Invention

[0003] Therefore, it is necessary to provide a verification method, apparatus, computer equipment, chip module, computer-readable storage medium, and computer program product that can discover SDC and CDC problems in the register-transfer level design stage and improve verification speed, in order to address the above-mentioned technical problems.

[0004] Firstly, this application provides a verification method, including:

[0005] Obtain the objects to be verified during the design phase of the on-chip system register transfer level;

[0006] Perform a static check on the object to be verified to identify any anomalies in the object.

[0007] Based on the pre-built target verification model and the register transfer level code in the register transfer level design phase, the anomalies are dynamically verified to obtain the verification result of the object to be verified.

[0008] In one embodiment, the object to be verified includes a timing constraint file;

[0009] The static inspection of the object to be verified to obtain anomalies in the object to be verified includes:

[0010] A static check is performed on the timing constraint file to identify any anomalies.

[0011] In one embodiment, the object to be verified includes a cross-clock domain design document;

[0012] The static inspection of the object to be verified to obtain anomalies in the object to be verified includes:

[0013] A static check is performed on the cross-clock domain design file to identify any anomalies.

[0014] In one embodiment, the method further includes:

[0015] Determine the initial verification model for the on-chip system;

[0016] The initial verification model is debugged to obtain the debugged verification model;

[0017] If the regression test of the debugged validation model passes, the target validation model is obtained based on the debugged validation model.

[0018] In one embodiment, the step of dynamically verifying the anomalies based on a pre-built target verification model and the register-transfer level code from the register-transfer level design phase, to obtain the verification result of the object to be verified, includes:

[0019] Dynamic simulation is performed based on the target verification model, the register transfer level code, and the anomaly items to obtain dynamic simulation results.

[0020] The dynamic simulation results are analyzed to obtain the verification results of the object to be verified.

[0021] In one embodiment, the step of parsing the dynamic simulation results to obtain the verification result of the object to be verified includes:

[0022] If the coverage of the dynamic simulation results reaches the target coverage, the dynamic simulation results are analyzed to obtain the verification results of the object to be verified.

[0023] In one embodiment, the method further includes:

[0024] Obtain simulation logs for dynamic simulation based on the target verification model, the register transfer level code, and the anomaly items;

[0025] Identify the target error message in the simulation log; the probability of the target error message occurring exceeds a preset threshold.

[0026] Based on the target error information, identify the problem nodes in the register transfer stage design phase; the problem nodes include at least one of timing constraint files, cross-clock domain design files, and register transfer stage code.

[0027] Secondly, this application also provides a verification device, comprising:

[0028] The object acquisition module is used to acquire the objects to be verified during the design phase of the on-chip system register transfer level.

[0029] The first verification module is used to perform static checks on the object to be verified and obtain the abnormal items in the object to be verified.

[0030] The second verification module is used to dynamically verify the anomalies based on the pre-built target verification model and the register transfer level code in the register transfer level design phase, and obtain the verification result of the object to be verified.

[0031] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method provided in the first aspect above.

[0032] Fourthly, this application also provides a chip module, including a communication module, a power module, a storage module, and a chip, wherein:

[0033] The power module is used to provide power to the chip module;

[0034] The storage module is used to store data and instructions;

[0035] The communication module is used for internal communication within the chip module, or for communication between the chip module and external devices.

[0036] The chip is used to perform the steps of the method provided in the first aspect above.

[0037] Fifthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method provided in the first aspect above.

[0038] Sixthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method provided in the first aspect above.

[0039] The aforementioned verification methods, apparatus, computer equipment, chip modules, computer-readable storage media, and computer program products acquire the object to be verified in the register-transfer level design phase of the on-chip system, perform static checks on the object to be verified to obtain anomalies, and dynamically verify the anomalies based on a pre-constructed target verification model and the register-transfer level code in the register-transfer level design phase to obtain the verification result of the object to be verified. This allows for the extraction of anomalies through static checks in the register-transfer level design phase, i.e., the pre-simulation phase, followed by dynamic verification of the anomalies. This enables the timely detection of timing issues such as SDC and CDC in the chip design process, thereby accelerating the verification speed in the chip design process. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a flowchart illustrating the verification method in one embodiment;

[0042] Figure 2 This is a flowchart illustrating a dynamic simulation method for SoC-level SDC design based on a Version Control System (VCS) platform in one embodiment.

[0043] Figure 3 This is a flowchart illustrating a dynamic simulation method for SoC-level CDC design based on a VCS platform in one embodiment.

[0044] Figure 4 This is a flowchart illustrating the verification method in another embodiment;

[0045] Figure 5 This is a structural block diagram of the verification device in one embodiment;

[0046] Figure 6 This is an internal structural diagram of a computer device in one embodiment;

[0047] Figure 7 This is an internal structure diagram of a chip module in one embodiment. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0049] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various components, but these components are not limited by these terms. These terms are only used to distinguish the first component from the second component. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the solutions, or any combination of multiple solutions. The terms "front-end simulation" and "back-end simulation" used in this application refer to logic function simulation that does not consider actual circuit delays, while "back-end simulation" refers to simulation that includes actual process and timing delays, and is closer to the actual operating state of the chip.

[0050] Given the significant manpower, time, and server resources invested in the post-simulation phase of past projects, there has been a search for methods to move parts of the post-simulation process to the pre-simulation phase. However, delegating timing problem verification to a formal verification engine presents several challenges. For instance, due to the nature of formal verification's input iteration, the number of error messages often increases exponentially with the design scale, impacting the project's feasibility. Furthermore, static checking results are often irrelevant to actual usage scenarios; real defects may be hidden among hundreds or thousands of false errors, hindering human review. Therefore, this application proposes incorporating the results of static checking into dynamic simulation. By constructing verification test cases, some paths not present in actual use are filtered out, ensuring no critical issues are missed while reducing the burden of human review.

[0051] Currently, there are many static inspection tools and methods, but pre-simulation verification for timing problems is lacking. In addition, there are frequent cases of waiving errors when manually confirming them, indicating that the presence of a large number of error messages reduces the reliability of human inspection. Introducing dynamic simulation can specifically solve this shortcoming of static inspection, delete redundant error messages, provide as few error items as possible for human inspection, and ensure the consistency between RTL behavior and SDC constraints and CDC design.

[0052] Furthermore, the VCS tool itself only provides a method for manually reviewing error messages, which is a laborious and time-consuming task, and there is still a possibility of false waiving. Automating the classification and accurate identification of error messages can significantly improve the efficiency of validation regression iterations.

[0053] Because input components for pre-simulation can be provided in parallel during the RTL design phase, while input components for post-simulation only begin to be used at certain project milestones, pre-simulation can begin verification earlier than post-simulation and identify potential problems that post-simulation might simulate. In terms of simulation efficiency, pre-simulation is significantly faster than post-simulation. When problems are discovered, the design and verification owners need to synchronize, resulting in a qualitative improvement in the iterative process and saving simulation server resources. Furthermore, problems discovered in pre-simulation can be fixed immediately without involving modifications to the netlist or timing and the need for Engineering Change Orders (ECOs). This reduces labor costs and project timelines while allowing sufficient time to ensure design quality.

[0054] Furthermore, compared to the runtime tool (Xcelium Run, xrun), VCS is not well-suited to the static inspection results of SDC / CDC, resulting in a large number of middleware modifications and increased manual inspection costs. Therefore, using VCS can also reduce costs.

[0055] In one exemplary embodiment, such as Figure 1 As shown, a verification method is provided. This embodiment illustrates the application of this method to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0056] Step S102: Obtain the object to be verified in the design phase of the on-chip system register transfer level.

[0057] The register-transfer level design stage refers to the phase in chip design where the abstract representation of circuit functions is achieved by describing the data transfer behavior of registers and combinational logic; it can also be called the pre-simulation stage. The object to be verified refers to the target object that needs to be verified during the chip design process, including but not limited to SDC constraints and CDC design.

[0058] Optionally, during the register-transfer level design phase of the system-on-chip, the object to be verified can be input into the terminal, and the terminal obtains the object to be verified accordingly. For example, during the RTL design phase of chip design, to verify SDC constraints, the SDC constraint file can be input into the terminal, and the terminal obtains the SDC constraint file; to verify CDC design, the CDC design file can be input into the terminal, and the terminal obtains the CDC design file.

[0059] Step S104: Perform a static check on the object to be verified to obtain the anomalies in the object to be verified.

[0060] Static checking refers to verifying the correctness of a circuit by analyzing its characteristics without relying on actual runtime simulation, including but not limited to static checking of SDC and / or CDC. Anomalies are objects to be verified that fail the static check; in practical applications, anomalies can also be called failure items or error items.

[0061] Optionally, after obtaining the object to be verified, the terminal can perform a static check on it. If the static check passes, the next object to be verified is checked; otherwise, if the static check fails, the object to be verified is treated as an exception. In practical applications, a Time Compression Multiplexer (TCM) can be installed on the terminal to perform static checks on the SDC constraint file and output the SDC constraint files that fail the check. The terminal can also have a Verification Compiler SpyGlass (VC SpyGlass) installed to perform static checks on the CDC design file and output System Verilog Assertion (SVA) assertions for the CDC design files that fail the check.

[0062] Step S106: Based on the pre-built target verification model and the register transfer level code in the register transfer level design phase, perform dynamic verification on the anomalies to obtain the verification result of the object to be verified.

[0063] The target verification model refers to a pre-built SoC-level verification environment, including but not limited to SoC-level verification environments built on VCS simulation platforms. Register-transfer level code refers to the high-level abstract language used in chip design to describe circuit behavior, which can be written in Verilog or a hardware description language (VHSIC Hardware Description Language, VHDL), but is not limited to this. Verification results refer to the results of verifying anomalies and RTL design within the SoC-level verification environment; for example, whether anomalies match the RTL design, and whether SDC or CDC issues exist.

[0064] Optionally, a target verification model can be pre-built on the terminal. After identifying anomalies in the object to be verified through static checks, dynamic verification can be performed on the anomalies and RTL code based on the target verification model to obtain the corresponding verification results. For example, the terminal can perform dynamic simulation using error items in the SDC constraint file and RTL code based on a pre-built SoC-level verification environment, obtain dynamic simulation results, and identify SDC problems from the dynamic simulation results. Based on the pre-built SoC-level verification environment, the terminal can also perform dynamic simulation using error items in the CDC design file and RTL code, obtain dynamic simulation results, and identify CDC problems from the dynamic simulation results.

[0065] The above verification method obtains the object to be verified in the register-transfer level design stage of the on-chip system, performs static checks on the object to be verified to obtain anomalies, and performs dynamic verification on the anomalies based on the pre-built target verification model and the register-transfer level code in the register-transfer level design stage to obtain the verification result of the object to be verified. It can extract anomalies through static checks in the register-transfer level design stage, i.e. the pre-simulation stage, and then perform dynamic verification on the anomalies, thereby timely discovering timing problems such as SDC and CDC in the chip design process and accelerating the verification speed in the chip design process.

[0066] In an exemplary embodiment, the object to be verified includes a timing constraint file; step S104 above may specifically include: performing a static check on the timing constraint file to obtain anomalies in the timing constraint file.

[0067] Optionally, the terminal can perform static checks on the SDC constraint files. If the check passes, it continues to check other files; otherwise, if the check fails, the SDC constraint file can be output as an exception. For example, a TCM tool can be installed on the terminal to perform static checks on the SDC constraint files and output the SDC constraint files that fail the check as failure items (Fail SDC).

[0068] In this embodiment, by performing a static check on the timing constraint file, abnormal items in the timing constraint file are obtained, and failed items can be filtered out from the SDC constraints. Thus, during dynamic checks, only failed items can be checked, without having to check all SDC constraints, thereby improving the efficiency of SDC checks.

[0069] In an exemplary embodiment, the object to be verified includes a cross-clock domain design file; step S104 above may specifically include: performing a static check on the cross-clock domain design file to obtain anomalies in the cross-clock domain design file.

[0070] Optionally, the terminal can perform static checks on CDC design files. If the check passes, it continues to check other files; otherwise, if the check fails, the CDC design file can be output as an exception. For example, the VC SpyGlass tool can be installed on the terminal to perform static checks on CDC design files, and CDC design files that fail the check can be output as failures (Structural CDC) with the corresponding SVA assertions.

[0071] In this embodiment, by performing a static check on the cross-clock domain design file, abnormal items in the cross-clock domain design file are obtained, and failure items can be filtered out from the CDC design. Thus, during dynamic checking, only failure items can be checked, without having to check all CDC designs, thereby improving the efficiency of CDC checking.

[0072] In an exemplary embodiment, the above verification method may further include: determining an initial verification model for the on-chip system; debugging the initial verification model to obtain a debugged verification model; and obtaining a target verification model based on the debugged verification model if the regression test of the debugged verification model passes.

[0073] The initial verification model can be the initially configured verification environment. The debugged verification model can be a verification environment adapted to a specified Electronic Design Automation (EDA) simulation tool after parameter adjustments.

[0074] Optionally, the terminal can pre-build an initial verification model at the SoC level, debug the initial verification model to obtain a debugged verification model, and perform regression testing on the debugged verification model. If the regression test passes, the debugged verification model can be used as the target verification model; otherwise, if the regression test fails, debugging continues until the regression test passes. In practical applications, a SoC-level verification environment can be built based on RTL design characteristics, and this SoC-level verification environment can be debugged based on a VCS simulation platform until the regression test passes. It can be understood that passing the regression test indicates that the built verification environment is usable.

[0075] In this embodiment, by determining the initial verification model of the on-chip system, debugging the initial verification model, and obtaining the debugged verification model, and if the regression test of the debugged verification model passes, the target verification model is obtained based on the debugged verification model. This can build a practical simulation environment for the pre-simulation of the object to be verified and determine the reliable execution of the simulation.

[0076] In an exemplary embodiment, step S106 may specifically include: performing dynamic simulation based on the target verification model, register transfer level code, and exception items to obtain dynamic simulation results; and parsing the dynamic simulation results to obtain the verification results of the object to be verified.

[0077] Among them, dynamic simulation results refer to the results obtained by simulating error items and RTL code based on the verification environment, including but not limited to simulation log files.

[0078] Optionally, the terminal can perform dynamic simulation based on the target verification model, RLT code, and anomalies in the object to be verified to obtain dynamic simulation results. By parsing the dynamic simulation results, the verification results of the object to be verified can be obtained. For example, the terminal can pre-build a SoC-level verification environment based on RTL design characteristics, debug and pass regression on the VCS simulation platform, and then perform dynamic simulation by combining the error items obtained from static checking, RTL code, and verification environment to obtain dynamic simulation results. The terminal can also automatically identify the dynamic simulation results, for example, by using deep learning, neural networks, and other methods to determine whether there are SDC or CDC problems in the pre-simulation stage.

[0079] In this embodiment, dynamic simulation is performed based on the target verification model, register transfer level code, and exceptions to obtain dynamic simulation results. The dynamic simulation results are then analyzed to obtain the verification results of the object to be verified. Dynamic simulation can be performed in combination with the results of static simulation, and the chip design can be automatically determined to have SDC or CDC problems in the pre-simulation stage, thereby improving the efficiency of chip design.

[0080] In an exemplary embodiment, the step of parsing the dynamic simulation results to obtain the verification result of the object to be verified may specifically include: parsing the dynamic simulation results to obtain the verification result of the object to be verified when the coverage of the dynamic simulation results reaches the target coverage.

[0081] Coverage refers to the degree to which test cases cover the design. The target coverage can be a pre-set, desired coverage level.

[0082] Optionally, the terminal can calculate the coverage of the dynamic simulation results. If the coverage reaches the target coverage, the dynamic simulation results can be parsed to obtain the verification result of the object to be verified. Otherwise, if the coverage does not reach the target coverage, the simulation can continue until the coverage reaches the target coverage. For example, the target coverage can be set to 100%, and the dynamic simulation output results can be analyzed for coverage. If the coverage does not reach 100%, or the dynamic simulation output results show failure, the process returns to the starting point, and the verification environment is re-debugged. Otherwise, if the coverage reaches 100%, the dynamic simulation output results can be parsed to determine whether the simulation verification passed or failed. A successful simulation verification can be understood as the chip design not having SDC or CDC issues, and a failed simulation verification indicates that the chip design has SDC or CDC issues.

[0083] In this embodiment, by parsing the dynamic simulation results when the coverage of the dynamic simulation results reaches the target coverage, the verification results of the object to be verified can be obtained, which can ensure the coverage of simulation verification and increase the reliability of simulation verification.

[0084] In an exemplary embodiment, the above verification method may further include: acquiring simulation logs of dynamic simulation based on the target verification model, register transfer level code, and exception items; identifying target error information in the simulation logs; the probability of occurrence of the target error information exceeding a preset threshold; determining problem nodes in the register transfer level design stage based on the target error information; the problem nodes include at least one of timing constraint files, cross-clock domain design files, and register transfer level code.

[0085] The simulation log is the simulation log file. Target error messages refer to error messages whose occurrence probability exceeds a specified threshold, such as frequently occurring error messages, where the occurrence probability refers to the likelihood of the error occurring. Problem nodes refer to factors that cause simulation verification to fail, including but not limited to SDC constraint files, CDC constraint files, and RTL code.

[0086] Optionally, after performing dynamic simulation based on the target verification model, RTL code, and anomalies in the object to be verified, and obtaining the dynamic simulation results and corresponding simulation logs, the terminal can automatically identify error messages in the simulation logs whose occurrence probability exceeds a preset threshold, obtain the target error messages, and then determine the nodes causing problems in the current RTL design stage based on the target error messages. For example, the terminal can automatically analyze the log files generated by the simulation, including but not limited to automatically identifying frequently occurring errors in the log files through deep learning, neural networks, etc., and determining whether the problem node is the SDC constraint file, CDC constraint file, or RTL code based on the frequently occurring errors. Otherwise, if no frequently occurring errors are identified from the log files, it means that there are no problems in the current RTL design stage, and there is no need to determine the problem node.

[0087] In this embodiment, by acquiring the simulation logs of dynamic simulation based on the target verification model, register transfer level code, and exception items, the target error information in the simulation logs is identified, and the problem nodes in the register transfer level design stage are determined based on the target error information. This can automatically identify the nodes that cause problems in the RTL design stage, making it easier to quickly troubleshoot SDC or CDC issues.

[0088] To facilitate a deeper understanding of the embodiments of this application by those skilled in the art, a specific example will be used for illustration below.

[0089] This application provides a general method for verification, applicable to chips, chip modules, terminals, base stations, etc. In all projects requiring post-simulation verification, using the acceleration solution proposed in this application during the verification phase can yield significant efficiency gains, reduce labor costs, and shorten project cycles.

[0090] The technical steps involved are the same for different types of products. The input components required in the technical route are consistent with those in the simulation and synthesis processes, and there are no additional input component requirements; the intermediate deliverables generated in the technical route do not require complex processing, and the final output is a simulation log file.

[0091] To address the issue of slow verification speed for timing problems in post-simulation, this application allows the focus of post-simulation to be shifted to the pre-simulation stage during the verification process. Since pre-simulation begins verification earlier than post-simulation, shifting the focus of post-simulation to pre-simulation verification effectively shortens the project cycle and saves manpower costs. Furthermore, when design problems (bugs) are discovered during pre-simulation, the cost of modification is lower, and the impact on the project is smaller.

[0092] The technical solution proposed in this application can reduce the number of post-simulation test cases when applied to the verification stage, while supplementing the coverage of extreme scenarios (corners) in post-simulation verification. Previously, projects would refer to the SDC exception path list to identify test cases when selecting post-simulation test cases. The number of SDC constraints for multi-cycle paths / pseudo-paths (mcp / fp paths) directly determines the number of test cases. The verification platform and post-simulation test case selection process built with the TCM tool can effectively reduce the number of post-simulation test cases. Specifically, the post-simulation test case selection process can pre-set corresponding priority levels for each test case. For example, higher priority can be assigned to test cases that fail or partially fail, medium priority to test cases with no result or skipped paths, and lower priority to test cases with no path or pass. During simulation verification, higher priority test cases are verified first, followed by medium priority test cases, while lower priority test cases can be omitted by default, thus reducing the number of test cases. Given the low simulation efficiency of post-simulation, the verification test cases of post-simulation often only select a portion, and the probability of discovering problems is limited. However, timing problems may occur in every corner of the chip. Therefore, this application can make up for the shortcomings of post-simulation in verifying corners in front-simulation.

[0093] This application can improve the quality of SDC constraints and CDC designs during the verification phase. Both SDC constraints and CDC designs contain errors that do not affect synthesis implementation. These errors may not currently impact the design's timing, but they are still undesirable and could pose risks in future scenarios if left unchecked. This application will present these unreasonable aspects of the constraints as warnings, helping front-end developers to review and modify them, thereby improving the quality of the constraints and design.

[0094] Figure 2 A flowchart illustrating a dynamic simulation method for SoC-level SDC design based on the VCS platform is provided. Figure 2 The dynamic simulation method for SoC-level SDC design based on the VCS platform can include the following steps:

[0095] Step 1: Build a SoC-level verification environment based on RTL design characteristics, and debug and pass regression tests on the VCS simulation platform;

[0096] Step 2: Perform static checks on SDC constraints using the TCM tool, and combine the output of failed SDCs with RTL and the verification environment to perform VCS SDC dynamic simulation.

[0097] Step 3: Automated processing of the results of the VCS SDC dynamic simulation, extracting all possible problematic constraint paths and sorting them by priority;

[0098] Step 4: When a problem is discovered, manually or automatically analyze and identify whether it is an SDC problem or an RTL design problem, and then iterate the above steps. For example, return to step 1 above.

[0099] Figure 3 A flowchart illustrating a dynamic simulation method for SoC-level CDC design based on the VCS platform is provided. Figure 3 The dynamic simulation method for SoC-level CDC design based on the VCS platform can include the following steps:

[0100] Step 1: Build a SoC-level verification environment based on RTL design characteristics, and debug and pass regression tests on the VCS simulation platform;

[0101] Step 2: Perform static checks on the CDC design using the VC SpyGlass tool, output SVA for error items, and perform VCS CDC dynamic simulation in conjunction with RTL and verification environment.

[0102] Step 3: Automated processing of the results of VCS CDC dynamic simulation, extracting all SVA errors and sorting them by priority;

[0103] Step 4: When a problem is discovered, manually or automatically analyze and identify whether it is a CDC constraint problem or an RTL design problem, and then iterate the above steps. For example, return to step 1 above.

[0104] In one exemplary embodiment, a method for accelerating the runtime of VCS dynamic simulation is provided, comprising:

[0105] Form general rules to simplify the number of SDCs covered by dynamic simulation before the simulation.

[0106] Starting with the verification platform and the testbench, we can create an option for compilation + simulation acceleration;

[0107] In one exemplary embodiment, a method for simplifying post-simulation verification testcases is provided, comprising:

[0108] A standardized inspection and identification process was established, and the coverage points of the simplified test case were simulated.

[0109] In summary, the technical solution provided in this application can save post-simulation time, thereby shortening the project cycle, discovering SDC and CDC problems as early as possible, improving the efficiency of discovering timing defects in the design, improving the quality of SDC constraints and CDC design, and ensuring the mass production and shipment of chips.

[0110] In one exemplary embodiment, such as Figure 4 As shown, a verification method is provided, which may specifically include:

[0111] Step S401: Determine the initial verification model of the on-chip system, debug the initial verification model to obtain the debugged verification model, and obtain the target verification model based on the debugged verification model if the regression test of the debugged verification model passes.

[0112] Step S402: Obtain the object to be verified in the design phase of the on-chip system register transfer level; the object to be verified includes timing constraint files or cross-clock domain design files;

[0113] Step S403: Perform a static check on the object to be verified to obtain the anomalies in the object to be verified;

[0114] Step S404: Perform dynamic simulation based on the target verification model, register transfer level code, and exception items to obtain dynamic simulation results;

[0115] Step S405: Analyze the dynamic simulation results to obtain the verification results of the object to be verified;

[0116] Step S406: Obtain the simulation log, identify the target error information in the simulation log, and determine the problem node in the register transfer stage design based on the target error information; the problem node includes at least one of the timing constraint file, cross-clock domain design file, and register transfer stage code.

[0117] Optionally, the terminal can pre-build an initial verification model at the SoC level, debug the initial verification model to obtain a debugged verification model, and perform regression testing on the debugged verification model. If the regression test passes, the debugged verification model is used as the target verification model; otherwise, if the regression test fails, debugging continues until the regression test passes. The terminal can obtain the objects to be verified in the pre-simulation stage, including SDC constraint files or CDC design files. Then, it can first perform static verification on the objects to be verified to obtain anomalies. Then, based on the target verification model, it can perform dynamic simulation on the RTL code and anomalies to obtain dynamic simulation results. The terminal can parse the dynamic simulation results to obtain the verification result of whether the dynamic verification passes or fails. If the dynamic verification passes, other objects can be verified; otherwise, if the dynamic verification fails, i.e., the verification result reports an error, it is necessary to determine which of the following—the SDC constraint file, the CDC design file, or the RTL code—caused the verification failure. The terminal can also obtain simulation logs and automatically identify the target error information in the simulation logs, and then determine the node causing the problem in the current RTL design stage based on the target error information.

[0118] The above verification method can first extract abnormal items through static inspection during the register-transfer level design stage, i.e. the pre-simulation stage, and then perform dynamic verification on the abnormal items, thereby timely discovering timing problems such as SDC and CDC in the chip design process and accelerating the verification speed in the chip design process.

[0119] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0120] Based on the same inventive concept, this application also provides a verification apparatus for implementing the verification method described above. This apparatus can be applied to or integrated into a chip or chip module, for example. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more verification apparatus embodiments provided below can be found in the limitations of the verification method above, and will not be repeated here.

[0121] In one exemplary embodiment, such as Figure 5 As shown, a verification device is provided, including: an object acquisition module 501, a first verification module 502, and a second verification module 503, wherein:

[0122] The object acquisition module 501 is used to acquire the objects to be verified during the design phase of the on-chip system register transfer level.

[0123] The first verification module 502 is used to perform a static check on the object to be verified and obtain the abnormal items in the object to be verified.

[0124] The second verification module 503 is used to dynamically verify the anomalies based on the pre-built target verification model and the register transfer level code in the register transfer level design phase, and obtain the verification result of the object to be verified.

[0125] In an exemplary embodiment, the first verification module 502 is further configured to perform a static check on the timing constraint file to obtain anomalies in the timing constraint file.

[0126] In an exemplary embodiment, the first verification module 502 described above is further configured to perform a static check on the cross-clock domain design file to obtain anomalies in the cross-clock domain design file.

[0127] In an exemplary embodiment, the verification apparatus further includes a model building module for determining an initial verification model of the on-chip system; debugging the initial verification model to obtain a debugged verification model; and, if the regression test of the debugged verification model passes, obtaining the target verification model based on the debugged verification model.

[0128] In an exemplary embodiment, the second verification module 503 is further configured to perform dynamic simulation based on the target verification model, the register transfer level code, and the exception item to obtain dynamic simulation results; and to parse the dynamic simulation results to obtain the verification result of the object to be verified.

[0129] In an exemplary embodiment, the second verification module 503 is further configured to parse the dynamic simulation results to obtain the verification results of the object to be verified when the coverage of the dynamic simulation results reaches the target coverage.

[0130] In an exemplary embodiment, the verification device further includes a problem localization module, configured to acquire simulation logs of dynamic simulation based on the target verification model, the register transfer level code, and the anomaly; identify target error information in the simulation logs; determine the probability of occurrence of the target error information exceeding a preset threshold; and identify problem nodes in the register transfer level design stage based on the target error information; the problem nodes include at least one of timing constraint files, cross-clock domain design files, and register transfer level code.

[0131] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0132] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a verification method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0133] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0134] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0135] Based on the same inventive concept, this application also provides a chip, including a processor and a communication interface; the communication interface is used to receive or send data; the processor is configured to cause the chip to perform the following steps:

[0136] Obtain the objects to be verified during the design phase of the on-chip system register transfer level;

[0137] Perform a static check on the object to be verified to identify any anomalies in the object.

[0138] Based on the pre-built target verification model and the register transfer level code in the register transfer level design phase, the anomalies are dynamically verified to obtain the verification result of the object to be verified.

[0139] In one embodiment, the processor is configured to cause the chip to perform the following steps:

[0140] A static check is performed on the timing constraint file to identify any anomalies.

[0141] In one embodiment, the processor is configured to cause the chip to perform the following steps:

[0142] A static check is performed on the cross-clock domain design file to identify any anomalies.

[0143] In one embodiment, the processor is configured to cause the chip to perform the following steps:

[0144] Determine the initial verification model for the on-chip system;

[0145] The initial verification model is debugged to obtain the debugged verification model;

[0146] If the regression test of the debugged validation model passes, the target validation model is obtained based on the debugged validation model.

[0147] In one embodiment, the processor is configured to cause the chip to perform the following steps:

[0148] Dynamic simulation is performed based on the target verification model, the register transfer level code, and the anomaly items to obtain dynamic simulation results.

[0149] The dynamic simulation results are analyzed to obtain the verification results of the object to be verified.

[0150] In one embodiment, the processor is configured to cause the chip to perform the following steps:

[0151] If the coverage of the dynamic simulation results reaches the target coverage, the dynamic simulation results are analyzed to obtain the verification results of the object to be verified.

[0152] In one embodiment, the processor is configured to cause the chip to perform the following steps:

[0153] Obtain simulation logs for dynamic simulation based on the target verification model, the register transfer level code, and the anomaly items;

[0154] Identify the target error message in the simulation log; the probability of the target error message occurring exceeds a preset threshold.

[0155] Based on the target error information, identify the problem nodes in the register transfer stage design phase; the problem nodes include at least one of timing constraint files, cross-clock domain design files, and register transfer stage code.

[0156] It is understood that the chip involved in the embodiments of this application may be a field-programmable gate array (FPGA), may include an application-specific integrated circuit (ASIC), may be a system on chip (SoC), may be a central processor unit (CPU), may be a network processor (NP), may be a digital signal processor (DSP), may be a microcontroller unit (MCU), may be a programmable logic device (PLD), or other integrated chips, etc.

[0157] Based on the same inventive concept, this application also provides a chip module, such as... Figure 7 As shown, the chip module includes a communication module, a power module, a storage module, and a chip. Among them:

[0158] The power module is used to provide power to the chip module; the storage module is used to store data and instructions; the communication module is used for internal communication within the chip module, or for communication between the chip module and external devices; this chip corresponds to the chip in the above chip embodiment.

[0159] The implementation method of this chip module can be found in the relevant content of the above chip embodiment, and will not be repeated here.

[0160] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0161] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0162] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0163] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0164] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0165] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A verification method, characterized in that, The method includes: Obtain the objects to be verified during the design phase of the on-chip system register transfer level; Perform a static check on the object to be verified to identify any anomalies in the object. Based on the pre-built target verification model and the register transfer level code in the register transfer level design phase, the anomalies are dynamically verified to obtain the verification result of the object to be verified.

2. The method according to claim 1, characterized in that, The object to be verified includes a timing constraint file; The static inspection of the object to be verified to obtain anomalies in the object to be verified includes: A static check is performed on the timing constraint file to identify any anomalies.

3. The method according to claim 1, characterized in that, The objects to be verified include cross-clock domain design documents; The static inspection of the object to be verified to obtain anomalies in the object to be verified includes: A static check is performed on the cross-clock domain design file to identify any anomalies.

4. The method according to claim 1, characterized in that, The method further includes: Determine the initial verification model for the on-chip system; The initial verification model is debugged to obtain the debugged verification model; If the regression test of the debugged validation model passes, the target validation model is obtained based on the debugged validation model.

5. The method according to claim 1, characterized in that, The step of dynamically verifying the anomalies based on the pre-built target verification model and the register-transfer level code in the register-transfer level design phase, to obtain the verification result of the object to be verified, includes: Dynamic simulation is performed based on the target verification model, the register transfer level code, and the anomaly items to obtain dynamic simulation results. The dynamic simulation results are analyzed to obtain the verification results of the object to be verified.

6. The method according to claim 5, characterized in that, The step of parsing the dynamic simulation results to obtain the verification result of the object to be verified includes: If the coverage of the dynamic simulation results reaches the target coverage, the dynamic simulation results are analyzed to obtain the verification results of the object to be verified.

7. The method according to claim 1, characterized in that, The method further includes: Obtain simulation logs for dynamic simulation based on the target verification model, the register transfer level code, and the anomaly items; Identify the target error message in the simulation log; the probability of the target error message occurring exceeds a preset threshold. Based on the target error information, identify the problem nodes in the register transfer stage design phase; the problem nodes include at least one of timing constraint files, cross-clock domain design files, and register transfer stage code.

8. A verification device, characterized in that, The device includes: The object acquisition module is used to acquire the objects to be verified during the design phase of the on-chip system register transfer level. The first verification module is used to perform static checks on the object to be verified and obtain the abnormal items in the object to be verified. The second verification module is used to dynamically verify the anomalies based on the pre-built target verification model and the register transfer level code in the register transfer level design phase, and obtain the verification result of the object to be verified.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images