Defect analysis method, related device and readable storage medium

Abstract

The application provides a defect analysis method, related equipment and a readable storage medium, and relates to the technical field of computers. The method is applied to a server, and the method comprises the following steps: acquiring defect information corresponding to target chip design code; wherein the defect information corresponding to the target chip design code comprises at least one of the discovery level of a target defect, reproduction information corresponding to the target defect, the number of times that the target defect occurs, and the stage at which the target defect is discovered; and performing first processing based on the defect information corresponding to the target chip design code. According to the embodiments of the application, different first processing can be performed according to different defect information of the target chip design code, comprehensive analysis of the target defect in the target chip design code can be implemented, the defect analysis efficiency can be effectively improved, and the development efficiency of the chip design code can be improved.

Description

[0001] This application is a divisional application of application number 202210910403.4, filed on July 29, 2022, entitled "Project Management Method, Defect Analysis Method, Related Equipment and Readable Storage Medium". Technical Field

[0002] This application relates to the field of computer technology, and in particular to a defect analysis method, related equipment, and readable storage medium. Background Technology

[0003] Currently, chip projects are becoming increasingly numerous and complex. From the project initiation stage, they generally need to go through multiple stages such as code writing, code submission, code verification, and code modification before they can be truly put into production and use.

[0004] In existing technologies, chip projects are generally managed through existing project management systems, which focus only on the code writing, code submission, and code verification stages.

[0005] It can be seen that the existing project management methods have relatively limited scope and cannot manage defect information in chip projects. Therefore, the existing project management methods suffer from poor management effectiveness and low management efficiency. Summary of the Invention

[0006] The purpose of this application is to address the shortcomings of the prior art by providing a defect analysis method, related equipment, and readable storage medium, which can improve the efficiency of chip project management and development.

[0007] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0008] In a first aspect, the present invention provides a project management method applied to a server, wherein a project management system is deployed on the server, the project management system including a code management module and a defect management module, wherein the code management module stores chip design code for at least one chip and identification information corresponding to the chip design code during the logic design code verification process by the designer, and the defect management module stores defect information corresponding to the chip design code;

[0009] The code management module obtains the logic design instructions submitted by the first designer through the user terminal, and in response to the logic design instructions, obtains the target chip design code, wherein the target chip design code is associated with target identification information;

[0010] The defect management module obtains the defect information corresponding to the target chip design code based on the target identification information.

[0011] By applying the embodiments of this application, it is possible to query the defect information corresponding to the target chip design code. Compared with the prior art, it is possible to achieve more comprehensive management of the target chip design code and effectively improve the management effect of the project management system. In addition, based on the defect information corresponding to the queried target chip design code, it is convenient for project managers to further analyze defects, improve the management efficiency of chip projects, speed up the progress of chip projects, and reduce the probability of defects occurring in the chip design process.

[0012] In an optional implementation, the defect information corresponding to the target chip design code includes at least one of the following: the target defect itself, the registration link corresponding to the target defect, the discovery level of the target defect, the reproduction information corresponding to the target defect, the number of times the target defect occurs, and the stage at which the target defect is discovered.

[0013] In an optional implementation, the target defect can be discovered at any of the following levels: module level, subsystem level, bare-metal system level, and operating system level.

[0014] In an optional implementation, the registration link of the target defect is used to characterize the link path of the target defect in the defect management module.

[0015] In an optional implementation, the reproduction information corresponding to the target defect is used to indicate whether the target defect is reproducible, and the corresponding reproduction level if the target defect is reproducible.

[0016] In an optional implementation, the stage at which the target defect is discovered is any one of the register-to-converter circuit code stage, netlist code stage, manual modification of integrated circuit code stage, and post-silicon code stage.

[0017] By applying the embodiments of this application, project managers can quickly query various defect information corresponding to the target chip design code based on the actual application scenario. Then, based on the various defect information, they can further analyze and modify the target chip design code in a timely manner, thereby improving the management efficiency and development efficiency of chip projects.

[0018] In an optional implementation, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced at the module level, and the target defect is caused by a module interface, the method further includes:

[0019] A first prompt message is sent to the user terminal to instruct the first designer to check whether the subsystem-level design specifications have clearly described the interfaces between modules.

[0020] By applying the embodiments of this application, when it is determined that the target defect is caused by the module interface, the first designer can be promptly reminded to check the subsystem-level design specifications, and the subsystem-level design specifications can be updated in a timely manner according to the inspection results to eliminate the target defect. This can accelerate the development progress of the chip project and improve the management efficiency of the chip project.

[0021] In an optional implementation, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced at the module level, and the target defect is caused by the module-level environment, the method further includes:

[0022] The defect management module obtains an environment modification request submitted by the user terminal for the target defect, and the environment modification request is used to modify the module-level environment.

[0023] In response to the environment modification request, the module-level environment in the code management module is modified so that the target defect can be reproduced based on the module-level environment.

[0024] By applying the embodiments of this application, when it is determined that the target defect is caused by the module-level environment, the target defect can be reproduced in a timely manner in response to the environment modification request submitted by the user terminal. This improves the efficiency of project managers in reproducing the target defect, and makes it easier for project managers to fix the target defect in a timely manner according to the cause of the defect reproduction, thereby accelerating the development progress of the chip project.

[0025] In an optional implementation, the method further includes:

[0026] The defect management module obtains the verification request for the target defect submitted by the verifier through the user terminal.

[0027] The defect management module responds to the verification request and reproduces the target defect in a preset tool based on the verification stimulus corresponding to any level.

[0028] By applying the embodiments of this application, it is possible to respond to the verification request submitted by the user terminal for the target defect and reproduce the target defect, thereby improving the efficiency of project managers in reproducing the target defect, and thus improving the management efficiency and development efficiency of the chip project.

[0029] In an optional implementation, the project management system further includes: a file management module for storing verification work and verification result documents corresponding to the target chip design code, wherein the verification result documents store historical verification results; the step of responding to the verification request through the defect management module and reproducing the target defect in a preset tool based on the verification stimulus corresponding to any level includes:

[0030] The defect management module responds to the verification request and retrieves the verification work corresponding to the target chip design code from the file management module.

[0031] Based on the verification work, the target defect is reproduced in the preset tool through the defect management module based on the verification stimulus corresponding to any level to obtain the current verification result, and the historical verification result is updated in the file management module based on the current verification result;

[0032] The current verification result includes the verification incentive name, function point, and verification incentive result when reproducing the target defect.

[0033] By applying the embodiments of this application, project managers can analyze the target defect based on the current verification results, reduce the probability of the target defect appearing in other chip design code, and accelerate the development progress of the chip project.

[0034] In an optional implementation, the file management module further stores design specification information corresponding to the chip design code of at least one chip; before obtaining the verification request for the target defect submitted by the verifier through the user terminal via the defect management module, the method further includes:

[0035] If the file management module stores the design specification information corresponding to the target chip design code, it sends a second prompt message to the user terminal. The second prompt message is used to prompt the verifier to trigger a verification request for the target defect.

[0036] In an optional implementation, the method further includes:

[0037] If the file management module does not store the design specification information corresponding to the target chip design code, a third prompt message is sent to the user terminal. The third prompt message is used to prompt the first designer to upload the design specification information corresponding to the target chip design code to the file management module.

[0038] By applying the embodiments of this application, it is possible to perform targeted checks on the relevant content of the target chip design code based on the reasons for the modification of the target chip design code, thereby accelerating the development progress of the chip project.

[0039] In an optional implementation, the project management system further includes an email management module, and the method further includes:

[0040] The email management module sends the defect information corresponding to the target chip design code to the user terminal, so as to prompt the first designer or verifier to modify the target chip design code based on the defect information.

[0041] By applying the embodiments of this application, defect information corresponding to the target chip design code can be synchronized with project managers in a timely manner, which facilitates timely modification of the target chip design code by project managers and accelerates the development progress of the chip project.

[0042] Secondly, the present invention provides a defect analysis method, the method being applied to a server, the method comprising:

[0043] Obtain defect information corresponding to the target chip design code; wherein, the defect information corresponding to the target chip design code includes at least one of the following: the discovery level of the target defect, the reproduction information of the target defect, the number of times the target defect occurs, and the stage at which the target defect is discovered;

[0044] Based on the defect information corresponding to the target chip design code, the first process is performed.

[0045] By applying the embodiments of this application, different first processes can be executed according to the different defect information of the target chip design code, so as to realize a comprehensive analysis of the target defects in the target chip design code, which can effectively improve the efficiency of defect analysis and thus improve the development efficiency of chip design code.

[0046] In an optional implementation, the target defect can be discovered at any of the following levels: module level, subsystem level, bare-metal system level, and operating system level.

[0047] In an optional implementation, the reproduction information corresponding to the target defect is used to indicate whether the target defect is reproducible, and the corresponding reproduction level if the target defect is reproducible.

[0048] In an optional implementation, the stage at which the target defect is discovered is any one of the register-to-converter circuit code stage, netlist code stage, manual modification of integrated circuit code stage, and post-silicon code stage.

[0049] In an optional implementation, the defect information corresponding to the target chip design code includes the discovery level of the target defect; the step of performing the first process based on the defect information corresponding to the target chip design code includes:

[0050] The target defect is reproduced at the target defect discovery level, and the target defect discovery level and the first relevant information of reproducing the target defect at the target defect discovery level are sent to the user terminal.

[0051] The target chip design code is modified by the user terminal based on the reproduction level corresponding to the target defect and the first relevant information of the target defect.

[0052] By applying the embodiments of this application, when the defect information corresponding to the target chip design code includes the discovery level of the target defect, the verifier can be guided to conduct targeted analysis of the target defect and feed the analysis results back to the user terminal. Then, the designer of the target chip design code can submit the modified target chip design code through the user terminal based on the analysis results. In this way, the efficiency of defect analysis and the development efficiency of chip design code can be improved.

[0053] In an optional implementation, the target chip design code includes multiple chip functional modules. In two dependent chip functional modules, a module interface is provided between one chip functional module and the other. If the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module-level environment, the first processing based on the defect information corresponding to the target chip design code includes:

[0054] Determine whether the module interfaces contained in the target chip design code meet the preset module interface requirements;

