Method for detecting register transfer level code, electronic equipment and medium

Abstract

The invention relates to the technical field of computers and provides a method for detecting a register transfer level code, electronic equipment and a medium. The method comprises the following steps: determining the code maturity of a first register transfer level code according to a code maturity index; determining a first chip development stage matched with the first register transfer level code based on the code maturity corresponding to each of the plurality of chip development stages; when the first chip development stage is an acceptance stage, carrying out the quality detection of the front-end design process through the comprehensive verification tool according to the quality detection item of the comprehensive verification tool; and when the first chip development stage is not the acceptance stage, configuring the comprehensive verification tool according to configuration environment input to obtain a configured comprehensive verification tool, and then performing quality detection of the front-end design process according to the quality detection items included in the rapid quality detection item set through the configured comprehensive verification tool. In this way, correctness is ensured, and iteration efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, electronic device, and medium for detecting register transfer level code. Background Art

[0002] The main chip development process can be divided into the specification definition phase, system design phase, front-end design phase, and back-end design phase. System-level design, such as determining the chip's functional requirements and module division, is completed during the specification definition and system design phases. Circuit logic design is completed during the front-end design phase, and the back-end design phase transforms the design results from the front-end design phase into a physical layout. The front-end design phase involves coding in a hardware description language (HDL) to describe the integrated circuit at multiple levels, typically at the advanced system and algorithm levels. Register transfer level (RTL) code is then generated for the specific circuits, resulting in RTL code. Circuit logic functionality is then verified, and revisions are made based on the verification results. Finally, a comprehensive verification tool is used to convert the RTL code into a gate-level netlist (GTL), also known as logic synthesis. The conversion of the front-end design results into the chip netlist file is used to create the physical layout and perform verification in the back-end design phase. It can be seen that the register transfer level code needs to be repeatedly verified and modified during the front-end design phase. Then, after the register transfer level code is converted into a gate-level netlist, the physical layout converted from the netlist file also needs to be repeatedly verified and modified during the back-end design phase. In addition, some problems discovered during the back-end design phase may need to be fed back to the front-end design phase. After the developers responsible for the front-end design phase make modifications, they can be delivered to the developers in the back-end design phase for subsequent development. As a result, the overall chip development process may involve multiple iterations of development versions and a lot of communication and modifications between the front-end and back-end design phases, resulting in a lot of waiting time costs, which is not conducive to improving chip development efficiency and shortening the chip development cycle.

[0003] To this end, the present application provides a method, electronic device, and medium for detecting register transfer level code, which is conducive to improving chip development efficiency and shortening the chip development cycle. Summary of the Invention

[0004] In the first aspect, the present application provides a method for detecting register transfer level code. The method includes: determining the code maturity of the first register transfer level code according to the code maturity index; determining the first chip development stage that matches the first register transfer level code in the multiple chip development stages based on the code maturity corresponding to each of the multiple chip development stages, wherein the multiple chip development stages include at least a trial operation stage, a pre-acceptance stage and an acceptance stage, wherein the code maturity corresponding to the acceptance stage is one hundred percent; when the first chip development stage is the acceptance stage, the first register transfer level code is subjected to a quality inspection of the front-end design process through a comprehensive verification tool according to the quality inspection items provided by the comprehensive verification tool; when the first chip development stage is not the acceptance stage, The comprehensive verification tool is configured according to a configuration environment input to obtain a configured comprehensive verification tool. Then, through the configured comprehensive verification tool, quality inspection of the front-end design process is performed on the first register transfer level code according to quality inspection items included in a fast quality inspection item set, wherein the configuration environment input is determined based on the first register transfer level code, the fast quality inspection item set is obtained by deleting first-category quality inspection items and extracting second-category quality inspection items from quality inspection items provided by the comprehensive verification tool, and the correlation between the first-category quality inspection items and the back-end design process is lower than the correlation between the second-category quality inspection items and the back-end design process.

[0005] Through the first aspect of the present application, the quality inspection items provided by the comprehensive verification tool are utilized, and the first type of quality inspection items in the quality inspection items provided by the comprehensive verification tool are deleted and the second type of quality inspection items are extracted, thereby obtaining the fast quality inspection item set; by distinguishing the first type of quality inspection items with lower correlation from the second type of quality inspection items with higher correlation, and skipping the first type of quality inspection items with lower correlation, a fast iteration path is added on the basis of the conventional path, which can conveniently perform quality inspection on the inspection points in the fast quality inspection item set and quickly generate a netlist file for the back-end design stage; it helps to achieve parallel development between the front-end design stage and the back-end design stage, fully considers the needs of subsequent links in the overall chip development process, and is conducive to improving chip development efficiency and shortening the chip development cycle. In addition, according to the progress of the overall chip development project and the chip development stage in which it is located, an appropriate quality inspection path is selected, so that designers can perform verification in parallel at the beginning of the code design completion, while ensuring the correctness of the delivery to the physical implementation personnel, thereby ensuring the completeness and correctness of the simulation verification while also improving the iteration efficiency.

[0006] In a possible implementation of the first aspect of the present application, the failure result of the first type of quality inspection item does not block the execution of the back-end design process, and the failure result of the second type of quality inspection item blocks the execution of the back-end design process.

[0007] In a possible implementation of the first aspect of the present application, the correction work associated with the failure results of the first type of quality inspection items in the front-end design process is carried out synchronously with the execution of the back-end design process, and the correction work associated with the failure results of the second type of quality inspection items in the front-end design process is carried out serially with the execution of the back-end design process.

[0008] In a possible implementation of the first aspect of the present application, the first category of quality inspection items includes: detecting whether there are different time scales for setting simulation time units and simulation time accuracy, detecting whether there are undriven output ports, and detecting whether a clock signal is used as a data signal.

[0009] In a possible implementation of the first aspect of the present application, the second category of quality inspection items includes: detecting whether there are input pins without loaded inputs, detecting whether there are undriven netlists, detecting whether there are latches, and detecting whether the connection bandwidth of the module port is different from the bandwidth defined inside the module.

[0010] In a possible implementation of the first aspect of the present application, the quality inspection items provided by the comprehensive verification tool include third-category quality inspection items, and the comprehensive verification tool feeds back harmless processing suggestions for the failure results of the third-category quality inspection items. The rapid quality inspection item set extracts and updates the third-category quality inspection items included in the quality inspection items provided by the comprehensive verification tool to obtain updated third-category quality inspection items, and the comprehensive verification tool feeds back corrective processing suggestions for the failure results of the updated third-category quality inspection items.

[0011] In a possible implementation of the first aspect of the present application, the third category of quality inspection items includes: detecting whether there are empty modules that are missing module definitions or signal declarations, and detecting whether there are black box modules whose internal logic definitions are unknown.

