Verification method of low-power-consumption design, terminal equipment and storage medium

Abstract

The invention is suitable for the technical field of digital chip verification, and provides a low-power-consumption design verification method, terminal equipment and a storage medium, and the method comprises the steps that before a digital chip runs, a first file and a second file are loaded, and in the first file, a first language is adopted to describe the function of a first logic unit in the digital chip; a second language is adopted in the second file to describe the function of the first logic unit; verifying the consistency of the function description of the first logic unit in the first file and the second file to obtain a first verification result; and determining the function of the digital chip according to the first verification result. According to the method, the verification efficiency of the low-power-consumption function design of the digital chip can be improved, and the verification cost is reduced.

Description

Technical Field

[0001] The present application belongs to the field of chip verification technology, and in particular relates to a low-power design verification method, terminal equipment, and storage medium. Background Art

[0002] As digital chips become more complex and integrated, and as they adopt advanced process technologies, their static power consumption increases, impacting chip performance and applications. Therefore, power-sensitive digital chip manufacturers integrate power management units into their products to dynamically adjust and manage the dynamic and static power consumption of digital chips. The industry's mainstream low-power designs are based on the Unified Power Format (UPF) or Common Power Format (CPF) standards to ensure consistency in low-power management intent throughout the digital chip design process. During implementation, relevant verification tools are required to verify the low-power design.

[0003] However, existing verification tools, such as electronic design automation (EDA), can only check the UPF writing specifications and basic design errors of low-power designs. They cannot verify the consistency between the chip's low-power design specifications and the UPF design. Therefore, verification can only be performed through dynamic simulation using dynamic stimulation in the form of low-power dynamic simulation. This dynamic simulation suffers from slow simulation speeds, high server resource consumption, and late defect exposure, which reduces the verification efficiency of low-power functional designs and requires a long time to fix design defects. Summary of the Invention

[0004] The embodiments of the present application provide a verification method, terminal device and storage medium for low-power design, which can improve the verification efficiency of low-power functional design of digital chips and reduce verification costs.

[0005] In a first aspect, an embodiment of the present application provides a method for verifying a low-power design, including:

[0006] Before the digital chip is run, a first file and a second file are loaded, wherein the first file uses a first language to describe the function of the first logic unit in the digital chip; and the second file uses a second language to describe the function of the first logic unit;

[0007] Verifying consistency of functional descriptions of the first logic unit in the first file and the second file to obtain a first verification result;

[0008] The function of the digital chip is determined according to the first verification result.

[0009] In an embodiment of the present application, a first file defines the functions of multiple first logic units in a digital chip, and a second file uses a preset description language to describe the functions of the multiple first logic units in the first file. The verification process mainly checks whether the description of the logic unit function in the second file is consistent with the function defined in the first file. This avoids chip design errors caused by inconsistent functional descriptions, ensures that each logic unit can operate according to the expected function during actual operation of the chip, and improves the accuracy and reliability of the chip design. Therefore, the above method can improve the verification efficiency of the low-power functional design of digital chips and reduce verification costs.

[0010] In a possible implementation of the first aspect, the second file includes multiple sub-files, and different sub-files use different second languages to describe the function of the first logic unit;

[0011] Verifying consistency between the functional description of the first logic unit in the first file and the second file includes:

[0012] Verifying consistency between the functional description of the first logic unit in the first file and each sub-file respectively, to obtain a second verification result;

[0013] The first verification result is determined according to the second verification result.

[0014] In the embodiments of the present application, the second file is typically composed of multiple sub-files. Different sub-files may be responsible for describing different aspects of the first logical unit's functionality, or may embody the functionality from different angles and in different implementations. Verifying the first file and each sub-file separately allows for in-depth analysis of the details of each sub-file, comprehensively checking whether the functional descriptions therein are consistent with those in the first file. Compared to directly verifying the first and second files as a whole, this approach avoids missing local inconsistencies due to the broad nature of the overall verification, greatly improving verification accuracy.

[0015] In a possible implementation of the first aspect, verifying consistency of the functional description of the first logic unit in the first file and each sub-file to obtain a second verification result includes:

[0016] Different verification methods are used to verify the consistency of the functional description of the first logic unit in the first file and each sub-file, respectively, to obtain a second verification result.