[0055] If it is determined that the module interface contained in the target chip design code does not meet the preset module interface requirements, the target defect is determined to be caused by the module interface, and it is determined whether the module interface has been clearly defined in the subsystem-level environment; wherein, the subsystem-level environment has a lower priority than the module-level environment.

[0056] By applying the embodiments of this application, when the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in the module-level environment, the verifier can be guided to further locate the cause of the target defect and feed back the analysis results of the target defect to the user terminal. Then, the designer of the target chip design code can submit the modified target chip design code through the user terminal based on the analysis results. In this way, the efficiency of defect analysis and the development efficiency of chip design code can be improved.

[0057] In an optional implementation, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module-level environment, the first processing based on the defect information corresponding to the target chip design code includes:

[0058] Determine whether the target defect can be reproduced in the target module-level environment; wherein, the target module-level environment is obtained by modifying the module-level environment;

[0059] If it is determined that the target defect cannot be reproduced in the target module-level environment, the target module-level environment is modified until the target defect can be reproduced in the modified target module-level environment.

[0060] The reproduction information of the target defect in the modified target module-level environment is sent to the user terminal;

[0061] Receive the target chip design code submitted by the user terminal based on the modified target module-level environment.

[0062] By applying the embodiments of this application, when the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in the module-level environment, the verifier can be guided to modify the module-level environment to reproduce the target defect, and the analysis results of the target defect can be fed back to the user terminal. Then, the designer of the target chip design code can submit the modified target chip design code through the user terminal based on the analysis results. In this way, the efficiency of defect analysis and the development efficiency of chip design code can be improved.

[0063] In an optional implementation, the defect information corresponding to the target chip design code includes the stage at which the target defect was discovered; the step of performing the first process based on the defect information corresponding to the target chip design code includes:

[0064] The target defect is reproduced at the stage where the target defect is discovered, and the stage where the target defect is discovered and the second relevant information for reproducing the target defect at the stage where the target defect is discovered are sent to the user terminal.

[0065] The system receives modified chip design stage code submitted by the user terminal for the target defect discovery stage and for the second relevant information for reproducing the target defect during the target defect discovery stage.

[0066] By applying the embodiments of this application, when the defect information corresponding to the target chip design code includes the stage of target defect discovery, the verifier can be guided to reproduce the target defect at the stage of target defect discovery and feed back the analysis results of the target defect to the user terminal. Then, the designer of the target chip design code can submit the modified target chip design code through the user terminal based on the analysis results. In this way, the efficiency of defect analysis and the development efficiency of chip design code can be improved.

[0067] In an optional implementation, the defect information corresponding to the target chip design code includes the number of times the target defect occurs; the step of performing the first process based on the defect information corresponding to the target chip design code includes:

[0068] If the number of occurrences of the target defect exceeds a preset threshold, an early warning message will be output.

[0069] By applying the embodiments of this application, when it is determined that the number of times a target defect occurs is greater than a preset threshold, a warning message can be output, which makes it easier for chip design code designers or verifiers to focus on the target defect, thereby reducing the probability of the target defect occurring and improving the development efficiency of chip design code.

[0070] Thirdly, the present invention provides a project management device applied to a server, wherein a project management system is deployed on the server, the project management system including a code management module and a defect management module, wherein the code management module stores chip design code for at least one chip and identification information corresponding to the chip design code during the logic design code verification process by the designer, and the defect management module stores defect information corresponding to the chip design code;

[0071] The code management module is used to obtain the logic design instructions submitted by the first designer through the user terminal, and in response to the logic design instructions, obtain the target chip design code, wherein the target chip design code is associated with target identification information;

[0072] The defect management module is used to obtain defect information corresponding to the target chip design code based on the target identification information.

[0073] In an optional implementation, the defect information corresponding to the target chip design code includes at least one of the following: the target defect itself, the registration link corresponding to the target defect, the discovery level of the target defect, the reproduction information corresponding to the target defect, the number of times the target defect occurs, and the stage at which the target defect is discovered.

[0074] In an optional implementation, the target defect can be discovered at any of the following levels: module level, subsystem level, bare-metal system level, and operating system level.

[0075] In an optional implementation, the registration link of the target defect is used to characterize the link path of the target defect in the defect management module.

[0076] In an optional implementation, the reproduction information corresponding to the target defect is used to indicate whether the target defect is reproducible, and the corresponding reproduction level if the target defect is reproducible.

[0077] In an optional implementation, the stage at which the target defect is discovered is any one of the register-to-converter circuit code stage, netlist code stage, manual modification of integrated circuit code stage, and post-silicon code stage.

[0078] In an optional implementation, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced at the module level, and the target defect is caused by a module interface, the method further includes:

[0079] A first prompt message is sent to the user terminal to instruct the first designer to check whether the subsystem-level design specifications have clearly described the interfaces between modules.

[0080] In an optional implementation, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced at the module level, and the target defect is caused by the module-level environment, the defect management module is further configured to obtain an environment modification request for the target defect submitted by the user terminal, and the environment modification request is used to modify the module-level environment.

[0081] In response to the environment modification request, the module-level environment in the code management module is modified so that the target defect can be reproduced based on the module-level environment.

[0082] In an optional implementation, the defect management module is further configured to obtain verification requests for the target defect submitted by the verifier through the user terminal.

[0083] The defect management module responds to the verification request and reproduces the target defect in a preset tool based on the verification stimulus corresponding to any level.

[0084] In an optional implementation, the project management system further includes: a file management module for storing verification work and verification result documents corresponding to the target chip design code, wherein the verification result documents store historical verification results; and a defect management module specifically for responding to the verification request through the defect management module and obtaining the verification work corresponding to the target chip design code from the file management module.

[0085] Based on the verification work, the target defect is reproduced in the preset tool according to the verification stimulus corresponding to any level to obtain the current verification result, and the historical verification result is updated in the file management module based on the current verification result;

[0086] The current verification result includes the verification incentive name, function point, and verification incentive result when reproducing the target defect.

[0087] In an optional implementation, the file management module further stores design specification information corresponding to the chip design code of at least one chip; the file management module is used to send a second prompt message to the user terminal if the design specification information corresponding to the target chip design code is stored, the second prompt message being used to prompt the verifier to trigger a verification request for the target defect.

[0088] In an optional implementation, the file management module is further configured to send a third prompt message to the user terminal if the design specification information corresponding to the target chip design code is not stored. The third prompt message is used to prompt the first designer to upload the design specification information corresponding to the target chip design code to the file management module.

[0089] In an optional implementation, the project management system further includes an email management module, which is used to send defect information corresponding to the target chip design code to the user terminal to prompt the first designer or verifier to modify the target chip design code based on the defect information.

[0090] Fourthly, the present invention provides a defect analysis apparatus, wherein the method is applied to a server, and the defect analysis apparatus includes:

[0091] An acquisition module is used to acquire defect information corresponding to the target chip design code; wherein, the defect information corresponding to the target chip design code includes at least one of the following: the discovery level of the target defect, the reproduction information of the target defect, the number of times the target defect occurs, and the stage at which the target defect is discovered;

[0092] The execution module is used to perform the first processing based on the defect information corresponding to the design code of the target chip.

[0093] In an optional implementation, the target defect can be discovered at any of the following levels: module level, subsystem level, bare-metal system level, and operating system level.

[0094] In an optional implementation, the reproduction information corresponding to the target defect is used to indicate whether the target defect is reproducible, and the corresponding reproduction level if the target defect is reproducible.

[0095] In an optional implementation, the stage at which the target defect is discovered is any one of the register-to-converter circuit code stage, netlist code stage, manual modification of integrated circuit code stage, and post-silicon code stage.

[0096] In an optional implementation, the defect information corresponding to the target chip design code includes the discovery level of the target defect; the execution module is specifically used to reproduce the target defect at the discovery level of the target defect, and send the discovery level of the target defect and the first relevant information of reproducing the target defect at the discovery level of the target defect to the user terminal.

[0097] The target chip design code is modified by the user terminal based on the reproduction level corresponding to the target defect and the first relevant information of the target defect.

[0098] In an optional implementation, the target chip design code includes multiple chip functional modules. Among two chip functional modules that have a dependency relationship, a module interface is set between one chip functional module and the other chip functional module. If the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module-level environment, the execution module is specifically used to determine whether the module interface included in the target chip design code meets the preset module interface requirements.

[0099] If it is determined that the module interface contained in the target chip design code does not meet the preset module interface requirements, the target defect is determined to be caused by the module interface, and it is determined whether the module interface has been clearly defined in the subsystem-level environment; wherein, the subsystem-level environment has a lower priority than the module-level environment.

[0100] In an optional implementation, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module-level environment, the execution module is specifically used to determine whether the target defect can be reproduced in a target module-level environment; wherein, the target module-level environment is obtained by modifying the module-level environment;

[0101] If it is determined that the target defect cannot be reproduced in the target module-level environment, the target module-level environment is modified until the target defect can be reproduced in the modified target module-level environment.

[0102] The reproduction information of the target defect in the modified target module-level environment is sent to the user terminal;

[0103] Receive the target chip design code submitted by the user terminal based on the modified target module-level environment.

[0104] In an optional implementation, the defect information corresponding to the target chip design code includes the stage at which the target defect was discovered; the execution module is specifically used to reproduce the target defect at the stage at which the target defect was discovered, and to send the stage at which the target defect was discovered and the second relevant information on reproducing the target defect at the stage at which the target defect was discovered to the user terminal.

[0105] The system receives modified chip design stage code submitted by the user terminal for the target defect discovery stage and for the second relevant information for reproducing the target defect during the target defect discovery stage.

[0106] In an optional implementation, the defect information corresponding to the target chip design code includes the number of times the target defect occurs; the execution module is specifically used to output warning information when the number of times the target defect occurs is greater than a preset threshold.

[0107] Fifthly, the present invention provides a server for executing the project management method or the defect analysis method as described in any of the foregoing embodiments.

[0108] In a sixth aspect, the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the project management method or the defect analysis method as described in any of the foregoing embodiments.

[0109] The beneficial effects of this application are:

[0110] The defect analysis method, related equipment, and readable storage medium provided in this application embodiment are applied to a server. A project management system is deployed on the server. The project management system includes a code management module and a defect management module. The code management module stores chip design codes for at least one chip and corresponding identification information for the chip design codes during the logic design code verification process. The defect management module stores defect information corresponding to the chip design codes. The code management module obtains logic design instructions submitted by the first designer through a user terminal. In response to the logic design instructions, the target chip design code is obtained, wherein the target chip design code is associated with target identification information. The defect management module, based on the target identification information, obtains the defect information corresponding to the target chip design code. This method enables the querying of defect information corresponding to the target chip design code. Compared to existing technologies, it allows for more comprehensive management of the target chip design code, effectively improving the management effect of the project management system. Furthermore, based on the queried defect information corresponding to the target chip design code, project managers can further conduct defect analysis, improving the management efficiency of chip projects, accelerating chip project progress, and reducing the probability of defects occurring during chip design. Attached Figure Description

[0111] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0112] Figure 1 A schematic diagram of the architecture of a project management system provided for an embodiment of this application;

[0113] Figure 2 A flowchart illustrating a project management method provided in an embodiment of this application;

[0114] Figure 3 This is a schematic diagram illustrating the discovery hierarchy corresponding to the target defect provided in the embodiments of this application;

[0115] Figure 4 A flowchart illustrating another project management method provided in this application embodiment;

[0116] Figure 5 A flowchart illustrating yet another project management method provided in this application embodiment;

[0117] Figure 6 A flowchart illustrating another project management method provided in this application embodiment;

[0118] Figure 7 A flowchart illustrating yet another project management method provided in this application embodiment;

[0119] Figure 8 A schematic diagram illustrating the project management method corresponding to the reasons for each code modification associated with the target chip design code provided in the embodiments of this application;

[0120] Figure 9 A flowchart illustrating another project management method provided in this application embodiment;

[0121] Figure 10 A flowchart illustrating another project management method provided in this application embodiment;

[0122] Figure 11 A schematic diagram illustrating the project management method corresponding to the discovery of the target defect at each preset stage, as provided in the embodiments of this application;

[0123] Figure 12 A flowchart illustrating a defect analysis method provided in an embodiment of this application;

[0124] Figure 13 A flowchart illustrating another defect analysis method provided in an embodiment of this application;

[0125] Figure 14 A flowchart illustrating yet another defect analysis method provided in an embodiment of this application;

[0126] Figure 15 A flowchart illustrating another defect analysis method provided in an embodiment of this application;

[0127] Figure 16 A flowchart illustrating yet another defect analysis method provided in an embodiment of this application;

[0128] Figure 17 A flowchart illustrating another defect analysis method provided in an embodiment of this application;

[0129] Figure 18 This application provides a schematic diagram of the functional modules of a project management device.

[0130] Figure 19 This is a functional module diagram of a defect analysis device provided in an embodiment of this application;

[0131] Figure 20 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation

[0132] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0133] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0134] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0135] To better understand this application, the technical terms used in this application will be explained below:

[0136] Designer: Used to complete chip design code using basic chip design units (registers, counters, buffers, etc.) according to chip design requirements.

[0137] Verifier: Used to verify whether the design logic of the chip design code provided by the designer meets the chip design requirements.

[0138] Figure 1 This application provides an embodiment of a project management system architecture diagram, as shown below. Figure 1 As shown, the project management system may include a server 110 and at least one user terminal 120. Each user terminal 120 can establish a communication connection with the server 110 through a network 130. Optionally, each user terminal 120 can be a terminal device used by the designer corresponding to each chip design code, or it can be a terminal device used by the verifier corresponding to each chip design code; no limitation is made here.

[0139] Figure 2 This application provides a flowchart illustrating a project management method, which can be applied to the above-mentioned methods. Figure 1The system uses a server with a project management system deployed on it. The project management system includes a code management module and a defect management module. The code management module stores the chip design code for at least one chip, along with its corresponding identifier information, generated during the logic design code verification process. The defect management module stores defect information corresponding to the chip design code. Optionally, the defect management module can integrate various defect-related functional modules such as defect identification, defect resolution, and defect reproduction. Optionally, the code management module can be implemented based on an open-source version control system (e.g., Subversion) or a distributed version control system (e.g., Git). This is not limited here, and the appropriate module can be flexibly selected based on the actual application scenario.

[0140] In some embodiments, the code type of the chip design code can be: RTL code, gate-level netlist code, etc., which is not limited here; the identification information corresponding to the chip design code can include: version information of the chip design code, storage path information of the chip design code, etc., which is not limited here. The defect information corresponding to each chip design code can include: defect identifier, registration link corresponding to the defect, defect discovery level, reproduction information corresponding to the defect, number of times the defect occurs, stage at which the defect was discovered, etc., which is not limited here.

[0141] like Figure 2 As shown, the project management methods may include:

[0142] S101. Obtain the logic design instructions submitted by the first designer through the user terminal through the code management module. In response to the logic design instructions, obtain the target chip design code, wherein the target chip design code is associated with target identification information.

[0143] The user terminal can be Figure 1 From any user terminal in the system, the first designer can submit logic design instructions based on that user terminal. These logic design instructions may include design instructions for the target chip design code. Optionally, these design instructions may include location setting instructions and quantity setting instructions for basic chip design units such as registers, counters, and buffers in the target chip design code, which are not limited here.

[0144] In response to the logical design instruction, the server can obtain the corresponding target chip design code. In some embodiments, the target identification information associated with the target chip design code may include: the version number, design name, defect identifier, version stability identifier, etc. of the target chip design code. Of course, other information may also be included depending on the actual application scenario, which is not limited here. Among them, the version stability identifier can indicate the stability of the target chip design code. Based on the version stability identifier, the verification work of the target chip design code can be determined. Optionally, if the version stability identifier associated with the target chip design code indicates that the target chip design code is a stable version, it means that the code compilation of the target chip design code has no problems and has passed the smoke test, and the verification work does not need to include a smoke test verification plan; otherwise, it means that the code compilation of the target chip design code has problems or the target chip design code has not undergone smoke testing (pre-testing before the verification process; smoke testing is generally a relatively simple data path test), then the verification work needs to include a smoke test verification plan. Of course, in some embodiments, the setting of the verification work may not depend on the version stability identifier associated with the target chip design code.

[0145] Optionally, the target chip design code mentioned above can be the initial chip design code corresponding to the target chip, or it can be an updated version of the historical chip design code corresponding to the target chip, which is not limited here.

[0146] S102. Through the defect management module, based on the target identification information, obtain the defect information corresponding to the target chip design code.

[0147] As explained above, since the defect management module stores defect information corresponding to the chip design code of at least one chip, the defect information corresponding to the target chip design code can be retrieved from the defect management module based on the target identification information. This enables rapid retrieval of defect information corresponding to the target chip design code, facilitating further defect analysis by project managers, improving the management efficiency of chip projects, accelerating chip project progress, and reducing the probability of defects occurring during chip design.

[0148] It is worth noting that, based on the type of defect information stored in the defect management module, the defect information corresponding to the target chip design code of the corresponding type can be obtained.

[0149] In summary, this application provides a project management method applied to a server. The server is equipped with a project management system, which includes a code management module and a defect management module. The code management module stores chip design code for at least one chip and corresponding identification information during logic design code verification. The defect management module stores defect information corresponding to the chip design code. The method obtains logic design instructions submitted by a first designer via a user terminal through the code management module. In response to these instructions, the method retrieves the target chip design code, which is associated with target identification information. The method then retrieves the defect information corresponding to the target chip design code based on the target identification information. This method allows for the querying of defect information corresponding to the target chip design code. Compared to existing technologies, it enables more comprehensive management of the target chip design code, effectively improving the management efficiency of the project management system. Furthermore, the queried defect information facilitates further defect analysis by project managers, improving chip project management efficiency, accelerating project progress, and reducing the probability of defects occurring during chip design.

[0150] Optionally, the defect information corresponding to the target chip design code includes at least one of the following: the target defect itself, the registration link corresponding to the target defect, the discovery level of the target defect, the reproduction information corresponding to the target defect, the number of times the target defect occurs, and the stage at which the target defect is discovered.

[0151] Figure 3 This diagram illustrates the discovery level of a target defect as provided in an embodiment of this application. In some embodiments, the target defect itself may include: a target defect identifier, chip design code corresponding to the target defect, etc., which are not limited here; the discovery level of the target defect is used to indicate the verification stage at which the target defect is discovered. Optionally, as... Figure 3 As shown, the target defect discovery level can be any of the following: module level, subsystem level, bare-metal system level, and operating system level. The levels of module level, subsystem level, bare-metal system level, and operating system level are progressively higher. It should be noted that the levels mentioned here are defined from the perspective of chip design code design.

[0152] The registration link corresponding to the target defect represents the link path of the target defect in the defect management module, that is, the access path of the target defect in the defect management module. For example, in some embodiments, the registration link corresponding to the target defect can be a web page link, such as http: / / 10.23.100.100 / xxx / xxxx / ID, where ID can be the defect identifier of the target defect. Of course, the specific form of the registration link is not limited to this.

[0153] The number of times a target defect occurs can characterize the number of times that target defect appears in the historical chip design code. Optionally, the historical chip design code can be the chip design code corresponding to the target chip or other chips within a historical time period, and this is not limited here.

[0154] The stage at which a target defect is discovered can be any of the following: Register Transfer Level (RTL) code stage, netlist code stage, Engineering Change Order (ECO) code stage, and post-silicon code stage.

[0155] The RTL code stage describes the abstract level of synchronous digital circuit operation, and the chip design code in the RTL code stage is called RTL code; the netlist code stage describes the interconnection relationship between circuit elements, and the chip design code in the netlist code stage is called gate-level netlist code.

[0156] The ECO code stage is the stage after the chip design code is frozen (meaning the verification results indicate that the chip design code has no defects and modification of the corresponding RTL code is not allowed). The ECO code stage can be divided into a logic ECO code stage and a physical ECO code stage. The logic ECO code stage is mainly used to modify or improve the logic function of the circuit, while the physical ECO code stage is mainly used to modify the physical implementation of the circuit to meet various constraints. The post-silicon coding stage is the stage where the user modifies the chip design code when defects are found during chip verification.