[0012] In a possible implementation of the first aspect of the present application, the harmless processing suggestion is to remove or not process the empty module and the black box module, and the correction processing suggestion is to add module definition and signal declaration to the empty module and add internal logic definition to the black box module.

[0013] In a possible implementation of the first aspect of the present application, the configuration environment input includes: a delivered version of the first register transfer level code, a list of modules and top levels of the first register transfer level code, a library of the first register transfer level code, definitions of parameters and macros of the first register transfer level code, a file list of the first register transfer level code, and a module type of the first register transfer level code.

[0014] In a possible implementation of the first aspect of the present application, the code maturity in the trial operation stage is 40% to 60%, and the code maturity in the pre-acceptance stage is 85% to 95%.

[0015] In a possible implementation of the first aspect of the present application, the code maturity index includes a functional correctness index, a test completeness index, a functional robustness index, and a maintainability index, wherein the code maturity corresponding to each of the multiple chip development stages is determined based on the percentage of the code maturity index achieved by each of the multiple chip development stages.

[0016] In a possible implementation of the first aspect of the present application, the functional correctness indicators include whether the functional points required by the chip specifications are realized and the simulation verification pass rate; the test completeness indicators include the requirement coverage, code coverage, and function coverage of the test cases for all functional points of the chip specifications; the functional robustness indicators include cross-clock domain processing mechanism, abnormal self-recovery capability, and static check pass rate; the maintainability indicators include modular design, complete annotations, consistent style, and parameterized design.

[0017] In a possible implementation of the first aspect of the present application, the rapid quality inspection item set is independently managed and maintained.

[0018] In a second aspect, an embodiment of the present application further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements a method according to any one of the implementation methods of any of the above aspects when executing the computer program.

[0019] In a third aspect, an embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed on a computer device, the computer device executes a method according to any one of the implementation methods of any of the above aspects.

[0020] In a fourth aspect, an embodiment of the present application further provides a computer program product, which includes instructions stored on a computer-readable storage medium, and when the instructions are executed on a computer device, enables the computer device to execute a method according to any one of the implementation methods of any of the above aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the description of the embodiments. Obviously, the drawings described below are 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.

[0022] Figure 1 A flowchart of a method for detecting register transfer level code provided in an embodiment of the present application; Figure 2 A reference provided for the embodiments of this application Figure 1 Schematic diagram of the front-end design flow of the method for detecting register transfer level code shown; Figure 3 A reference provided for the embodiments of this application Figure 1 Schematic diagram of the chip development process of the method for detecting register transfer level code shown; Figure 4 A schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

[0024] It should be understood that, in the description of this application, "at least one" means one or more, and "a plurality" means two or more. In addition, unless otherwise specified, the terms "first" and "second" are used only for descriptive purposes and are not to be construed as indicating or implying relative importance or order.

[0025] Figure 1 A flow chart of a method for detecting register transfer level code provided in an embodiment of the present application. Figure 1 As shown, the method includes the following steps.

[0026] Step S101: Determine the code maturity of the first register transfer level code according to the code maturity index.

[0027] Step S103: Based on the code maturity corresponding to each of the multiple chip development stages, determine the first chip development stage in the multiple chip development stages that matches the first register transfer level code, wherein the multiple chip development stages include at least a trial operation stage, a pre-acceptance stage and an acceptance stage, wherein the code maturity corresponding to the acceptance stage is one hundred percent.

[0028] Step S105: Determine whether the first chip development stage is the acceptance stage. If yes, execute step S107; if not, execute step S109.

[0029] Step S107: When the first chip development stage is the acceptance stage, a front-end design process quality inspection is performed on the first register transfer level code through a comprehensive verification tool according to the quality inspection items provided by the comprehensive verification tool.

[0030] Step S109: When the first chip development stage is not the acceptance stage, the comprehensive verification tool is configured according to the configuration environment input to obtain a configured comprehensive verification tool, and then, through the configured comprehensive verification tool, the first register transfer level code is subjected to quality inspection of the front-end design process according to the quality inspection items included in the fast quality inspection item set, wherein the configuration environment input is determined based on the first register transfer level code, and the fast quality inspection item set is obtained by deleting the first type of quality inspection items and extracting the second type of quality inspection items in the quality inspection items of the comprehensive verification tool, and the correlation between the first type of quality inspection items and the back-end design process is lower than the correlation between the second type of quality inspection items and the back-end design process.

[0031] Figure 1The method for checking register transfer level (RTL) code shown in this paper is applied to the front-end design phase of the chip development process. The chip development process can be divided into the specification definition phase, system design phase, front-end design phase, and back-end design phase. System-level design, such as determining the chip's functional requirements and module division, is completed during the specification definition and system design phases. Circuit logic design is completed during the front-end design phase, and the back-end design phase converts the design results from the front-end design phase into a physical layout. In the front-end design phase, hardware description language coding is used to describe the integrated circuit at multiple levels, typically at the advanced system and algorithm levels. Register transfer level (RTL) code is then described for the specific circuit to generate RTL code. Circuit logic functionality is then verified, and revisions are made based on the verification results. Finally, a synthesis verification tool is used to convert the RTL code into a gate-level netlist (GTL), also known as logic synthesis. The design results from the front-end design phase are converted into a chip netlist file, which is used to create the physical layout and perform verification in the back-end design phase. Therefore, during the front-end design phase, register transfer level (RTL) code is a key deliverable, transitioning from circuit logic design to gate-level netlist and then to physical layout. Simulation verification of the RTL code primarily involves verifying the circuit's logical functionality, such as by inputting stimulus signals and testing whether the output waveform conforms to the expected design. Generally, after converting the RTL code into a gate-level netlist through logic synthesis, the actual logical structure and connectivity relationships are obtained. Constraints on gate-level circuits, such as area, timing, and latency, also need to be considered. Static timing analysis is performed on the gate-level netlist to determine signal propagation delays, analyze clock quality, and verify whether the module meets pre-set constraints. Finally, at the end of the front-end design phase, code coverage and functional coverage are reviewed. The approved netlist is then delivered to the back-end design phase for physical layout fabrication and verification. It can be seen that after the register transfer level code is generated, the description phase of the current register transfer level code needs to be verified and repeatedly modified in terms of the circuit logic function. Then, in the subsequent logic synthesis step, static timing analysis of the netlist circuit is required. Then, in the back-end design phase, the physical layout needs to be verified. Therefore, after the generation of the register transfer level code, the subsequent phases need to be repeatedly verified and modified, and some problems found during testing need to be fed back to the description phase of the register transfer level code. The problems can only be solved by modifying the register transfer level code. For example, some problems found in the back-end design phase may need to be fed back to the front-end design phase. After the developers responsible for the front-end design phase make modifications, they can be delivered to the developers in the back-end design phase for subsequent development.Therefore, the overall chip development process may involve multiple iterations of development versions and a lot of communication and modification between the front-end design stage and the back-end design stage. This may cause a lot of waiting time costs, which is not conducive to improving chip development efficiency and shortening the chip development cycle. Figure 1 The method for detecting register transfer level code shown in the figure proposes an optimized design for quality detection of the description link of the register transfer level code in the front-end design stage, that is, quality detection after the register transfer level code is generated and before logic synthesis is performed. It also fully considers the needs of subsequent links in the overall chip development process, which is conducive to improving chip development efficiency and shortening the chip development cycle.