[0017] In the embodiment of the present application, since the sub-files have different formats and are described in different second languages, a single verification method is difficult to adapt to all situations. Different verification methods can be flexibly selected according to the characteristics of the sub-files to improve verification efficiency and effectiveness.

[0018] In a possible implementation of the first aspect, the verification method includes a first method;

[0019] The step of verifying the consistency of the functional description of the first logic unit in the first file and the sub-file using the first method to obtain a second verification result includes:

[0020] Extracting first attribute information of the first file; the first attribute information is communication port information corresponding to the first logical unit described in a first language;

[0021] Extracting second attribute information corresponding to the sub-file; the second attribute information is a communication port information corresponding to the first logical unit described in a second language;

[0022] The consistency of the first attribute information and the second attribute information is verified to obtain a second verification result.

[0023] In the embodiments of this application, the first file is usually the design standards and specifications. By verifying the consistency of the attribute information, it can be ensured that the sub-file strictly complies with the design requirements of the first file. This helps to maintain a unified standard throughout the design process and improve the standardization and maintainability of the design.

[0024] In a possible implementation of the first aspect, the verification method includes the second method;

[0025] The steps of verifying the consistency of the functional description of the first logic unit in the first file and the sub-file using the second method to obtain a second verification result include:

[0026] Extracting first characteristic information of the first file; the first characteristic information is a description of characteristics and requirements corresponding to the first logical unit in the first language;

[0027] Extracting second characteristic information corresponding to the sub-file; the second characteristic information is a description of characteristics and requirements corresponding to the first logical unit in a second language;

[0028] The consistency of the first characteristic information and the second characteristic information is verified to obtain a second verification result.

[0029] In the embodiment of the present application, the first and second characteristic information are extracted and compared to verify each other, which can quickly locate inconsistent parameters. Once a discrepancy is found, the designer can directly check and correct these parameters, greatly improving the efficiency of problem detection and resolution.

[0030] In a possible implementation of the first aspect, determining the first verification result according to the second verification result includes:

[0031] Verifying the sub-file to determine whether there is preset category error information in the sub-file, and outputting a third verification result;

[0032] The first verification result is determined according to the second verification result and the third verification result.

[0033] In the embodiment of the present application, the second verification result focuses on the consistency of the functional description of the first logical unit in the first file and the sub-file, focusing on the degree of matching at the functional design level. The third verification result focuses on the preset category error information in the sub-file. These error messages may cover multiple aspects such as syntax errors, logical loopholes, and violations of design specifications, and check the file from different dimensions. Combining the two to determine the first verification result can comprehensively cover the verification of the file in terms of functional description consistency and error information, avoiding the limitations of a single verification method and ensuring that the design meets the requirements in all aspects.

[0034] In a possible implementation of the first aspect, the method further includes:

[0035] If the first verification result indicates that there is error information, the first file and the second file are corrected respectively to obtain a corrected third file and a corrected fourth file;

[0036] Re-verify the third and fourth files.

[0037] In the embodiment of the present application, when an error message appears in the first verification result, the first and second files are corrected and re-verified, which can solve the current problem at one time and avoid problems in the subsequent development process. This can save a lot of time and labor costs and speed up the project progress.

[0038] In a possible implementation of the first aspect, the method further includes:

[0039] If the first verification result indicates that there is no error information, classifying the information corresponding to the first verification result and outputting classified information;

[0040] Generate a verification report based on the classification information.

[0041] In the examples of this application, a verification report is generated based on the classified information, presenting the verification results comprehensively and systematically. The report confirms the consistency of the functional descriptions of each part, providing a reliable reference for the design team. Designers can use the report content to determine whether the existing design needs to be optimized or upgraded.

[0042] In a second aspect, an embodiment of the present application provides a terminal device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, a verification method for a low-power design as described in any one of the first aspects above is implemented.

[0043] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements a low-power design verification method as described in any one of the first aspects above.

[0044] In a fourth aspect, an embodiment of the present application provides a computer program product, which, when running on a terminal device, enables the terminal device to execute the low-power design verification method of any one of the above-mentioned first aspects.

[0045] It can be understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0047] Figure 1 1 is a flow chart of a method for verifying a low-power design according to an embodiment of the present application;