[0157] The reproduction information corresponding to the target defect is used to indicate whether the target defect is reproducible, and if the target defect is reproducible, the corresponding reproduction level. The reproduction level corresponding to the target defect being reproducible can be any level among module level, subsystem level, bare metal system level, and operating system level, without any limitation.

[0158] By applying the embodiments of this application, project managers can quickly query various defect information corresponding to the target chip design code based on the actual application scenario. Then, based on the various defect information, they can further analyze and modify the target chip design code in a timely manner, thereby improving the management efficiency and development efficiency of chip projects.

[0159] In some embodiments, the reproduction information corresponding to the target defect can be determined by the first designer or verifier based on human experience, or it can be determined based on a preset test script, which is not limited here.

[0160] If the reproduction information corresponding to the target defect indicates that the target defect can be reproduced at the module level, the defect management module can obtain and store the reproduction information corresponding to the target defect submitted by the user terminal. During the storage process, the defect management module can mark the reproduction level of the target defect as the module level. If the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced at the module level, the target defect may be caused by the module interface or by the module-level environment. These two situations will be explained below.

[0161] Figure 4 This is a flowchart illustrating another project management method provided in an embodiment of this application. Optionally, as... Figure 4 As shown, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced at the module level, and the target defect is caused by the module interface, the above method further includes:

[0162] S201. Send a first prompt message to the user terminal to instruct the first designer to check whether the subsystem-level design specifications have clearly described the interfaces between modules.

[0163] Optionally, the server can send a first prompt message to the user terminal via email or pop-up window. If the target defect is caused by a module interface, the first prompt message can be sent to the user terminal, allowing the first designer to check whether the subsystem-level design specification corresponding to the target chip design code clearly describes the interfaces between modules. If it is determined that the interface is not clearly described, the first designer can submit an updated subsystem-level design specification corresponding to the target chip design code to the server through the user terminal. The updated subsystem-level design specification may include a clear description of the interfaces between modules.

[0164] By applying the embodiments of this application, when it is determined that the target defect is caused by the module interface, the first designer can be promptly reminded to check the subsystem-level design specifications, and the subsystem-level design specifications can be updated in a timely manner according to the inspection results to eliminate the target defect. This can accelerate the development progress of the chip project and improve the management efficiency of the chip project.

[0165] Figure 5 This is a flowchart illustrating another project management method provided in an embodiment of this application. Optionally, as... Figure 5 As shown, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced at the module level, and the target defect is caused by the module-level environment, the above method further includes:

[0166] S301. Obtain the environment modification request for the target defect submitted by the user terminal through the defect management module. The environment modification request is used to modify the module-level environment.

[0167] S302. In response to the environment modification request, modify the module-level environment in the code management module so that the target defect can be reproduced based on the module-level environment.

[0168] If the target defect is caused by the module-level environment, the verifier corresponding to the target chip design code can submit an environment modification request for the target defect to the server through the user terminal. The server can then modify the module-level environment in the code management module based on this request, enabling the target defect to be reproduced based on the modified module-level environment. Optionally, during the actual reproduction process, the modified module-level environment can be combined with relevant verification stimuli to achieve reproduction in a chip simulation tool.

[0169] By applying the embodiments of this application, when it is determined that the target defect is caused by the module-level environment, the target defect can be reproduced in a timely manner in response to the environment modification request submitted by the user terminal. This improves the efficiency of project managers in reproducing the target defect, and makes it easier for project managers to fix the target defect in a timely manner according to the cause of the defect reproduction, thereby accelerating the development progress of the chip project.

[0170] Based on the above explanation, to better understand this application, a brief description of the chip project development process is provided first. During chip project development, the chip design code can be divided from top to bottom into system design modules (top-level design modules). Each system design module can contain multiple subsystem design modules, and each subsystem design module can be further divided into multiple design modules. Specifically, the top-level design module corresponds to system-level verification, the subsystem design modules correspond to subsystem-level verification, and the design modules correspond to module-level verification.

[0171] Understandably, if a target defect is identified in the target chip design code, it is necessary to verify the defect to obtain information on its cause, reproduction, and elimination methods. Defect verification can be performed in a bottom-up manner: first, module-level verification; then, subsystem-level verification; and finally, system-level verification. System-level verification is further divided into bare-metal system-level verification and operating system-level verification. Bare-metal system-level verification involves writing simple verification stimuli on pre-defined tools without operating system code; operating system-level verification involves using operating system code and is performed on a simulator platform.

[0172] It should be noted that, from the perspective of chip design code design, the operating system level is higher than the bare-metal system level, the bare-metal system level is higher than the subsystem level, and the subsystem level is higher than the module level.

[0173] Furthermore, it is worth noting that when verifying a target defect to reproduce it, if the target defect is first discovered at a higher level (e.g., the operating system level), it is necessary to rediscover the target defect at a lower level (e.g., the module level or subsystem level) by constructing verification stimuli or modifying the environment, that is, to reproduce the target defect. When reproducing the target defect, based on the bottom-up reproduction principle, if the target defect can be reproduced by writing verification stimuli or modifying the environment at the module level, then the reproduction level of the target defect is registered as module-level reproduction in the defect management module, and the reproduction ends. If it cannot be reproduced at the module level, but can be reproduced by writing verification stimuli or modifying the environment at the subsystem level, then the reproduction level of the target defect is registered as subsystem reproduction in the defect management module, and the reproduction ends. If it cannot be reproduced at either the module or subsystem level, but can be reproduced by writing verification stimuli or modifying the environment at the bare-metal system level, then the reproduction level of the target defect is registered as bare-metal system-level reproduction in the defect management module, and the reproduction ends. If it cannot be reproduced at the module, subsystem, or bare-metal system level, but can be reproduced by writing verification stimuli or modifying the environment at the operating system level, then the reproduction level of the target defect is registered as operating system-level reproduction in the defect management module, and the reproduction ends.

[0174] Based on the above description, the code management module can also store chip verification code designed by the verifier for at least one chip's chip design code during the verification process, as well as the identification information corresponding to the chip verification code. Optionally, the identification information corresponding to the chip verification code may include: verification stage identifier, chip verification code version information, chip design code storage path information, etc., which are not limited here.

[0175] Figure 6 This is a flowchart illustrating another project management method provided in an embodiment of this application. Based on the above description, optionally, as... Figure 6 As shown, the above method also includes:

[0176] S401. Obtain verification requests for target defects submitted by verifiers through user terminals via the defect management module.

[0177] S402. Respond to the verification request through the defect management module and reproduce the target defect based on the verification stimulus corresponding to any level in the preset tool.

[0178] When further verifying the target defect based on the actual application scenario, the verifier can submit a verification request for the target defect through the user terminal. This verification request may include chip verification code, which may include verification stimuli at the level where the target defect resides, such as subsystem verification stimuli, bare-metal verification stimuli, etc., without limitation. Based on the above description, the acquired chip verification code can be stored in the code management module.

[0179] The server can receive the verification request through the defect management module. In response to the verification request, the server can verify the target defect using the corresponding verification stimulus in a preset tool, thereby reproducing the target defect. Optionally, the preset tool can be a chip simulation tool.

[0180] By applying the embodiments of this application, it is possible to respond to the verification request submitted by the user terminal for the target defect and reproduce the target defect, thereby improving the efficiency of project managers in reproducing the target defect, and thus improving the management efficiency and development efficiency of the chip project.

[0181] Optionally, the aforementioned project management system further includes a file management module for storing verification work and verification result documents corresponding to the target chip design code. The verification result documents store historical verification results. Verification work can be understood as a verification plan, which may include verification methods, verification content, expected verification results, etc., without limitation. Optionally, the file management module can be implemented based on an open-source version control system (e.g., Subversion) or a distributed version control system (e.g., Git), without limitation, and can be flexibly selected according to the actual application scenario.

[0182] In some embodiments, based on the design stage corresponding to the target chip design code, the verification work corresponding to the target chip design code can be further divided into: system-level verification plan, subsystem-level verification plan, and module-level verification plan; the verification result document corresponding to the target chip design code can be further divided into: system-level verification result document, subsystem-level verification result document, and module-level verification result document. Of course, the specific division method is not limited to this.

[0183] Among them, the historical verification results can be used to indicate whether there are historical defects in the target chip design code other than the target defect during the historical verification process, the cause of the historical defects, the location of the historical defects, and the corresponding reproduction level when the historical defects are reproduced if they exist, etc., without being limited here.

[0184] Figure 7 This is a flowchart illustrating another project management method provided in an embodiment of this application. In some embodiments, such as Figure 7As shown, the above-mentioned response to verification requests through the defect management module, and reproduction of the target defect based on the verification stimulus corresponding to any level in the preset tool, includes:

[0185] S501: Respond to the verification request through the defect management module and obtain the verification work corresponding to the target chip design code from the file management module.

[0186] S502. Based on the verification work, the target defect is reproduced in the preset tool through the defect management module based on the verification stimulus corresponding to any level to obtain the current verification result, and the historical verification result is updated in the file management module based on the current verification result.

[0187] The current verification results include the verification stimulus name, function point, and verification stimulus result when the target defect is reproduced. The verification stimulus name is used to indicate the verification stimulus identifier corresponding to the target defect reproduction. The function point is used to indicate the verification function point when the target defect is reproduced. For example, it can be the function verification point of a basic chip design unit such as a register, counter, or buffer. The verification stimulus result is used to indicate the specific defect information corresponding to the target defect under the verification stimulus corresponding to the verification stimulus name.

[0188] As explained above, after obtaining the verification work corresponding to the target chip design code, the defect management module can reproduce the target defect in the preset tools based on the verification stimulus corresponding to any level to obtain the current verification result. Understandably, to facilitate subsequent analysis by other personnel (such as designers or verifiers) on the cause of the target defect, historical verification results can be updated based on the current verification result; for example, the current verification result can be appended to historical verification results.

[0189] By applying the embodiments of this application, project managers can analyze the target defect based on the current verification results, reduce the probability of the target defect appearing in other chip design code, and accelerate the development progress of the chip project.

