System-level verification method and device, computer device and chip

Abstract

The application relates to a system-level verification method, device, computer equipment and chip. The method comprises the following steps: in response to an IP module of a chip passing module-level verification and failing system-level verification, acquiring reference timing data of the module level and failure timing data of the system level corresponding to a preset same verification case; determining information of an abnormal signal in each input signal of the IP module according to the reference timing data and the failure timing data; and outputting indication information according to the information of the abnormal signal; wherein the indication information is used for indicating modification of system-level design code or a system-level verification environment of the chip. By using the method, a verification personnel can complete debugging with the least debugging times, so that the debugging efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of chip verification technology, and in particular to a system-level verification method, apparatus, computer equipment, and chip. Background Technology

[0002] Currently, in chip verification, after the module-level verification of the Intellectual Property Core (IP) module passes, further system-level verification of the IP module is required to confirm whether it can still function properly after integration into the chip system. If system-level verification fails, debugging is necessary until it passes. However, the reasons for system-level verification failures are often more complex, introducing system issues such as interface signals and cross-module interactions compared to module-level verification, making debugging more difficult.

[0003] In related technologies, debugging typically relies on verification personnel's in-depth understanding and comprehensive mastery of the IP module's functionality and the system-level verification environment. Therefore, this method not only depends on subjective experience but also leads to a time-consuming, labor-intensive, and inefficient debugging process. Summary of the Invention

[0004] Therefore, it is necessary to provide a system-level verification method, apparatus, computer equipment, chip, and chip module that can improve debugging efficiency in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a system-level verification method, including:

[0006] In response to the chip's IP module passing module-level verification but failing system-level verification, obtain the module-level baseline timing data and system-level failure timing data corresponding to the same preset verification test case;

[0007] Based on the reference timing data and the failure timing data, information on abnormal signals in each input signal of the IP module is determined;

[0008] Based on the information of the abnormal signal, an indication message is output; wherein, the indication message is used to indicate the correction of the system-level design code or system-level verification environment of the chip.

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

[0010] In response to a correction to the system-level design code or the system-level verification environment, new failure timing data is reacquired, and the process returns to the step of determining information about abnormal signals in each input signal of the IP module based on the baseline timing data and the failure timing data, until the IP module passes system-level verification.

[0011] In one embodiment, determining the information of abnormal signals in each input signal of the IP module based on the reference timing data and the failure timing data includes:

[0012] By comparing the baseline timing data with the failure timing data, the target input signal that first appears abnormal in each input signal of the IP module and the difference time point corresponding to the target input signal are determined.

[0013] In one embodiment, determining the target input signal that first appears abnormal among the input signals of the IP module and the corresponding difference time point by comparing the reference timing data with the failure timing data includes:

[0014] The first signal value time series of each input signal of the IP module is obtained from the reference timing data, and the second signal value time series of each input signal of the IP module is obtained from the failure timing data.

[0015] By comparing the time series of the first signal value with the time series of the second signal value, the target input signal that first appears abnormal and the time point of difference corresponding to the target input signal are determined.

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

[0017] The visualization interface displays the first waveform corresponding to the time series of the first signal value and the second waveform corresponding to the time series of the second signal value.

[0018] Visual annotations are made for waveform segments in the first waveform and the second waveform where there are differences in signal values.

[0019] In one embodiment, the step of outputting indication information based on the information of the abnormal signal includes:

[0020] The information in response to the abnormal signal originates from the system-level design code of the chip, and a first indication is output; wherein, the first indication is used to indicate that the system-level design code should be corrected;

[0021] In response to the abnormal signal, which originates from the system-level verification environment of the chip, a second indication is output; wherein the second indication is used to indicate that the system-level verification environment should be corrected.

[0022] In one embodiment, the IP module responding to the chip passes module-level verification but fails system-level verification, acquires module-level baseline timing data and system-level failure timing data corresponding to the same preset verification test case, including:

[0023] Run the preset verification test cases corresponding to the IP module in the module-level verification environment to perform module-level verification on the IP module. In response to the successful module-level verification, obtain the module-level baseline timing data corresponding to the verification test cases.

[0024] The same verification test case is run in the system-level verification environment of the chip to perform system-level verification on the IP module. In response to the IP module failing the system-level verification, the system-level failure timing data corresponding to the verification test case is obtained.