[0032] See Figure 1In step S101, the code maturity of the first register transfer level code is determined based on a code maturity index. In step S103, based on the code maturity corresponding to each of multiple chip development stages, the first chip development stage corresponding to the first register transfer level code is determined. The multiple chip development stages include at least a trial run stage, a pre-acceptance stage, and an acceptance stage, and the code maturity corresponding to the acceptance stage is 100%. Here, the code maturity index is used to assess the stage of the overall chip development project. Various dimensions of the overall chip development project can be evaluated using pre-set quantitative indicators to determine the code maturity of the first register transfer level code. The first register transfer level code is the register transfer level code that requires quality inspection during the description phase of the register transfer level code in the front-end design phase. In some embodiments, the code maturity index can be set from multiple perspectives. For example, a numerical value corresponding to 100% code maturity can be set first, and then different chip development stages can be defined based on the percentage of these numerical values ​​being met. For example, the multiple chip development stages can be set to include at least a trial run stage, a pre-final stage, and a final stage. Here, the code maturity corresponding to the acceptance phase is set to 100%. Then, by assessing whether the current code maturity of the overall chip development project reaches a certain percentage of the value corresponding to the acceptance phase, the first chip development phase corresponding to the first register transfer level code is determined. In some embodiments, the code maturity corresponding to the pilot phase can be set to approximately 40% to 60%, the code maturity corresponding to the pre-acceptance phase to approximately 85% to 95%, and the code maturity corresponding to the acceptance phase to 100%. Multiple chip development phases are intended to better assess the overall progress of the chip development project. Each of these phases has different priorities, which influences the focus of quality testing during the back-end design phase, and in turn, the focus of quality testing of the register transfer level code during the front-end design phase. For example, during the pilot phase, developers in the back-end design phase primarily perform floorplanning, such as placing inputs and outputs, memory, hardware macros, and planning grounding and power. For another example, during the pre-acceptance phase, developers in the back-end design phase have already largely finalized the inputs and outputs, memory, hardware macros, grounding, and power, allowing them to focus their work on other areas. Therefore, by determining the first chip development stage in the multiple chip development stages that matches the first register transfer level code, a basis is provided for subsequent quality inspection.In some embodiments, the code maturity indicators include functional correctness indicators, test completeness indicators, functional robustness indicators, and maintainability indicators, wherein the code maturity corresponding to each of the multiple chip development stages is determined based on the percentage of the code maturity indicators achieved by each of the multiple chip development stages. In some examples, the functional correctness indicators include whether the functional points required by the chip specification (spec) are implemented and the simulation verification pass rate; the test completeness indicators include the requirement coverage rate, code coverage rate, and functional coverage rate of the test cases for all functional points of the chip specification; the functional robustness indicators include cross-clock domain processing mechanism, abnormal self-recovery capability, and static check pass rate; the maintainability indicators include modular design, complete comments, consistent style, and parameterized design. Functional robustness indicators include static detection code quality.

[0033] Continue reading Figure 1In step S105, it is determined whether the first chip development stage is the acceptance stage. If so, step S107 is executed; if not, step S109 is executed. In step S107, when the first chip development stage is the acceptance stage, a comprehensive verification tool is used to perform a quality check of the front-end design process on the first register transfer level code according to the quality check items provided by the comprehensive verification tool. In step S109, when the first chip development stage is not the acceptance stage, the comprehensive verification tool is configured according to the configuration environment input to obtain a configured comprehensive verification tool. Then, the configured comprehensive verification tool is used to perform a quality check of the front-end design process on the first register transfer level code according to the quality check items included in a fast quality check item set, wherein the configuration environment input is determined based on the first register transfer level code, and the fast quality check item set is obtained by deleting a first category of quality check items and extracting a second category of quality check items from the quality check items provided by the comprehensive verification tool, wherein the correlation between the first category of quality check items and the back-end design process is lower than the correlation between the second category of quality check items and the back-end design process. In this manner, based on determining the first chip development stage among the multiple chip development stages that matches the first register transfer-level code, two quality inspection paths are selected based on whether the first chip development stage is the acceptance stage. Specifically, the appropriate quality inspection path is selected based on the progress of the overall chip development project and the chip development stage, thereby ensuring the completeness and correctness of simulation verification while also improving verification efficiency. Here, when the first chip development stage is the acceptance stage, it means that the overall chip development project has reached the acceptance stage, corresponding to 100% code maturity. This means that comprehensive quality inspection is required to meet the requirements of subsequent logic synthesis and back-end design stages. Therefore, when the first chip development stage is the acceptance stage, the first register transfer-level code is subjected to front-end design flow quality inspection using a comprehensive verification tool, according to the quality inspection items provided by the comprehensive verification tool. Here, the comprehensive verification tool can be a logic synthesis tool or application provided by an Electronic Design Automation (EDA) platform or service provider. The quality inspection projects provided by the comprehensive verification tool are managed and maintained in a relatively independent environment. These rule files define the checkpoints where quality inspection is required. Users can add custom verification rules through commands.Conversely, when the first chip development stage is not the acceptance stage, the integrated verification tool is configured according to the configuration environment input to obtain a configured integrated verification tool. Then, using the configured integrated verification tool, the first register transfer-level code is quality-checked according to the quality inspection items included in the rapid quality inspection item set. Here, the integrated verification tool's built-in quality inspection items are utilized. The rapid quality inspection item set is obtained by deleting the first category of quality inspection items and extracting the second category of quality inspection items from the integrated verification tool's built-in quality inspection items. Therefore, the coverage of the rapid quality inspection item set is smaller than the coverage of the integrated verification tool's built-in quality inspection items because at least the first category of quality inspection items has been deleted. Thus, two quality inspection paths are provided: a conventional path, which performs front-end design flow quality inspection on the first register transfer-level code according to the built-in quality inspection items of the integrated verification tool. The other is a rapid iterative path, which performs front-end design flow quality inspection on the first register transfer-level code according to the quality inspection items included in the rapid quality inspection item set. Moreover, the correlation between the first type of quality inspection items and the back-end design process is lower than the correlation between the second type of quality inspection items and the back-end design process. Therefore, the first type of quality inspection items with lower correlation can be deleted, and the second type of quality inspection items with higher correlation can be extracted as the detection points of the fast iteration path. It should be understood that if the overall chip development project is already in the acceptance stage, that is, when the first chip development stage is the acceptance stage, then both the first type of quality inspection items and the second type of quality inspection items need to be tested and rule filtered. Only when all rules are met can the logic synthesis and back-end design stages be entered. Therefore, by distinguishing the first type of quality inspection items with lower correlation and the second type of quality inspection items with higher correlation, and skipping the first type of quality inspection items with lower correlation, a fast iteration path is added on the basis of the conventional path, which can conveniently perform quality inspection on the detection points in the fast quality inspection project set and quickly generate a netlist file for the back-end design stage.