[0048] Figure 2 This is a schematic diagram of the process of obtaining the first verification result provided in the embodiment of the present application. Figure 1 ;

[0049] Figure 3 This is a schematic diagram of the process of obtaining the second verification result provided in the embodiment of the present application. Figure 1 ;

[0050] Figure 4 This is a schematic diagram of the process of obtaining the second verification result provided in the embodiment of the present application. Figure 2 ;

[0051] Figure 5 This is a schematic diagram of the process of obtaining the first verification result provided in the embodiment of the present application. Figure 2 ;

[0052] Figure 6 This is a schematic diagram of the overall structure of a verification method for low-power design provided by an embodiment of the present application;

[0053] Figure 7 This is a structural diagram of the terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0054] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0055] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.

[0056] It will also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0057] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0058] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0059] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in yet other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized.

[0060] As digital chips become more complex and integrated, and as they adopt advanced process technologies, their static power consumption increases, impacting chip performance and applications. Therefore, power-sensitive digital chip manufacturers integrate power management units into their products to dynamically adjust and manage the dynamic and static power consumption of digital chips. The industry's mainstream low-power designs are based on the Unified Power Format (UPF) or Common Power Format (CPF) standards to ensure consistency in low-power management intent throughout the digital chip design process. During implementation, relevant verification tools are required to verify the low-power design.

[0061] However, existing verification tools, such as electronic design automation (EDA), can only check the UPF writing specifications and basic design errors of low-power designs. They cannot verify the consistency between the chip's low-power design specifications and the UPF design. Therefore, verification can only be performed through dynamic simulation using dynamic stimulation in the form of low-power dynamic simulation. This dynamic simulation suffers from slow simulation speeds, high server resource consumption, and late defect exposure, which reduces the verification efficiency of low-power functional designs and requires a long time to fix design defects.

[0062] In order to solve the problems in the above-mentioned related technologies, an embodiment of the present application provides a low-power design verification method. The method configures inspection items and rules through design specification documents, register transfer level (RTL) code files, and UPF database files, and processes file data through Python script construction modules to perform consistency checks. If there is no error information during the inspection, a report is output; if there is, the error is corrected and re-verified. This method can discover design differences in the early stages of chip development, has fast running speed, low resource consumption, and improves the efficiency of low-power verification and design iteration.

[0063] See also Figure 1 , is a flow chart of a method for verifying a low-power design provided in an embodiment of the present application. As an example and not a limitation, the method may include the following steps:

[0064] S101 , before the digital chip runs, loading a first file and a second file, wherein the first file uses a first language to describe the function of a first logic unit in the digital chip; and the second file uses a second language to describe the function of the first logic unit.

[0065] In the embodiment of the present application, in the low-power design of the digital chip, in order to ensure the accuracy and reliability of the chip design, it is necessary to verify the functional description of the logic unit in the chip. The first file uses the first language to describe the function of the first logic unit in the digital chip, which is equivalent to a low-power design specification file, namely SPEC. _ DB file. The "first language" here can be a relatively general and intuitive way to define the functionality of a logic unit. For example, it could be a document-like file that combines natural language with specific technical terminology to describe the current low-power design intent, such as the number of instantiations of all design modules in the chip to be verified, power requirements, pins, package PCB requirements, interconnect relationships, package pinouts, and other related information.

[0066] The "second language" is typically a hardware description language, such as Verilog or VHDL. Hardware description languages are precise and executable, capable of being understood and processed by computers and related design tools. It converts the logic unit functions defined in the first file into code that can be simulated, synthesized, and verified. Loading these two files before the digital chip is operational allows for subsequent functional verification to identify errors in the chip's low-power design files.

[0067] S102 , verifying consistency between the functional description of the first logic unit in the first file and the second file to obtain a first verification result.

[0068] In an embodiment of the present application, in a digital chip design, a first file and a second file are different description carriers of the functions of a first logic unit in the chip. The first file may use a natural language, a design document specification, or a high-level abstract language to define the functions that the first logic unit should have; the second file may use a hardware description language (such as Verilog or VHDL) to write code to implement the functions of the first logic unit. Verifying the consistency of the functional descriptions of the first logic unit in the two files is to check whether the functions implemented by the second file match the functions defined in the first file, and obtain a matching result, namely the first verification result.