[0025] Secondly, this application also provides a system-level verification device, comprising:

[0026] The first acquisition module is used to acquire the module-level baseline timing data and system-level failure timing data corresponding to the same preset verification test case when the chip's IP module passes module-level verification but fails system-level verification.

[0027] The determination module is used to determine information about abnormal signals in each input signal of the IP module based on the reference timing data and the failure timing data;

[0028] The output module is used to output indication information based on the information of the abnormal signal; wherein the indication information is used to indicate the correction of the system-level design code or system-level verification environment of the chip.

[0029] 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 method described in the first aspect above.

[0030] Fourthly, this application also provides a chip including a processor and a communication interface, the processor being configured to cause the chip to perform the method described in the first aspect above.

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

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

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

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

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

[0036] Sixthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect above.

[0037] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0038] The aforementioned system-level verification method, apparatus, computer equipment, chip, and chip module, in response to a chip's IP module passing module-level verification but failing system-level verification, acquires module-level baseline timing data and system-level failure timing data corresponding to the same preset verification test case; determines information about abnormal signals in each input signal of the IP module based on the baseline timing data and failure timing data; and outputs indication information based on the information about the abnormal signals. The indication information is used to instruct the verification personnel to correct the chip's system-level design code or system-level verification environment. This application embodiment introduces module-level baseline timing data as a reference and compares it with system-level failure timing data. This automatically and more accurately locates the abnormal signals causing system-level verification failure and outputs indication information to instruct verification personnel to correct the chip's system-level design code or system-level verification environment. Compared to traditional methods that rely on verification personnel blindly debugging, this reduces or avoids blind global checks or ineffective trial and error, reduces reliance on verification personnel's experience, improves debugging accuracy and efficiency by locating abnormal signals, and allows verification personnel to complete debugging with the fewest possible attempts, thereby improving debugging efficiency. Attached Figure Description

[0039] 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.

[0040] Figure 1 This is a diagram illustrating the application environment of a system-level verification method in one embodiment.

[0041] Figure 2 This is a flowchart illustrating a system-level verification method in one embodiment;

[0042] Figure 3 This is a flowchart illustrating the process of determining the target input signal and the corresponding time difference points in one embodiment.

[0043] Figure 4 This is a flowchart illustrating a system-level verification method in another embodiment;

[0044] Figure 5 This is a flowchart illustrating a system-level verification method in a specific example.

[0045] Figure 6 This is a structural block diagram of a system-level verification device in one embodiment;

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

[0047] Figure 8 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 elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. 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 embodiments, or any combination of multiple embodiments.

[0050] Explanation of terminology in this application's embodiments:

[0051] System-level verification: Focuses on the functional correctness of the entire system, including verification of interactions between multiple IP modules, bus protocols, power management, etc.

[0052] Module-level verification: Focuses on the functional correctness of a single module or component, ensuring that it can function independently and normally under specific conditions.

[0053] In the field of chip verification, a verification use case is a pre-designed set of complete verification activity specifications for verifying a specific function or scenario. A verification use case is not merely a piece of stimulus code; it includes a complete verification task unit with verification objectives, configuration requirements, stimulus sequences, checking mechanisms, and pass / fail criteria. Verification use cases are executed in a specific verification environment to determine whether the behavior of the design being verified conforms to expectations.

[0054] Debug: The process of debugging in programming and software development environments.

[0055] Top layer: The top-level module where IP modules are instantiated in the system-level design.

[0056] To address the challenges of debugging system-level verification and the significant learning curve for verification personnel, this application proposes a system-level verification method. By comparing the input signals of the IP modules in module-level verification test cases and system-level verification test cases, system-level verification debugging is achieved. This method enables more accurate and rapid identification of the causes of system-level verification failures, allowing verification personnel to complete debugging with minimal attempts, thereby improving debugging efficiency. The following is an exemplary description.

[0057] The system-level verification method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on the cloud or other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0058] In one exemplary embodiment, such as Figure 2 As shown, a system-level verification method is provided, which is applied to... Figure 1 Taking the terminal in the example, the explanation includes the following steps 201 to 203. Wherein:

[0059] Step 201: In response to the chip's IP module passing module-level verification but failing system-level verification, obtain the module-level baseline timing data and system-level failure timing data corresponding to the same preset verification test case.

[0060] In this context, a verification test case refers to a verification task unit designed to determine the correctness of a specific function of an IP module, which can be executed independently and whose result is judged. A verification test case must include at least: a verification objective (e.g., verifying DMA transfer functionality), an environment configuration and initialization sequence, a stimulus sequence for driver design work, a checking mechanism for determining functional correctness, and pass / fail criteria. Verification test cases are used in both module-level and system-level verification to verify the same function or service of the IP module, ensuring that the same verification test case is executed at both the module and system levels. This is a prerequisite for ensuring the comparability of subsequent timing data and effective debugging.

[0061] For example, when an IP module has passed all functional verifications in an independent module-level verification environment, but fails a pre-defined verification test case (fails system-level verification) during system-level verification after integration into the chip, the module-level baseline timing data and system-level failure timing data corresponding to that verification test case are retrieved from the verification database. The baseline timing data is the complete simulation data recorded when the IP module executes the verification test case and passes module-level verification in the module-level verification environment. This data represents the standard signal sequence (including signal values ​​and corresponding time points) of the IP module under normal operating conditions. The failure timing data is the complete simulation data recorded when the same verification test case is executed and fails in the system-level verification environment. This data represents the actual signal sequence (including signal values ​​and corresponding time points) of the IP module in the system verification environment.

[0062] Step 202: Determine the information of abnormal signals in each input signal of the IP module based on the reference timing data and failure timing data.

[0063] The input signals (also known as input interface signals) of an IP module refer to the set of signals transmitted on all ports declared as input directions in the top-level module of the IP module's hardware design code. These signals represent all the drive, data, control, and status information received by the IP module when interacting with the outside world. Therefore, the signal flow of input signals is from the outside to the inside of the IP module. Input signals may include clock and reset signals, data and address signals, control signals, status signals, and power management signals, etc. Abnormal signals refer to signals in the failure timing data where the IP module's input signals are abnormal or differ from the reference timing. For example, for a certain input signal A, its signal value is 1 in the reference timing data at a certain moment, but its signal value is 0 in the failure timing data; then, signal A is an abnormal signal.

[0064] For example, the input signals of the IP module in the reference timing data and the input signals of the IP module in the failure timing data are compared and analyzed to determine at least one input signal with a signal value or timing difference as an abnormal signal, and obtain relevant information about the abnormal signal. This information may include: the identifier of the abnormal signal (such as the signal name), the signal value of the abnormal signal, the corresponding difference time point or time period, and the type of difference (such as signal value error, timing offset, etc.) for subsequent analysis.

[0065] Step 203: Output indication information based on the information of the abnormal signal; wherein, the indication information is used to indicate the correction of the chip's system-level design code or system-level verification environment.

[0066] The indication information includes information about the abnormal signal, such as the signal value and the corresponding time point. There can be at least one abnormal signal. When there are multiple abnormal signals, the indication information can be generated and output by combining the information of multiple abnormal signals, or the indication information can be generated and output based on the information of the abnormal signal with the highest priority among the multiple abnormal signals.

[0067] For example, the information of the abnormal signal is analyzed to obtain the analysis results. Based on the analysis results, an instruction message is generated and output. The instruction message can be a detailed debugging report, which can be output to the terminal display interface through pop-up prompts, voice prompts, or clickable links. This allows verification personnel to read and correct the chip's system-level design code or system-level verification environment to complete the debugging. For example, the instruction message could be "Input signal A experiences a signal value difference at 100ns. Please correct the system-level design code or system-level verification environment." After receiving the instruction message, the verification personnel can make corresponding corrections. Since the instruction message is generated based on the information of the abnormal signal, it can largely reflect the root cause of the abnormality. Therefore, by making corresponding corrections based on the instruction message, the verification personnel can maximize the success rate of the debugging and thus improve debugging efficiency.

[0068] Optionally, if the analysis result indicates that the anomaly is caused by a chip hardware connection or logic design error, the indication information is used to instruct modifications to the chip's system-level design code; if the analysis result indicates that the anomaly is caused by a verification environment configuration or stimulus error, the indication information is used to instruct modifications to the chip's system-level verification environment. This provides verification personnel with more accurate anomaly localization information, further improving debugging efficiency.