[0034] Continue reading Figure 1If the distinction between the less relevant first-category quality check items and the more relevant second-category quality check items is not made, the conventional path requires filtering all rules, and logic synthesis and the back-end design phase are performed only after all rules are met. This results in a serial development sequence between the front-end and back-end design phases. In other words, developers in the back-end design phase must wait for the front-end design phase to complete all quality checks within the synthesis verification tool before proceeding to the next step. However, after register transfer level (RTL) code generation, the circuit logic functionality needs to be verified and repeatedly modified during the current RTL code description phase. Subsequently, static timing analysis of the netlist circuit is performed in the subsequent logic synthesis step, and finally, the physical layout needs to be verified during the back-end design phase. Therefore, repeated verification and modification are required in subsequent phases after register transfer level code generation. Some issues discovered during verification need to be fed back to the RTL code description phase and resolved through RTL code modifications. For large-scale chip development projects, each comprehensive and complete test requires a lot of time to make modifications, and generally takes days or weeks to iterate. During this period, developers in the back-end design stage can only wait for the completion of the comprehensive test of the register transfer level code, which makes the quality test of the register transfer level code block the back-end design stage. Figure 1 The method for detecting register transfer level code shown in the figure distinguishes between the first type of quality detection items with lower correlation and the second type of quality detection items with higher correlation, and skips the first type of quality detection items with lower correlation. In this way, a fast iteration path is added on the basis of the conventional path, which can conveniently perform quality detection on the detection points in the fast quality detection item set and quickly generate a netlist file for the back-end design stage. For example, developers in the front-end design stage can quickly perform quality detection on a certain quality detection item in the fast quality detection item set of the first register transfer level code by executing a command, so as to quickly determine whether the delivery standard of the back-end design stage is met, so as to quickly locate the register transfer level code problems and make modifications without waiting for the completion of the comprehensive detection of the register transfer level code. This means that using Figure 1The method for detecting register transfer level code shown helps to achieve parallel development between the front-end design stage and the back-end design stage, that is, it avoids the blocking problem caused by the serial relationship in the development timing. Furthermore, the first type of quality inspection items with lower correlation and the second type of quality inspection items with higher correlation can be distinguished according to whether the back-end design process is blocked. In some embodiments, the failure result of the first type of quality inspection item does not block the execution of the back-end design process, and the failure result of the second type of quality inspection item blocks the execution of the back-end design process. In some embodiments, the correction work associated with the failure result of the first type of quality inspection item in the front-end design process is carried out synchronously with the execution of the back-end design process, and the correction work associated with the failure result of the second type of quality inspection item in the front-end design process is carried out serially with the execution of the back-end design process. In this way, based on the distinction between the first type of quality inspection projects with lower correlation and the second type of quality inspection projects with higher correlation, the quality inspection projects with lower correlation can be developed and modified synchronously in the front-end design stage and the back-end design stage. Because the failure results of these projects will not hinder the execution of the back-end design process, synchronous development will not affect the code quality. For the quality inspection projects with higher correlation, the serial relationship in development timing is still maintained, thus ensuring the code quality. In addition, according to the progress of the overall chip development project and the chip development stage it is in, the appropriate quality inspection path is selected, thereby ensuring the completeness and correctness of the simulation verification while also improving the verification efficiency.

[0035] Continue reading Figure 1When the first chip development phase is not the acceptance phase, the integrated verification tool is configured according to the configuration environment input to obtain a configured integrated verification tool. Because the quality testing of the conventional path provided by the integrated verification tool is skipped, the integrated verification tool needs to be configured according to the configuration environment input to meet the quality testing requirements of the fast iteration path. In some embodiments, the configuration environment input includes: a delivered version of the first register transfer level code, a list of modules and top levels of the first register transfer level code, a library of the first register transfer level code, parameter and macro definitions of the first register transfer level code, a file list of the first register transfer level code, and the module type of the first register transfer level code. Thus, by configuring the integrated verification tool to obtain a configured integrated verification tool, the RTL can be read, compiled, and linked. The RTL compilation results are then tested according to the test points in the input fast quality test item set. If the result passes, the result can be delivered to the logic synthesis step. If it fails, the result can be returned to the RTL description stage for code modification. In some embodiments, the first category of quality checks includes: checking for different timescales used to set simulation time units and simulation time accuracy, checking for undriven output ports, and checking for the use of clock signals as data signals. Even if detected, these first category quality checks will not affect subsequent processes and will not hinder the back-end design process. In some embodiments, the second category of quality checks includes: checking for floating inputs, undriven nets, latches, and width mismatches between module ports. An undriven input, also known as a floating input, refers to an input pin that has no load, for example, neither a high nor a low state. An undriven net refers to an undriven metal line, such as an unconnected internal connection or a lack of driver for an input or output port. Bandwidth mismatch refers to a module port's bandwidth being different from the module's internally defined bandwidth, for example, if the data bit width is different, such as 10 bits for one and 12 bits for another. Alignment can be achieved through automatic zero padding, but data loss may occur when transmitting data from a higher bit width to a lower bit width.Examples of the second category of quality inspection items affect multiple aspects, such as layout and routing, clock tree synthesis, performance, power consumption, and area, and therefore have a significant impact on the accuracy of evaluation results. Therefore, we can extract the second category of quality inspection items and then use scripts to automatically detect whether these issues exist in the RTL. If so, errors and warnings will be reported, prompting users to quickly identify the problems and return to modify the code.

[0036] In short, Figure 1 A method for testing register transfer level code is shown, which utilizes the quality inspection items provided by the comprehensive verification tool. By deleting the first type of quality inspection items and extracting the second type of quality inspection items in the quality inspection items provided by the comprehensive verification tool, the fast quality inspection item set is obtained. By distinguishing the first type of quality inspection items with lower correlation from the second type of quality inspection items with higher correlation and skipping the first type of quality inspection items with lower correlation, a fast iteration path is added on the basis of the conventional path, which can conveniently perform quality inspection on the inspection points in the fast quality inspection item set and quickly generate a netlist file for the back-end design stage. The method helps to achieve parallel development between the front-end design stage and the back-end design stage, fully considers the needs of subsequent links in the overall chip development process, and is conducive to improving chip development efficiency and shortening the chip development cycle. In addition, according to the progress of the overall chip development project and the chip development stage, an appropriate quality inspection path is selected, thereby ensuring the completeness and correctness of the simulation verification while also improving the verification efficiency.