[0190] Based on the above explanation, it should also be noted that the project management system may also include: a project database, which can store the design name, design level, storage path of the chip design code for each chip, design specification path and design specification name, verification specification path and verification specification name, designer identifier (e.g., ID card number, employee number, etc.) corresponding to each chip design code, and verifier identifier corresponding to each chip design code.

[0191] Specifically, regarding design specification paths and names, and verification specification paths and names, the design specification path and name will be used as an example. The design specification path and name indicate the storage path of the design specification information corresponding to each chip's design code. In other words, the design specification information corresponding to the target chip's design code can be retrieved by querying the design specification path and name. Optionally, the design specification information corresponding to the chip design code of at least one chip can be stored in a file management module. That is, the design specification information corresponding to the target chip's design code can be retrieved by querying the file management module based on the design specification path and name.

[0192] Optionally, each chip design code can correspond to multiple designer identifiers and multiple verifier identifiers. This is not limited here and can vary depending on the actual application scenario. For example, each subsystem design module can correspond to different designers and different verifiers. Regarding the designer identifiers and verifier identifiers corresponding to each chip design code, taking the designer identifier corresponding to each chip design code as an example, in conjunction with the above embodiments, optionally, the email management module can store the designer email accounts corresponding to each chip design code, as well as the mapping relationship between the designer identifiers and designer email accounts corresponding to each chip design code. Then, for the target chip design code, the first designer identifier corresponding to the target chip design code can be obtained through the project database. Based on this first designer identifier, the first designer email account corresponding to the first designer identifier can be obtained through the email management module, and then relevant prompt information can be sent to the first designer email account through the email management module. Of course, this application does not limit the specific prompt content here, and it can vary depending on the actual application scenario.

[0193] It should be noted that in some scenarios, if it is determined through querying that the email management module does not store the first designer's email account corresponding to the first designer's identifier, the server may optionally send a supplementary prompt to the user terminal based on the communication link between the server and the user terminal, prompting the user terminal to supplement the first designer's email account to the email management module.

[0194] Optionally, the file management module also stores design specification information corresponding to the chip design code of at least one chip. This design specification information may include: design scheme, timing diagram, register, state machine, counter, data buffer design specifications, etc., which are not limited here.

[0195] It should be noted that different versions of the chip design code for the same chip can correspond to different design specification information. For example, if the first version of the chip design code for a certain chip is updated to obtain the second version of the chip design code, it is also necessary to update the first design specification information corresponding to the first version of the chip design code according to the changes in the first version of the chip design code, so as to obtain the second design specification information corresponding to the second version of the chip design code. This allows project managers to know the reasons for the changes and the location of the changes in a timely manner based on the design specification information.

[0196] The design specification information can be retrieved by querying the design specification path and name. Optionally, based on the design stage corresponding to the chip design code, the design specification information corresponding to the chip design code can be further divided into: system-level design specification information, subsystem-level design specification information, and module-level design specification information.

[0197] In some embodiments, if the target chip design code is an updated version of the historical chip design code corresponding to the target chip, optionally, the target chip design code may be associated with a code modification reason and a target version identifier. The code modification reason may be any one or more of the following: design scheme change, the historical chip design code corresponding to the target chip exhibiting defects already present in other chip design codes, defects discovered during verification of the historical chip design code corresponding to the target chip, or defects discovered through code inspection tools. The target version identifier may be obtained by updating the historical chip design code corresponding to the target chip based on the historical version identifier, wherein the historical version identifier is the version identifier of the historical chip design code corresponding to the target chip.

[0198] Figure 8 This diagram illustrates the project management methods corresponding to the reasons for each code modification associated with the target chip design code provided in this application embodiment. For example, Figure 8 As shown, if the reason for the code modification associated with the target chip design code includes: design scheme changes, optionally, the server can send a fourth prompt message to the user terminal to prompt the first designer to check whether the design specification information corresponding to the target chip design code has changed some information of the design scheme. If the reason for the code modification associated with the target chip design code includes: the historical chip design code corresponding to the target chip has defects that already exist in other chip design codes, optionally, the server can send a fifth prompt message to the user terminal to prompt the first designer or verifier to analyze the historical chip design code to find the reason for the defect.

[0199] Figure 9This is a flowchart illustrating another project management method provided in an embodiment of this application. Optionally, if the reason for modifying the code associated with the target chip design code includes: defects were found in the historical chip design code corresponding to the target chip during the verification process, such as... Figure 8 and Figure 9 As shown, before obtaining the verification request for the target defect submitted by the verifier through the user terminal via the defect management module, the process also includes:

[0200] S601. If the file management module stores the design specification information corresponding to the target chip design code, a second prompt message is sent to the user terminal. The second prompt message is used to prompt the verifier to trigger a verification request for the target defect.

[0201] S602. If the file management module does not store the design specification information corresponding to the target chip design code, a third prompt message is sent to the user terminal. The third prompt message is used to prompt the first designer to upload the design specification information corresponding to the target chip design code to the file management module.

[0202] Based on the above embodiments, optionally, the design specification path and design specification name corresponding to the target chip design code can be obtained by querying the project database according to the design name associated with the target chip design code; the design specification information corresponding to the target chip design code can be obtained by querying the file management module according to the design specification path and design specification name corresponding to the target chip design code. If found, the server can send a second prompt message to the user terminal to indicate that the verifier can trigger a verification request for the target defect. In some embodiments, the verification request may include target identification information associated with the target chip design code, such as the version number of the target chip design code, etc., which is not limited here and may vary depending on the actual application scenario. If not found, the server can send a third prompt message to the user terminal to promptly prompt the first designer to upload the design specification information corresponding to the target chip design code to the file management module.

[0203] By applying the embodiments of this application, it is possible to perform targeted checks on the relevant content of the target chip design code based on the reasons for the modification of the target chip design code, which can improve the management efficiency and development efficiency of chip projects.

[0204] It should be noted that in some embodiments, if the target identification information associated with the target chip design code includes: design name and version stability identifier, wherein if the version stability identifier indicates that the target chip design code is an unstable version, it means that the target chip design code has not been verified, then the above steps S601 and S602 can also be executed. This realizes that if the version stability identifier indicates that the target chip design code is an unstable version, corresponding prompt information can be sent to the first designer or verifier corresponding to the target chip design code based on the actual query results, thereby promoting the development progress of the target chip design code and improving project development efficiency.

[0205] Regarding the file management module, it should be noted that it can also store all files related to the chip design code of at least one chip, including system requirements specifications, system architecture schemes, review schemes, relevant reference documents, user manuals, and verification specification information (including verification specification paths and names). This allows users to quickly find relevant files through the file management module, improving the management efficiency of chip projects.

[0206] Figure 10 This is a flowchart illustrating another project management method provided in an embodiment of this application. Optionally, the project management system further includes an email management module, which may store the designer's email account and the verifier's email account corresponding to each chip design code. In some embodiments, such as Figure 10 As shown, the above method also includes:

[0207] S701. The defect information corresponding to the target chip design code is sent to the user terminal through the email management module to prompt the first designer or verifier to modify the target chip design code based on the defect information.

[0208] In some embodiments, the first designer corresponding to the target chip design code can log in to the first designer's email account through a user terminal, and the verifier corresponding to the target chip design code can log in to the verifier's email account through a user terminal. Then, the server can send the defect information corresponding to the target chip design code to the user terminal in the form of an email based on the first designer's email account and the verifier's email account through the email management module. Thus, the first designer or the verifier can obtain the defect information corresponding to the target chip design code through the user terminal and make modifications accordingly.

[0209] By applying the embodiments of this application, defect information corresponding to the target chip design code can be synchronized with project managers in a timely manner, which facilitates timely modification of the target chip design code by project managers and can improve the management and development efficiency of chip projects.

[0210] Optionally, if the defect information corresponding to the target chip design code does not include the registration link corresponding to the target defect, the first designer or verifier can supplement the registration link corresponding to the target defect in the defect management module through the user terminal; if the number of times the target defect appears in the defect information corresponding to the target chip design code is 1, the first designer or verifier can analyze the reason why the target defect did not appear in the historical chip design code.

[0211] Figure 11 This is a schematic diagram illustrating the project management method corresponding to the discovery of a target defect at various preset stages, as provided in the embodiments of this application. In some embodiments, such as Figure 11 As shown, if the stage at which the target defect was discovered in the defect information corresponding to the target chip design code is the register conversion level circuit code stage, and the defect information corresponding to the target chip design code also includes the target defect discovery level, then the first designer or verifier can make modifications in the following manner.

[0212] If the defect discovery level of the target defect in the defect information corresponding to the target chip design code is at the module level, the verifier can analyze the reason for the discovery of the target defect, obtain the registration link corresponding to the target defect, and send the registration link of the target defect and the reason for the occurrence of the target defect to the server through the user terminal; the first designer can analyze the solution to the target defect and send the solution to the target defect and the modification to the target chip design code to solve the target defect to the server through the user terminal.

[0213] If the defect discovery level of the target defect in the defect information corresponding to the target chip design code is at the subsystem level, the first designer or verifier can analyze the first escape reason of the target defect escaping from the module level to the subsystem level before being discovered, and analyze whether the target defect can be reproduced at the module level. The verifier can then send the registration link of the target defect and the first escape reason of the target defect to the server through the user terminal. If the target defect can be reproduced at the module level, the verifier can also send the reproduction information of the target defect at the module level to the server through the user terminal.

[0214] If the defect discovery level in the defect information corresponding to the target chip design code is the bare-metal system level, the first designer or verifier can analyze the first escape reason of the target defect escaping from the module level and subsystem level to the bare-metal system level before being discovered, and analyze whether the target defect can be reproduced at the module level or subsystem level. The verifier can then send the registration link of the target defect and the first escape reason of the target defect to the server through the user terminal. If the target defect can be reproduced at the module level or subsystem level, the verifier can also send reproduction information of the target defect reproduction level at the module level or subsystem level to the server through the user terminal.

[0215] If the defect discovery level in the defect information corresponding to the target chip design code is the operating system level, the first designer or verifier can analyze the first escape reason why the target defect escapes from the module level, subsystem level, and bare-metal system level to the operating system level before being discovered, and analyze whether the target defect can be reproduced at the module level, subsystem level, or bare-metal system level. They can then send the registration link of the target defect and the first escape reason of the target defect to the server via the user terminal. If the target defect can be reproduced at the module level, subsystem level, or bare-metal system level, the verifier can also send reproduction information indicating that the target defect is reproduced at the module level, subsystem level, or bare-metal system level to the server via the user terminal. Optionally, if the target defect cannot be reproduced at the module level, subsystem level, or bare-metal system level, the first designer and verifier can analyze whether the design module corresponding to the target defect exists.