[0069] In the aforementioned system-level verification method, in response to a chip's IP module passing module-level verification but failing system-level verification, the method acquires module-level baseline timing data and system-level failure timing data corresponding to the same preset verification test case. Based on the baseline timing data and failure timing data, it determines information about abnormal signals in each input signal of the IP module. Based on the abnormal signal information, it outputs indication information, which instructs the verification personnel to correct the chip's system-level design code or system-level verification environment. This application embodiment introduces module-level baseline timing data as a reference and compares it with system-level failure timing data. This automatically and more accurately locates abnormal signals causing system-level verification failure and outputs indication information to instruct verification personnel to correct the chip's system-level design code or system-level verification environment. Compared to traditional methods that rely on verification personnel blindly debugging, this method reduces or avoids blind global checks or ineffective trial and error, lowers reliance on verification personnel's experience, improves debugging accuracy and efficiency by locating abnormal signals, and allows verification personnel to complete debugging with the fewest possible attempts, thereby improving debugging efficiency.

[0070] It should be noted that after the system-level design code or verification environment is modified, system-level verification needs to be performed again. If the verification passes, the process ends; if the verification fails, the above steps need to be repeated until the system-level verification passes.

[0071] In one exemplary embodiment, the method further includes: in response to a correction in the system-level design code or the system-level verification environment, acquiring new failure timing data and returning to the step of determining information about abnormal signals in each input signal of the IP module based on the baseline timing data and the failure timing data, until the IP module passes system-level verification.

[0072] For example, after modifications to the system-level design code or system-level verification environment, a new round of system-level verification is automatically triggered by the debugging system or manually triggered by the verification personnel: the same verification test case from step 201 is rerun. If the system-level verification still fails, a new set of system-level failure timing data is generated. Then, steps 202 and 203 are returned: based on the baseline timing data and the failure timing data, information on abnormal signals in each input signal of the IP module is determined, and indication information is output based on the information on the abnormal signals. This process is repeated iteratively until the test case passes the system-level verification, at which point the loop terminates, and debugging is complete.

[0073] Therefore, this embodiment implements iterative debugging. Each iteration uses the original baseline timing data from step 201 as an unchanging reference standard and compares and analyzes it with the system-level timing data generated after the latest correction. This ensures that the debugging direction is always toward the goal of converging the system-level behavior with the module-level baseline behavior, thereby reducing the number of iterations.

[0074] In an exemplary embodiment, the information of the abnormal signal includes the target input signal that first appears abnormal and the difference time point corresponding to the target input signal. Step 201 includes: determining the target input signal that first appears abnormal and the difference time point corresponding to the target input signal among the input signals of the IP module by comparing the reference timing data and the failure timing data.

[0075] The first abnormal target input signal refers to at least one input signal among those that show a difference, with the earliest time point of the difference. The first occurrence is determined by the time sequence advancing along the simulation time axis.

[0076] For example, system-level verification failures are often the result of a chain reaction. For instance, an early, root cause signal anomaly can lead to a series of derivative errors. To improve debugging efficiency and avoid getting bogged down in numerous ineffective debugging attempts, this embodiment employs a first-time location strategy. First, by comparing the input signals of the IP module in the baseline timing data with those in the failure timing data, candidate input signal time series with discrepancies or anomalies are identified, including the signal values ​​and corresponding time points of the candidate input signals. Then, the candidate input signal with the earliest time point is selected from each candidate input signal time series. This selected candidate input signal is determined as the target input signal, and the time point corresponding to the selected candidate input signal is determined as the difference time point, i.e., the earliest difference point after the simulation begins. For example, if the comparison reveals that input signal A first exhibits a level error at 100ns and input signal B first exhibits a data error at 150ns, the system will determine input signal A as the target input signal, with the corresponding difference time point being 100ns.

[0077] Therefore, this embodiment employs a first-time location strategy. Through mandatory time-series filtering, it ensures that each debugging session prioritizes the target input signal that first exhibits anomalies or differences throughout the entire simulation time. This allows corrective actions to directly target the source of the problem, minimizing the risk of masking the fundamental issue by fixing derivative errors and leading to repetitive debugging cycles. Consequently, this embodiment optimizes the debugging path, guiding verification resources directly to the root causes most likely to trigger system-level failures, enabling a rapid and convergent debugging process.