[0069] Verifying consistency allows for the timely detection of potential errors or deviations during the design process. Any discrepancies between the two files indicate a design issue that requires correction to ensure the chip ultimately functions as intended. Performing functional verification early in the chip design process can identify issues before they occur, saving significant time and costs.

[0070] S103: Determine the function of the digital chip according to the first verification result.

[0071] In an embodiment of the present application, when the first verification result shows consistency, it means that the first logic unit can complete its function according to the design requirements, that is, the low-power consumption scheme of the designed digital chip has low power consumption when the digital chip is running, otherwise it may cause the chip power consumption to increase.

[0072] In one embodiment, the second file includes multiple sub-files, and different sub-files use different second languages to describe the functions of the first logic unit. Figure 2 , is a schematic diagram of the process of obtaining the first verification result provided in the embodiment of the present application Figure 1 ,like Figure 2 As shown, step S102 includes:

[0073] S201 , verifying the consistency of the functional description of the first logic unit in the first file and each sub-file respectively, to obtain a second verification result.

[0074] In the embodiment of the present application, the second file is split into multiple sub-files, and each sub-file uses a different second language to describe the function of the first logic unit. The second language here is usually a different type of hardware description language or a description language for a specific field. For example, a sub-file may be a file in the register transfer level (RTL) format, that is, RTL _ DB file, RTL_DB mainly refers to the design code file developed based on the IEEE Std 1364-1995 or IEEE Std 1364-2001 hardware description language (HDL) standard.

[0075] Another sub-file can be a UPF file that is generated by processing the low-power design using EDA tools. _ DB, which can reflect the connection relationship between all the same cells or different cells in the current chip and the power supply and ground, as well as the corresponding voltage values and power primary properties.

[0076] RTL _ DB files and UPF _ DB files all describe the functions of the first logical unit. Verifying the consistency of the functional descriptions of the first logical unit between the first file and each sub-file involves individually checking whether the functions described in each sub-file match those defined in the first file. The resulting second verification result reflects the consistency of the functional descriptions of all sub-files with the first file.

[0077] In one embodiment, step S201 includes:

[0078] Different verification methods are used to verify the consistency of the functional description of the first logic unit in the first file and each sub-file, respectively, to obtain a second verification result.

[0079] In the embodiment of the present application, due to the different formats or structures of the sub-files, during the verification process of the first file and each sub-file, it is necessary to select multiple different verification methods based on the characteristics of the sub-files and the focus of the verification to obtain a second verification result.

[0080] In the above methods, due to the different formats of sub-files and the use of different second languages for description, a single verification method is not suitable for all situations. Different verification methods can be flexibly selected according to the characteristics of the sub-files to improve verification efficiency and effectiveness.

[0081] In one embodiment, the verification method includes a first method; see Figure 3 , is a schematic diagram of the process of obtaining the second verification result provided in the embodiment of the present application Figure 1 ,like Figure 3 As shown, step S201 further includes:

[0082] S301 , extracting first attribute information of a first file; the first attribute information is communication port information corresponding to a first logical unit described in a first language.

[0083] In the embodiment of the present application, if the sub-file is RTL _ DB file, then in the SPEC _ DB file (first file) and RTL _ The first method is used to verify the DB file. The first method includes extracting the communication port information corresponding to the first logic unit described in the first language in the first file, such as the attributes of digital IO, power ground IO, and analog IO. These attributes cover the pin name definition, pull-up and pull-down configuration, etc., which clearly define the port characteristics of the first logic unit for communication and interaction with the outside world.

[0084] Specifically, a gate parser can be used. For example, Python's ply library can be used to construct a simple Verilog parser. While this method is relatively complex to implement, it provides more accurate parsing results. Since this application has no specific constraints on SPEC_DB files, its implementation can be in various document formats such as DOC, EXCEL, XML, and TXT. Therefore, text parsing methods can be used to extract attribute information. Since there are many ways to extract attributes, this application does not limit the specific extraction method.

[0085] S302 , extracting second attribute information corresponding to the sub-file; the second attribute information is communication port information corresponding to the first logical unit described in a second language.

