Method and system for detecting unknown state signal and medium
By generating an unknown_checker, the unknown state signals in the chip's power domain are automatically checked, solving the problems of time-consuming, labor-intensive, and easily overlooked manual checks in existing technologies, and improving the efficiency of low-power verification.
Patent Information
- Application Number
- CN202511532254.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-24
- Publication Date
- 2026-02-10
AI Technical Summary
In existing technologies, checking unknown state signals in the chip power domain relies on manual methods, which is time-consuming, labor-intensive, and prone to omissions, making automated checking impossible.
By generating an unknown signal checker (unknown_checker), a list of signals to be checked can be obtained using scripting tools such as Python or Perl, and then integrated into the verification environment to automatically check whether a signal is in an unknown state.
It enables automated checking of unknown signals in the chip power domain, avoiding omissions in manual checks, improving low-power verification efficiency and saving human resources.
Smart Images
Figure CN121503367A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of digital chip verification technology, and specifically to a method, system, and medium for detecting unknown state signals. Background Technology
[0002] In existing technologies, most chips involve power domain management, with more complex designs involving multiple power domains. Each power domain can be independently controlled for switching on and off (e.g., when the CPU core is working, the Bluetooth module can be powered off to save power). When a power domain is powered off, all signals in that power domain should be in an unknown state (except for signals controlled by ISO). This is also how to determine whether a power domain has truly lost power during verification. However, the checking method is usually done manually by observing waveforms, which does not achieve automated checking. This verification method is not only time-consuming and labor-intensive, but also carries the risk of omissions. For example, if some logic is powered off, a small portion of the circuit may not be powered off due to an error. If the manual check is not thorough, this situation may be missed. Summary of the Invention
[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method, system and medium for detecting unknown state signals.
[0004] The objective of this invention is achieved through the following technical solution: In a first aspect, the present invention discloses a method for detecting unknown state signals, comprising: A script containing set parameters is used to obtain a list of signals that need to be in an unknown state. Then, an unknown signal checker, unknown_checker, is generated to check the unknown signals. The unknown signal checker unknown_checker is integrated into the verification environment to verify whether the signal is in an unknown state.
[0005] Based on the first aspect, the setting parameters include: obtaining the power-down module by viewing the low-power scheme, and matching the power-down flag signal to it according to the low-power scheme; then storing all signals of the power-down module in a file, deleting the isolated signals in all files, and then transmitting them to the script as setting parameters.
[0006] Based on the first aspect, the script is a Python or Perl script.
[0007] Based on the first aspect, the script extracts the signals that need to be checked for unknown states from the contents of the file, saves them to the signal list signal_list, and generates the corresponding unknown signal checker unknown_checker through the signal list signal_list.
[0008] Based on the first aspect, through the signal list signal_list, a corresponding unknown signal checker unknown_checker is generated for each unknown signal. Specifically, the signal list signal_list has one row corresponding to a signal that needs to be checked, and its unknown value is checked. An assertion check is generated for each signal based on its corresponding power-down flag signal. This process is repeated for all signals that need to be checked for unknown status, generating a SystemVerilog assertion checker, which is then placed into the power-down module.
[0009] Based on the first aspect, the aforementioned checking of its unknown value includes: checking the trigger or enable signal through the unknown check, checking whether the signal is unknown logic code, and collecting coverage.
[0010] Based on the first aspect, integrating the unknown signal checker (unknown_checker) into the verification environment includes adding it to the file list of the verification environment or instantiating it in the verification environment.
[0011] Based on the first aspect, after the unknown signal checker (unknown_checker) is integrated into the verification environment, it is simulated to verify whether the signal is in an unknown state.
[0012] Secondly, the present invention discloses a detection system for unknown state signals, used in the aforementioned method for detecting unknown state signals, comprising: The parameter setting module is used to obtain the power-down module based on the low-power scheme, store all signals of the power-down module in a file, and then delete the isolated signals in all files to obtain the setting parameters. The processing module is used to obtain a list of signals that need to be in the unknown state using a script containing set parameters, and generate an unknown signal checker, unknown_checker, for checking unknown signals. The verification module is used to integrate the unknown signal checker (unknown_checker) into the verification environment to verify whether the signal is in an unknown state.
[0013] Thirdly, the present invention discloses a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the method described above.
[0014] The beneficial effects of this invention are: 1) This application realizes the automated checking of power failure function and unknown signal, which eliminates the need for manual checking and avoids the problem of omission.
[0015] 2) This application can be reused across different projects, saving a lot of human resources and improving the efficiency of low-power verification. Attached Figure Description
[0016] Figure 1 This is a flowchart illustrating a method for detecting unknown state signals according to an embodiment of the present invention. Detailed Implementation
[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0018] This application discloses a method, system, and medium for detecting unknown state signals, addressing the problem that existing technologies rely entirely on manual inspection of the power domain. This application uses scripting tools (such as Python, Perl, etc.) to obtain a list of signals in an unknown state. An unknown state refers to a signal whose value is unknown; each bit cannot be 0 or 1, but can be a high-impedance state or an X state. Then, an unknown signal checker (unknown_checker, which can be a module, interface, SVA, etc., and the user can choose the implementation method) is automatically generated. The unknown_checker is a checker that verifies the correctness of unknown signals; its function is to check whether the signal is correct. The checker is used for real-time or post-processing verification of the functional correctness of the design-under-body (DUT). It is not part of the DUT but rather a "supervisor" in the verification environment. The generated `unknown_checker` is then integrated into the verification environment. During power consumption simulation, when the corresponding power domain loses power, the check is automatically triggered, automatically checking whether the verification signal is in an "unknown" state. Besides power loss, which results in a large number of signals in an "unknown" state, there are also other special states that produce "unknown" signals; these can also be automatically checked using this application. The technical problem this application aims to solve is how to automate the power domain check, eliminating reliance on manual checks. The flowchart of the method is as follows... Figure 1 As shown, the specific steps include: using a script containing set parameters to obtain a list of signals that need to be in an unknown state, then generating an unknown signal checker (unknown_checker) for checking unknown signals, and integrating the unknown signal checker (unknown_checker) into the verification environment to verify whether a signal is in an unknown state.
[0019] Specifically, the setting parameters include: obtaining the power-down module by viewing the low-power scheme. Module is a functional block implemented in Verilog in the field of digital chips, and it is also a keyword in the Verilog programming language; and matching the power-down flag signal to it according to the low-power scheme; then storing all the signals of the power-down module in a file, deleting the isolated signals in all the files, and then transmitting them to the script as setting parameters.
[0020] For example, when detecting power failure in the signal of the power-down module, it is necessary to check whether it is truly unknown; match the power failure flag signal according to the low power scheme, such as a certain PD signal (power down, indicating a state or signal of power failure or power disconnection) or VDD power signal (power domain power signal); match the PD signals of these power-down modules one by one.
[0021] For example, when storing all signals from the power-down module to a file, you can simply use Verdi to select all signals and save them directly to the file, which is very quick and convenient. It's important to note that the files correspond one-to-one with the modules; one file corresponds to one module, which facilitates subsequent script processing.
[0022] For example, since all signals from the power-down module are stored in a file, and all signals are saved, the file needs post-processing. Specifically, ISO (Isolation) signals need to be removed. The essence of ISO signals is to physically or logically separate two or more parts, preventing them from directly affecting each other. The key purposes are to avoid interference (a problem in one part does not affect other parts), safety control (preventing the propagation of hazards such as current or data errors), and functional independence (modules can be designed / tested / operated independently). ISO signals are not in an unknown state even when power is lost, and therefore do not require unknown checks. Furthermore, determining which signals require ISO depends on the low-power design scheme.
[0023] Specifically, the script is written in a language such as Python or Perl.
[0024] For example, the script can process multiple files sequentially. Taking Python as an example, the script needs to be able to read the previously saved file of unknown signals. The script retrieves the signals whose unknown state needs to be checked from the contents of the file, and then saves them to the signal list signal_list. Based on the signal list signal_list, the corresponding unknown signal checker unknown_checker is generated.
[0025] Specifically, through the signal list signal_list, each unknown signal generates a corresponding unknown signal checker unknown_checker. This process includes: in the signal list signal_list, each row corresponds to a signal that needs to be checked, and its unknown value is checked. For each signal, an assertion check is generated based on the corresponding power-down flag signal. This process is repeated for all signals that need to be checked for unknown status, generating a SystemVerilog assertion checker, which is then placed into the power-down module.
[0026] For example, taking sv assertion as an example, where sv represents the SystemVerilog programming language and svassertion represents an assertion implemented in SystemVerilog, each line of signal_list checks the unknown value of a signal, and each signal generates an assertion check based on the PD signal and checks whether it is correct. This process is repeated to generate an sv assertionchecker for all unknown signals that need to be checked. Then, the sv assertionchecker is put into the module. This action can be implemented by a script (or an interface, or simply an assertion).
[0027] Specifically, the check for its unknown value includes: triggering or enabling signals through unknown checks, checking whether the signal is unknown logic code, and collecting coverage.
[0028] For example, during the process of generating unknown_checker, modules, interfaces, assertions, etc., implemented in SystemVerilog can be used. For example, the signal triggered or enabled by the unknown check includes: generally, a one-bit PD signal is pulled up before power failure; when the PD signal is pulled up, the check of the unknown signal is immediately started to see if it is unknown; when the PD signal fails, the unknown check is turned off.
[0029] For example, logic code to check if a signal is unknown can be used, such as by using `sv assertion` or `always` statements. However, this check needs to be performed immediately when a PD (Power-Only) is encountered. This check is not a one-time check but needs to be able to be repeated continuously. Both of the methods mentioned above can achieve this.
[0030] For example, coverage collection. The reason why svassertion was used as an example earlier is because svassertion is very convenient to match with coverage, because coverage can be directly written for each assertion. This is a feature of svassertion, which does not require engineers to write coverage separately.
[0031] Specifically, integrating the unknown signal checker (unknown_checker) into the verification environment includes adding it to the file list of the verification environment or instantiating it in the verification environment.
[0032] Specifically, after the unknown signal checker (unknown_checker) is integrated into the verification environment, it is simulated to verify whether the signal is in an unknown state.
[0033] For example, in simulation scenarios, such as power consumption simulation, simulations are performed with a UPF / CPU and random power-on / off cycles. In the chip verification field, UPF stands for Unified Power Format. It's not the verification method itself, but a standard specification document describing the low-power design intent of a chip. CPF provides a tool-independent, standardized language for explicitly describing the chip's power management architecture during the RTL (Register Transfer Level) design phase, including power domain partitioning, power switching control, signal isolation rules, and state preservation strategies. CPF is one of the core standards of the low-power design flow, competing with another mainstream format, UPF (Unified Power Format, IEEE 1801). While their functions are similar, their syntax and ecosystems differ. Alternatively, simulations can be performed using PG netlists. PG netlists (Power / Ground Netlists) are key data files describing the physical connections of the chip's power supply network, primarily used for power integrity verification and power analysis after physical design. The system will automatically check whether the signals listed are "unknown" at appropriate times.
[0034] For example, this application can also detect whether a signal is a definite value. First, a list of signals that need to be in the unknown state is obtained using a script containing set parameters. Then, a checker is generated to generate a checker for checking definite values (this step only requires the corresponding logic to be inverted). The checker is integrated into the verification environment and can then be used to detect whether a signal is a definite value.
[0035] This invention also discloses a detection system for unknown state signals, used in the aforementioned method for detecting unknown state signals, comprising: The parameter setting module is used to obtain the power-down module based on the low-power scheme, store all signals of the power-down module in a file, and then delete the isolated signals in all files to obtain the setting parameters. The processing module is used to obtain a list of signals that need to be in the unknown state using a script containing set parameters, and generate an unknown signal checker, unknown_checker, for checking unknown signals. The verification module is used to integrate the unknown signal checker (unknown_checker) into the verification environment to verify whether the signal is in an unknown state.
[0036] By way of example, the present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.
[0037] For example, the aforementioned computer-readable storage media may include, but are not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.
[0038] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.
Claims
1. A method for detecting unknown state signals, characterized in that, include: A script containing set parameters is used to obtain a list of signals that need to be in an unknown state. Then, an unknown signal checker, unknown_checker, is generated to check the unknown signals. The unknown signal checker unknown_checker is integrated into the verification environment to verify whether the signal is in an unknown state.
2. The method for detecting unknown state signals according to claim 1, characterized in that, The setting parameters include: obtaining the power-down module by viewing the low-power scheme, and matching the power-down flag signal to it according to the low-power scheme; then storing all the signals of the power-down module in a file, deleting the isolated signals in all the files, and then transmitting them to the script as setting parameters.
3. The method for detecting unknown state signals according to claim 2, characterized in that: The script is a Python or Perl script.
4. The method for detecting unknown state signals according to claim 1, characterized in that: The script extracts the signals that need to be checked for unknown status from the contents of the file, saves them to the signal list signal_list, and generates the corresponding unknown signal checker unknown_checker from the signal list signal_list.
5. The method for detecting unknown state signals according to claim 4, characterized in that: Using the signal list signal_list, a corresponding unknown signal checker unknown_checker is generated for each unknown signal. Specifically, each row in the signal list signal_list corresponds to a signal that needs to be checked, and its unknown value is checked. An assertion check is generated for each signal based on its corresponding power-down flag signal. This process is repeated for all signals that need to be checked for unknown status, generating a SystemVerilog assertion checker. Finally, it is placed into the power-down module.
6. The method for detecting unknown state signals according to claim 5, characterized in that, The aforementioned checking of its unknown value includes: checking the trigger or enable signal through the unknown check, checking whether the signal is unknown logic code, and collecting coverage.
7. The method for detecting unknown state signals according to claim 1, characterized in that, Integrating the unknown signal checker (unknown_checker) into the verification environment includes adding it to the file list of the verification environment or instantiating it in the verification environment.
8. The method for detecting unknown state signals according to claim 1, characterized in that, After the unknown signal checker (unknown_checker) is integrated into the verification environment, it is simulated to verify whether the signal is in an unknown state.
9. A detection system for unknown state signals, used in the detection method for unknown state signals according to any one of claims 1-8, characterized in that, include: The parameter setting module is used to obtain the power-down module based on the low-power scheme, store all signals of the power-down module in a file, and then delete the isolated signals in all files to obtain the setting parameters. The processing module is used to obtain a list of signals that need to be in the unknown state using a script containing set parameters, and generate an unknown signal checker, unknown_checker, for checking unknown signals. The verification module is used to integrate the unknown signal checker (unknown_checker) into the verification environment to verify whether the signal is in an unknown state.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the method according to any one of claims 1-8.