[0078] In one exemplary embodiment, such as Figure 3 As shown, by comparing the baseline timing data with the failure timing data, the target input signal that first appears abnormal among the input signals of the IP module and the corresponding difference time point are determined, including steps 301 and 302. Wherein:

[0079] Step 301: Obtain the first signal value time series of each input signal of the IP module from the reference timing data, and obtain the second signal value time series of each input signal of the IP module from the failure timing data.

[0080] For example, the baseline timing data and the failure timing data are parsed separately. Then, for each input signal of the IP module, the corresponding signal value time series is extracted from the parsed baseline timing data and failure timing data. Optionally, from the module-level baseline timing data, the signal value sequence of each input signal arranged in chronological order within the complete simulation cycle is parsed to obtain the first signal value time series, which includes the standard signal value of the input signal in the correct operating state and the corresponding time point. From the system-level failure timing data, the signal value sequence of each identical input signal arranged in chronological order within the complete simulation cycle is parsed to obtain the second signal value time series, which includes the actual signal value of the input signal in the timing system-level verification environment and the corresponding time point.

[0081] Step 302: By comparing the time series of the first signal value with the time series of the second signal value, determine the target input signal that first appears abnormal and the time point of difference corresponding to the target input signal.

[0082] The first occurrence of an anomaly may include the first difference in signal values.

[0083] For example, this step includes: First, by comparing the time series of a first signal value with the time series of a second signal value, a candidate input signal time series in which there is a difference in signal values ​​is obtained between the time series of the first signal value and the time series of the second signal value. Then, the candidate input signal with the earliest time point is selected from the candidate input signal time series, the selected candidate input signal is determined as the target input signal, and the time point corresponding to the selected candidate input signal is determined as the difference time point.

[0084] In this embodiment, the sequence extraction and comparison of each input signal can be performed simultaneously, further improving the comparison efficiency.

[0085] Therefore, this embodiment extracts the signal value time series from the original data sequence as the comparison object, which can reduce processing overhead and improve comparison efficiency. Furthermore, this embodiment supports parallel processing and is suitable for large-scale multi-signal comparison.

[0086] It should be noted that the waveforms corresponding to the extracted signal value time series can be displayed in the terminal's visual interface, allowing users to view them and assisting verification personnel in debugging. An example is provided below.

[0087] In one exemplary embodiment, such as Figure 4As shown, the method further includes steps 401 and 402, wherein:

[0088] Step 401: Display the first waveform corresponding to the time series of the first signal value and the second waveform corresponding to the time series of the second signal value in the visualization interface.

[0089] For example, after extracting the first signal value time series and the second signal value time series according to the method in step 301, a graphical waveform software can be used to load the first waveform corresponding to the first signal value time series and the second waveform corresponding to the second signal value time series. When at least one input signal of interest is selected through the software, the graphical waveform software displays the first and second waveforms of that input signal in a visual interface. Optionally, the first and second waveforms can be displayed side-by-side on the same time axis to facilitate visual comparison by verification personnel to select the time point at which the difference first appears. The target input signal is then identified from all the input signals of interest where the signal value difference is most pronounced at the earliest corresponding time point. Verification personnel then modify the system-level design code or system-level verification environment according to the properties of the target input signal to complete the debugging process.

[0090] Step 402: Visually label the waveform segments in the first waveform and the second waveform where there are differences in signal values.

[0091] For example, after displaying the first and second waveforms, starting from time zero, the signal values ​​of the two waveforms are compared, and the waveform segments with different signal values ​​are visually marked, such as by highlighting with a bright color (e.g., red), highlighting with lines or borders, or adding difference markers and text prompts above the waveforms, so that the verification personnel can observe the waveforms more intuitively and make debugging decisions.

[0092] Optionally, the first and second waveforms of the visualization annotation can be displayed simultaneously or at different times on the visualization interface. When there are multiple target input signals, the verifier can determine the priority of multiple target input signals based on experience, and select one of the target input signals as the target to be modified, so as to modify the system-level design code or verification environment.