[0037] Figure 2 A reference provided for the embodiments of this application Figure 1 The schematic diagram of the front-end design process of the method for detecting register transfer level code is shown in FIG. Figure 2 As shown, reference Figure 1 The method for detecting register transfer level code shown in the figure, the improved front-end design process includes the following steps.

[0038] Step S201: Start hardware description language encoding.

[0039] Step S203: performing register transfer level code description to obtain a first register transfer level code.

[0040] Step S205: Select a quality detection path based on the code maturity of the first register transfer level code. Figure 1 The method for detecting register transfer level code shown may select a conventional path, ie, step S210 , or may select a fast iteration path, ie, step S220 .

[0041] Step S210: Using a comprehensive verification tool, and in accordance with the quality inspection items provided by the comprehensive verification tool, the first register transfer level code is subjected to a quality inspection of the front-end design process. Step S210 corresponds to a conventional path.

[0042] Step S220: The integrated verification tool is configured according to the configuration environment input to obtain a configured integrated verification tool. The configured integrated verification tool then performs a front-end design flow quality check on the first register transfer level code according to the quality check items included in the fast quality check item set. Step S220 corresponds to the fast iteration path.

[0043] Step S230: Determine whether the quality test has passed. If an error is found in the quality test of step S210 or step S220, it means that the judgment of step S230 is no, and step S234 is executed. If no error is found in the quality test of step S210 or step S220, it means that the judgment of step S230 is yes, and step S232 is executed.

[0044] Step S232: Perform logic synthesis.

[0045] Step S234: Modify the first register transfer level code.

[0046] Figure 2 A reference shown Figure 1 The front-end design process of the method for testing register transfer level code shown in the figure distinguishes between the first-category quality test items with lower correlation and the second-category quality test items with higher correlation, and skips the first-category quality test items with lower correlation. In this way, a fast iteration path is added on the basis of the conventional path, which can conveniently perform quality test on the test points in the fast quality test item set and quickly generate a netlist file for the back-end design stage. For example, developers in the front-end design stage can quickly perform quality test on a certain quality test item in the fast quality test item set of the first register transfer level code by executing a command, so as to quickly determine whether the delivery standard of the back-end design stage is met, so as to quickly locate the register transfer level code problems and make modifications without waiting for the completion of the comprehensive test of the register transfer level code. This means that using Figure 1The method for detecting register transfer level code shown helps to achieve parallel development between the front-end design stage and the back-end design stage, that is, it avoids the blocking problem caused by the serial relationship in the development timing. Furthermore, the first type of quality inspection items with lower correlation and the second type of quality inspection items with higher correlation can be distinguished according to whether the back-end design process is blocked. In some embodiments, the failure result of the first type of quality inspection item does not block the execution of the back-end design process, and the failure result of the second type of quality inspection item blocks the execution of the back-end design process. In some embodiments, the correction work associated with the failure result of the first type of quality inspection item in the front-end design process is carried out synchronously with the execution of the back-end design process, and the correction work associated with the failure result of the second type of quality inspection item in the front-end design process is carried out serially with the execution of the back-end design process. In this way, based on the distinction between the first type of quality inspection projects with lower correlation and the second type of quality inspection projects with higher correlation, the quality inspection projects with lower correlation can be developed and modified synchronously in the front-end design stage and the back-end design stage. Because the failure results of these projects will not hinder the execution of the back-end design process, synchronous development will not affect the code quality. For the quality inspection projects with higher correlation, the serial relationship in development timing is still maintained, thus ensuring the code quality. In addition, according to the progress of the overall chip development project and the chip development stage it is in, the appropriate quality inspection path is selected, thereby ensuring the completeness and correctness of the simulation verification while also improving the verification efficiency.

[0047] Figure 3 A reference provided for the embodiments of this application Figure 1 The schematic diagram of the chip development process of the method for detecting register transfer level code is shown in FIG. Figure 3As shown, in the front-end design phase 303, according to the development sequence 301, the front-end design node 330 associated with the second-type quality inspection project A 320, the front-end design node 332 associated with the second-type quality inspection project B 322, the front-end design node 334 associated with the first-type quality inspection project A 310, and the front-end design node 336 associated with the first-type quality inspection project B 312 are sequentially performed. In the back-end design phase 305, according to the development sequence 301, the back-end design node 340 associated with the first-type quality inspection project A 310, the back-end design node 342 associated with the first-type quality inspection project B 312, the back-end design node 344 associated with the second-type quality inspection project A 320, and the back-end design node 346 associated with the second-type quality inspection project B 322 are sequentially performed. In this way, on the basis of distinguishing the first type of quality inspection projects with lower correlation and the second type of quality inspection projects with higher correlation, the front-end design stage and the back-end design stage can be selected to synchronously develop and modify the quality inspection projects with lower correlation, because the failure results of these projects will not hinder the execution of the back-end design process, so synchronous development will not affect the code quality, and for the quality inspection projects with higher correlation, the serial relationship in the development timing is still maintained, thus ensuring the code quality. In addition, according to the progress of the overall chip development project and the chip development stage it is in, the appropriate quality inspection path is selected, thereby ensuring the completeness and correctness of the simulation verification while also improving the verification efficiency. Figure 3For example, because the first-category quality inspection project A310 and the first-category quality inspection project B312 belong to the first-category quality inspection project, this means that the developer in the front-end design phase can quickly perform a quality inspection on the first register transfer level code for a quality inspection project in the quick quality inspection project set by executing a command, thereby quickly determining whether the delivery standard of the back-end design phase has been met, so that the register transfer level code problem can be quickly located and modified without waiting for the full inspection of the register transfer level code to be completed. In this way, it is helpful to achieve parallel development between the front-end design phase and the back-end design phase, that is, to avoid the blocking problem caused by the serial relationship in the development timing. In contrast, the second-category quality inspection project A320 and the second-category quality inspection project B322 belong to the second-category quality inspection project. Therefore, only after the relevant work of the front-end design phase 303 is completed can the relevant work of the back-end design phase 305 be started. In summary, by distinguishing between the first-category quality inspection items with lower correlation and the second-category quality inspection items with higher correlation, and skipping the first-category quality inspection items with lower correlation, a fast iteration path is added on the basis of the conventional path, which can conveniently perform quality inspection on the inspection points in the fast quality inspection item set, and quickly generate a netlist file for the back-end design stage; it helps to achieve parallel development between the front-end design stage and the back-end design stage, fully considering the needs of subsequent links in the overall chip development process, and is conducive to improving chip development efficiency and shortening the chip development cycle. In addition, according to the progress of the overall chip development project and the chip development stage, the appropriate quality inspection path is selected, thereby ensuring the completeness and correctness of the simulation verification while also improving the verification efficiency.