[0086] In the embodiment of the present application, the second attribute information is RTL _ The IO design information in the DB file code. RTL code is written in a hardware description language (such as Verilog or VHDL) and is used to describe the behavior and structure of digital circuits. The IO design information in it describes the specific implementation of the input and output ports of the first logic unit in the actual design.

[0087] Similarly, RTL can be parsed using syntax parsers and text parsing methods. _ Extract attribute information from DB files.

[0088] S303: Verify the consistency of the first attribute information and the second attribute information to obtain a second verification result.

[0089] In the embodiment of the present application, the first attribute information and the second attribute information are checked for consistency according to the preset check rules. The check rules are a set of predefined standards and conditions used to determine whether the two sets of information match. For example, the rules may require that the pin name and direction defined in the first attribute information must be consistent with the RTL _ The IO design information in the DB file code must be consistent, or the pull-up and pull-down configurations must also match. After completing the consistency comparison check, you need to record the check results in detail, which is the second verification result.

[0090] In this approach, the first file typically contains the design standards and specifications. By verifying the consistency of attribute information, the sub-files can be guaranteed to strictly adhere to the design requirements of the first file. This helps maintain a unified standard throughout the design process, improving the standardization and maintainability of the design.

[0091] In one embodiment, the verification method includes a second method; see Figure 4 , is a schematic diagram of the process of obtaining the second verification result provided in the embodiment of the present application Figure 2 ,like Figure 3 As shown, step S201 further includes:

[0092] S401 , extracting first characteristic information of a first file; the first characteristic information is a description of characteristics and requirements corresponding to a first logical unit in a first language.

[0093] In the embodiment of the present application, if the sub-file is UPF _ DB file, then in the first file and UPF _ DB file can be verified using the second method. The second method involves extracting the characteristics and requirements corresponding to the first logic unit in the first file. These parameters include key information (first characteristic information) such as module name, power pin, direction definition, package mapping, and operating range of power supply voltage.

[0094] S402 , extracting second characteristic information corresponding to the sub-file; the second characteristic information is a description of characteristics and requirements corresponding to the first logical unit in a second language.

[0095] In the embodiment of this application, UPF _ The DB file is a database generated by processing a low-power design UPF file using an EDA tool. The design information in the file includes the instance name, power domain, isolation information, power ground pin, power voltage range, primary power attribution, and primary power voltage range (secondary characteristic information). This information primarily focuses on the chip's low-power design intent and describes the power management and connection relationships between different parts of the circuit. Therefore, the second characteristic information corresponding to the first file is also extracted from the UPF database file.

[0096] Specifically, feature information in sub-files can be extracted based on text parsing, including defining corresponding parsing rules according to the file format and the organization of feature information, extracting the required feature information from the file content according to the parsing rules, and performing necessary processing and storage on the extracted feature information.

[0097] S403: Verify the consistency between the first characteristic information and the second characteristic information to obtain a second verification result.

[0098] In the implementation of this application, a consistency comparison check is performed on the first characteristic information and the second characteristic information according to a pre-set check rule. The check rule is formulated according to the specifications and requirements of the chip design and is used to determine whether the two sets of characteristic information match to obtain a second verification result.

[0099] For example, the check rule may stipulate that the power pin definition in the first file should be consistent with the UPF _ The DB file's power ground pins and power supply voltage ranges must match, and the module names in both must conform to design requirements. During the inspection process, the two sets of information are compared one by one. Any discrepancies found are recorded in detail, including the specific parameters and location of the discrepancy. This allows designers to quickly identify and resolve design issues based on these records, ensuring the chip's low-power design aligns with the overall functional design, and improving the chip's reliability and stability.

[0100] In this method, extracting the first and second characteristic information separately for comparison and verification can quickly locate inconsistent parameters. Once discrepancies are discovered, designers can directly check and correct these parameters, greatly improving the efficiency of problem identification and resolution.

[0101] In this method, extracting the first and second characteristic information separately for comparison and verification can quickly locate inconsistent parameters. Once discrepancies are discovered, designers can directly check and correct these parameters, greatly improving the efficiency of problem identification and resolution.

[0102] S202: Determine the first verification result according to the second verification result.

[0103] In this embodiment of the present application, the first verification result primarily reflects the consistency of the functional description of the first logical unit in the first file and the second file (as a whole), while the second verification result focuses on the consistency of the functional description of the first logical unit in each of the multiple subfiles in the first file and the second file. The first verification result can be determined based on the second verification result.