[0093] Therefore, this embodiment, through a visual presentation of differences, can assist verification personnel in locating anomalies, avoiding potential omissions, slowness, and errors that may occur when manually observing waveforms, thereby improving the success rate and efficiency of debugging.

[0094] To facilitate more accurate debugging by verification personnel, the debugging system can output instruction information pointing to the system-level design code or the system-level verification environment, making it easier for verification personnel to debug.

[0095] In one exemplary embodiment, step 203 includes: in response to the information of the abnormal signal originating from the system-level design code of the chip, outputting first indication information; wherein the first indication information is used to indicate the correction of the system-level design code; in response to the information of the abnormal signal originating from the system-level verification environment of the chip, outputting second indication information; wherein the second indication information is used to indicate the correction of the system-level verification environment.

[0096] For example, based on preset rules or analysis models, it is determined whether the root cause of the abnormal signal is the chip's system-level design code (i.e., hardware logic design defects) or the chip's system-level verification environment (i.e., test platform, stimulus, or configuration errors, etc.). If the root cause of the abnormal signal is the system-level design code, a first indication is generated and output to instruct the correction of the system-level design code. The first indication may include the path to the code file to be corrected, the code segment, and the target code, with the purpose of directly guiding the verification personnel to correct the design logic. If the root cause of the abnormal signal is the system-level verification environment, a second indication is generated and output to instruct the correction of the system-level verification environment components. The second indication may include the configuration file, stimulus file, and target file to be corrected, with the purpose of guiding the verification personnel to correct the verification environment.

[0097] Taking the first occurrence of a difference in the target input signal and the corresponding time point of the difference as an example, the source of the signal value difference can be determined from the type of the target input signal and the nature of the difference, indicating whether it originates from the system-level design code or the system-level verification environment. The types of target input signals include at least one of the following: clock signal, reset signal, data signal, address signal, and control handshake signal; the nature of the difference includes at least one of the following: level error, timing error, and protocol violation. For example, if the anomaly or difference is a fixed level error in the clock signal, it usually originates from the system-level design code; if the anomaly or difference is a specific configuration data value error, it may originate from the system-level verification environment.

[0098] Therefore, this embodiment provides verification personnel with clear action instructions, preventing them from choosing the wrong debugging direction. Traditional methods rely heavily on the personal experience of verification personnel to make debugging direction judgments, which are subjective and uncertain. In contrast, this embodiment, through root cause judgment, outputs clearly categorized instruction information. The first instruction information directs the correction direction to the hardware design level, preventing ineffective debugging in the verification environment; the second instruction information directs the correction direction to the software and configuration level, preventing erroneous modifications to the correct hardware design or ineffective debugging. This categorized instruction information greatly compresses the debugging cycle, eliminates ineffective correction iterations caused by target errors, and ensures that every correction attempt directly addresses the most likely cause of failure.

[0099] In an exemplary embodiment, step 201 includes: running a preset verification test case corresponding to the IP module in a module-level verification environment to perform module-level verification on the IP module; in response to the module-level verification passing, obtaining the module-level baseline timing data corresponding to the verification test case; running the same verification test case in the chip's system-level verification environment to perform system-level verification on the IP module; in response to the IP module failing the system-level verification, obtaining the system-level failure timing data corresponding to the verification test case.

[0100] For example, during the independent development and verification phase of an IP module, verification personnel pre-build a module-level verification environment and a series of verification test cases. These test cases are then run within the module-level verification environment based on the module-level design code. When a specific verification test case is run, if the IP module's functionality fully meets expectations, the module-level verification is considered successful, and complete signal data from the start to the end of the simulation is recorded, thus obtaining the module-level baseline timing data. Then, in the system-level verification phase, the IP module is integrated into the chip, and the same verification test cases as in the module-level verification are run in the chip's system-level verification environment. However, due to integration issues, such as interface configuration errors or clock asynchrony, the verification fails. The simulation data from this failure is captured and saved, becoming the system-level failure timing data. This timing data can be waveform files, including signal values ​​and their corresponding time points.

[0101] Therefore, this embodiment ensures that the acquired time-series data is completely consistent with the functional intent and business scenario by running the same verification test case in two different verification environments, thereby ensuring the effectiveness of data comparison.