[0216] In some embodiments, continue to refer to Figure 11 As shown, if the target defect was discovered at the netlist code stage in the defect information corresponding to the target chip design code, the first designer or verifier can analyze the second escape reason for the target defect escaping from the register conversion stage to the netlist code stage before being discovered, and send the second escape reason of the target defect to the server through the user terminal.

[0217] If the defect information corresponding to the target chip design code indicates that the target defect was discovered during the stage of manually modifying the integrated circuit code, the first designer or verifier can analyze the second escape reason why the target defect escaped to the stage of manually modifying the integrated circuit code before the target chip design code was frozen, and send the second escape reason of the target defect to the server through the user terminal.

[0218] If the target defect was discovered at the post-silicon code stage in the defect information corresponding to the target chip design code, the first designer or verifier can analyze the second escape reason that the target defect escaped to the post-silicon code stage before the target chip was fabricated, and send the second escape reason of the target defect to the server through the user terminal.

[0219] In some embodiments, the defect information corresponding to the target chip design code may further include: the method of discovering the target defect. In addition, in conjunction with the foregoing related content, the reasons for code modification associated with the target chip design code may include: the historical chip design code corresponding to the target chip has defects that already exist in other chip design codes; defects are found in the historical chip design code corresponding to the target chip during the verification process; and defects are found in the historical chip design code corresponding to the target chip through code inspection tools.

[0220] Alternatively, refer to the above. Figure 8 As shown, the target defect can be discovered during the verification process or through code inspection tools. Based on this description, if the defect information corresponding to the target chip design code indicates that the target defect was discovered through code inspection tools, the server can send a sixth prompt message to the user terminal to instruct the first designer or verifier to analyze the reasons for the target defect's escape and the reasons why the target defect was not discovered during the verification process. This facilitates timely self-inspection by project developers during project development, thereby improving the design efficiency of subsequent chip design code.

[0221] It should be noted that if the first designer corresponding to the target chip design code logs in to the first designer's email account through the first user terminal, and the verifier corresponding to the target chip design code logs in to the verifier's email account through the second user terminal, then the server can send the defect information corresponding to the target chip design code to the first user terminal and the second user terminal respectively in the form of email through the email management module.

[0222] Of course, if there are multiple first designer email accounts or verifier email accounts corresponding to the target chip design code, the server can choose to send the defect information corresponding to the target chip design code to some of the first designer email accounts or verifier email accounts, thereby reducing the server's power consumption; of course, it can also choose to send the defect information corresponding to the target chip design code to all first designer email accounts or verifier email accounts, so that each first designer or verifier can respond in a timely manner and improve response efficiency. There is no limitation here, and the sending strategy can be flexibly selected according to the actual application scenario.

[0223] By applying the embodiments of this application, it is possible to perform refined processing based on the specific content of the defect information corresponding to the target chip design code, which facilitates project managers to modify the target chip design code in a timely manner based on the target defect, thereby accelerating the chip project development efficiency.

[0224] Based on the above embodiments, it should also be noted that even if the code management module, defect management module, file management module, and email management module are deployed as separate systems on the server in the embodiments of this application, the association between the various modules can be established without the need for manual association. In this way, when any module is updated, relevant prompt information can be sent to other modules in a timely manner, so that project managers can receive the prompt information in a timely manner and make adaptive modifications, which can effectively improve the management efficiency and development efficiency of chip projects.

[0225] Furthermore, in existing technologies, defect analysis of chip design code mainly relies on verification engineers to conduct analysis based on historical verification experience. This approach suffers from problems such as insufficient analysis and low analysis efficiency.

[0226] In view of this, the present application provides a defect analysis method, which can be used to analyze the defect information of chip design code more comprehensively and improve the efficiency of defect analysis.

[0227] Figure 12 This is a flowchart illustrating a defect analysis method provided in an embodiment of this application. The execution entity of this method can be a server, such as... Figure 12 As shown, the method may include:

[0228] S801: Obtain the defect information corresponding to the target chip design code.

[0229] The defect information corresponding to the target chip design code may include at least one of the following: the discovery level of the target defect, the reproduction information of the target defect, the number of times the target defect occurs, and the stage at which the target defect is discovered.

[0230] It is understandable that, depending on the actual application scenario, the defect information corresponding to the target chip design code may include the various types mentioned above. Of course, in addition to the defect information shown above, other types of defect information may also be included, which are not limited here. Furthermore, it should be noted that the process of obtaining the defect information corresponding to the target chip design code can be found in the relevant content of the project management methods mentioned above, and will not be repeated here.

[0231] S802. Based on the defect information corresponding to the target chip design code, perform the first processing.

[0232] Different first processes can be executed depending on the different defect information corresponding to the target chip design code. Optionally, the first process may be the reproduction of the target defect in the defect information, or the correction of the target defect, or the warning prompt to the user terminal. No limitation is made here. Different defect analyses can be performed according to different defect information to achieve rapid analysis. By applying the embodiments of this application, different first processes can be executed according to different defect information in the target chip design code. Compared with the prior art, a more comprehensive analysis of the target defects in the target chip design code can be performed, which can effectively improve the efficiency of defect analysis and thus improve the development efficiency of chip design code.

[0233] In summary, this application provides a defect analysis method that can be applied to a server. The method includes: acquiring defect information corresponding to the target chip design code; wherein the defect information corresponding to the target chip design code includes at least one of the following: the discovery level of the target defect, the reproduction information of the target defect, the number of times the target defect occurs, and the stage at which the target defect is discovered; and performing a first process based on the defect information corresponding to the target chip design code. By applying this application, different first processes can be performed according to different defect information of the target chip design code, thereby achieving a comprehensive analysis of the target defects in the target chip design code, effectively improving defect analysis efficiency, and thus improving the development efficiency of chip design code.

[0234] Optionally, the discovery level of the target defect can be any of the following levels: module level, subsystem level, bare-metal system level, and operating system level.

[0235] Optionally, the reproduction information corresponding to the target defect is used to indicate whether the target defect is reproducible, and the corresponding reproduction level if the target defect is reproducible.

[0236] Optionally, the stage at which the target defect is discovered is any one of the register-to-converter circuit code stage, netlist code stage, manual modification of integrated circuit code stage, and post-silicon code stage.

[0237] It should be noted that the discovery levels of target defects, the reproduction information of target defects, and the stages at which target defects are discovered can be found in the relevant content of the above project management methods, and will not be repeated here.

[0238] Figure 13 This is a flowchart illustrating another defect analysis method provided in an embodiment of this application. Optionally, if the defect information corresponding to the target chip design code includes the discovery level of the target defect; such as Figure 13 As shown, the first process, based on the defect information corresponding to the target chip design code, includes:

[0239] S901. Reproduce the target defect at the target defect discovery level, and send the target defect discovery level and the first relevant information of reproducing the target defect at the target defect discovery level to the user terminal.

[0240] Among them, the first relevant information for reproducing the target defect at the target defect discovery level can be used to indicate the relevant reproduction information when the target defect is reproduced. Optionally, it may include: target defect description (e.g., the time and location of the target defect discovery), the name and code version of the design module corresponding to the target defect, the excitation signal of the design module when the target defect is reproduced, the module environment of the design module when the target defect is reproduced, the difficulty of reproducing the target defect, etc., which are not limited here and may vary depending on the actual application scenario.

[0241] If the defect information corresponding to the target chip design code includes the discovery level of the target defect, then in this case, the target defect can be reproduced at the discovery level to obtain the first relevant information of the target defect. Furthermore, the first relevant information and the discovery level of the target defect can be sent to the user terminal so that the designer of the target chip design code can modify the target chip design code through the user terminal to correct or eliminate the target defect.

[0242] S902: Receive the target chip design code modified by the user terminal based on the reproduction level corresponding to the target defect and the first relevant information of the target defect.

[0243] In this process, after the designer of the target chip design code modifies the target chip design code through the user terminal, the modified target chip design code can be sent to the server. Upon receiving the modified target chip design code, the server can further verify the target chip design code through the user terminal to ensure that the target chip design code does not have the defect, thereby ensuring the reliability of the chip operation corresponding to the target chip design code in actual application.

[0244] By applying the embodiments of this application, when the defect information corresponding to the target chip design code includes the discovery level of the target defect, the verifier can be guided to conduct targeted analysis of the target defect and feed the analysis results back to the user terminal. Then, the designer of the target chip design code can submit the modified target chip design code through the user terminal based on the analysis results. In this way, the efficiency of defect analysis and the development efficiency of chip design code can be improved.

[0245] Figure 14This is a flowchart illustrating another defect analysis method provided in an embodiment of this application. Optionally, the target chip design code may include multiple chip functional modules. In two chip functional modules with a dependency relationship, a module interface is provided between one chip functional module and the other chip functional module. The two chip functional modules with a dependency relationship mean that the output signal of one chip functional module needs to be used as the input signal of the other chip functional module; that is, the two chip functional modules with a dependency relationship can transmit signals through the provided module interface.

[0246] Each chip functional module implements a portion of the functions of the target chip design code. These multiple chip functional modules communicate and cooperate to meet the design requirements of the target chip design code. Of course, this application does not limit the number of chip functional modules in the target chip design code; the number can vary depending on the design requirements of the target chip design code.

[0247] Optionally, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module-level environment, such as Figure 14 As shown, the first process, based on the defect information corresponding to the target chip design code, includes:

[0248] S1001. Determine whether the module interfaces contained in the target chip design code meet the preset module interface requirements.

[0249] Optionally, the preset module interface requirements may include: module interface definition requirements, calling requirements, data communication requirements, etc., which are not limited here and may vary depending on the actual application scenario. In particular, by determining whether the module interfaces contained in the target chip design code conform to the preset module interface requirements, the cause of the target defect can be further determined when the target defect cannot be reproduced in a module-level environment.