[0048] See Figure 1 、 Figure 2 and Figure 3 In a possible implementation, the failure results of the first-category quality inspection items do not block the execution of the back-end design process, and the failure results of the second-category quality inspection items do block the execution of the back-end design process. In this way, on the basis of distinguishing the first-category quality inspection items with lower correlation and the second-category quality inspection items with higher correlation, the front-end design stage and the back-end design stage can be selected to synchronously develop and modify the quality inspection items with lower correlation, because the failure results of these items will not hinder the execution of the back-end design process, so the synchronous development will not affect the code quality, and the serial relationship in the development timing of the quality inspection items with higher correlation is still maintained, thus ensuring the code quality. In addition, according to the progress of the overall chip development project and the chip development stage, the appropriate quality inspection path is selected, thereby ensuring the completeness and correctness of the simulation verification while also improving the verification efficiency.

[0049] In some embodiments, the correction work associated with the failure results of the first type of quality inspection items in the front-end design process is performed synchronously with the execution of the back-end design process, and the correction work associated with the failure results of the second type of quality inspection items in the front-end design process is performed serially with the execution of the back-end design process. In this way, by distinguishing the first type of quality inspection items with lower correlation from the second type of quality inspection items with higher correlation, and skipping the first type of quality inspection items with lower correlation, a fast iteration path is added on the basis of the conventional path, which can conveniently perform quality inspection on the inspection points in the fast quality inspection item set and quickly generate a netlist file for the back-end design stage; it helps to achieve parallel development between the front-end design stage and the back-end design stage, fully considers the needs of subsequent links in the overall chip development process, is conducive to improving chip development efficiency and shortening the chip development cycle, and selects an appropriate quality inspection path according to the progress of the overall chip development project and the chip development stage, thereby ensuring the completeness and correctness of the simulation verification while also improving the verification efficiency.

[0050] In a possible embodiment, the first type of quality inspection items include: detecting whether there are different time scales for setting simulation time units and simulation time accuracy, detecting whether there are undriven output ports, and detecting whether a clock signal is used as a data signal. In this way, the example of the first type of quality inspection items, even if it is detected to exist, will not affect the subsequent process, and will not hinder the back-end design process. By distinguishing the first type of quality inspection items with lower correlation and the second type of quality inspection items with higher correlation, and skipping the first type of quality inspection items with lower correlation, a fast iteration path is added on the basis of the conventional path, which can conveniently perform quality inspection on the inspection points in the fast quality inspection item set, and quickly generate a netlist file for the back-end design stage.

[0051] In some embodiments, the second category of quality inspection items includes: detecting whether there are input pins without loaded inputs, detecting whether there are netlists without drivers, detecting whether there are latches, and detecting whether the connection bandwidth of the module port is different from the bandwidth defined inside the module. In this way, examples of the second category of quality inspection items affect multiple aspects, such as layout and routing, clock tree synthesis, performance, power consumption, area, etc., and therefore have a significant impact on the accuracy of the evaluation results. To this end, the second category of quality inspection items can be extracted, and then the RTL can be automatically detected to see if these problems exist in the form of a script. If so, errors and warnings will be reported to remind users to quickly identify the problem and return to modify the code.

[0052] In one possible embodiment, the quality inspection items provided by the integrated verification tool include third-category quality inspection items, the integrated verification tool provides harmless processing suggestions for the failure results of the third-category quality inspection items, the rapid quality inspection item set extracts and updates the third-category quality inspection items included in the quality inspection items provided by the integrated verification tool to obtain updated third-category quality inspection items, and the integrated verification tool provides correction processing suggestions for the failure results of the updated third-category quality inspection items. As mentioned above, by distinguishing between the first-category quality inspection items with lower correlation and the second-category quality inspection items with higher correlation, and skipping the first-category quality inspection items with lower correlation, a rapid iteration path is added on the basis of the conventional path, which can conveniently perform quality inspection on the inspection points in the rapid quality inspection item set and quickly generate a netlist file for the back-end design stage. Furthermore, the quality control items included with the integrated verification tool are primarily targeted at situations where code maturity reaches 100%, i.e., the acceptance phase. Because quality control begins late in the front-end design phase, some issues discovered during testing may require significant RTL code modifications if addressed. However, these issues can be mitigated to ensure the execution of subsequent logic synthesis and back-end design processes. Therefore, for these third-category quality control items, the integrated verification tool provides mitigation suggestions for failed results. This ensures RTL code delivery without requiring significant RTL code modifications. The rapid quality control item set targets situations in the first chip development phase, not the acceptance phase. Therefore, quality control can be initiated early in the front-end design phase. At this time, detected failures in third-category quality control items can be resolved without requiring significant RTL code modifications. This approach differs from providing mitigation suggestions for failed results in third-category quality control items by detecting updated third-category quality control items and providing corrective action suggestions for these updated third-category quality control items. In this way, according to the progress of the overall chip development project and the chip development stage it is in, the appropriate quality inspection path is selected, and the updated third-category quality inspection items and the feedback and correction processing suggestions for the failed results of the updated third-category quality inspection items are selected on the fast iteration path. This will help to solve the problems of the third-category quality inspection items as soon as possible and improve chip quality.

[0053] In some embodiments, the third category of quality checks includes detecting the presence of empty modules (missing module definitions or signal declarations), and detecting the presence of black box modules (with unknown internal logic definitions). As mentioned above, the quality checks included with the integrated verification tool primarily target code maturity reaching 100%, i.e., the acceptance phase. Because quality checks begin late in the front-end design phase, some issues discovered during testing may require significant RTL code modifications if corrected. However, these issues can be mitigated to ensure the success of subsequent logic synthesis and back-end design processes. Here, an empty module refers to a module that should not exist in the physical design. For example, a missing module definition or signal declaration may indicate a lack of internal logic content, such as wiring, inputs, or outputs. When an empty module is detected, filling in the missing logic content may require significant RTL code modifications. Therefore, the integrated verification tool provides mitigation suggestions for failed results in the third category of quality checks, such as for empty modules. A black box module is one whose internal logic definition is unknown, such as a missing RTL module that provides this internal logic definition. A black box module typically consists of only input and output ports and can be integrated with other modules or incorporated into a larger system design. When a black box module is detected, analyzing its internal logic definition may involve parsing and modifying the RTL code. Therefore, comprehensive verification tools provide mitigation recommendations for failed results for the third quality check item, exemplified by black box modules. However, during circuit logic design, the presence of empty or black box modules may be intentional, but developers may forget to add or update them later. These empty or black box modules may also provide redundant circuitry or backup resources. Therefore, mitigation measures, such as removing them from the RTL code or isolating them to avoid impacting the operation of key systems and core circuits, ensure the correctness of the delivered RTL code. However, this approach negates the beneficial effects of thorough error correction for these empty or black box modules, exemplified by the third quality check item, such as enhanced system robustness and the provision of redundant circuitry and backup resources.To this end, the rapid quality inspection project set is to extract and update the third-category quality inspection items included in the quality inspection items that come with the comprehensive verification tool to obtain the updated third-category quality inspection items. In this way, a rapid iteration path is added on the basis of the conventional path. According to the progress of the overall chip development project and the chip development stage it is in, the appropriate quality inspection path is selected. In addition, the updated third-category quality inspection items are selected on the rapid iteration path, and the failure results of the updated third-category quality inspection items are fed back and correction processing suggestions are given. This means that in the early stage of the overall chip development project, the existence of empty modules and black box modules can be discovered as early as possible without making major modifications to the RTL code, so that corresponding measures can be taken, which helps to enhance the robustness of the system and provide redundant circuits and backup resources.