[0102] The following describes the system-level verification method of this application embodiment through a specific example.

[0103] like Figure 5 As shown, the system-level verification method includes the following steps:

[0104] Step 501: Based on the module-level code and module-level verification environment, run a benchmark waveform file corresponding to the verification test case that has passed module-level verification;

[0105] Step 502: Based on the system-level code and system-level verification environment, run a failure waveform file corresponding to the same verification test case that failed the system-level verification;

[0106] Step 503: Extract the first waveform of all input signals of the top layer of the IP module from the reference waveform file, and extract the second waveform of all input signals of the top layer of the IP module from the failure waveform file; the waveform file contains the time and signal value of each input signal;

[0107] Step 504: Load the first and second waveforms using graphical waveform software. When the verification personnel select an input signal that needs to be focused on through the software, the graphical waveform software will display the two waveforms in the visualization interface.

[0108] Step 505: Starting from time zero, compare the two sets of waveform signals and visually label the waveform segments where the signal values ​​differ.

[0109] Step 506: Find the target input signal with the earliest time point where the signal value differs among all the input signal waveforms that need to be focused on, and display it using graphical waveform software;

[0110] Step 507: The verification personnel modify the system-level code or environment to make it consistent with the signal value of the target input signal in the module-level waveform, and then return to step 502 to iterate and run the verification test cases again until the system-level verification is passed.

[0111] In summary, the embodiments of this application output directional indication information based on the input signal data of the IP module, which facilitates the verification personnel to modify the system-level design code or system-level verification environment, greatly reduces subjective experience, and allows the verification personnel to complete the debugging with the fewest number of debugging attempts, thereby improving debugging efficiency.

[0112] 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.

[0113] Based on the same inventive concept, this application also provides a system-level verification apparatus for implementing the system-level 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 system-level verification apparatus embodiments provided below can be found in the limitations of the system-level verification method described above, and will not be repeated here.

[0114] In one exemplary embodiment, such as Figure 6 As shown, a system-level verification device is provided, including: a first acquisition module 601, a determination module 602, and an output module 603, wherein:

[0115] The first acquisition module 601 is used to acquire the module-level baseline timing data and the system-level failure timing data corresponding to the same preset verification test case in response to the chip's IP module passing module-level verification but failing system-level verification.

[0116] The determination module 602 is used to determine information about abnormal signals in each input signal of the IP module based on the reference timing data and the failure timing data;

[0117] The output module 603 is used to output indication information based on the information of the abnormal signal; wherein the indication information is used to indicate the correction of the system-level design code or system-level verification environment of the chip.

[0118] In one embodiment, the apparatus further includes a second acquisition module, configured to, in response to a correction of the system-level design code or the system-level verification environment, reacquire new failure timing data and return to the step of determining information of abnormal signals in each input signal of the IP module based on the baseline timing data and the failure timing data, until the IP module passes system-level verification.

[0119] In one embodiment, the determining module 602 includes a determining unit, configured to determine, by comparing the reference timing data with the failure timing data, the target input signal in each input signal of the IP module that first shows an anomaly and the difference time point corresponding to the target input signal.

[0120] In one embodiment, the determining unit is specifically configured to: obtain a first signal value time series of each input signal of the IP module from the reference timing data, and obtain a second signal value time series of each input signal of the IP module from the failure timing data; and determine the target input signal that first appears abnormal and the difference time point corresponding to the target input signal by comparing the first signal value time series with the second signal value time series.

[0121] In one embodiment, the device further includes a display module and an annotation module, wherein: the display module is used to display a first waveform corresponding to the first signal value time series and a second waveform corresponding to the second signal value time series in a visualization interface; the annotation module is used to perform visual annotation on waveform segments in the first waveform and the second waveform where there are signal value differences.

[0122] In one embodiment, the output module 603 is specifically configured to: output first indication information in response to the information of the abnormal signal originating from the system-level design code of the chip; wherein the first indication information is used to indicate the correction of the system-level design code; and output second indication information in response to the information of the abnormal signal originating from the system-level verification environment of the chip; wherein the second indication information is used to indicate the correction of the system-level verification environment.