[0250] S1002. If it is determined that the module interface contained in the target chip design code does not meet the preset module interface requirements, determine that the target defect is caused by the module interface, and determine whether the module interface has been clearly defined in the subsystem-level environment.

[0251] In this context, the subsystem-level environment has a lower priority than the module-level environment. Priority indicates the order in which target defects can be reproduced. As explained earlier, from a chip design code perspective, each subsystem design module can be divided into multiple design modules (i.e., chip functional modules). Furthermore, the subsystem-level hierarchy is higher than the module-level hierarchy. This means that when designing chip design code, the module interfaces of each design module must first be clearly defined at the subsystem level before the specific functions implemented by each module are designed. Therefore, if the target defect is determined to be caused by a module interface at the module level, it can be further determined at the higher subsystem level whether the module interface is clearly defined, thereby identifying the specific cause of the target defect.

[0252] It should be noted that the module interface set between two chip functional modules that have a dependency relationship is defined in the subsystem-level environment, specifically in the subsystem-level design specification corresponding to the subsystem level.

[0253] Understandably, if the module interfaces contained in the target chip design code do not meet the preset module interface requirements, then it can be determined that the target defect is caused by the module interface. Based on the above explanation, for the module interface, it can be further determined whether the subsystem-level environment clearly defines the module interface corresponding to the target defect. If it is determined that the subsystem-level environment does not clearly define the module interface corresponding to the target defect, optionally, the server can send a modification request to the user terminal, so that the designer or verifier of the target chip design code can modify the subsystem-level environment according to the modification request to eliminate the target defect.

[0254] By applying the embodiments of this application, when the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in the module-level environment, the verifier can be guided to further locate the cause of the target defect and feed back the analysis results of the target defect to the user terminal. Then, the designer of the target chip design code can submit the modified target chip design code through the user terminal based on the analysis results. In this way, the efficiency of defect analysis and the development efficiency of chip design code can be improved.

[0255] Figure 15 This is a flowchart illustrating another defect analysis method provided in an embodiment of this application. If the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module-level environment, optionally, such as... Figure 15 As shown, the first process, based on the defect information corresponding to the target chip design code, includes:

[0256] S1101. Determine whether the target defect can be reproduced in the target module-level environment.

[0257] The target module-level environment is obtained by modifying the module-level environment. If it is determined that the target defect can be reproduced in the target module-level environment, optionally, the first reproduction information when the target defect is reproduced can be obtained and sent to the user terminal. Optionally, the first reproduction information may include: environment parameters of the target module-level environment (environment name, environment code version, etc.), description of the target defect (e.g., the time and location of the target defect discovery), the name of the design module and the code version of the design module corresponding to the target defect, the stimulus name of the design module when the target defect is reproduced, the difficulty of reproducing the target defect, etc., which are not limited here and may vary depending on the actual application scenario.

[0258] Furthermore, after receiving the first reproduction information through the user terminal, the designer of the target chip design code can modify the target chip design code according to the first reproduction information so that the modified target chip design code does not have the target defect, and then send the modified target chip design code to the server.

[0259] S1102. If it is determined that the target defect cannot be reproduced in the target module-level environment, modify the target module-level environment until the target defect can be reproduced in the modified target module-level environment.

[0260] S1103. Send the reproduction information of the target defect in the modified target module-level environment to the user terminal.

[0261] S1104. Receive the target chip design code submitted by the user terminal based on the modified target module-level environment.

[0262] Based on the above explanation, it is understood that if the target defect still cannot be reproduced in the target module-level environment, then further modifications can be made to the target module-level environment. Of course, this application does not limit the number of modifications. Depending on the actual application scenario, it can be modified once or multiple times until the target defect can be reproduced in the modified target module-level environment, and the reproduction information of the target defect in the modified target module-level environment is sent to the user terminal.

[0263] Optionally, the specific details of the reproduction information of the target defect in the modified target module-level environment can be found in the first reproduction information mentioned above, and will not be repeated here.

[0264] For the designer of the target chip design code, the target chip design code can receive the reproduction information of the target defect in the modified target module-level environment sent by the server through the user terminal. Based on this, the designer can modify the target chip design code so that the modified target chip design code does not contain the target defect, and send the modified target chip design code to the server, thereby improving the development efficiency of the target chip design code.

[0265] By applying the embodiments of this application, when the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in the module-level environment, the verifier can be guided to modify the module-level environment to reproduce the target defect, and the analysis results of the target defect can be fed back to the user terminal. Then, the designer of the target chip design code can submit the modified target chip design code through the user terminal based on the analysis results. In this way, the efficiency of defect analysis and the development efficiency of chip design code can be improved.

[0266] Figure 16 This is a flowchart illustrating another defect analysis method provided in an embodiment of this application. Optionally, if the defect information corresponding to the target chip design code includes the stage at which the target defect was discovered, such as... Figure 16 As shown, the first process, based on the defect information corresponding to the target chip design code, includes:

[0267] S1201. Reproduce the target defect at the stage where the target defect was discovered, and send the stage where the target defect was discovered and the second relevant information on reproducing the target defect at the stage where the target defect was discovered to the user terminal.

[0268] The second relevant information for reproducing the target defect during the stage when the target defect is discovered can be found in the content of the first relevant information mentioned above, and will not be repeated here.

[0269] It is understandable that by reproducing the target defect at the stage where the target defect is discovered, the second relevant information of the target defect can be obtained, and then the stage where the target defect was discovered and the second relevant information of the target defect can be sent to the user terminal.

[0270] S1202: Receive the modified chip design stage code submitted by the user terminal for the target defect discovery stage and the second relevant information for reproducing the target defect in the target defect discovery stage.

[0271] In this process, the designer of the target chip design code can receive the stage at which the target defect has been discovered and the second relevant information of the target defect from the server through the user terminal. Based on this, the designer can modify the target chip design code so that the modified target chip design code does not contain the target defect, and send the modified target chip design code to the server, thereby improving the development efficiency of the target chip design code.

[0272] By applying the embodiments of this application, when the defect information corresponding to the target chip design code includes the stage of target defect discovery, the verifier can be guided to reproduce the target defect at the stage of target defect discovery and feed back the analysis results of the target defect to the user terminal. Then, the designer of the target chip design code can submit the modified target chip design code through the user terminal based on the analysis results. In this way, the efficiency of defect analysis and the development efficiency of chip design code can be improved.

[0273] Figure 17 This is a flowchart illustrating another defect analysis method provided in an embodiment of this application. Optionally, if the defect information corresponding to the target chip design code includes the number of times the target defect occurs, such as... Figure 17 As shown, the first process, based on the defect information corresponding to the target chip design code, includes:

[0274] S1301. If the number of times the target defect occurs exceeds the preset threshold, output a warning message.

[0275] The preset threshold is also the preset number of times threshold. Optionally, the preset threshold can be 3, 5, etc., which is not limited here and can vary depending on the actual application scenario.

[0276] Understandably, by statistically analyzing the frequency of a target defect's occurrence, its severity can be determined. If the frequency of a target defect exceeds a preset threshold, it indicates that the defect is frequently occurring during the chip design code process, and a warning message can be issued. Optionally, the warning message can be further sent to the user terminal via email or a webpage. This allows the chip design code designer or verifier to receive the warning message and focus on the target defect, preventing its recurrence in other chip design code and effectively improving chip design code development efficiency.

[0277] By applying the embodiments of this application, when it is determined that the number of times a target defect occurs is greater than a preset threshold, a warning message can be output, which makes it easier for chip design code designers or verifiers to focus on the target defect, thereby reducing the probability of the target defect occurring and improving the development efficiency of chip design code.

[0278] Figure 18 This is a functional module diagram of a project management device provided in an embodiment of this application. The project management device can be applied to a server, on which a project management system is deployed. The project management system includes a code management module and a defect management module. The code management module stores chip design code for at least one chip and the corresponding identification information of the chip design code during the logic design code verification process. The defect management module stores defect information corresponding to the chip design code. The basic principle and technical effects of this device are the same as those of the aforementioned corresponding method embodiments. For the sake of brevity, parts not mentioned in this embodiment can be referred to the corresponding content in the method embodiments.

[0279] like Figure 18 As shown, the project management device 200 includes:

[0280] The code management module 210 is used to obtain the logic design instructions submitted by the first designer through the user terminal, and in response to the logic design instructions, obtain the target chip design code, wherein the target chip design code is associated with target identification information;

[0281] The defect management module 220 is used to obtain defect information corresponding to the target chip design code based on the target identification information.

[0282] In an optional implementation, the defect information corresponding to the target chip design code includes at least one of the following: the target defect itself, the registration link corresponding to the target defect, the discovery level of the target defect, the reproduction information corresponding to the target defect, the number of times the target defect occurs, and the stage at which the target defect is discovered.

[0283] In an optional implementation, the target defect can be discovered at any of the following levels: module level, subsystem level, bare-metal system level, and operating system level.

[0284] In an optional implementation, the registration link of the target defect is used to characterize the link path of the target defect in the defect management module.

[0285] In an optional implementation, the reproduction information corresponding to the target defect is used to indicate whether the target defect is reproducible, and the corresponding reproduction level if the target defect is reproducible.

[0286] In an optional implementation, the stage at which the target defect is discovered is any one of the register translation level circuit code stage, netlist code stage, manual modification of integrated circuit code stage, and post-silicon code stage.

[0287] In an optional implementation, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced at the module level, and the target defect is caused by the module interface, the method further includes:

[0288] Send a first prompt message to the user terminal to instruct the first designer to check whether the subsystem-level design specifications have clearly described the interfaces between modules.

[0289] In an optional implementation, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced at the module level, and the target defect is caused by the module-level environment, the defect management module is also used to obtain the environment modification request for the target defect submitted by the user terminal, and the environment modification request is used to modify the module-level environment.

[0290] In response to environment modification requests, modify the module-level environment in the code management module so that the target defect can be reproduced based on the module-level environment.

[0291] In an optional implementation, the defect management module 220 is further configured to obtain verification requests for target defects submitted by the verifier through the user terminal;

[0292] In response to a verification request, reproduce the target defect in the preset tool based on the verification stimulus corresponding to any level.