[0104] In the above method, the second file is typically composed of multiple subfiles. Different subfiles may describe different aspects of the first logical unit's functionality, or implement the functionality from different perspectives and with different implementation methods. Verifying the first file and each subfile separately allows for in-depth detail in each subfile, comprehensively checking whether the functional descriptions within them are consistent with those in the first file. Compared to directly verifying the first and second files as a whole, this approach avoids missing local inconsistencies due to the broad nature of the overall verification, significantly improving verification accuracy.

[0105] In one embodiment, see Figure 5 , is a schematic diagram of the process of obtaining the first verification result provided in the embodiment of the present application Figure 2 ,like Figure 5 As shown, step S202 includes:

[0106] S501 : Verify the sub-file to determine whether there is preset category error information in the sub-file, and output a third verification result.

[0107] In the embodiment of the present application, verifying the sub-file refers to verifying the UPF _ The DB file is verified separately according to the preset inspection rules to obtain the third verification result. _ The DB file is a database generated after the low-power design UPF file is processed by the EDA tool. Since the EDA tool cannot completely check all UPF design errors, the UPF_DB file needs to be checked for consistency according to the preset check rules.

[0108] The UPF_DB file primarily refers to the process of importing the UPF design, along with other design files such as RTL, netlist, and library, into a low-power verification EDA tool. Based on the low-power verification check requirements (pre-set check rules), a low-power data file containing the design instantiation and power connections is then re-output. However, the EDA tool generation process may have the following flaws: Some module ports in the netlist belong to the always-on power domain. If isolation cells are mistakenly inserted during the previous synthesis process, the subsequent low-power verification tool will not be able to effectively identify this error. Secondly, some module interfaces are connected to fixed values in the design, appearing in the netlist as connected to fixed Tiehigh / TielowCELL cells. However, the operating voltage of these cells does not match the operating voltage of the connected modules, making the tool unable to identify this error. Thirdly, the power connections of some modules do not match the supply voltage required by the library, and are connected to the wrong power line, which the tool still cannot identify.

[0109] This embodiment, however, extracts information for identifying these three situations (categorical error information) and performs checks according to preset checking rules to obtain a second verification result.

[0110] S502: Determine the first verification result according to the second verification result and the third verification result.

[0111] In the embodiment of the present application, combined with the second verification result SPEC _ Consistency check results between DB file and RTL_DB, SPEC _ The consistency check result of the DB file and the UPF_DB file is analyzed in combination with the third verification result, that is, the consistency check result of the UPF_DB file itself, to determine the inspection result of the second file itself, that is, the first verification result.

[0112] In the above method, the second verification result focuses on the consistency of the functional description of the first logical unit in the first file and the subfile, emphasizing the degree of matching at the functional design level. The third verification result, on the other hand, focuses on the error messages pre-set in the subfile. These error messages may include syntax errors, logical loopholes, violations of design specifications, and other aspects, examining the file from different dimensions. Combining these two to determine the first verification result comprehensively covers the verification of the file in terms of functional description consistency and error messages, avoiding the limitations of a single verification method and ensuring that the design meets requirements in all aspects.

[0113] In one embodiment, step S502 includes:

[0114] If the first verification result indicates that there is erroneous information, the first file and the second file are corrected respectively to obtain a corrected third file and a fourth file; and the third file and the fourth file are re-verified.

[0115] In the embodiment of the present application, when executing SPEC _ DB file and RTL_DB consistency check, SPEC _ When checking the consistency between the DB file and the UPF_DB file and the UPF_DB file, the main check information is filtered into three categories: normal information, warning information, and error information.

[0116] By screening the second and third verification results, if any error information is found, indicating a verification error in the first verification result, the error information needs to be analyzed to determine the functional module, signal interaction, timing issues, and other aspects involved in the error. For example, in communication interface design, if verification reveals a data transmission error, it is necessary to investigate whether the problem lies in the signal definition, transmission protocol, or logical implementation. Through detailed analysis, the specific location and related parts of the error in the first and second files can be accurately located, providing a clear direction for subsequent corrections.