[0054] In some embodiments, the harmless processing suggestion is to remove or not process the empty module and the black box module, and the corrective processing suggestion is to add module definitions and signal declarations to the empty module and add internal logic definitions to the black box module. In this way, based on the progress of the overall chip development project and the chip development stage it is in, an appropriate quality inspection path is selected, and on the fast iteration path, the updated third-category quality inspection items are selected and corrective processing suggestions are fed back for the failed results of the updated third-category quality inspection items. This is conducive to resolving problems with the third-category quality inspection items as soon as possible and improving chip quality.

[0055] In a possible implementation, the configuration environment input includes: a delivered version of the first register transfer level code, a list of modules and top levels of the first register transfer level code, a library of the first register transfer level code, definitions of parameters and macros of the first register transfer level code, a file list of the first register transfer level code, and a module type of the first register transfer level code. In this way, because the quality inspection of the conventional path provided by the comprehensive verification tool is skipped, it is necessary to configure the comprehensive verification tool according to the configuration environment input to meet the quality inspection needs of the fast iteration path. By configuring the comprehensive verification tool to obtain a configured comprehensive verification tool, the RTL can be read, the RTL can be compiled and linked, and then the RTL compilation results can be inspected according to the inspection points in the input fast quality inspection project set. If it passes, it can be delivered to the logic synthesis step. If it fails, it can return to the RTL description link to modify the code.

[0056] In one possible implementation, the code maturity level in the pilot phase is 40% to 60%, and the code maturity level in the pre-acceptance phase is 85% to 95%. Thus, code maturity indicators can be set from multiple perspectives. For example, a value corresponding to 100% code maturity can be set, and then different chip development stages can be defined based on a certain percentage of these values ​​being met.

[0057] In one possible implementation, the code maturity indicators include a functional correctness indicator, a test completeness indicator, a functional robustness indicator, and a maintainability indicator. The code maturity corresponding to each of the multiple chip development stages is determined based on the percentage of the code maturity indicators achieved by each of the multiple chip development stages. In this way, an appropriate quality inspection path is selected based on the overall chip development project progress and the chip development stage, thereby ensuring the completeness and correctness of simulation verification while also improving verification efficiency.

[0058] In some embodiments, the functional correctness indicators include whether the functional points required by the chip specifications are realized and the simulation verification pass rate; the test completeness indicators include the test case requirement coverage, code coverage, and function coverage for all functional points of the chip specifications; the functional robustness indicators include cross-clock domain processing mechanism, abnormal self-recovery capability, and static inspection pass rate; the maintainability indicators include modular design, complete annotations, consistent style, and parameterized design. In this way, multiple chip development stages are intended to better evaluate the development progress of the overall chip development project. Multiple chip development stages also have different work focuses, which affects the focus of quality inspection in the back-end design stage, and in turn affects the focus of quality inspection of register transfer level code in the front-end design stage.

[0059] In a possible implementation, the rapid quality inspection project set is managed and maintained independently, thereby achieving separate project management and improving efficiency.

[0060] Figure 44 is a structural diagram of a computing device provided in an embodiment of the present application, wherein the computing device 400 includes: one or more processors 410, a communication interface 420, and a memory 430. The processor 410, the communication interface 420, and the memory 430 are interconnected via a bus 440. Optionally, the computing device 400 may further include an input / output interface 450, the input / output interface 450 being connected to an input / output device for receiving parameters set by a user, etc. The computing device 400 can be used to implement some or all of the functions of the device embodiment or the system embodiment in the above-mentioned embodiment of the present application; the processor 410 can also be used to implement some or all of the operating steps of the method embodiment in the above-mentioned embodiment of the present application. For example, the specific implementation of the various operations performed by the computing device 400 can refer to the specific details in the above-mentioned embodiments, such as the processor 410 is used to perform some or all of the steps in the above-mentioned method embodiment or some or all of the operations in the above-mentioned method embodiment. For another example, in an embodiment of the present application, the computing device 400 may be used to implement part or all of the functions of one or more components in the above-mentioned apparatus embodiment. In addition, the communication interface 420 may be specifically used to perform the communication functions necessary to implement the functions of these apparatuses and components, and the processor 410 may be specifically used to perform the processing functions necessary to implement the functions of these apparatuses and components.

[0061] It should be understood that Figure 4 The computing device 400 may include one or more processors 410, and the multiple processors 410 may be connected in parallel, serially, serially, or in parallel with each other, or in any other manner to collaboratively provide processing capabilities. Alternatively, the multiple processors 410 may form a processor sequence or a processor array, or the multiple processors 410 may be divided into a main processor and an auxiliary processor, or the multiple processors 410 may have different architectures, such as a heterogeneous computing architecture. In addition, Figure 4 The computing device 400 shown, and the related structural and functional descriptions are exemplary and non-limiting. In some exemplary embodiments, the computing device 400 may include Figure 4 More or fewer components may be shown, some components may be combined, some components may be separated, or there may be a different arrangement of components.

[0062] Processor 410 can have various specific implementation forms. For example, processor 410 can include a central processing unit (CPU), a graphics processing unit (GPU), a neural-network processing unit (NPU), a tensor processing unit (TPU), or a data processing unit (DPU), among others, and this is not specifically limited in the embodiments of the present application. Processor 410 can also be a single-core processor or a multi-core processor. Processor 410 can be a combination of a CPU and a hardware chip. The hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. Processor 410 can also be implemented solely using a logic device with built-in processing logic, such as an FPGA or a digital signal processor (DSP). The communication interface 420 may be a wired interface or a wireless interface for communicating with other modules or devices. The wired interface may be an Ethernet interface, a local interconnect network (LIN), etc. The wireless interface may be a cellular network interface or a wireless local area network interface, etc.

[0063] Memory 430 may be a non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 430 may also be a volatile memory, which may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). The memory 430 may also be used to store program codes and data, so that the processor 410 can call the program codes stored in the memory 430 to execute part or all of the operation steps in the above method embodiment, or to execute the corresponding functions in the above device embodiment. Figure 4 Show more or fewer components, or configure components differently.