[0293] In an optional implementation, the project management system further includes: a file management module for storing verification work and verification result documents corresponding to the target chip design code, wherein the verification result documents store historical verification results; and a defect management module 220, specifically used to respond to verification requests and obtain the verification work corresponding to the target chip design code from the file management module.

[0294] Based on the verification work, the target defect is reproduced in the preset tool according to the verification stimulus corresponding to any level to obtain the current verification result, and the historical verification result is updated in the file management module based on the current verification result;

[0295] The current verification results include the name of the verification stimulus, the function point, and the verification stimulus result when reproducing the target defect.

[0296] In an optional implementation, the file management module further stores design specification information corresponding to the chip design code of at least one chip; the file management module is used to send a second prompt message to the user terminal if the design specification information corresponding to the target chip design code is stored, the second prompt message being used to prompt the verifier to trigger a verification request for the target defect.

[0297] In an optional implementation, the file management module is further configured to send a third prompt message to the user terminal if the design specification information corresponding to the target chip design code is not stored. The third prompt message is used to prompt the first designer to upload the design specification information corresponding to the target chip design code to the file management module.

[0298] In an optional implementation, the project management system also includes an email management module, which is used to send defect information corresponding to the target chip design code to the user terminal to prompt the first designer or verifier to modify the target chip design code based on the defect information.

[0299] The above-described device is used to execute the project management method provided in the foregoing embodiments. Its implementation principle and technical effects are similar, and will not be described again here.

[0300] Figure 19 This is a functional module diagram of a defect analysis device provided in an embodiment of this application. The basic principle and technical effects of this device are the same as those of the corresponding method embodiments described above. For the sake of brevity, parts not mentioned in this embodiment can be referred to the corresponding content in the method embodiments. Figure 19 As shown, the defect analysis device 300 includes:

[0301] The acquisition module 310 is used to acquire defect information corresponding to the target chip design code; wherein, the defect information corresponding to the target chip design code includes at least one of the following: the discovery level of the target defect, the reproduction information of the target defect, the number of times the target defect occurs, and the stage at which the target defect is discovered;

[0302] The execution module 320 is used to perform the first processing based on the defect information corresponding to the target chip design code.

[0303] In an optional implementation, the target defect can be discovered at any of the following levels: module level, subsystem level, bare-metal system level, and operating system level.

[0304] In an optional implementation, the reproduction information corresponding to the target defect is used to indicate whether the target defect is reproducible, and the corresponding reproduction level if the target defect is reproducible.

[0305] In an optional implementation, the stage at which the target defect is discovered is any one of the register translation level circuit code stage, netlist code stage, manual modification of integrated circuit code stage, and post-silicon code stage.

[0306] In an optional implementation, the defect information corresponding to the target chip design code includes the target defect discovery level; the execution module 320 is specifically used to reproduce the target defect in the target defect discovery level, and send the target defect discovery level and the first relevant information of reproducing the target defect in the target defect discovery level to the user terminal.

[0307] Receive the target chip design code modified by the user terminal based on the reproduction level corresponding to the target defect and the first relevant information of the target defect.

[0308] In an optional implementation, the target chip design code contains multiple chip functional modules. Among two chip functional modules that have a dependency relationship, a module interface is set between one chip functional module and the other chip functional module. If the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module-level environment, module 320 is executed, which is specifically used to determine whether the module interface contained in the target chip design code meets the preset module interface requirements.

[0309] If it is determined that the module interface contained in the target chip design code does not meet the preset module interface requirements, the target defect is determined to be caused by the module interface, and it is determined whether the module interface has been clearly defined in the subsystem-level environment; among them, the subsystem-level environment has lower priority than the module-level environment.

[0310] In an optional implementation, if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module-level environment, module 320 is executed, specifically to determine whether the target defect can be reproduced in a target module-level environment; wherein, the target module-level environment is obtained by modifying the module-level environment;

[0311] If it is determined that the target defect cannot be reproduced in the target module-level environment, modify the target module-level environment until the target defect can be reproduced in the modified target module-level environment.

[0312] Send the reproduction information of the target defect in the modified target module-level environment to the user terminal;

[0313] Receive target chip design code submitted by the user terminal based on the modified target module-level environment.

[0314] In an optional implementation, the defect information corresponding to the target chip design code includes the stage at which the target defect was discovered; the execution module 320 is specifically used to reproduce the target defect at the stage at which the target defect was discovered, and to send the stage at which the target defect was discovered and the second relevant information on the reproduction of the target defect at the stage at which the target defect was discovered to the user terminal.

[0315] Receive modified chip design stage code submitted by the user terminal for the target defect discovery stage and the second relevant information for reproducing the target defect in the target defect discovery stage.

[0316] In an optional implementation, the defect information corresponding to the target chip design code includes the number of times the target defect occurs; the execution module 320 is specifically used to output warning information when the number of times the target defect occurs exceeds a preset threshold.

[0317] The above-described device is used to execute the defect analysis method provided in the foregoing embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0318] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0319] Figure 20 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. This electronic device can be integrated into a server. Figure 20 As shown, the electronic device may include a processor 510, a storage medium 520, and a bus 530. The storage medium 520 stores machine-readable instructions executable by the processor 510. When the electronic device is running, the processor 510 communicates with the storage medium 520 via the bus 530. The processor 510 executes the machine-readable instructions to perform the steps of the above-described project management method or defect analysis method embodiments. The specific implementation and technical effects are similar and will not be described in detail here.

[0320] Optionally, this application also provides a storage medium storing a computer program, which, when run by a processor, executes the steps of the above-described project management method or defect analysis method embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0321] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0322] The units described as separate components may or may not be physically separate. The 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0323] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0324] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0325] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0326] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need further definition and explanation in subsequent figures. The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A defect analysis method characterized by, The method is applied to a server, and the method comprises: obtaining defect information corresponding to target chip design code; wherein the defect information corresponding to the target chip design code comprises at least one of a discovery level of a target defect, reproduction information corresponding to the target defect, a number of times of occurrence of the target defect, and a stage at which the target defect is discovered; performing first processing based on the defect information corresponding to the target chip design code; the target chip design code comprises a plurality of chip function modules, and a module interface is arranged between one chip function module and another chip function module in two chip function modules having a dependency relationship; if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module level environment, the performing of the first processing based on the defect information corresponding to the target chip design code comprises: determining whether the module interface included in the target chip design code meets preset module interface requirements; in a case where it is determined that the module interface included in the target chip design code does not meet the preset module interface requirements, determining that the target defect is caused by the module interface, and determining whether the module interface has been clearly defined in a subsystem level environment; wherein the priority of the subsystem level environment is lower than that of the module level environment.

2. The defect analysis method according to claim 1, wherein The discovery level of the target defect is any one of a module level, a subsystem level, a bare machine system level, and an operating system level.

3. The defect analysis method according to claim 1, wherein The reproduction information corresponding to the target defect is used to indicate whether the target defect can be reproduced, and a reproduction level corresponding to the target defect if the target defect can be reproduced.

4. The defect analysis method according to claim 1, wherein The stage at which the target defect is discovered is any one of a register conversion level circuit code stage, a netlist code stage, a code stage of manually modifying an integrated circuit, and a post-silicon code stage.

5. The defect analysis method according to claim 1 or 2, characterized by, The defect information corresponding to the target chip design code comprises the discovery level of the target defect; the performing of the first processing based on the defect information corresponding to the target chip design code comprises: reproducing the target defect in the discovery level of the target defect, and sending the discovery level of the target defect and first related information of reproducing the target defect in the discovery level of the target defect to a user terminal; receiving target chip design code modified by the user terminal based on the reproduction level corresponding to the target defect and the first related information of the target defect.

6. The defect analysis method according to claim 1 or 3, characterized by, If the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module level environment, the performing of the first processing based on the defect information corresponding to the target chip design code comprises: determining whether the target defect can be reproduced in a target module level environment; wherein the target module level environment is obtained by modifying the module level environment; in a case where it is determined that the target defect cannot be reproduced in the target module level environment, modifying the target module level environment until the target defect can be reproduced in the modified target module level environment; sending reproduction information of the target defect in the modified target module level environment to a user terminal; receive target chip design code submitted by the user terminal based on the modified target module level environment.

7. The defect analysis method according to claim 1 or 4, characterized by, The defect information corresponding to the target chip design code includes a stage at which the target defect is found; and the first processing is performed based on the defect information corresponding to the target chip design code, including: reproducing the target defect at the stage at which the target defect is found, and sending the stage at which the target defect is found and second related information of reproducing the target defect at the stage at which the target defect is found to the user terminal; receive modified chip design stage code submitted by the user terminal for the stage at which the target defect is found and the second related information of reproducing the target defect at the stage at which the target defect is found.

8. The defect analysis method according to claim 1, characterized by, The defect information corresponding to the target chip design code includes a number of times of occurrence of the target defect; The first processing is performed based on the defect information corresponding to the target chip design code, including: in a case where the number of times of occurrence of the target defect is greater than a preset threshold, outputting a warning information.

9. A defect analysis apparatus characterized by comprising: The defect analysis apparatus is applied to a server, and includes: an obtaining module, configured to obtain defect information corresponding to target chip design code; wherein the defect information corresponding to the target chip design code includes at least one of a discovery level of a target defect, reproduction information corresponding to the target defect, a number of times of occurrence of the target defect, and a stage at which the target defect is found; an executing module, configured to perform first processing based on the defect information corresponding to the target chip design code; The target chip design code includes a plurality of chip function modules, and a module interface is arranged between one chip function module and another chip function module in two chip function modules having a dependency relationship; if the reproduction information corresponding to the target defect indicates that the target defect cannot be reproduced in a module level environment, the executing module is specifically configured to determine whether a module interface included in the target chip design code meets a preset module interface requirement; in a case where it is determined that the module interface included in the target chip design code does not meet the preset module interface requirement, it is determined that the target defect is caused by the module interface, and it is determined whether the module interface has been clearly defined in a subsystem level environment; wherein the priority of the subsystem level environment is lower than that of the module level environment.

10. A server, characterized by The server is configured to perform the defect analysis method according to any one of claims 1-8.

11. A computer readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is run by a processor to perform the defect analysis method according to any one of claims 1-8.

Images