[0117] Based on the error analysis results, make targeted modifications to the first file. If the error stems from an ambiguous or inaccurate functional definition, the first logic unit's functionality needs to be reorganized and clearly and accurately defined. For example, if the originally defined logic unit functionality is ambiguous in complex scenarios, resulting in deviations in the second file's implementation, the functional description needs to be refined and special case handling methods should be added. Once these modifications are complete, the resulting file becomes the third file, representing a more precise and appropriate definition of the first logic unit's functionality.

[0118] Based on the changes to the first file, the second file is adjusted simultaneously. If the second file is written in a hardware description language, the code logic must be modified based on the new functional definition. For example, if the first file changes the input and output signal requirements of a logic unit, the code in the second file must adjust the signal port definitions, logical operation expressions, etc. accordingly. The modified second file forms the fourth file, so that its functional implementation matches the functional definition of the third file. The third and fourth files are then re-verified.

[0119] In the above method, if an error message is displayed in the first verification result, the first and second files are corrected and re-verified, which can solve the current problem at a time and avoid problems in subsequent development. This can save a lot of time and labor costs and speed up the project progress.

[0120] In one embodiment, step S502 further includes:

[0121] If the first verification result indicates that there is no error information, the information corresponding to the first verification result is classified and the classified information is output; and a verification report is generated according to the classified information.

[0122] In an embodiment of the present application, after completing the first verification of the consistency of the functional description of the first logical unit between the first file and the second file, if the verification result shows that there is no error information, the information corresponding to the first verification result is classified. After completing the information classification, it is necessary to output each type of information in a clear and easy-to-understand manner. The output classification information can be formatted and a static verification report can be generated based on the classification information. This is a summary and presentation of the entire verification process.

[0123] In this method, a verification report is generated based on the classified information, presenting the verification results in a comprehensive and systematic manner. The report confirms the consistency of the functional descriptions of each component, providing a reliable reference for the design team. Designers can use the report's content to determine whether existing designs need optimization or upgrades.

[0124] See also Figure 6 , is a schematic diagram of the overall structure of the verification method for low power design provided by the embodiment of the present application, such as Figure 6 As shown, the static verification steps are as follows:

[0125] 1. Load the first file and the second file through the interactive user interface

[0126] Load SPEC via (User Interface, UI)64 _ DB file (first file) 61, RTL_DB file (sub-file) 62 and UPF_DB (sub-file) 63, wherein the second file includes multiple sub-files;

[0127] 2. Data extraction through interactive UI 65

[0128] Extract SPEC _ The IO attribute information in the DB file and the IO design information corresponding to the RTL_DB file are processed and data formatted 66;

[0129] Extract SPEC _ The characteristic information in the DB file and the corresponding characteristic information in the UPF_DB file are processed by data formatting 66;

[0130] 3. Verify data consistency

[0131] The data processed by data formatting 66 is subjected to consistency verification 68 in combination with the preset check rules 67, and a first verification result is obtained, wherein the first verification result includes the SPEC _ Consistency check results of DB file and RTL_DB file, SPEC _ Consistency check results between the DB file and the UPF_DB file, and consistency check results between the UPF_DB file itself.

[0132] 4. Generate a report based on the verification results

[0133] The first verification result is analyzed. If the first verification result does not contain error information, the verification result is classified and a static verification report is generated.

[0134] This application provides a low-power design verification method. This method uses design specification documents, RTL files, and UPF database files, configures check items and rules, and then uses Python scripts to build modules to process the file data and perform consistency checks. If no errors are detected, a report is generated; if any are found, errors are corrected and reverified. This method can identify design discrepancies early in chip development, operates quickly, consumes minimal resources, and improves the efficiency of low-power verification and design iteration.

[0135] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0136] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0137] Figure 7 This is a schematic diagram of the structure of the terminal device provided in the embodiment of the present application. Figure 7 As shown, the terminal device 7 of this embodiment includes: at least one processor 70 ( Figure 7 Only one is shown in the figure) a processor, a memory 71, and a computer program 72 stored in the memory 71 and executable on at least one processor 70. When the processor 70 executes the computer program 72, the steps of any of the above-mentioned low-power design verification method embodiments are implemented.

[0138] The terminal device can be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The terminal device may include, but is not limited to, a processor and a memory. Those skilled in the art will understand that Figure 7 It is only an example of the terminal device 7 and does not constitute a limitation on the terminal device 7. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, it may also include input and output devices, network access devices, etc.