[0064] The bus 440 may be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (UBus or UB), a Compute Express Link (CXL), a Cache Coherent Interconnect for Accelerators (CCIX), etc. The bus 440 may be divided into an address bus, a data bus, a control bus, etc. In addition to the data bus, the bus 440 may also include a power bus, a control bus, and a status signal bus. However, for the sake of clarity, Figure 4 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0065] The methods and devices provided in the embodiments of the present application are based on the same inventive concept. Since the principles of the methods and devices for solving problems are similar, the embodiments, implementation methods, examples or implementation methods of the methods and devices can refer to each other, and the repeated parts will not be repeated. The embodiments of the present application also provide a system, which includes multiple computing devices, and the structure of each computing device can refer to the structure of the computing device described above. The functions or operations that can be implemented by the system can refer to the specific implementation steps in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be repeated here.

[0066] The present application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on a computer device (e.g., one or more processors), the method steps described in the above method embodiments can be implemented. The specific implementation of the above method steps by the processor of the computer-readable storage medium can refer to the specific operations described in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be further described here.

[0067] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. The present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. The embodiments of the present application may be implemented in whole or in part via software, hardware, firmware, or any other combination. When implemented using software, the above embodiments may be implemented in whole or in part as a computer program product. The present application may take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The computer program product comprises one or more computer instructions. When loaded or executed on a computer, the computer program instructions fully or partially perform the processes or functions described in the embodiments of the present application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. Computer-readable storage media can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that contains a collection of one or more available media. Available media can be magnetic media (such as floppy disks, hard disks, or magnetic tape), optical media, or semiconductor media. Semiconductor media can be solid-state drives, random access memory, flash memory, read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, or any other suitable storage medium.

[0068] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. Each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including the instruction device, which implements the function specified in the process. Figure 1a process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0069] In the above embodiments, the descriptions of each embodiment have different emphases. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. Obviously, those skilled in the art can make various changes and modifications to the embodiments of the present application without departing from the spirit and scope of the embodiments of the present application. The steps in the method of the embodiment of the present application can be adjusted in sequence, merged or deleted according to actual needs; the modules in the system of the embodiment of the present application can be divided, merged or deleted according to actual needs. If these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these modifications and variations.

Claims

1. A method for detecting register transfer level code, characterized in that: The method comprises: determining a code maturity of the first register transfer level code according to a code maturity indicator; Determining, based on code maturity levels corresponding to respective multiple chip development stages, a first chip development stage among the multiple chip development stages that matches the first register transfer level code, wherein the multiple chip development stages include at least a trial operation stage, a pre-acceptance stage, and an acceptance stage, wherein the code maturity level corresponding to the acceptance stage is 100%; When the first chip development stage is the acceptance stage, performing a quality inspection of the front-end design process on the first register transfer level code using a comprehensive verification tool according to the quality inspection items provided by the comprehensive verification tool; When the first chip development stage is not the acceptance stage, the comprehensive verification tool is configured according to the configuration environment input to obtain a configured comprehensive verification tool. Then, through the configured comprehensive verification tool, the first register transfer level code is subjected to quality inspection of the front-end design process according to the quality inspection items included in the fast quality inspection item set, wherein the configuration environment input is determined based on the first register transfer level code, the fast quality inspection item set is obtained by deleting the first type of quality inspection items and extracting the second type of quality inspection items from the quality inspection items provided by the comprehensive verification tool, and the correlation between the first type of quality inspection items and the back-end design process is lower than the correlation between the second type of quality inspection items and the back-end design process.

2. The method according to claim 1, characterized in that The failure result of the first type of quality inspection items does not block the execution of the back-end design process, and the failure result of the second type of quality inspection items blocks the execution of the back-end design process.

3. The method according to claim 2, characterized in that The correction work associated with the failure results of the first type of quality inspection items in the front-end design process is carried out synchronously with the execution of the back-end design process, and the correction work associated with the failure results of the second type of quality inspection items in the front-end design process is carried out serially with the execution of the back-end design process.

4. The method according to claim 1, wherein The first type of quality inspection items include: detecting whether there are different time scales for setting simulation time units and simulation time accuracy, detecting whether there are undriven output ports, and detecting whether a clock signal is used as a data signal.

5. The method according to claim 4, characterized in that The second type of quality inspection items include: detecting whether there are input pins without loaded inputs, detecting whether there are undriven netlists, detecting whether there are latches, and detecting whether the connection bandwidth of the module port is different from the bandwidth defined inside the module.

6. The method according to claim 1, characterized in that The quality inspection items provided by the comprehensive verification tool include third-category quality inspection items. The comprehensive verification tool provides feedback on harmless processing suggestions for the failure results of the third-category quality inspection items. The rapid quality inspection item set extracts and updates the third-category quality inspection items included in the quality inspection items provided by the comprehensive verification tool to obtain updated third-category quality inspection items. In addition, the comprehensive verification tool provides feedback on corrective processing suggestions for the failure results of the updated third-category quality inspection items.

7. The method according to claim 6, characterized in that The third category of quality inspection items includes: detecting whether there are empty modules that are missing module definitions or signal declarations, and detecting whether there are black box modules whose internal logic definitions are unknown.

8. The method according to claim 7, characterized in that The harmless processing suggestion is to remove or not process the empty module and the black box module, and the correction processing suggestion is to add module definition and signal declaration to the empty module and add internal logic definition to the black box module.

9. The method according to claim 1, characterized in that The configuration environment input includes: a delivered version of the first register transfer level code, a list of modules and top levels of the first register transfer level code, a library of the first register transfer level code, definitions of parameters and macros of the first register transfer level code, a file list of the first register transfer level code, and a module type of the first register transfer level code.

10. The method according to claim 1, characterized in that The code maturity level in the trial operation phase is 40% to 60%, and the code maturity level in the pre-acceptance phase is 85% to 95%.

11. The method according to claim 1, wherein The code maturity indicators include a functional correctness indicator, a test completeness indicator, a functional robustness indicator, and a maintainability indicator, wherein the code maturity corresponding to each of the multiple chip development stages is determined based on the percentage of the code maturity indicators achieved by each of the multiple chip development stages.

12. The method according to claim 11, characterized in that The functional correctness indicators include whether the functional points required by the chip specifications are realized and the simulation verification pass rate; the test completeness indicators include the test case requirement coverage, code coverage, and function coverage of all functional points of the chip specifications; the functional robustness indicators include cross-clock domain processing mechanism, abnormal self-recovery capability, and static check pass rate; the maintainability indicators include modular design, complete annotations, consistent style, and parameterized design.

13. The method according to claim 1, wherein The rapid quality inspection item set is independently managed and maintained.

14. An electronic device, characterized in that: The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 13 when executing the computer program.

15. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, which, when executed on a computer device, cause the computer device to perform the method according to any one of claims 1 to 13.

Images