[0123] In one embodiment, the first acquisition module 601 is specifically used to: run a preset verification test case corresponding to the IP module in a module-level verification environment to perform module-level verification on the IP module; and obtain the module-level baseline timing data corresponding to the verification test case in response to the module-level verification passing; and run the same verification test case in the system-level verification environment of the chip to perform system-level verification on the IP module; and obtain the system-level failure timing data corresponding to the verification test case in response to the IP module failing the system-level verification.

[0124] 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.

[0125] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7As 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 system-level 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.

[0126] Those skilled in the art will understand that Figure 7 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.

[0127] 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.

[0128] 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 steps in the above method embodiments.

[0129] 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.

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

[0131] 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.

[0132] 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.

[0133] In one 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 method embodiments.

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

[0135] 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.

[0136] 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.

[0137] 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 system-level verification method, characterized in that, The method includes: In response to the chip's IP module passing module-level verification but failing system-level verification, obtain the module-level baseline timing data and system-level failure timing data corresponding to the same preset verification test case; Based on the reference timing data and the failure timing data, information on abnormal signals in each input signal of the IP module is determined; Based on the information of the abnormal signal, an indication message is output; wherein, the indication message is used to indicate the correction of the system-level design code or system-level verification environment of the chip.

2. The method according to claim 1, characterized in that, The method further includes: In response to a correction to the system-level design code or the system-level verification environment, new failure timing data is reacquired, and the process returns to the step of determining information about abnormal signals in each input signal of the IP module based on the baseline timing data and the failure timing data, until the IP module passes system-level verification.

3. The method according to claim 1, characterized in that, The step of determining the information of abnormal signals in each input signal of the IP module based on the reference timing data and the failure timing data includes: By comparing the baseline timing data with the failure timing data, the target input signal that first appears abnormal in each input signal of the IP module and the difference time point corresponding to the target input signal are determined.

4. The method according to claim 3, characterized in that, The step of determining the target input signal that first appears abnormal among the input signals of the IP module and the corresponding difference time point by comparing the baseline timing data with the failure timing data includes: The first signal value time series of each input signal of the IP module is obtained from the reference timing data, and the second signal value time series of each input signal of the IP module is obtained from the failure timing data. By comparing the time series of the first signal value with the time series of the second signal value, the target input signal that first appears abnormal and the time point of difference corresponding to the target input signal are determined.

5. The method according to claim 4, characterized in that, The method further includes: The visualization interface displays the first waveform corresponding to the time series of the first signal value and the second waveform corresponding to the time series of the second signal value. Visual annotations are made for waveform segments in the first waveform and the second waveform where there are differences in signal values.

6. The method according to any one of claims 1 to 5, characterized in that, The step of outputting indication information based on the information of the abnormal signal includes: The information in response to the abnormal signal originates from the system-level design code of the chip, and a first indication is output; wherein, the first indication is used to indicate that the system-level design code should be corrected; In response to the abnormal signal, which originates from the system-level verification environment of the chip, a second indication is output; wherein the second indication is used to indicate that the system-level verification environment should be corrected.

7. The method according to any one of claims 1 to 5, characterized in that, The IP module responding to the chip passes module-level verification but fails system-level verification, and acquires module-level baseline timing data and system-level failure timing data corresponding to the same preset verification test case, including: Run the preset verification test cases corresponding to the IP module in the module-level verification environment to perform module-level verification on the IP module. In response to the successful module-level verification, obtain the module-level baseline timing data corresponding to the verification test cases. The same verification test case is run in the system-level verification environment of the chip to perform system-level verification on the IP module. In response to the IP module failing the system-level verification, the system-level failure timing data corresponding to the verification test case is obtained.

8. A system-level verification device, characterized in that, The device includes: The first acquisition module is used to acquire the module-level baseline timing data and system-level failure timing data corresponding to the same preset verification test case when the chip's IP module passes module-level verification but fails system-level verification. The determination module is used to determine information about abnormal signals in each input signal of the IP module based on the reference timing data and the failure timing data; The output module is used to output indication information based on the information of the abnormal signal; wherein the indication information is used to indicate the correction of the system-level design code or system-level verification environment of the chip.

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 chip, characterized in that, The device includes a processor and a communication interface, the processor being configured to cause the chip to perform the steps of the method described in any one of claims 1 to 7.

Images