[0139] The processor 70 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor may be a microprocessor or any conventional processor.

[0140] In some embodiments, the memory 71 may be an internal storage unit of the terminal device 7, such as a hard disk or memory of the terminal device 7. In other embodiments, the memory 71 may also be an external storage device of the terminal device 7, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the terminal device 7. Furthermore, the memory 71 may include both an internal storage unit of the terminal device 7 and an external storage device. The memory 71 is used to store an operating system, application programs, a boot loader, data, and other programs, such as the program code of a computer program. The memory 71 may also be used to temporarily store data that has been output or is about to be output.

[0141] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0142] An embodiment of the present application provides a computer program product. When the computer program product is run on a terminal device, the terminal device can implement the steps in the above-mentioned method embodiments when executing the computer program product.

[0143] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device that can carry the computer program code to the device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electric carrier signal, a telecommunication signal and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk. In some jurisdictions, according to legislation and patent practice, a computer-readable medium cannot be an electric carrier signal or a telecommunication signal.

[0144] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0145] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0146] In the embodiments provided in this application, it should be understood that the disclosed devices / terminal devices and methods can be implemented in other ways. For example, the device / terminal device embodiments described above are merely illustrative. For example, the division of modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0147] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0148] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A verification method for low power design, characterized in that: The method comprises: Before the digital chip is run, a first file and a second file are loaded, wherein the first file uses a first language to describe the function of a first logic unit in the digital chip; and the second file uses a second language to describe the function of the first logic unit; Verifying consistency between the functional description of the first logic unit in the first file and the second file to obtain a first verification result; The performance of the digital chip is determined according to the first verification result.

2. The low power design verification method according to claim 1, wherein: The second file includes a plurality of sub-files, and different sub-files use different second languages to describe the function of the first logic unit; Verifying the consistency of the functional description of the first logic unit in the first file and the second file includes: Verifying consistency between the functional description of the first logic unit in the first file and each of the sub-files, respectively, to obtain a second verification result; The first verification result is determined according to the second verification result.

3. The low power design verification method according to claim 2, wherein: The verifying the consistency of the functional description of the first logic unit in the first file and each of the sub-files to obtain a second verification result includes: Different verification methods are used to verify the consistency of the functional description of the first logic unit in the first file and each of the sub-files, respectively, to obtain a second verification result.

4. The low power design verification method according to claim 3, wherein: The verification method includes a first method; The step of verifying the consistency of the functional description of the first logic unit in the first file and the sub-file by using the first method to obtain a second verification result includes: Extracting first attribute information of the first file; the first attribute information is a description of communication port information corresponding to the first logical unit in the first language; Extracting second attribute information corresponding to the subfile; the second attribute information is a description of communication port information corresponding to the first logic unit in the second language; Verify the consistency of the first attribute information and the second attribute information to obtain the second verification result.

5. The low power design verification method according to claim 3, wherein: The verification method includes a second method; The step of verifying the consistency of the functional description of the first logic unit in the first file and the sub-file by using the second method to obtain a second verification result includes: Extracting first characteristic information of the first file; the first characteristic information is a description of characteristics and requirements corresponding to the first logical unit in the first language; Extracting second characteristic information corresponding to the sub-file; the second characteristic information is a description of characteristics and requirements corresponding to the first logical unit in the second language; Verify the consistency of the first feature information and the second feature information to obtain the second verification result.

6. The low power design verification method according to any one of claims 2 to 5, characterized in that: The determining the first verification result according to the second verification result includes: Verifying the sub-file to determine whether there is preset category error information in the sub-file, and outputting a third verification result; The first verification result is determined according to the second verification result and the third verification result.

7. The low power design verification method according to claim 6, wherein: The method further comprises: If the first verification result indicates that error information exists, correcting the first file and the second file respectively to obtain a corrected third file and a corrected fourth file; The third file and the fourth file are re-verified.

8. The low power design verification method according to claim 7, wherein: The method further comprises: If the first verification result indicates that the error information does not exist, classifying the information corresponding to the first verification result and outputting classification information; A verification report is generated based on the classification information.

9. A terminal device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 8 is implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images